Have you tried to disable rpf check ? Thanks
On 3/10/11, Phil Mayers <[email protected]> wrote: > 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; > } > } > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Sent from my mobile device ./diogo -montagner _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
