附件下载
源MAC地址攻击导致端口流量瞬断故障处理.pdf(135.45 KB)
目 录
组网如图1-1所示，Switch下接DSLAM，上接BAS，由BAS终结用户的拨号PPPoE报文。在Switch上配置灵活QinQ功能，用户侧VLAN为824，网络侧VLAN为1003。BAS的网关MAC地址为0090-1AA0-D47A。
图1-1 源MAC地址攻击导致端口流量瞬断组网图
故障现象为：DSLAM下挂用户不定时大规模掉线。出现问题时，发现Ethernet3/0/4端口的流量急剧下降，从该端口进来的单播报文被全部丢弃。大约5分钟左右，Ethernet3/0/4端口的流量开始慢慢回升，证明此时大规模掉线已经结束，DSLAM下挂用户又在逐步恢复连接，网络在逐步恢复正常状态。
<Switch> display interface ethernet 3/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
Unknown-speed mode, unknown-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 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 //端口在故障时只有组播和广播报文的记数
150 broadcasts, 121 multicasts
Input (normal): 271 packets, 12250 bytes
150 broadcasts, 121 multicasts
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
13 broadcasts, 860 multicasts, 0 pauses
Output (normal): 1522 packets, - bytes
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
从现象上看，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（QinQ外层VLAN），不会学习到用户侧端口，除非网络中有环路或者其他原因。
下面是正常情况下Switch的MAC地址表信息：
<Switch> display mac-address
MAC ADDR VLAN ID STATE PORT INDEX AGING TIME(s)
0090-1aa0-d47a 1003 Learned GigabitEthernet2/0/1 AGING
0090-1aa0-d47a 1101 Learned GigabitEthernet2/0/1 AGING
0090-1aa0-d47a 1201 Learned GigabitEthernet2/0/1 AGING
0090-1aa0-d47a 4093 Learned GigabitEthernet2/0/1 AGING
再看看出故障时学习到Switch的Ethernet3/0/4端口的MAC地址：
0090-1aa0-d47a 824 Learned Ethernet3/0/4 AGING
这个MAC地址是BAS的MAC地址，却学习到了用户侧Switch的Ethernet3/0/4端口的VLAN 824。这时，从Switch的Ethernet3/0/4端口上来的PPPoE正常业务报文的目的MAC地址正是这个MAC地址，结果被作为源端口返回报文全部丢弃。
重新检视故障前后的定位信息，发现了这样的规律：大规模掉线时（端口大量丢包），BAS的MAC地址学习到了Switch的Ethernet3/0/4端口，而在业务流量逐渐恢复到正常的期间，这个MAC地址被老化掉了。
因为DSLAM和Switch是直连，中间没有其他交换机导致环路，网络拓扑一直处于稳定状态，因此可以得出结论：DSLAM下挂用户通过仿冒网关MAC地址的方法对Switch进行攻击，导致该DSLAM下面用户大规模掉线。从用户的攻击心理看，攻击大多数是为了获取更大的带宽，把其他用户踢下线，让网络系统重新来一次初始化，攻击者会明显感觉网速比以前要快了。
在Switch的上行口GigabitEthernet2/0/1配置一个用户侧VLAN 824的静态网关MAC地址，这样网关MAC地址就永远不会学习到Switch的Ethernet3/0/4端口了，攻击者仿冒MAC地址的攻击也就不起作用了，方法如下：
# 首先，把GigabitEthernet2/0/1端口加入到VLAN 824：
<Switch> system-view
[Switch] interface gigabitethernet 2/0/1
[Switch-GigabitEthernet2/0/1] port link-type trunk
[Switch-GigabitEthernet2/0/1] port trunk permit vlan 824
# 然后，在GigabitEthernet2/0/1端口的VLAN 824设置一个网关静态MAC地址：
[Switch-GigabitEthernet2/0/1] quit
[Switch] mac-address static 0090-1aa0-d47a interface gigabitethernet 2/0/1 vlan 824
配置了静态MAC地址后，DSLAM下挂的用户运行很稳定，再未出现掉线的情况。
& 说明：
在有多个上行口的情况下，在任意一个上行口配置该静态MAC地址即可。
在使能灵活QinQ的情况下，为了防止用户进行源MAC地址攻击，建议在设备的上行口配置网关的静态MAC地址。
Copyright ©2008 杭州华三通信技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
本文档中的信息可能变动，恕不另行通知。
源MAC地址攻击导致端口流量瞬断故障处理.pdf(135.45 KB)