[c-nsp] 6500/SRA: vpnv4 vs. equal-cost multipath ?

[Alexandre Snarskii]

Hi!

Summary: looks like IOS 12.2(33)SRA* can't handle vpnv4 routes
which comes from peer reachable via two equal paths. 

May be it's known issue, just run into it and want to share experience.. 

Our topology is really simple, 

RouterA -------- RouterB
  |                |
  |                |
RouterC -------- RouterD

all routers are 65xx/Sup720/PFC3BXL, IOS version on RouterA is 12.2(33)SRA3,
on RouterD - 12.2(33)SRA1, all links are 10ge (6704-based, if it matters) 
with same ospf cost of 4. 

Configuring simple MPLS/BGP VPN between RouterA and RouterD, 
configuration is straightforward. But I was unable to ping 
one router from another within VPN... :( 

After some digging, i found that however RouterA knows vpnv4 route
from RouterD:

RouterA#show ip bgp vpnv4 vrf LOCAL 192.168.103.120
BGP routing table entry for MyAS:230:192.168.103.120/29, version 14208
Paths: (1 available, best #1, table LOCAL)
  Not advertised to any peer
  Local
    RouterD.234 (metric 20) from RouterD.234 (192.168.10.133)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:MyAS:230
      mpls labels in/out nolabel/535

this route is not installed in MPLS Forwarding table (at least not
installed in correct way): 

RouterA#show mpls forwarding-table vrf LOCAL 192.168.103.120 detail 
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
None   535           192.168.103.120/29[V]   \
                                       0             
        Recursive paths, Label Stack{535}
         00217000
        VPN route: LOCAL
        No output feature configured

- you see, no outgoing interface mentioned in output, and label
stack is just incorrect - it consists only from one (final) label... 

As insane as it sounds, source of problem was in the fact that RouterA
has two equal paths to RouterD: 

RouterA#show ip route RouterD.234                                
Routing entry for RouterD.234/32
  Known via "ospf MyAS", distance 110, metric 20, type extern 2, forward metric 8
  Last update from CoreNet.197 on TenGigabitEthernet6/4, 00:01:43 ago
  Routing Descriptor Blocks:
    CoreNet.197, from RouterD.234, 00:01:43 ago, via TenGigabitEthernet6/4
      Route metric is 20, traffic share count is 1
  * CoreNet.169, from RouterD.234, 00:01:43 ago, via TenGigabitEthernet6/1
      Route metric is 20, traffic share count is 1


After lowering ospf metrics on one of our links and this getting rid of 
ECMP, mpls forwarding table became normal: 

RouterA#show mpls forwarding-table vrf LOCAL 192.168.103.120 detail
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
None   535           192.168.103.120/29[V]   \
                                       0             Te6/1      CoreNet.169
        MAC/Encaps=14/22, MRU=9212, Label Stack{1828 535}
        00D02B18A5000004DEFEC8008847 0072400000217000
        VPN route: LOCAL
        No output feature configured

and now everything works just as expected... 

PS: well, our topology is simple enough to easily avoid equal-cost path's
but in more complex networks this workaround may be inacceptable...