汇聚交换S75E VRRP组中,连接在VRRP主的ip电话设备运行正常,但是运行在VRRP备机S75E下的ip电话经常不通,不固定时间又能通,但是通后不久又不通。发现shutdown或者调整vrrp备机和10500的互联端口ospf cost值(调大),能解决ip电话不通问题。
同时还有一个故障现象是在VRRP的备机上始终无法ping 通其直接互联的话机,将话机更换为普通的pc不存在无法ping通的问题。
不涉及
通过收集到的信息分析,备机无法ping通ip phone,但是主机ping正常。同时shut down备机与10500的互联端口正常,因此根据我们对vrrp的转发了解,问题的目标根源很可能是备机上无法学习到ip phone的arp导致。
因此我们需要进一步分析为何备机无法学习到ip phone的arp。
第一步:直接在备机下抓设备与ip phone的报文,发现每次ping的时候,75E备机发出了正常的arp请求,ip phone也回应了正常的arp单播应答,报文正常。但是备用75E上的确没有学习到该arp,而主机75E上却能学习到该arp。貌似说明备机工作有问题,测试备机上多个单板,故障现象一样。
第二步:使用pc机进行测试,却一切正常,貌似问题只有是备机和ip phone配合才有问题。
第三步:打开rxtx的收发报文和平台eth报文,发现rxtx收到ip phone的arp应答报文,但是eth层看不到该报文。说明驱动丢失了该报文。
第四步:分析驱动收到的报文我们发现:
*Apr 30 03:00:43:056 2015 H3C RXTX/7/pkt: -Slot=2; drv_rxtx_rx():unit=0, port=22,pvlan=15,cos=3,reason=0x1000,length=64,sMod=8,sPort=22,dMod=0,dPort=0,opcode=1,rxMatched=30, ctag=0, rx_untagged=2, flags=0x0, hghdr: fb 80 a0 0f 41 16 05 00 00 00 00 00 00 00 00 00
*Apr 30 03:00:43:056 2015 H3C RXTX/7/pkt: -Slot=2;
From board 2: received packet from chip0,port22,reason=0x1000,cos=3,s
Mod=8,sPort=22,len=64, Matched=30,time is 0
*Apr 30 03:00:43:057 2015 H3C RXTX/7/pkt: -Slot=2;
-----------------------------------------------------
0000 70 ba ef 96 e9 f6 00 1b 4f 2f da d4 81 00 a0 00
0010 08 06 00 01 08 00 06 04 00 02 00 1b 4f 2f da d4
0020 0b cf 4b 90 70 ba ef 96 e9 f6 0b cf 4b f1 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-----------------------------------------------------
上述红色字体的解释如下:
Ctag=0说明75E收到的报文没有ctag;
rx_untagged=2 说明收到的报文带一层tag信息
根据打印出来的具体报文内容(81 00 a0 00)显示报文上cpu后带有tag信息,但是vlan=0,非法报文,因此该报文备丢弃。设备不学习该arp报文,这里貌似问题已经定位。但是还有很多匪夷所思的故障现象无法完全解释。
第五步:确认iphone到底是否发出了带tag的报文,我们做端口流量镜像测试,发现:
(1)75E发出的报文带tag=15的信息(连接ip phone的端口为access vlan 15),说明pc能抓tag的报文
(2)从抓取的报文看,ip phone 发出的arp报文不带tag信息。
(3)同时打开备S75E的收发报文,显示报文带优先级的tag。
(4)在S75E的主上打开debug,确认收到的ip phone2报文正常。
(5)在S75E的主上打开debug,确认收到的ip phone2报文正常。debug确认收到的ip phone 1报文不带tag。
(6)将vrrp主备倒换,问题依旧。
问题到此陷入绝境!!!到底是ip phone发的报文有问题,还是75E备私自修改报文tag?
如果是iphone发的报文有问题,为何在主机上的时候就没有问题?Vrrp主备切换后为何新的主用设备还是有问题?
第六步:实验室测试。
问题要么是S75E 备机所有芯片都修改ip phone原始报文导致,要么就是ip phone发出报文有问题导致,基于我们对芯片的了解,出现这个修改tag的问题只有现场配置voice vlan和gust vlan两个配置,检测芯片的表项,并未看到有修改的配置残留或者修改。
因此我们怀疑ip phone发出的特殊报文导致,因此在实验室我们进行了关键的测试,测试结果很快出来:
ip phone(smb模拟)发出 81 00 a0 00 的报文(81表示该报文为tag报文,a为优先级,000为vlan=0),镜像到smb的报文发现变为untag。转发到S75E master的报文为tag=15(ip phone的入端口pvid)。
到此,我们可以确认,现场问题就是ip phone电话发出的错误tag报文导致。
第七步:问题最终定位
① ip phone为avaya 品牌,默认启动后,如果学习到网关的arp,那么就发送untag 的报文;如果没有学习到网关的arp,就发送tag报文,tag报文中的vlan号根据ip电话的设置确定(avaya电话支持设置vlanid)。默认vlan为0,所以此时发送的tag报文的vlan=0
②在备机下的ip phone,由于上线时是与备机互联,此时主用75E并不感知其端口up,所以不会发送免费arp给备用75E下的ip phone。
③这样备用75E下的ip phone由于没有主动学习到网关的arp,发送的arp报文就是tag报文,vlan=0。
④75E 备机访问该ip phone时,收到回应的arp为vlan=0,所以认为为非法报文,本地不学习。但是bcm芯片对转发的tag报文中vlan 0的报文进行处理,转发时为入端口的pvid,而镜像时直接去掉tag信息。这就是我们之处匪夷所思的根本。
⑤由于75E主从vrrp互联端口收到的报文已经备75E备增加了pvid,因此能正常学习到arp。
⑥同时在主用75E身上的ip phone,由于其插入时,75E主机响应端口up事件,所以会主动发送免费arp,此时ip phone会主动学习到网关的arp,所以发送的报文就是untag,因此无问题。
问题的根源可以确认为是ip phone发出的报文太特殊,正常的行为应该是发送默认为untag的报文,如果特情况下要发送tag报文,也应该是vlan=1的报文,因为以太网标准中并没有vlan=0的定义,因此所有交换机或者相关设备中,缺省情况下vlan都是为1。
建议ip phone的设备行为我们不可控制,并且已经是既成事实,因此如果要从网络侧解决问题,最优秀推荐使用75E堆叠替换vrrp来解决问题。
一个疑问:为何现场75E主备机切换后,还是有问题?
问题其实很简单,因为主备倒换时,连接的ipphone并未下线,因此其没有与网关进行过启动时的arp和tag协商,因此依旧有问题。现场测试,只要把iphone插拔下,在75E新的主机上的电话不再有问题,而在原先主的75E上的电话则出现问题。
现场为何shutdown或者调整备机与S105间的ospf cost值后可以解决问题呢?
原因可以从整个流量走向中得到解释,报文从ip phone发送出来后由于ip gw 是VRRP的主机,因此报文是可以由VRRP主机正常转发出去的。当报文回程的时候若是正常hash到vrrp的主机上则没有问题,若是hash到VRRP的备机上则就不通了。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作