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

Mac 冲突导致呼叫失败的问题处理过程 现象现象 ucs 设备三块用户板的电话用户呼叫本板号码没有问题 板间用户相互呼叫不通 组网结构 如上图 单板采用独立的嵌入式的 linux 操作系统 分配独立的业务 ip 地址 通过背板 的业务网口接入主控交换单板 smca 用户板 fxs 通过两个网口接背板 一个维护一个业务 业务 ip 为 172 31 234 10 x 单业务板 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 103 arp 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 测试业务正常 归纳一下解决问题中的关键点 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 地址为索引查询对应端口来转发数据包 mac 地址在表中有唯一 性 没有重复 可以多个不同 mac 地址对应一个端口 不可能一个 mac 对应多个不同端口 较多出 现在交换机的级联口上 交换机通过记录数据包里的源 mac 来改写 mac 端口表 查找目的 mac 对应的端口来找出转发数据的端口 目的 mac 端口表中不存在对应的 mac 地址时 会使用范洪方式 将包广播到所有端口 当目的 mac 主机回复后 交换机记录回复主机的 mac 和端口对应关系 下次 有同样的目的 mac 数据包来时 直接转发到对应端口 不再使用范洪方式 端口在收到包时 记录 包的源 mac 地址 并启动有效的定时器 再次收到同样的 mac 地址包时 定时器复位 一般定时器 是 300s 当交换机下面有 mac 冲突时 另一个端口收到已经记录的 mac 的包时 mac 端口表被改 写 到这个 mac 的包会被发到后来的硬件上去 但是 impa 板中 arp 缓存会出现一个 mac 地址对应 多个 ip 地址的问题 发到交换机的 invite 消息被转发到错误的板卡上去 5 通常 linux 的网关类设备要进行单播验证 arp 缓存中的主机是否在线 通过发单播 arp 请求消息来实 现 一般是一分钟一次 若连续 N 次没有收到对应主机的单播回复 主机设备就会清除 arp 缓存表