• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

某局点S75E下AVAYA话机异常问题排查案例

2015-07-26 发表
  • 0关注
  • 1收藏 2082浏览
张磊 九段
粉丝:26人 关注:0人

   核心两台S10500做聚合,汇聚采用nS75E做内网网关,每两台一组,启动VRRP做网关备份。S10500和每组S75E之间采用等价路由互联。AVAYA话机连接在75E上,GWVRRP备份组的虚地址。

汇聚交换S75E VRRP组中,连接在VRRP主的ip电话设备运行正常,但是运行在VRRP备机S75E下的ip电话经常不通,不固定时间又能通,但是通后不久又不通。发现shutdown或者调整vrrp备机和10500的互联端口ospf cost值(调大),能解决ip电话不通问题。

同时还有一个故障现象是在VRRP的备机上始终无法ping 通其直接互联的话机,将话机更换为普通的pc不存在无法ping通的问题。


不涉及


通过收集到的信息分析,备机无法pingip phone,但是主机ping正常。同时shut down备机与10500的互联端口正常,因此根据我们对vrrp的转发了解,问题的目标根源很可能是备机上无法学习到ip phonearp导致。

因此我们需要进一步分析为何备机无法学习到ip phonearp

第一步:直接在备机下抓设备与ip phone的报文,发现每次ping的时候,75E备机发出了正常的arp请求,ip phone也回应了正常的arp单播应答,报文正常。但是备用75E上的确没有学习到该arp,而主机75E上却能学习到该arp。貌似说明备机工作有问题,测试备机上多个单板,故障现象一样。

第二步:使用pc机进行测试,却一切正常,貌似问题只有是备机和ip phone配合才有问题。

第三步:打开rxtx的收发报文和平台eth报文,发现rxtx收到ip phonearp应答报文,但是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

 -----------------------------------------------------

上述红色字体的解释如下:

Ctag0说明75E收到的报文没有ctag

rx_untagged=2 说明收到的报文带一层tag信息

根据打印出来的具体报文内容(81 00 a0 00)显示报文上cpu后带有tag信息,但是vlan0,非法报文,因此该报文备丢弃。设备不学习该arp报文,这里貌似问题已经定位。但是还有很多匪夷所思的故障现象无法完全解释。

第五步:确认iphone到底是否发出了带tag的报文,我们做端口流量镜像测试,发现:

 

175E发出的报文带tag15的信息(连接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 vlangust vlan两个配置,检测芯片的表项,并未看到有修改的配置残留或者修改。

因此我们怀疑ip phone发出的特殊报文导致,因此在实验室我们进行了关键的测试,测试结果很快出来:

ip phone(smb模拟)发出 81 00 a0 00 的报文(81表示该报文为tag报文,a为优先级,000vlan0),镜像到smb的报文发现变为untag。转发到S75E master的报文为tag15ip phone的入端口pvid)。

到此,我们可以确认,现场问题就是ip phone电话发出的错误tag报文导致。

第七步:问题最终定位

 

ip phoneavaya 品牌,默认启动后,如果学习到网关的arp,那么就发送untag 的报文;如果没有学习到网关的arp,就发送tag报文,tag报文中的vlan号根据ip电话的设置确定(avaya电话支持设置vlanid)。默认vlan0,所以此时发送的tag报文的vlan0

②在备机下的ip phone,由于上线时是与备机互联,此时主用75E并不感知其端口up,所以不会发送免费arp给备用75E下的ip phone

③这样备用75E下的ip phone由于没有主动学习到网关的arp,发送的arp报文就是tag报文,vlan0

75E 备机访问该ip phone时,收到回应的arpvlan0,所以认为为非法报文,本地不学习。但是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报文,也应该是vlan1的报文,因为以太网标准中并没有vlan0的定义,因此所有交换机或者相关设备中,缺省情况下vlan都是为1

建议ip phone的设备行为我们不可控制,并且已经是既成事实,因此如果要从网络侧解决问题,最优秀推荐使用75E堆叠替换vrrp来解决问题。


一个疑问:为何现场75E主备机切换后,还是有问题?

问题其实很简单,因为主备倒换时,连接的ipphone并未下线,因此其没有与网关进行过启动时的arptag协商,因此依旧有问题。现场测试,只要把iphone插拔下,在75E新的主机上的电话不再有问题,而在原先主的75E上的电话则出现问题。

现场为何shutdown或者调整备机与S105间的ospf cost值后可以解决问题呢?

原因可以从整个流量走向中得到解释,报文从ip phone发送出来后由于ip gw VRRP的主机,因此报文是可以由VRRP主机正常转发出去的。当报文回程的时候若是正常hashvrrp的主机上则没有问题,若是hashVRRP的备机上则就不通了。


该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

作者在2019-06-11对此案例进行了修订
0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作