mac地址漂移导致呼叫失败问题处理过程

1 现象：

ucs设备三块用户板的电话用户呼叫本板号码没有问题，板间用户相互呼叫不通。

2 组网结构：

如上图：单板采用独立的嵌入式的linux操作系统，分配独立的业务ip地址，通过背板的业务网口接入主控交换单板smca。用户板fxs通过两个网口接背板，一个维护一个业务，业务ip为172.31.234.10x（单业务板ip为3槽位172.31.234.103，4槽位为172.31.234.104,5槽位为172.31.234.105）。主控交换机板SMCA为所有的业务管理网口的网络交换板，相当于一个交换机，前面板有4个带内网络出口，和背板的所以业务网口相通。IMPA业务处理板是所有业务电话业务的sip协议注册语音处理接口，业务ip为172.31.234.220，通过背板接入smac的一个网口。

3 业务流程：

48fxs相当于通信终端集合体iad，smca相当一个网络交换机，ipma相当于业务处理平台。从网络拓补上来看48fxs和impa下挂于smca下面。Smca是*型组网的中心点。从业务角度看两个板卡下挂于impa下面，impa是*型组网的中心点。

4 抓包定位一下问题：

4.1 抓包看一下

客户反馈3槽位的1809呼叫本板的号码正常，呼叫4槽位的1828时，呼叫失败。用系统抓包功能抓包分析，抓包界面如下：

抓出包用wireshark打开如下：

首先流程应该是3槽位172.31.234.103的板卡发出invite到imp，imp板分析号码落地在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发出到imp，imp根据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的包就会被一会发给这个端口，一会发给那个端口，导致访问不正常。