鲁达 一、组网描述
某高校宿舍有线网采用大二层架构，利用QINQ技术使得接入交换机每个端口一个单独的VLAN，从而避免ARP、DHCP欺骗，广播风暴等。核心采用H3C SR8808-X作为BRAS设备，用来进行QINQ终结以及终端用户的PPPOE Server，实现终端用户的接入认证。
QINQ外层VLAN标签在RG S8610下联宿舍楼汇聚S5560的接口上启用，内层VLAN标签在接入交换机E528上。
二、问题描述
某日，从网管软件上收到217号宿舍楼汇聚和接入交换机丢包率高报警，经检查，发现网管软件的217号楼宿舍楼的设备丢包率达70%。
同时终端PC PPPOE拨号错误651。
三、处理过程
1.对网管软件的丢包告警进行验证；
PING 217号楼设备发现丢包率很高，远程登录设备发现操作特别卡顿，说明网管软件的丢包率告警并非软件误报。
2.通过网管软件发现其它宿舍楼宇的设备并未出现丢包率高报警，因此排除S8610到SR8808-X之间的物理线路和设备问题，同时仅该宿舍楼出现问题，怀疑是S8610的G2/8口有丢包，于是检查S8610的G2/8接口。发现接口下有错误包和丢包，但是数量不是很多，增长速度也不快；
3.尝试更换G2/8口下的单模光模块后，观察一段时间发现G2/8口未在出现错误包和丢包，收发光衰都在正在范围，同时网管软件上的217号楼丢包率高报警消除，拨号正常；
4.至此，以为出现丢包率高报警的原因是光模块导致。
5.过了大约一周的时间，网管软件再次发出217号楼设备丢包率高报警，按照之前同样的方法进行排查，发现S8610的G2/8接口并没有出现错误包和丢包情况。
6.回归拓扑图，考虑到217号楼设备的网关均在SR8808-X上，因此分段进行排查。先排查217号楼汇聚H3C S5560到SR8808-X路径上的丢包情况，经过测试发现SR8808-X到S8610并没有丢包，SR8610到S5560丢包严重。
7.因此怀疑丢包在S8610-----S5560两台设备和中间链路存在问题。于是在S8610上开启ACL计数判断丢包是否由设备本身造成。
在S8610上配置如下：其中172.16.204.44是217号楼汇聚S5560的管理地址，211.70.160.82是测试PC，可以认为是接在SR8808-X上；
ip access-list extended test
10 permit ip host 172.16.204.44
20 permit ip any any
ip access-list extended test1
10 permit ip host 172.16.204.44
20 permit ip any any
在分别在G2/8的IN方向，和AG6口的出方向丢用ACL，进行计数；
interface GigabitEthernet 2/8
switchport mode dot1q-tunnel
switchport dot1q-tunnel allowed vlan adduntagged 3608
switchport dot1q-tunnel native vlan 3608
medium-type fiber
ip access-group test in
spanning-tree bpdufilter enable
descriptionto_SS217_WiredNet_HuiJu_S5560_G1/0/28
interface AggregatePort 6
switchport mode uplink
switchport trunk allowed vlan remove1-3600,3615-4094
ip access-group test1 out
description to_SR8808-X(wirednet)
8.经过一段时间观察后，发现从G2/8口收到了1088421个数据包，但是从上联口仅转发出去1088362，少了59个包，并且随着时间的推移这个差值在增加。
9.对 S8610 设备的底层 buffer 计数，发现部分端口有丢包计数，摘取部分 log 如下：
DROP_PKT_CNT(3).cpu0[0xe200043]=0x49fd: <COUNT=0x49fd>
DROP_PKT_CNT(0).ge1[0xe21f040]=0x96: <COUNT=0x96>
DROP_PKT_CNT(0).ge2[0xe220040]=0x2c0: <COUNT=0x2c0>
DROP_PKT_CNT(0).ge3[0xe221040]=0xb21: <COUNT=0xb21>
DROP_PKT_CNT(0).ge7[0xe225040]=0x19b1:<COUNT=0x19b1>
10.经过与锐捷厂家确认后，目前S8610的两块千兆线卡的MAC芯片的buffer大小是3MB，当发送到某一个端口的瞬时流量超过千兆时，其端口就会丢包。当流量高峰期时，出现burst（突发）流量，是有可能因为buffer不足导致丢包的；
11.根据厂家的答复可能是设备硬件规格不够导致丢包，对此我是持怀疑态度的，主要有两方面原因：
1)客户现场有2块这种规格的千兆业务板卡，目前出现问题的只有其中一块，并且通过网管软件的监控，未出现问题的板卡流量一直要比出现问题的板卡流量大；
2)通过网管软件的监控，出现丢包的板卡单个千兆口最大高峰期流量200Mbps，并没有达到“瞬时流量超过千兆”
经过厂家的确定后，如果是硬件问题，只能新增业务板卡进行分流，没有其它好的解决方案。
12.过了大约2周后，丢包现象再次出现，利用ACL计数同样发现包丢在S8610上，但是经过检查，S8610底层上并没有丢包记录，也就是说这次丢包不是硬件buffer不足导致。
13.考虑到S8610仅根据MAC地址做二层转发，怀疑是不是有什么造成S8610上的MAC地址表学习错误导致转发失败。
14.因为终端和设备的网关均在SR8808-X上，而S8610作为二层设备，只是根据数据帧中的目的MAC地址（网关的MAC地址）转发，丢包有可能是数据帧中的目的MAC地址在S8610的MAC地址表中不存在表项或者对应的出接口不正确。基于此，想到通过二层ACL计数确定网关的MAC地址在S8610是通过正确上联口AG6口学习到。做了如下配置：
1)创建二层ACL，其中741f.4ac5.f802为网关的MAC地址
mac access-listextended 700
10 permit host 741f.4ac5.f802 any etype-any
20 permit any any etype-any
2)在所有接口下应用该ACL，上联口除外
mac access-group 700 in
3)开启对该ACL计数功能
mac access-list counter 700
15.果不其然，一段时间后发现ACL有计数，并且数量很多。正常情况下，网关的MAC地址不可能从下联口学习到，出现这种情况一般有两个原因：
1）有设备一直在模拟网关的MAC作为数据帧的源MAC在发送数据，导致S8610上MAC地址学习错误；
2）接口下联设备有环路；
16.为了定位在S8610的哪个接口学习到MAC地址，通过不停的在S8610上执行命令：
xq_stud_huiju_S8610#show mac-address-table address 741f.4ac5.f802
最终发现从G2/24口学习到MAC地址，这个接口也就是拓扑图上的连接217宿舍楼的接口，当时为了测试接口将G2/8调换到G2/24。
17.为了确认是何种类型的攻击，在S8610通过端口镜像将G2/24接口的IN方向的流量全部镜像到抓包电脑上，发现有大量的源MAC地址网关MAC的DHCP offer报文
18.怀疑有终端在伪造DHCP offer报文，于是利用DHCP报文中的“Client MAC address”字段中的MAC地址，该字段表示：请求通过DHCP获取IP地址的终端MAC地址。找到该终端。
最终定位到该MAC地址是从217号楼第2台接入交换机的G1/0/23口学习到，利用网络标签找到使用该终端的寝室和学生，是1台笔记本；
19.在笔记本上进行抓包，发现PC并没有发出大量的DHCP报文，通过安装杀毒软件进行检测也未发现可疑程序。但是E528的G1/0/23接口上的确学习到了网关的MAC地址，通过巡线、测线确定该接口就是连接这个寝室；
20.经过对该寝室其它终端进行排查，发现目前在用只有一台电脑，但是奇怪的是寝室用的TP-link 8口傻瓜交换机却有4个接口是亮灯的，排除该电脑使用一个接口，上联使用一个接口还多了2个UP的接口。
21.经过拔线测试，发现TP-link上3口拔掉线缆之后，5口也同时灭了，因此怀疑3口和5口是一根线，但是经过检查发现3口和5口是的确是2根独立的线缆。进一步测试，发现3口和5口只要有任何一个接口插上线缆，即使另外一个接口没有连接线缆，两个接口会同时UP和DOWN，怀疑TP-link傻瓜交换机内部环路。
22.为了最后确定原因，在E528上开启单端口环路检测，立即从G1/0/23口检测到环路。
23.至此可以确定，是由于TP-link 8口交换机内部自环导致，关闭该端口后，网管软件丢包率恢复正常，终端PC PPPOE拨号正常，问题消除。
四、解决方案
在所有接入设备上开启单端口环路检测
1) H3C、华为设备配置如下：
[SS210_1F_E_H3C E552]loopback-detection enable
[SS210_1F_E_H3C E552-GigabitEthernet1/0/1]loopback-detectionenable
2）锐捷设备配置如下：
xq_stud_huiju_S8610(config)#rldp enable
xq_stud_huiju_S8610(config-if-GigabitEthernet 1/1)#rldpport loop-detect block
五、总结
1.对于该种组网方式，利用QINQ已经实现每端口每VLAN，避免了设备之间的环路，广播风暴，ARP、DHCP等欺骗，但是无法避免接入交换机某个端口的环路；
2.利用单端口环路检测可以解决该问题，原理是：设备启用了单端口环路检测后，会从接口向外发送检测包，如果从该接口又收到了检测包，说明该接口下有环路。
H3C设备会根据配置对端口进行相应的处理：
1）block：将该端口阻塞，不进行数据转发，端口物理状态UP，同时设备日志中会有告警；
2）shutdown：将该端口关闭，不进行数据转发，端口物理状态down，同时设备日志中会有告警；
锐捷的设备会根据配置对端口进行如下处理：
1）block：将该端口阻塞，不进行数据转发，端口物理状态UP，同时设备日志中会有告警；
2）shutdown-port：将该端口关闭，不进行数据转发，端口物理状态down，同时设备日志中会有告警；
3）shutdown-svi：将该端口对应svi置于shutdown状态，同时设备日志中会有告警；
4）warning：设日志中仅发出告警，不做其它操作；
一般建议使用shutdown方式，这样排错时也比较容易，同时设备又不损耗资源。
3.强烈建议此种组网方式，必须要在接入设备上开启单端口环路检测功能；