几年前处理过的一个问题，有客户反馈3g煤炭专网系统，一个新加基站，无法连接核心网，核心网网管上看基站是断开状态。要求给定位解决。
已知新加基站的ip是18.250.0.199，核心网ip是18.250.0.9，核心网和基站用sctp协议的5050端口进行偶联，应用层协议在sctp层上封装。
远程抓包过滤基站的ip，有如下显示：
发现基站一直在尝试建立偶联，反复进行。找个正常的偶联过程对比一下：
发现正常的进入cookie验证阶段，通过后，互发心跳。而这个199基站在核心网init_ack发出后，没有进入cookie验证过程，而是发出icmp的协议不可达消息。抓一下基站日志看看有如下：
对比正常基站如下：
为啥199基站没有进入cookie验证态？发现该基站没有收到到核心网的init_ack消息的打印，而没有后面的进展。而且这个18.250.0.199回的消息是协议不可达，而基站明显是打开5050的sctp协议的端口的，怎么会回协议不可达呢？难道这个ip回的消息不是发出sctp的init的设备？环境里存在ip冲突？
怀疑要么是基站没有收到sctp的init_ack消息，要么是init_ack回复的不正确？
检查抓包里init_ack消息发向，核心网的init_ack发向了错误的mac地址，过程如下：
调整wireshark里的显示项，让显示源和目的mac地址：
发现基站发出init的源mac是00:0e:5e:18:9a:84 ，而核心网回的init_ack的地址却是Destination: 40:f2:e9:68:8c:70 。我司基站都是以00:0e:5e打头的，这个40:f2:e9打头的是什么设备？
改wireshark里的name revolution后，发向init_ack发给了一个ibm设备，而不是我们基站的raisecom设备
发现init消息和init_ack消息里的源和mac地址只有服务器发生调换，直连网络中，收发应该源和目的调换，但这个服务器里init_ack却发给了另一个ibm的设备。
这个ibm设备发出协议不可达的icmp消息，表示它没有开sctp协议。
确定环境中有两个18.250.0.199，ip冲突了，过滤arp验证一下：arp contains 12fa-00c7 || arp contains 12fa-0009。
发现环境中有两个设备回答了核心网发出arp广播消息，而错误ibm设备消息后到，覆盖了正确的arp缓存表，导致核心网应答init的init_ack发给了错误ibm设备。
这台核心网服务器处理arp缓存更新的机制是只处理自己arp请求发出后的应答，对下联设备发出的arp请求，无论单播还得多播都不处理。
让现场修改ip地址，反馈 ibm设备不知道在哪里，就修改了基站的ip为其他ip后，问题解决。
总结：
ip冲突导致故障，冲突后，错误的设备后发arp应答reply消息，导致arp缓存被更新，而sctp的偶联init_ack发给了错误的设备，错误设备没开sctp协议，发出icmp错误，目的不可达的协议不可达。导致基站一直在重发发出建链请求。
当时不懂icmp错误消息的含义和产生条件，应该看到这个icmp的协议不可达就能判断出问题，ip冲突了，而花大量时间去查看基站的日志打印。
