由于LSP超规格导致NE20 部分MPLS VPN业务不通

发布时间:  2009-05-11 浏览次数:  163 下载次数:  0
问题描述
组网:
中心NE20---C7507---故障NE20
两台NE20作为PE接入MPLS VPN
问题描述:
客户反馈故障NE20与C7507之间的链路发生中断,链路恢复后发现故障NE20与中心NE20之间的MPLS VPN业务不通,但是中断之前是可以通的。
处理过程
1、检查配置确认两台设备的配置都没有做过修改,而且配置正确;
2、在中心NE20上面查看到故障NE20的路由,发现查看VPV4的路由时可以看到故障NE20的业务网段路由,但是查看VPN的路由表却发现这条路由是不生效的。如下所示:
<mek-vpn-ne20>dis bgp vpnv4 all routing-table
 Route Distinguisher: 837:5300 
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn
 *>i  10.21.1.0/25       202.98.110.33   0          100        0      ?
 *>i  10.21.1.128/25     202.98.110.34   0          100        0      ?
<mek-vpn-ne20> disp ip routing-table vpn-instance AB_MA5300 10.21.1.128 25 verbose 
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : AB_MA5300
Summary Count : 1
Destination: 10.21.1.128/25
     Protocol: BGP             Process ID: 0
   Preference: 255                   Cost: 0
      NextHop: 202.98.110.34    Neighbour: 202.98.110.76
        State: Inactive Adv WaitQ     Age: 00h13m30s
          Tag: 0                 Priority: 0
        Label: 15367              QoSInfo: 0x0
 RelayNextHop: 0.0.0.0          Interface: NULL0
     TunnelID: 0x0                  Flags: R 
3、通过如上信息可以看出不生效的原因是因为没有迭代到公网的LSP,所以查看公网的LSP,发现没有到202.98.110.34(故障NE20 LSR ID)的LSP;
4、在故障NE20上面查看标签分配情况确认针对202.98.110.34分配了标签,如下:
<AB-LX-NE20-PE1>disp mpls lsp include 202.98.110.34 32
----------------------------------------------------------------------
                 LSP Information: LDP LSP
----------------------------------------------------------------------
FEC                In/Out Label  In/Out IF                      Vrf Name  
5、客户让C厂家工程师协助查看C7507标签分配情况,也确认C7507给中心NE20分配了标签;
6、在中心NE20查看LSP统计发现ingress对应的标签数量为1024,但是公网路由的数量却有5000多条,而且包含好多32位的主机路由,所以怀疑是标签超规格,经过确认NE20 LSP的规格是10K,但是32位主机路由对应的LSP规格为1024,到此可以定位该问题是由于NE20LSP超规格导致的。
<mek-vpn-ne20>disp mpls lsp statistics 
Lsp Type       Total     Ingress   Transit   Egress    
STATIC LSP     0         0         0         0         
STATIC CRLSP   0         0         0         0         
LDP LSP        1025      1024      0         1         
RSVP CRLSP     0         0         0         0         
BGP LSP        24        0         0         24        
ASBR LSP       0         0         0         0         
BGP IPV6 LSP   0         0         0         0 
<mek-vpn-ne20>disp ip routing-table statistics 
Proto     total      active      added        deleted      freed   
          routes     routes      routes       routes       routes  
DIRECT    5          5           5            0            0         
STATIC    0          0           0            0            0         
RIP       0          0           0            0            0         
OSPF      5015       5013        10107        5092         5092      
IS-IS     0          0           0            0            0         
BGP       0          0           0            0            0         
Total     5020       5018        10112        5092         5092
根因
最开始,中心NE20上面没有那么多路由,后来由于上层设备引入的外部路由,而且没有做过滤,导致NE20收到过多的路由,而且LSP超过规格,但是为什么链路中断之前,VPN可以互通?为什么链路中断又恢复之后却不通了?原因如下:
中断之前,虽然LSP超规格,但是原来的公网LSP一直没有中断,所以可以互通,但是中断之后故障NE20对应的公网LSP失效,这时中心NE20马上会收到上端C7507分配的其他路由的标签。当链路恢复后,虽然故障NE20和C7507都分配了标签,但是由于中心NE20的LSP数量一直是1024,也就是最大规格,所以无法接收C7507分配的标签。
解决方案
NA
建议与总结
遇到一些特殊的问题时,可以考虑一下是否是规格的问题。

END