NE40E设备TE FRR备用Tunnel UP后业务存在丢包

发布时间:  2014-10-22 浏览次数:  102 下载次数:  0
问题描述

【Problem Summary】NE40E与对端两台cisco设备建立mpls TE,业务走L3VPN,当TE FRR UP后业务异常,cisco下挂的RNC发现部分基站业务异常。

【Problem Details】

<CX600_Personal-PJC>与Cisco-01之间建立TE tunnel,主tunnel为0/0/116,备用tunnel为0/0/117,业务正常情况下承载在0/0/116上。10月15日,客户将备用tunnel0/0/117打开后,右侧RNC发现业务存在丢包和流量下降的现象,业务承载在vpn-instance Iub中。如下流量图也显示了当时0/0/117 UP后流量下降的情况,注意:NMS时间比CX600快1小时。

 

Oct 14 2014 14:55:07-04:00 CX600_Personal-PJC %%01IFNET/4/LINK_STATE(l)[157266]:The line protocol None on the interface Tunnel0/0/117 has entered the DOWN state.

Oct 15 2014 09:08:53-04:00 CX600_Personal-PJC %%01IFNET/4/LINK_STATE(l)[158862]:The line protocol None on the interface Tunnel0/0/117 has entered the UP state.

Oct 15 2014 10:04:37-04:00 CX600_Personal-PJC %%01IFNET/4/LINK_STATE(l)[158952]:The line protocol None on the interface Tunnel0/0/117 has entered the DOWN state.

Oct 15 2014 10:08:44-04:00 CX600_Personal-PJC %%01IFNET/4/LINK_STATE(l)[159110]:The line protocol None on the interface Tunnel0/0/117 has entered the UP state.

Oct 15 2014 10:48:49-04:00 CX600_Personal-PJC %%01IFNET/4/LINK_STATE(l)[159218]:The line protocol None on the interface Tunnel0/0/117 has entered the DOWN state.

 

 

 

interface Tunnel0/0/116

description PRI_ROUNGNNOR1

ip address unnumbered interface LoopBack1

tunnel-protocol mpls te

destination 10.143.253.7

mpls te tunnel-id 116

mpls te record-route label

mpls te path explicit-path pri-roungnnor1

mpls te fast-reroute

mpls te backup hot-standby mode revertive wtr 60

mpls te reserved-for-binding

mpls te commit

statistic enable

#

interface Tunnel0/0/117

description BCK_ROUNGNNOR1

ip address unnumbered interface LoopBack1

tunnel-protocol mpls te

destination 10.143.253.7

mpls te tunnel-id 117

mpls te record-route label

mpls te path explicit-path bck-roungnnor1

mpls te bypass-tunnel

mpls te protected-interface GigabitEthernet7/5/0.221

mpls te commit

 

 #

explicit-path bck-roungnnor1

  next hop 192.168.57.245

  next hop 10.143.251.10

 

 explicit-path pri-roungnnor1

  next hop 192.168.53.2 

 

 ip vpn-instance Iub

ipv4-family

  route-distinguisher 192.168.54.5:70

  vpn frr route-policy FRR

  tnl-policy ipran-norte

  vpn-target 100:70 export-extcommunity

  vpn-target 100:70 import-extcommunity

 

tunnel-policy ipran-norte

tunnel binding destination 10.143.253.7 te Tunnel0/0/116

组网如下图:

处理过程

分析我们TE FRR备用tunnel的UP流程,当备用的Tunnel没有配置FA和shortcut时,即不参与流量转发时对于主用Tunnel没有任何影响。

从理论分析看,备用Tunnel UP不会对现网流量产生任何影响。

 

注意:某些TE FRR的备用tunnel可能也是其他VPN或者业务的主用Tunnel,此时可能导致流量路径切换,流量形成负载分担。

 

进一步分析,TE FRR的UP的条件是打开了cisco设备之间的直连链路,此时可能导致cisco设备使能负载分担导致流量发生切换,如果链路拥塞会导致业务受损。

根因
客户复现该问题后发现cisco设备上存在负载分担,且链路拥塞,导致丢包,业务流量下降,当去掉负载分担后,TE FRR的备用Tunnel仍然UP,业务正常。
解决方案

【Resolution Summary】

1,去掉cisco设备的负载分担.

2,增加拥塞链路带宽。

建议与总结
对于流量下降问题,不能简单从谁触发谁处理的角度出发,更多的从端到端,来回业务流量模型出发,找到可能存在的怀疑点,然后深度定位。

END