Catalyst 交換機維護若干類型的表,這些表經(jīng)過調(diào)整,適用于第 2 層交換或多層交換 (MLS),并且保存在非??焖俚拇鎯ζ髦校员憧梢圆⑿斜容^幀或數(shù)據(jù)包內(nèi)的許多字段。
· ARP —映射一個IP地址對MAC地址為了提供在第2層廣播域內(nèi)的IP通信。例如,主機 B 要向主機 A 發(fā)送信息,但在其 ARP 緩存中沒有主機 A 的 MAC 地址。主機 B 生成一個廣播消息發(fā)往廣播域中的所有主機,以獲取與主機 A 的 IP 地址關(guān)聯(lián)的 MAC 地址。廣播域中的所有主機都收到 ARP 請求,但只有主機 A 以其 MAC 地址作出響應(yīng)。
· CAM —所有Catalyst交換機型號使用CAM表第二層交換。當(dāng)幀到達(dá)交換機端口時,交換機了解到源 MAC 地址并將其記錄在 CAM 表中。表中記錄所到達(dá)的端口和相應(yīng)的 VLAN,并附帶一個時間戳。如果在交換機的一個端口上了解到的 MAC 地址已移至不同的端口,則為最新到達(dá)的端口記錄該 MAC 地址和時間戳。然后,刪除前一個條目。如果已在表中為正確的到達(dá)端口發(fā)現(xiàn)了 MAC 地址,則僅更新其時間戳。
· 三重內(nèi)容可編址存儲器—在多層交換機中,訪問控制列表(ACL)在傳統(tǒng)路由提供,例如匹配,過濾的所有進程或者控制特定的流量,在硬件方面實現(xiàn)。通過 TCAM,對表查找一次即可將數(shù)據(jù)包對照整個訪問列表進行評估。大多數(shù)交換機都有多個 TCAM,以便可以同時評估入站和出站安全以及 Qos ACL,或?qū)⑵渫耆c第 2 層或第 3 層轉(zhuǎn)發(fā)決策并行進行。
排除與ARP 或 CAM 相關(guān)的問題
分布式交換過程中丟失動態(tài) MAC 地址
在分布式交換,每Distributed Feature Card(DFC)對維護每自己的CAM表負(fù)責(zé)。這意味著每個 DFC 將了解到 MAC 地址并使其老化,具體取決于該特定條目的 CAM 老化和流量匹配。使用分布式交換的情況下,Supervisor 引擎經(jīng)常會暫時收不到某個特定 MAC 地址的任何流量,因此該條目可能會到期。當(dāng)前有可用兩的機制保持CAM表一致區(qū)別引擎之間,例如DFC (在線路模塊的存在)和策略特性卡(PFC) (在Supervisor模塊的存在) :
· Flood to Fabric (FF)
· MAC 通告 (MN)
當(dāng) MAC 地址條目在 PFC 上老化時,show mac-address address
為了防止 DFC 或 PFC 上的某個條目老化,即使該 MAC 地址沒有流量,仍要啟用 MAC 地址同步。發(fā)出以下這些命令以啟用同步:
!--- This is a global configuration command andis used to enable the synchronization.
Cat6K-IOS(config)#mac-address-tablesynchronize
!--- This is a privileged EXEC command and isused to clear dynamic MAC addresses.
Cat6K-IOS#clear mac-address-table dynamic
mac-address-table同步命令從Cisco IOS軟件版本12.2(18)SXE4是可得到和以后。啟用它之后,您有可能仍會看到在 PFC 或 DFC 中并不存在的條目。但是,模塊有辦法從使用以太網(wǎng)帶外信道 (EOBC) 的其他設(shè)備中獲取它。
注意: mac-address-table synchronize 命令將清除經(jīng)過路由的 MAC 條目。要避免這種情況,請用 mac-address-table aging-time 0 routed-mac 全局配置命令禁止清除經(jīng)過路由的MAC。
CEF 定期丟棄數(shù)據(jù)包
思科快速轉(zhuǎn)發(fā)(CEF)是提供優(yōu)越性能與其他交換技術(shù)比較的一種第3層IP交換技術(shù),特別是在與動態(tài)流量模式的網(wǎng)絡(luò)。CEF維護數(shù)據(jù)結(jié)構(gòu)呼叫前轉(zhuǎn)情報基地(FIB)和鄰接表。FIB 表真實反映路由表中的信息,并用于做出轉(zhuǎn)發(fā)決策。鄰接表包含預(yù)先計算得出的下一跳設(shè)備的鏈路層報頭。根據(jù)下一跳的接口,F(xiàn)IB 表中的條目映射到鄰接表中的條目。如果鄰接表中沒有填充必要信息,則設(shè)備無法執(zhí)行 CEF 交換數(shù)據(jù)包。
如果 CEF 定期丟棄數(shù)據(jù)包,并且間隔為正常操作的時間,那么這很可能是因為定期清除鄰接表。這種情況是由 ARP 條目的老化造成的。在用所需的下一跳信息填充鄰接表期間,不以 CEF 方式交換數(shù)據(jù)包。當(dāng)默認(rèn)情況下每四小時刷新一次 ARP 條目時,將 ARP 超時值配置得太小會造成 CEF 操作中斷。
交換機從 CAM 表中過濾全零的 MAC 地址
交換機從 CAM 表中過濾源 MAC 地址為 00-00-00-00-00-00(這是無效的源 MAC)的幀。以下是發(fā)生這種情況時syslog 錯誤輸出的示例:
%SYS-4-P2_WARN: 1/Filtering MAC address 00-00-00-00-00-00on port 2/48 from host table
這些消息傳達(dá)信息,告訴您找到了源MAC 地址為 00-00-00-00-00-00 的幀,而交換機不會將其添加到CAM 表中。但是,交換機將會轉(zhuǎn)發(fā)來自全零 MAC 地址的流量。
解決方法是找出生成源 MAC 地址為全零的幀的終端站。一般而言,以下這些設(shè)備之一會發(fā)出這樣的幀:
· 數(shù)據(jù)流生成器,如 Spirent SmartBits
· 某種類型的服務(wù)器,如進行負(fù)載均衡的 IBM WebSphere 服務(wù)器
· 配置有誤的路由器或終端站,例如發(fā)出全零廣播的設(shè)備
· 有故障的 NIC
網(wǎng)絡(luò)中每 5 分鐘發(fā)生一次單播泛洪
LAN 交換機使用轉(zhuǎn)發(fā)表(如第 2 層表和 CAM 表)按幀的 VLAN 編號和目標(biāo) MAC 地址將流量引向特定端口。當(dāng)沒有條目對應(yīng)于幀在傳入 VLAN 中的目標(biāo) MAC 地址時,向各自 VLAN 內(nèi)的所有轉(zhuǎn)發(fā)端口發(fā)送該(單播)幀。這樣即導(dǎo)致了泛洪。泛洪的確切原因是交換機的第 2 層轉(zhuǎn)發(fā)表中沒有數(shù)據(jù)包的目標(biāo) MAC 地址。在這種情況下,將從數(shù)據(jù)包所在 VLAN 中的所有轉(zhuǎn)發(fā)端口(收到該數(shù)據(jù)包的端口除外)向外泛洪該數(shù)據(jù)包。
默認(rèn)的 ARP 表老化時間為 4 小時,而 CAM 對于條目只保留 5 分鐘。當(dāng)目標(biāo) MAC 地址因老化離開 CAM 表時,交換機向各自 VLAN 內(nèi)的所有轉(zhuǎn)發(fā)端口發(fā)出一個幀。CAM老化計時器需要大于或等于ARP 超時以防止單播泛洪。作為解決方法,可以發(fā)出以下這些命令之一,以增加故障 VLAN 的 CAM 老化計時器,從而匹配 ARP 老化時間:
· 對于 CatOS,發(fā)出 set cam agingtime 命令。
· 對于 Cisco IOS 軟件,發(fā)出 mac-address-table aging-time 命令。
注意:在運行熱備份路由協(xié)議(HSRP)的所有Catalyst環(huán)境,推薦您保證CAM和ARP定時器同步。
混合 CatOS 中有 ARP 問題
在混合模式, Supervisor引擎運行CatOS,并且多層交換機特性卡(MSFC)運行Cisco IOS。CatOS 運行在第 2 層,并建立 CAM 地址表以保留 VLAN、MAC 地址和端口號信息。MSFC 中的 Cisco IOS 運行在第 3 層,并建立 ARP 表以保留 IP 地址到 MAC 地址的解析。當(dāng)更改任意設(shè)備(如打印機或服務(wù)器)的 IP 地址時,可能無法 Ping 通該新 IP 地址。但是,可以從相同的 VLAN Ping 通新的 IP 地址。這可能是 MSFC 上的一個 ARP 問題。
下面這個解決方法可以幫助分離并解決問題:
1. 清除 MSFC 上的 ARP 表。
2. MSFC2#clear arp int vlan 40
3. 驗證 ARP 超時值。默認(rèn)值為 4 小時。如果 VLAN 中的 ARP 超時太長,可以將超時值設(shè)置回默認(rèn)值或最佳值。
4. MSFC2#show int vlan 40
5. Vlan40 is up, line protocol is up
6. Hardware is Cat6k RPVirtual Ethernet, address is 00d0.0050.33fc (bia 00d0.005
7. 0.33fc)
8. Internet address is40.40.40.3/24
9. MTU 1500 bytes, BW 1000000Kbit, DLY 10 usec,
10. reliability 255/255,txload 1/255, rxload 1/255
11. Encapsulation ARPA,loopback not set
12. Keepalive not supported
13. ARP type: ARPA, ARPTimeout 04:00:00
14. Last input 00:00:00,output 00:01:44, output hang never
15. Last clearing of"show interface" counters never
Inputqueue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
MSFC2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MSFC2(config)#int vlan 40
MSFC2(config-if)#arp timeout ?
<0-2147483> Seconds
MSFC2(config-if)#arp timeout 240
16. 重新啟動 MSFC。
17. MSFC2#write memory
18. Building configuration...
19. [OK]
20. MSFC2#reload
21. Proceed with reload? [confirm]
Supervisor> (enable)
在查找 CAM 表期間發(fā)生 EARL-2-EARL4LOOKUPRAMERROR 錯誤
以下是遇到此問題時 syslog 錯誤輸出的示例:
%EARL-2-EARL4LOOKUPRAMERROR:Address eac6, data0-0-8000-0, count 8
當(dāng)執(zhí)行 CAM 表查找時,就會顯示此消息。當(dāng)訪問存儲器時因奇偶校驗錯誤會發(fā)生這種情況。當(dāng)發(fā)出 show cam 命令以訪問 CAM 表時,通常會產(chǎn)生此錯誤。在某些情況下,當(dāng)發(fā)出 show cam 命令時交換機也會重置。
%EARL-2-EARLLOOKUPRAMERROR: Address [hex], data[hex]-[hex]-[hex]-[hex], count [dec]
此錯誤消息表明已檢測到查找RAM 奇偶校驗錯誤。address [hex] 字段是轉(zhuǎn)發(fā)表中檢測到錯誤的地址。data[hex]-[hex]-[hex]-[hex] 字段是產(chǎn)生了奇偶校驗錯誤的 RAM 數(shù)據(jù)的 word0、word1、word2 和 word3。count [dec] 字段是奇偶校驗錯誤的總數(shù)。
此消息不是災(zāi)難性的,并且如果它只是間斷地出現(xiàn)幾次,則可能也不會導(dǎo)致中斷情況。如果連續(xù)不斷地收到此消息,則表明交換機在向 CAM 表添加新條目時所嘗試寫入的 DRAM 扇區(qū)有故障。因此需要更換 DRAM 或 Supervisor 本身。
Supervisor 切換之后丟失靜態(tài) CAM 條目
快速切換之后丟失在活動的 Supervisor 引擎上配置的靜態(tài) CAM 條目。作為此問題的一個解決方法,必須在快速切換之后重新配置 CAM 條目。
%ACL-5-TCAMFULL:acl engine TCAM table is full
如果TCAM是全雙工和您嘗試添加新建的ACL或者訪問控制條目(ACE)對存在的ACL,進行或地圖進程發(fā)生故障。先前的任何配置仍有效。一旦路由器訪問控制列表(RACL), ACL在多層交換機特性卡(MSFC)的軟件方面被強制執(zhí)行與對應(yīng)的影響性能。
在運行混合軟件的交換機上,如果所配置的虛擬局域網(wǎng)訪問控制列表 (VACL) 或 Qos ACL ACE 超出 TCAM 的模式或掩碼容量,則向控制臺輸出類似于此的 syslog 消息:
%ACL-5-TCAMFULL: acl engine TCAM table is full
在 Supervisor IOS 系統(tǒng)上,或在混合系統(tǒng)中的 MSFC 上,如果所配置的 RACL ACE 超出 TCAM 的容量,則向控制臺輸出類似于此的syslog 消息:
%FM-4-TCAM_ENTRY: Hardware TCAM entry capacityexceeded
在 Supervisor IOS 系統(tǒng)上,或在混合系統(tǒng)中的 MSFC 上,發(fā)出 show fm summary 命令以查看哪些接口以硬件實施ACL (ACTIVE),以及哪些接口以軟件實施 ACL (INACTIVE)。
此問題的解決方法是從交換機配置中刪除不使用的 ACL 或 Qos。
Catalyst 6500 系列交換機中 MSFC 不響應(yīng) ARP 請求時發(fā)生 Ping 問題
當(dāng) Ping VLAN 接口時,向默認(rèn)路由器 (MSFC) 發(fā)送源 IP 位于該 VLAN 的 ARP 請求,但路由器不響應(yīng)該 ARP 請求,并且 debug ARP 顯示此錯誤消息:
IP ARP req filtered src [ip-address][mac-address] dst [ip-address]
[mac-address] wrong cable, interface-id
對于每個 ARP 數(shù)據(jù)報,如果目標(biāo) IP 地址與本地主機地址不匹配,則丟棄ARP 應(yīng)答。如果源 IP 地址不在相同的子網(wǎng)內(nèi),則丟棄ARP 請求。應(yīng)由配置參數(shù)忽略此測試,以支持同一電纜上共存多個子網(wǎng)的罕見情況。
只有在從本地主機可訪問目標(biāo)協(xié)議 IP地址(這一點由路由算法決定)并且下一跳不通過相同接口時,才會生成 ARP 應(yīng)答。如果本地主機充當(dāng)網(wǎng)關(guān),則可能導(dǎo)致對不在相同子網(wǎng)內(nèi)的目標(biāo)進行 ARP 應(yīng)答。這表明丟棄 ARP 請求是合理的。
通過使 Catalyst 6500 不對所有 ARP 請求都做出響應(yīng)可解決此問題,因為ARP 請求中的源 IP地址與 ARP 中的目標(biāo) IP 地址在不同的子網(wǎng)上。因此,MSFC/Router得出 ARP 不在同一個第 2 層域的結(jié)論,并顯示電纜類型錯誤。換句話說,當(dāng) ARP 源和目標(biāo)不屬于同一個第 2 層域時,就會生成電纜錯誤的調(diào)試消息。要使 ARP 在這種場景下正常工作,作為一種解決方法,必須可使用靜態(tài)路由訪問目標(biāo)協(xié)議 IP。
MAC 地址表中有多個條目
MAC 地址表中對于 MAC 地址顯示兩個條目。
Cat6K#show mac-address-table int gi 6/11
Displaying entries from Line card 6:
Legend: * - primary entry
age - seconds since last seen
n/a - not available
vlan mac address type learn age ports
------+----------------+--------+-----+----------+--------------------------
[FE 1]:
* 100 0011.857c.4d10 dynamic Yes 0 Gi6/11
[FE 2]:
* 100 0011.857c.4d10 dynamic Yes 95 Gi6/11
Cat6K#show module 6
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------------------------- -----------
6 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SADxxxxxxxx
Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------------------ ------------ -------
6 001d.45fd.xx4a to 001d.45fd.xx79 2.6 12.2(14r)S5 12.2(18)SXF8 Ok
Mod Sub-Module Model Serial Hw Status
---- --------------------------------------------- ----------- ------- -------
6 Distributed Forwarding CardWS-F6700-DFC3B SALxxxxxxxx 4.6 Ok
Mod Online Diag Status
---- -------------------
6 Pass
DFC 環(huán)境中存在兩種第 2 層轉(zhuǎn)發(fā)查找引擎。在 dCEF 環(huán)境中,F(xiàn)E1 和 FE2 經(jīng)常會在 CEF720/dCEF720 體系結(jié)構(gòu)線路卡上的同一個端口上了解到相同的 MAC 地址。
無法訪問 Microsoft 負(fù)載均衡所使用的虛擬 IP 地址
Cisco 路由器要求每個虛擬 IP 地址都有一個 ARP(地址解析協(xié)議)條目。而網(wǎng)絡(luò)負(fù)載均衡使用第 2 層多播傳遞數(shù)據(jù)包。在 Cisco 所實現(xiàn)的 RFC 中,多播僅用于 IP 多播。因此,當(dāng)路由器未發(fā)現(xiàn)多播 IP 地址時,它不會自動創(chuàng)建 ARP 條目,而是必須由您手工向路由器添加此類條目。
通常,如果通過單播 IP 地址(群集的虛擬地址)解析得到多播MAC 地址(群集虛擬 MAC 地址),則 Cisco 設(shè)備不會在 ARP 表中放置后者。要解決此問題,需要將單播虛擬 IP 地址靜態(tài)映射到多播 MAC 地址。
- 北京炫億時代專業(yè)服務(wù)器運輸,機房搬遷包裝以及倉儲托
- 思科CISCO無線AP 啟動加載不了ios
- 【云爍俱樂部分享會】第十二期 某游戲開發(fā)公司內(nèi)部網(wǎng)
- 【云爍俱樂部分享會】第十一期 某政府網(wǎng)絡(luò)安全架構(gòu)方
- 【云爍俱樂部分享會】第九期 中小企業(yè)網(wǎng)絡(luò)搭建思路分
- 【云爍俱樂部分享會】第八期 某倉庫無線覆蓋項目分享
- 【云爍俱樂部分享會】第七期 工程師網(wǎng)絡(luò)設(shè)備實操理論
- 【云爍俱樂部分享會】第六期 工程師百度無線覆蓋項目
- 【云爍俱樂部分享會】第五期 工程師項目分享會
- 【云爍俱樂部分享會】第四期 工程師項目分享會
熱門文章
- 北京機房搬遷改造公司,系統(tǒng)集成有哪些公司?-2019-11-04
- 如何打造一個安全的網(wǎng)絡(luò)環(huán)境?政府要做到這四點-2019-11-04
- 北京辦公室網(wǎng)絡(luò)布線,綜合布線施工價格-2019-11-04
- 深信服產(chǎn)品專業(yè)上網(wǎng)行為管理,安全設(shè)備有保障-2019-11-04
- 兩年內(nèi)網(wǎng)絡(luò)安全市場規(guī)模將達(dá)千億級別?來看看詳細(xì)分析-2019-11-04
- 北京炫億時代專業(yè)機房設(shè)備除塵,機房網(wǎng)絡(luò)改造-2019-11-04
- 企業(yè)如何保障移動辦公的安全性?移動辦公存在的七大安-2019-11-01
- 北京深信服AC-1000-A400產(chǎn)品租賃購買,專業(yè)IT上網(wǎng)行為管理-2019-11-01
- 互聯(lián)網(wǎng)企業(yè)軟件開發(fā)如何才能沒有漏洞?專業(yè)工程師給出-2019-11-01
- 如何避免APP的“越權(quán)”行為?要靠制定相關(guān)法律法規(guī)-2019-11-01