PTN用户侧路由合并操作案例

发布时间:  2014-12-18 浏览次数:  181 下载次数:  0
问题描述

XX局点客户反馈用户侧路由数量巨大,维护工作量大,要求合并用户侧路由。

在实际合并中由于操作顺序问题导致业务出现中断问题。

处理过程

由于该问题是由于在人为操作期间发生的业务中断,故分析重点聚焦在操作过程的复盘,详细分析每一步操作确认是否为设备产品问题或操作问题。

排查步骤及结果:

首先,与现场工程师确认具体操作时间、操作内容、操作步骤,复原操作过程

xx月xx日,晚上22:51-22:53分,为了合并市区L3到县区L2/L3节点的UNI侧多条24位掩码的路由,合并为21和22位掩码的路由。先配置100.70.152/21静态路由,然后删除100.70.152.0/24~100.70.159.0/24的明细路由,先删除用户侧路由,再在网络侧自动计算路由。

第二,确认业务中断时间、影响范围、梳理共性

在合并路由期间,下挂的xxxx个基站中断1~2分钟,集中在100.70.152~159.0网段

其次,采集网管操作日志,网元日志

再次,分析相关时间点日志,还原操作过程,与现场工程师了解的信息进行匹配,排除或确认为操作问题;若排除操作问题,继续分析设备异常点(此问题不涉及)。

1、12月11日 22:15,添加了100.70.152.0/21路由,下一跳为县区节点
Dec 11 2014 16:15:54 HUAWEI %%01SHELL/5/CMDRECORD(l)[96072]:Record command information. (Task=VT0, Ip=129.11.0.251, User=ptnsdadmin, Command="ip route-static vpn-instance 1 100.70.152.0 21 Eth-Trunk12.1 172.31.11.17 preference 30", Result=Success)
2、12月12日22:51,删除了100.70.151.0/24-100.70.159.0/24的明细路由,
Dec 12 2014 22:51:30 HUAWEI %%01SHELL/5/CMDRECORD(l)[96746]:Record command information. (Task=VT0, Ip=129.11.0.251, User=ptnsdadmin, Command="undo ip route-static vpn-instance 1 100.70.154.0 24 Eth-Trunk12.1 172.31.11.17", Result=Success)
Dec 12 2014 22:51:30 HUAWEI %%01SHELL/5/CMDRECORD(l)[96750]:Record command information. (Task=VT0, Ip=129.11.0.251, User=ptnsdadmin, Command="undo ip route-static vpn-instance 1 100.70.156.0 22 Eth-Trunk12.1 172.31.11.17", Result=Success)
Dec 12 2014 22:51:31 HUAWEI %%01SHELL/5/CMDRECORD(l)[96754]:Record command information. (Task=VT0, Ip=129.11.0.251, User=ptnsdadmin, Command="undo ip route-static vpn-instance 1 100.70.155.0 24 Eth-Trunk12.1 172.31.11.17", Result=Success)
此时,设备上存在24位掩码下一跳为VPN Peer的网络侧路由,根据路由最长匹配原则,流量转向对端L3节点,同一时间点,对端L3节点上也删除了下一跳为县区节点的用户侧路由。同时对端L3也存在下一跳为本节点的24位掩码的网络侧路由,从而导致下行流量在L3节点之间形成互转,业务中断。
3、12月12日22:53,下一跳为VPN Peer的24位掩码路由被删除 ,100.70.152.0/21,下一跳是县区节点,业务恢复
Dec 12 2014 22:53:53  Command="undo ip route-static vpn-instance 1 100.70.154.0 24 static-vpn-peer 1.11.12.159", Result=Success)
Dec 12 2014 22:53:53  Command="undo ip route-static vpn-instance 1 100.70.152.0 24 static-vpn-peer 1.11.12.159", Result=Success)
Dec 12 2014 22:53:55  Command="ip route-static vpn-instance 1 100.70.152.0 21 static-vpn-peer 1.11.12.159 preference 90", Result=Success)
至此,设备操作日志和现场反馈操作完全吻合,确认非产品问题。

最终,确定根因和客户交流沟通。

 

根因

12月11日新增加的合并路由21位掩码的用户侧路由未选中(存在更长路由),12月12日22:51同时在主备L3节点先删除了24位掩码的用户侧路由,这样由于路由最长匹配原则及FRR保护,仍然是24位掩码的路由生效,从而导致下行路由成环,基站业务断;而在22:53主备L3节点删除网络侧路由,新配置100.70.152.0/21路由被选中,业务恢复。

 

解决方案

用户侧路由合并操作建议:

1、提前在主、备L3节点部署大网段路由(21位掩码)
2、在主用设备上做混合FRR的切换,通过修改路由优先级来搞定
3、删除主L3节点的一条用户侧明细路由(24位掩码)触发混合FRR倒换
4、再删除主L3节点的对应网络侧明细路由,通过网络侧自动计算路由搞定,此时业务倒换到UNI侧选大网段路由转发,可确认大网段路由转发正常
5、第3、4步骤正常,则依次依序删除其他要合并的用户侧和网络侧明细路由。等小网段的明细路由全部删除完毕后,确认流量全部都走到大段路由
6、备用L3节点采用同样方法先删除用户侧路由,再通过网管自动计算删除网络侧路由
7、最后在网管计算网络侧路由,确认混合FRR形成正确,建议再做下倒换测试验证下。

建议与总结

随着业务上量,路由数量越来越多,合理规划路由对于网络的维护越来越重要了。针对用户侧路由的合并,以及混合FRR侧的扩容,路由调整可以参考案例中的步骤,但仅供参考,具体实施方案务必根据现网业务进行编写和调整。

 

建议:涉及L3VPN路由调整的操作,均属于高危操作,严格要求在行业默许时间00:00-05:00操作,并申请业务中断时间窗,谢谢!

END