ip冲突引起呼叫故障的问题处理过程

      一次领导让去贵州六盘水，去帮办事处解决一个公司ippbx的呼叫故障问题，说问题已经反馈处理一个月，工程和研发多次处理都没定位，现场意见很大，再不解决，用户要拆设备了。研发这边不派人去，可能会造成当地办事处不满，我们研发要派人到现场给个认真处理的态度。于是很忐忑的被派去，想这是一个擦屁股，背锅的差事，我就是一个测试维护人员9527,这是什么套路？

    飞到贵阳和办事处人员汇合，了解基本情况如下：

    六盘水监狱，iad+ippbx+ims组网，反馈问题是打入打出多次尝试才能成功，重启后能正常一段时间。有时打出提示线路忙，再次尝试能成功。

ip配置：共27个iad，ip从172.31.234.51到172.31.234.77

wan的ip是10.8.64.252./24

imp：172.31.234.220，wan口10.8.64.252，网关：10.8.64.1

主用ims：221.13.5.226     备用ims：221.13.4.174

号码：本地小号：1,3,5,7,8,9打头四位号长

公网号码：085881649百号段，ims注册和呼叫使用+868581649xxx

  

 根据组网确定定位方法：

1、去现场了解故障的范围，发生的有啥共性和规律性？

2、根据反馈情况进行抓包跟踪，确定是否有sip信令表项，根据信令表项排查故障。

排查过程：

        到监狱后，了解到是一个新建监狱，还未正式使用，监狱办公楼和岗亭，生活区，监狱内部通过光纤组网，用iad接入模拟电话，对接ippbx后，接入联通ims。办公楼区域反馈故障多，主要是不能呼出，一会能正常一下。

       决定先抓包，看一下是否有信令的表现？

       公司的ippbx上有一个信令和业务处理板名称是imp板，硬件是一个四口千兆网卡百兆snmp的嵌入centos6.5的板卡，它的eth2上有172.31.234.220这个ip地址，作为信令和语音rtp的ip，用于下联iad。eth3是运营商的内网地址10.8.64.252./24用于上联ims。iad用分机注册到imp板，imp记录分机注册的ip地址和号码。imp用eth3的地址和公网号码向ims注册。分机呼出公网号码时，iad发出消息到imp，携带注册时的分机号码作为主叫，imp上有公网号码和分机对应关系，相当呼出做nat，主叫号码由分机转换为公网号码用wan口ip发给ims。由公网的呼入，eth3接受消息，被叫是ippbx在公网的注册号码+8685881649xxx，反向查nat公网号码和分机对应关系，被叫公网号码转换i内网分机短号，imp用eth2，给对应iad的ip发出呼叫消息。内部分机互打时，主机iad发消息给imp，imp再查被叫分机注册时的对应ip地址，再把消息转给被叫的注册ip地址。

1、串口上去，给imp板的snmp添加ip地址，用于ssh访问和抓包。

 

考虑现象不是一直有，为不遗漏现象，采用多文件抓包的方法，让wireshark自动记录，自动打包。便于后面分析。

2、利用rpcapd进行抓包，先抓一下eth2，多文件抓包，每50M自动打包一个。

 3、抓包后，对语音的voip进行分析，发现有一些呼叫失败，被叫号码是1028,1032。

 发现是业务板imp172.31.234.220的ip地址发给iad172.31.234.66时被拒绝了。看一下这个ip的iad

是否有啥问题？

登录172.31.234.66发现上仅仅配置一个号码9005，那为什么imp会把1032,1028的呼叫指向iad66呢？

imp会记录分机注册成功时，携带的ip地址，有呼叫会发给这个地址，难道1032和1028也用这个ip注册过，但为啥有时会拒绝呼叫？环境中存在两个172.31.234.66的ip地址？

4、怀疑系统中存在两个172.31.234.66，让在另一台pc上cmd模式下ping 172.31.234.66，然后arp –a显示mac缓存表。Linux下ping 172.31.234.66 –c 10，arp –n显示mac表，对比两个mac地址是否一致？

imp板上的ping后显示：

对应mac地址00:0e:5e:55:4e:86。

而另一台pc上ping后，显示的mac地址为00:0e:5e:58:d2:49。两个mac地址不一致，telnet逐个检查每个iad的配置，登陆172.31.234.66时发现它有这个mac地址。检查留存的ip地址配置文件表，发现有两个 iad的ip为172.31.234.66（分别为备勤楼,号码为1001到1034，另一个是计划岗楼4，号码仅一个9004）。判断分配ip时，没有留心，把ip地址分重了！

5、去岗楼不方便，备勤楼外部人员可以进入，决定把备勤楼的ip进行修改为172.31.234.75后，观察一天再未出现此类故障。

确定是ip冲突导致的问题。到现场一个小时找到故障，松了口气，锅不用背了。办事处的运营商的很满意，说监狱在郊外20公里山里，一个月间，来回多次都没解决问题，今天这么快就找到问题，释然了。

三楼机房看看监狱的外层五米高墙，上面有铁丝网电网和岗楼，里面还有一圈铁网隔离墙，上面是有刀片式铁丝网，看得人心悸，问监控室的，说出大门得三道门，三个干警掌管钥匙，没有人配合，逃出概率为0。看围墙内犯人排队吃饭，还有朗朗的读英语声，犯人还学英语，不错。

ip冲突导致sip信令故障原因分析：

     观察期间，对问题进行分析，呼叫一会好，一会不行，感觉imp上一回发给了正确的172.31.234.66的mac地址，一会发给了错误的mac地址，于是过来arp和sip消息。

     过滤：(sip  && ip.addr==172.31.234.66) ||  arp  contains  ac1f-ea42  arp过滤的是消息里包含ip 地址172.31.234.66的包。

为了wireshark方便查看，调整wireshark的列显示edit→preference→columns

内部小号为1001到1032的iad备勤楼对应iad的mac00:0e:5e:55:4e:86，计划岗楼iad的mac00:0e:5e:58:d2:49,仅分配一个号码9004。

发现有这四种情况：

1、当有呼叫1001到1032其中的一个号码的呼叫时（内线或外线呼叫），此时linux里的mac表被更新为错误的mac，导致invite消息发向了错误iad，这个iad上没有这些号码，直接回600，服务器忙，呼叫失败。

 

 

上图中淡黄色的是arp单播探查消息，这是imp的缓存里还是错误的mac，arp单播probe探查消息，依然是错误的iad给的响应，导致arp缓存的定时器被恢复到reachable的状态。下一一次还是发给错误 iad。

2、当1001至1032的用户主动发起呼叫时，imp的缓存只有arp的请求imp的地址或者有对你imp发出arp请求作出响应时才被修改，imp板回的100trying发向了错误mac地址上，由于没有收到100trying，源iad在0.5,1,4秒后重发invite。

3、当正确mac的iad发出arp单播探查请求的imp板上时，imp会更新缓存中的mac值，imp消息发到正确iad上，通话能正常。

 

 

 172.31.234.220 is at 00:0e:5e:34:8e:29 (duplicate use of 172.31.234.66 detected!) 

4、超时重复发invite在隔四秒重发前，正确的iad发出单播arp探查消息，更新了mac地址缓存，imp把后向183消息，发给了正确的iad，呼叫流程正常走下去

结论：mac更新正常后，呼叫会成功，但当错误mac被更新到缓存中，呼叫会失败。

 总结：

呼入呼出故障系两个iad的ip配置成了172.31.234.66，导致imp板的arp缓存有时被更新为错误的mac地址，当由ims呼入的电话到imp，imp板把invite消息转到错误的mac地址的iad上，iad没有配置相应的号码，回600全局忙，导致呼叫失败。正常的iad呼出时，imp发的100try发到了错误的mac地址上，导致iad超时重发invite，最后呼叫失败。

 要点：

1、arp缓存要在收到设备发出arp请求或者回答本机的arp请求后才会被更改。

2、处理问题时，要关注mac地址的变化。