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

《最新mac地址冲突导致呼叫失败问题处理过程.docx》由会员分享，可在线阅读，更多相关《最新mac地址冲突导致呼叫失败问题处理过程.docx（16页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-datemac地址冲突导致呼叫失败问题处理过程mac地址冲突导致呼叫失败问题处理过程Mac冲突导致呼叫失败的问题处理过程现象：ucs设备三块用户板的电话用户呼叫本板号码没有问题，板间用户相互呼叫不通。组网结构： 如上图：单板采用独立的嵌入式的linux操作系统，分配独立的业务ip地址，通过背板的业务网口接入主控交换单板smca。用户板fxs通过两个网口接背板，一个维护一个业务

2、，业务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

3、是*型组网的中心点。从业务角度看两个板卡下挂于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收到没有响应，首先排除第

4、一种情况，发给了错误的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

5、:ee,和3槽位172.31.234.103发出消息的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地址的功能，并且交换机的一个接口可以对应多个MA

6、C地址，但是一个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地址到三

7、块板子后send mac slot x，测试业务正常。归纳一下解决问题中的关键点：1， 界面sip协议抓包是默认执行tcpdump -i any udp port 5060，这样抓出包没有完整的mac层显示，显示为linux cooked capture。udp port 5060为预过滤sip协议端口的信令消息。2， 自定义抓包执行的tcpdump -i eth2，因为要过滤所有的包，所以无需在后面执行预过滤项。3， Sip协议有超时重发机制，invite发出后，等待100trying的回复，会在距离上一次消息的发出的消息0.5秒，1秒，2秒重发。4， 交换机通过mac端口表是以mac地址为

8、索引查询对应端口来转发数据包，mac地址在表中有唯一性，没有重复。可以多个不同mac地址对应一个端口，不可能一个mac对应多个不同端口（较多出现在交换机的级联口上）。交换机通过记录数据包里的源mac来改写mac端口表。查找目的mac对应的端口来找出转发数据的端口，目的mac端口表中不存在对应的mac地址时，会使用范洪方式，将包广播到所有端口，当目的mac主机回复后，交换机记录回复主机的mac和端口对应关系，下次有同样的目的mac数据包来时，直接转发到对应端口，不再使用范洪方式。端口在收到包时，记录包的源mac地址，并启动有效的定时器，再次收到同样的mac地址包时，定时器复位。一般定时器是300

9、s。当交换机下面有mac冲突时，另一个端口收到已经记录的mac的包时，mac端口表被改写。到这个mac的包会被发到后来的硬件上去。但是impa板中arp缓存会出现一个mac地址对应多个ip地址的问题。发到交换机的invite消息被转发到错误的板卡上去。5， 通常linux的网关类设备要进行单播验证arp缓存中的主机是否在线，通过发单播arp请求消息来实现，一般是一分钟一次，若连续N次没有收到对应主机的单播回复，主机设备就会清除arp缓存表中的对应项目，当要发送数据时，会使用广播arp消息来查询对应的主机的mac地址。6， Fxs用户呼叫本板用户，因为语音的rtp楼20ms一次不断发出，交换机的mac端口始终不变，所以拨打本板没有问题。拨打其他板卡，会出现imp 发来包转发到源板卡上，导致呼叫失败。-