[j-nsp] IPv4 FIB corruption with 6vPE/"protocols mpls ipv6-tunneling"

Phil Mayers p.mayers at imperial.ac.uk
Thu Mar 10 06:06:07 EST 2011


All,

We use a bunch of J-series routers, currently running 10.1R1.8, to serve 
100meg-connected remote sites.

These J-series are all MPLS L3VPN PEs (as well as P-routers, since it's 
a routed ring for cost reasons). The vast majority of edge-facing 
interfaces are in a routing instance. In that role, they work fine.

We wanted to enable 6vPE on these routers, to deploy v6 inside the 
L3VPNs, but we ran into a problem on one router.

This router has a 3d party connected. Their interface is *not* in a 
routing-instance, and already has both IPv4 and IPv6 enabled. When we do 
this:

set protocols mpls ipv6-tunneling

...the 3rd-parties IPv4 connectivity breaks. Their routes remain 
advertised, and the LDP FECs and so forth all look ok - but the traffic 
does not reach them (or possibly the return-path traffic doesn't come 
back - it's hard to be sure).

IPv4 connectivity can be restored by *disabling* their static IPv6 
route, and doing a "clear ldp session":

deactivate routing-options rib inet6.0 static route <x:x>/48
commit and-quit
clear ldp session


It's worth noting that, at this site, we actually have two PE routers, 
and use VRRP to provide resilient routing to the customer for IPv4. The 
customer IPv6 is only configured on one router however.


Looking at the traffic path from our core, it goes:

border router - label imposed
hop 2         - label swap
hop N-1       - label swap
hop N         - label pop
broken router - unlabelled IPv4 traffic

...so I guess one of four things is happening:

  1. The broken router is dropping the unlabelled IPv4 on receive
  2. The broken router is failing to egress the IPv4 to the customer
  3. The customer return-path traffic is being dropped in ingress
  4. The customer return-path traffic is failing to egress to the 
next-hop P-router

Is there any way I can determine which of these is the case?



The config sort-of looks like this (customer-facing interface is 
ge-0/0/2.951):

interfaces {
     ge-0/0/0 {
         description "to another P/PE router"
         mtu 1544;
         unit 0 {
             family inet {
                 address <w.w.w.w>/31;
             }
             family inet6 {
                 address <x:x>/112;
             }
             family mpls;
         }
     }

     ge-0/0/2 {
         vlan-tagging;
         unit 951 {
             description "3rd party";
             vlan-id 951;
             family inet {
                 rpf-check;
                 address a.b.c.d/27 {
                     vrrp-group 1 {
                         apply-groups VRRP;
                         virtual-address a.b.c.1;
                     }
                 }
             }
             family inet6 {
                 rpf-check;
                 address 2001:db8:1::1/112;
             }
         }
     }
}
routing-options {
     rib inet6.0 {
         static {
             route 2001:db8:100::/48 next-hop 2001:db8:1::2;
         }
     }
}
protocols {
     mpls {
         inactive: ipv6-tunneling;
         icmp-tunneling;
         interface ge-0/0/0.0;
     }
     bgp {
         # standard L3VPN stuff here
     }
     ldp {
         interface ge-0/0/0.0;
     }
}
routing-instances {
     # loads and loads of these
     XXXX {
         description "Gold network";
         instance-type vrf;
         interface ge-0/0/2.xx;
         route-distinguisher a.b.c.d:1;
         vrf-target target:a.b.c.d:1;
         vrf-table-label;
     }
}


More information about the juniper-nsp mailing list