mac地址冲突导致呼叫失败问题处理过程.docx

Mac冲突导致呼叫失败的问题处理过程 现象：ucs设备三块用户板的电话用户呼叫本板号码没有问题，板间用户相互呼叫不通。 组网结构： 如上图：单板采用独立的嵌入式的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的一个网口。 业务流程： 48fxs相当于通信终端集合体iad，smca相当一个网络交换机，ipma相当于业务处理平台。从网络拓补上来看48fxs和impa下挂于smca下面。Smca是*型组网的中心点。从业务角度看两个板卡下挂于impa下面，impa是*型组网的中心点。 客户反馈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后，出现重发现象 根据经验判断，重发要么是imp发给错误的mac地址，要么是104收到没有响应，首先排除第一种情况，发给了错误的mac地址？ 询问研发，界面跟踪抓包sip包使用的是tcpdump -i any udp port 5060的命令，这样就无法获得完整的mac地址。mac层会被改写成linux cooked capture。看不到目的mac地址。 改用自定义模式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地址冲突导致目的板卡收不到对应的invite消息，再次用arp消息来验证，因为linux系统有单播消息来探查目的主机是否在线的功能，一分钟发一次，连续几次收不到响应后，会删除arp缓存，发arp广播请求消息。 过滤arp消息分析如下： 过滤(arp.src.proto_ipv4=172.31.234.103arp.dst.proto_ipv4=172.31.234.103)得出上面的结果。三个板卡发出的arp单播请求消息的mac地址相同。 交换机具有动态学习源MAC地址的功能，并且交换机的一个接口可以对应多个MAC地址，但是一个MAC地址只能对应一个接口。交换机动态学习的MAC地址默认只有300S的有效期，如果300S内记录的MAC地址没有通信，则会删除此记录。根据此理论： 当同一mac从不同端口进入交换机，mac端口表会被改写，没有数据发送时，mac端口表项保留300秒。收到相同端口mac上来的消息，定时器恢复为300秒。 结论即改正方法：结论是3块fxs的mac配置相同，导致数据包收发不正常，落地的invite发到了错误的端口，导致等待100trying超时，imp发403呼叫失败。 改正方法：发现主控上fxs的mac已经配置，而且不是00:aa:bb:cc:dd:ee,三块不同。重新下发mac地址到三块板子后send mac slot x，测试业务正常。 归纳一下解决问题中的关键点： 界面sip协议抓包是默认执行tcpdump -i any udp port 5060，这样抓出包没有完整的mac层显示，显示为linux cooked capture。udp port 5060为预过滤sip协议端口的信令消息。 自定义抓包执行的tcpdump -i eth2，因为要过滤所有的包，所以无需在后面执行预过滤项。 Sip协议有超时重发机制，invite发出后，等待100trying的回复，会在距离上一次消息的发出的消息0.5秒，1秒，2秒重发。 交换机通过mac端口表是以mac地址为索引查询对应端口来转发数据包，mac地址在表中有