本帖最后由 blakegao 于 2015-4-9 16:21 编辑 Catalyst 交换机维护若干类型的表，这些表经过调整，适用于第 2 层交换或多层交换 (MLS)，并且保存在非常快速的存储器中，以便可以并行比较帧或数据包内的许多字段。
· ARP —映射一个IP地址对MAC地址为了提供在第2层广播域内的IP通信。例如，主机 B 要向主机 A 发送信息，但在其 ARP 缓存中没有主机 A 的 MAC 地址。主机 B 生成一个广播消息发往广播域中的所有主机，以获取与主机 A 的 IP 地址关联的 MAC 地址。广播域中的所有主机都收到 ARP 请求，但只有主机 A 以其 MAC 地址作出响应。
· CAM —所有Catalyst交换机型号使用CAM表第二层交换。当帧到达交换机端口时，交换机了解到源 MAC 地址并将其记录在 CAM 表中。表中记录所到达的端口和相应的 VLAN，并附带一个时间戳。如果在交换机的一个端口上了解到的 MAC 地址已移至不同的端口，则为最新到达的端口记录该 MAC 地址和时间戳。然后，删除前一个条目。如果已在表中为正确的到达端口发现了 MAC 地址，则仅更新其时间戳。
· 三重内容可编址存储器—在多层交换机中，访问控制列表(ACL)在传统路由提供，例如匹配，过滤的所有进程或者控制特定的流量，在硬件方面实现。通过 TCAM，对表查找一次即可将数据包对照整个访问列表进行评估。大多数交换机都有多个 TCAM，以便可以同时评估入站和出站安全以及 Qos ACL，或将其完全与第 2 层或第 3 层转发决策并行进行。
排除与ARP 或 CAM 相关的问题
分布式交换过程中丢失动态 MAC 地址
在分布式交换，每Distributed Feature Card(DFC)对维护每自己的CAM表负责。这意味着每个 DFC 将了解到 MAC 地址并使其老化，具体取决于该特定条目的 CAM 老化和流量匹配。使用分布式交换的情况下，Supervisor 引擎经常会暂时收不到某个特定 MAC 地址的任何流量，因此该条目可能会到期。当前有可用两的机制保持CAM表一致区别引擎之间，例如DFC (在线路模块的存在)和策略特性卡(PFC) (在Supervisor模块的存在) ：
· Flood to Fabric (FF)
· MAC 通告 (MN)
当 MAC 地址条目在 PFC 上老化时，show mac-address address all 命令会显示保留此 MAC 地址的 DFC 或 PFC。
为了防止 DFC 或 PFC 上的某个条目老化，即使该 MAC 地址没有流量，仍要启用 MAC 地址同步。发出以下这些命令以启用同步：
!--- 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 中并不存在的条目。但是，模块有办法从使用以太网带外信道 (EOBC) 的其他设备中获取它。
注意： mac-address-table synchronize 命令将清除经过路由的 MAC 条目。要避免这种情况，请用 mac-address-table aging-time 0 routed-mac 全局配置命令禁止清除经过路由的MAC。
CEF 定期丢弃数据包
思科快速转发(CEF)是提供优越性能与其他交换技术比较的一种第3层IP交换技术，特别是在与动态流量模式的网络。CEF维护数据结构呼叫前转情报基地(FIB)和邻接表。FIB 表真实反映路由表中的信息，并用于做出转发决策。邻接表包含预先计算得出的下一跳设备的链路层报头。根据下一跳的接口，FIB 表中的条目映射到邻接表中的条目。如果邻接表中没有填充必要信息，则设备无法执行 CEF 交换数据包。
如果 CEF 定期丢弃数据包，并且间隔为正常操作的时间，那么这很可能是因为定期清除邻接表。这种情况是由 ARP 条目的老化造成的。在用所需的下一跳信息填充邻接表期间，不以 CEF 方式交换数据包。当默认情况下每四小时刷新一次 ARP 条目时，将 ARP 超时值配置得太小会造成 CEF 操作中断。
交换机从 CAM 表中过滤全零的 MAC 地址
交换机从 CAM 表中过滤源 MAC 地址为 00-00-00-00-00-00（这是无效的源 MAC）的帧。以下是发生这种情况时syslog 错误输出的示例：
%SYS-4-P2_WARN: 1/Filtering MAC address 00-00-00-00-00-00on port 2/48 from host table
这些消息传达信息，告诉您找到了源MAC 地址为 00-00-00-00-00-00 的帧，而交换机不会将其添加到CAM 表中。但是，交换机将会转发来自全零 MAC 地址的流量。
解决方法是找出生成源 MAC 地址为全零的帧的终端站。一般而言，以下这些设备之一会发出这样的帧：
· 数据流生成器，如 Spirent SmartBits
· 某种类型的服务器，如进行负载均衡的 IBM WebSphere 服务器
· 配置有误的路由器或终端站，例如发出全零广播的设备
· 有故障的 NIC
网络中每 5 分钟发生一次单播泛洪
LAN 交换机使用转发表（如第 2 层表和 CAM 表）按帧的 VLAN 编号和目标 MAC 地址将流量引向特定端口。当没有条目对应于帧在传入 VLAN 中的目标 MAC 地址时，向各自 VLAN 内的所有转发端口发送该（单播）帧。这样即导致了泛洪。泛洪的确切原因是交换机的第 2 层转发表中没有数据包的目标 MAC 地址。在这种情况下，将从数据包所在 VLAN 中的所有转发端口（收到该数据包的端口除外）向外泛洪该数据包。
默认的 ARP 表老化时间为 4 小时，而 CAM 对于条目只保留 5 分钟。当目标 MAC 地址因老化离开 CAM 表时，交换机向各自 VLAN 内的所有转发端口发出一个帧。CAM老化计时器需要大于或等于ARP 超时以防止单播泛洪。作为解决方法，可以发出以下这些命令之一，以增加故障 VLAN 的 CAM 老化计时器，从而匹配 ARP 老化时间：
注意：在运行热备份路由协议(HSRP)的所有Catalyst环境，推荐您保证CAM和ARP定时器同步。
混合 CatOS 中有 ARP 问题
在混合模式， Supervisor引擎运行CatOS，并且多层交换机特性卡(MSFC)运行Cisco IOS。CatOS 运行在第 2 层，并建立 CAM 地址表以保留 VLAN、MAC 地址和端口号信息。MSFC 中的 Cisco IOS 运行在第 3 层，并建立 ARP 表以保留 IP 地址到 MAC 地址的解析。当更改任意设备（如打印机或服务器）的 IP 地址时，可能无法 Ping 通该新 IP 地址。但是，可以从相同的 VLAN Ping 通新的 IP 地址。这可能是 MSFC 上的一个 ARP 问题。
下面这个解决方法可以帮助分离并解决问题：
1. 清除 MSFC 上的 ARP 表。
2. MSFC2#clear arp int vlan 40
3. 验证 ARP 超时值。默认值为 4 小时。如果 VLAN 中的 ARP 超时太长，可以将超时值设置回默认值或最佳值。
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 表期间发生 EARL-2-EARL4LOOKUPRAMERROR 错误
以下是遇到此问题时 syslog 错误输出的示例：
%EARL-2-EARL4LOOKUPRAMERROR:Address eac6, data0-0-8000-0, count 8
当执行 CAM 表查找时，就会显示此消息。当访问存储器时因奇偶校验错误会发生这种情况。当发出
show cam 命令以访问 CAM 表时，通常会产生此错误。在某些情况下，当发出
show cam 命令时交换机也会重置。
%EARL-2-EARLLOOKUPRAMERROR: Address [hex], data[hex]-[hex]-[hex]-[hex], count [dec]
此错误消息表明已检测到查找RAM 奇偶校验错误。address [hex] 字段是转发表中检测到错误的地址。data[hex]-[hex]-[hex]-[hex] 字段是产生了奇偶校验错误的 RAM 数据的 word0、word1、word2 和 word3。count [dec] 字段是奇偶校验错误的总数。
此消息不是灾难性的，并且如果它只是间断地出现几次，则可能也不会导致中断情况。如果连续不断地收到此消息，则表明交换机在向 CAM 表添加新条目时所尝试写入的 DRAM 扇区有故障。因此需要更换 DRAM 或 Supervisor 本身。
Supervisor 切换之后丢失静态 CAM 条目
快速切换之后丢失在活动的 Supervisor 引擎上配置的静态 CAM 条目。作为此问题的一个解决方法，必须在快速切换之后重新配置 CAM 条目。
%ACL-5-TCAMFULL:acl engine TCAM table is full
如果TCAM是全双工和您尝试添加新建的ACL或者访问控制条目(ACE)对存在的ACL，进行或地图进程发生故障。先前的任何配置仍有效。一旦路由器访问控制列表(RACL)， ACL在多层交换机特性卡(MSFC)的软件方面被强制执行与对应的影响性能。
在运行混合软件的交换机上，如果所配置的虚拟局域网访问控制列表 (VACL) 或 Qos ACL ACE 超出 TCAM 的模式或掩码容量，则向控制台输出类似于此的 syslog 消息：
%ACL-5-TCAMFULL: acl engine TCAM table is full
在 Supervisor IOS 系统上，或在混合系统中的 MSFC 上，如果所配置的 RACL ACE 超出 TCAM 的容量，则向控制台输出类似于此的syslog 消息：
%FM-4-TCAM_ENTRY: Hardware TCAM entry capacityexceeded
在 Supervisor IOS 系统上，或在混合系统中的 MSFC 上，发出 show fm summary 命令以查看哪些接口以硬件实施ACL (ACTIVE)，以及哪些接口以软件实施 ACL (INACTIVE)。
此问题的解决方法是从交换机配置中删除不使用的 ACL 或 Qos。
Catalyst 6500 系列交换机中 MSFC 不响应 ARP 请求时发生 Ping 问题
当 Ping VLAN 接口时，向默认路由器 (MSFC) 发送源 IP 位于该 VLAN 的 ARP 请求，但路由器不响应该 ARP 请求，并且 debug ARP 显示此错误消息：
IP ARP req filtered src [ip-address][mac-address] dst [ip-address]
[mac-address] wrong cable, interface-id
对于每个 ARP 数据报，如果目标 IP 地址与本地主机地址不匹配，则丢弃ARP 应答。如果源 IP 地址不在相同的子网内，则丢弃ARP 请求。应由配置参数忽略此测试，以支持同一电缆上共存多个子网的罕见情况。
只有在从本地主机可访问目标协议 IP地址（这一点由路由算法决定）并且下一跳不通过相同接口时，才会生成 ARP 应答。如果本地主机充当网关，则可能导致对不在相同子网内的目标进行 ARP 应答。这表明丢弃 ARP 请求是合理的。
通过使 Catalyst 6500 不对所有 ARP 请求都做出响应可解决此问题，因为ARP 请求中的源 IP地址与 ARP 中的目标 IP 地址在不同的子网上。因此，MSFC/Router得出 ARP 不在同一个第 2 层域的结论，并显示电缆类型错误。换句话说，当 ARP 源和目标不属于同一个第 2 层域时，就会生成电缆错误的调试消息。要使 ARP 在这种场景下正常工作，作为一种解决方法，必须可使用静态路由访问目标协议 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 环境中存在两种第 2 层转发查找引擎。在 dCEF 环境中，FE1 和 FE2 经常会在 CEF720/dCEF720 体系结构线路卡上的同一个端口上了解到相同的 MAC 地址。
无法访问 Microsoft 负载均衡所使用的虚拟 IP 地址
Cisco 路由器要求每个虚拟 IP 地址都有一个 ARP（地址解析协议）条目。而网络负载均衡使用第 2 层多播传递数据包。在 Cisco 所实现的 RFC 中，多播仅用于 IP 多播。因此，当路由器未发现多播 IP 地址时，它不会自动创建 ARP 条目，而是必须由您手工向路由器添加此类条目。
通常，如果通过单播 IP 地址（群集的虚拟地址）解析得到多播MAC 地址（群集虚拟 MAC 地址），则 Cisco 设备不会在 ARP 表中放置后者。要解决此问题，需要将单播虚拟 IP 地址静态映射到多播 MAC 地址。
