mac地址漂移导致呼叫失败问题处理过程
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
1 现象
ucs设备三块用户板的电话用户呼叫本板号码没有问题板间用户相互呼叫不通。
2 组网结构
如上图单板采用独立的嵌入式的linux操作系统分配独立的业务ip地址通过背板的业务网口接入主控交换单板smca。用户板fxs通过两个网口接背板一个维护一个业务业务ip为172.31.234.10x单业务板ip为3槽位172.31.234.1034槽位为172.31.234.104,5槽位为172.31.234.105。主控交换机板SMCA为所有的业务管理网口的网络交换板相当于一个交换机前面板有4个带内网络出口和背板的所以业务网口相通。IMPA业务处理板是所有业务电话业务的sip协议注册语音处理接口业务ip为172.31.234.220通过背板接入smac的一个网口。
3 业务流程
48fxs相当于通信终端集合体iadsmca相当一个网络交换机ipma相当于业务处理平台。从网络拓补上来看48fxs和impa下挂于smca下面。Smca是*型组网的中心点。从业务角度看两个板卡下挂于impa下面impa是*型组网的中心点。
4 抓包定位一下问题
4.1 抓包看一下
客户反馈3槽位的1809呼叫本板的号码正常呼叫4槽位的1828时呼叫失败。用系统抓包功能抓包分析抓包界面如下
抓出包用wireshark打开如下
首先流程应该是3槽位172.31.234.103的板卡发出invite到impimp板分析号码落地在4槽位172.31.234.104所以发invite到4槽位板卡。4槽位根据被叫状态进行后续应答操作。
发现imp转给4槽位的172.31.234.104后出现重发现象
根据经验判断可能性如下
1、重发要么是第一种情况imp发给错误的mac地址,导致正确的板卡没有收到消息导致没有响应消息发出imp没有收到响应消息在不断的按0.5,1,2,4,8,16的间隔重发消息
2、要么第二种情况是四板卡的问题ip为104的板卡收到消息没有响应消息发出
查看抓包文件的发现没有目的mac地址这样无法判断消息发给谁
根据mac层的结构如下图可知抓包里目的mac为空
询问研发界面跟踪抓包sip包使用的是tcpdump -i any udp port 5060的命令这样就无法获得完整的mac地址。mac层会被改写成linux cooked capture。看不到目的mac地址。
4.2 更改抓包方式后重抓
改用自定义模式ctrl+shift+f12激活自定义抓包模式。见下图改成 –i eth2只抓imp板的业务网口的包。相当于执行了tcpdump -i eth2,eth2是impa板的业务口。
再次信令跟踪抓包看目的mac清楚显示
查看imp转给4槽位172.31.234.103发出的invite消息发现mac地址也是00:aa:bb:cc:dd:ee,和3槽位172.31.234.103发出消息的mac地址相同。
发现mac地址冲突存在mac地址漂移。
初步判断是mac地址冲突导致目的板卡收不到对应的invite消息再次用arp消息来验证因为linux系统有单播消息来探查目的主机是否在线的功能一分钟发一次连续几次收不到响应后会删除arp缓存发arp广播请求消息。
过滤arp消息分析如下
过滤(arp.src.proto_ipv4>=172.31.234.103&&arp.dst.proto_ipv4>=172.31.234.103)得出上面的结果。发现三个板卡发出的arp单播请求消息的mac地址相同。
交换机具有动态学习源MAC地址的功能并且交换机的一个接口可以对应多个MAC地址但是一个MAC地址只能对应一个接口。交换机动态学习的MAC地址默认只有300S的有效期如果300S内记录的MAC地址没有通信则会删除此记录。根据此理论
4.3 故障的可能性如下图
问题的原因
正常的3槽位的号码呼叫4槽位的号码invite发出到impimp根据4槽位号码注册的ip确定ip和路由mac地址路由发给对应的mac地址交换机smca根据mac地址表对应mac地址发给对应4槽位的设备接口。
现在的问题是345槽位的mac地址一样导致谁发包mac地址表的对应mac会被不断改写。3发出invite后改写交换机smca的mac地址表对应mac地址对应接口被改写3这样imp发出invite被转发到3槽位的设备上而3槽位收到invite消息里ip不是自己的不处理。而imp等不到invite的后向100try的确认消息导致按0.5,1,2,4这样的时间差发出在等100trying的5s超时后停止发invite消息发出403给3槽位呼叫失败。
5 结论及改正方法
结论是3块fxs的mac配置相同导致数据包收发不正常落地的invite发到了错误的端口导致invite消息不断重发5s后等待后向100trying超时imp发403呼叫失败。
改正方法发现主控上fxs的mac已经配置而且不是00:aa:bb:cc:dd:ee,三块不同。重新下发mac地址到三块板子后send mac slot x测试业务正常。
归纳一下解决问题中的关键点
1.界面sip协议抓包是默认执行tcpdump -i any udp port 5060这样抓出包没有完整的mac层显示显示为linux cooked capture。udp port 5060为预过滤sip协议端口的信令消息。
2.自定义抓包执行的tcpdump -i eth2因为要过滤所有的包所以无需在后面执行预过滤项2.
3.Sip协议有超时重发机制invite发出后等待100trying的回复会在距离上一次消息的发出的消息0.5秒1秒2秒重发。Invite发出后等待100trying超时时长是4秒。超时不到发403消息。中断呼叫。
4.交换机通过mac端口表是以mac地址为索引查询对应端口来转发数据包mac地址在表中有唯一性没有重复。可以多个不同mac地址对应一个端口不可能一个mac对应多个不同端口较多出现在交换机的级联口上。交换机通过记录数据包里的源mac来改写mac端口表。查找目的mac对应的端口来找出转发数据的端口目的mac端口表中不存在对应的mac地址时会使用范洪方式将包广播到所有端口当目的mac主机回复后交换机记录回复主机的mac和端口对应关系下次有同样的目的mac数据包来时直接转发到对应端口不再使用范洪方式。端口在收到包时记录包的源mac地址并启动有效的定时器再次收到同样的mac地址包时定时器复位。一般定时器是300s。
5.当交换机下面有mac冲突时另一个端口收到已经记录的mac的包时mac端口表被改写。到这个mac的包会被发到后来的硬件上去。但是impa板中arp缓存会出现一个mac地址对应多个ip地址的问题。发到交换机的invite消息被转发到错误的板卡上去。
6.通常linux的网关类设备要进行单播验证arp缓存中的主机是否在线通过发单播arp请求消息来实现一般是一分钟一次若连续N次没有收到对应主机的单播回复主机设备就会清除arp缓存表中的对应项目当要发送数据时会使用广播arp消息来查询对应的主机的mac地址。
7.Fxs用户呼叫本板用户因为语音的rtp楼20ms一次不断发出交换机的mac端口始终不变所以拨打本板没有问题。拨打其他板卡会出现imp 发来包转发到源板卡上导致呼叫失败。
6 总结
交换机下的mac地址表是以mac地址为唯一索引的多个mac地址可以对应一个端口但一个mac只能对应一个端口当一个mac出现在另外一个端口上时mac地址表会被更新。当两个设备配置同一个mac时就会出现mac地址漂移而交换机的arp的表是以ip为唯一索引当arp表不变时发给这个ip的包就会被一会发给这个端口一会发给那个端口导致访问不正常。