H3C--MAC地址表故障处理手册
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
MAC地址表故障处理手册
目录
1-1
1 MAC地址表故障处理··························································································································
1-1
1.1 源MAC地址攻击导致端口流量瞬断故障处理·····················································································
··· 1-1
1.1.1 故障描述 ······························································································································
1.1.2 故障处理步骤··························································································································
1-1
······ 1-3
1.2 故障诊断命令·······························································································································
1 MAC地址表故障处理
1.1 源MAC地址攻击导致端口流量瞬断故障处理
1.1.1 故障描述
如图1-1所示,Switch下接DSLAM(Digital Subscriber Line Access Multiplexer,数字用户线接入复用器),Switch上接BAS(Broadband Access Server,宽带接入服务器),由BAS终结用户的拨号PPPoE报文。在Switch上配置灵活QinQ功能,对应的用户侧VLAN为824,网络侧VLAN为1003。
BAS上作为网关的MAC地址为0090-1aa0-d47a。
故障现象为:DSLAM下挂用户不定时大规模掉线。出现问题时,发现端口Ethernet3/0/4的流量急剧下降。大约5分钟左右,端口Ethernet3/0/4的流量开始慢慢回升,证明此时大规模掉线已经结束,DSLAM下挂用户又在逐步恢复连接,网络在逐步恢复正常状态。
图1-1源MAC地址攻击导致端口流量瞬断故障处理组网图
1.1.2 故障处理步骤
(1) 检查接口信息
执行display interface命令显示端口Ethernet3/0/4的相关信息:
Ethernet3/0/4 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 000f-e200-8048
Description: Ethernet3/0/4 Interface
Loopback is not set
Media type is twisted pair, port hardware type is 100_BASE_TX
100Mbps-speed mode, full-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 9022
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
Allow jumbo frame to pass
PVID: 100
Mdi type: auto
Port link-type: trunk
VLAN passing : 824
VLAN permitted: 824
Trunk port encapsulation: IEEE 802.1q
Port priority: 0
Last clearing of counters: Never
Peak value of input: 4 bytes/sec, at 2012-04-26 12:07:48
Peak value of output: 81 bytes/sec, at 2012-04-26 12:09:24
Last 300 seconds input: 1 packets/sec 147 bytes/sec
Last 300 seconds output: 1 packets/sec 179 bytes/sec
Input (total): 271 packets, 12250 bytes
0 unicasts, 150 broadcasts, 121 multicasts, 0 pauses
Input (normal): 271 packets, 12250 bytes
0 unicasts, 150 broadcasts, 121 multicasts, 0 pauses
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, - overruns, 0 aborts
- ignored, - parity errors
Output (total): 1522 packets, 183608303 bytes
0 unicasts, 13 broadcasts, 860 multicasts, 0 pauses
Output (normal): 1522 packets, - bytes
0 unicasts, 13 broadcasts, 860 multicasts, 0 pauses
Output: 0 output errors, - underruns, 1 buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, - no carrier
可以看到,端口在故障时只有组播和广播报文的记数。
(2) 原因分析
从现象上看,Switch的端口Ethernet3/0/4的入方向报文计数在故障时只有组播和广播报文,基本上可以确定:由于某种原因,导致从Switch的端口Ethernet3/0/4进来的单播报文被全部丢弃了。DSLAM下挂用户正常通信的流量以单播报文为主,这种丢弃行为导致用户下线,然后重新认证,所以端口流量大大减小。
因此从报文被丢弃的原因着手分析问题。这种报文丢弃特征和“源端口返回报文”丢弃很吻合,也就是说很可能端口收到了目的MAC地址和本端口学习到的目的MAC地址一致的报文。正常工作状态下,BAS的MAC地址(也就是从Switch的端口Ethernet3/0/4上来的PPPoE单播流量的目的MAC地址)只会学习到Switch的端口GigabitEthernet2/0/1上的VLAN 1003,不会学习到用户侧端口,除非网络中有环路或者其他原因。
下面是正常情况下Switch的MAC地址表信息:
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
0090-1aa0-d47a 1003 Learned GE2/0/1 AGING
0090-1aa0-d47a 1101 Learned GE2/0/1 AGING
0090-1aa0-d47a 1201 Learned GE2/0/1 AGING
0090-1aa0-d47a 4093 Learned GE2/0/1 AGING
再看看出故障时学习到Switch的端口Ethernet3/0/4的MAC地址: