[j-nsp] 6PE RR & next-hop resolution best practices

[James Jun]

Hey Adam,

Thanks for your reply.

On Sat, May 16, 2015 at 06:45:45AM +0000, Adam Vitkovsky wrote:

[ .. snip.. ]

> If you say that the RRs act as "thru-traffic boxes for the transiting LSPs between PE's" then they should just perform pure label switching and no IPv6 lookup.
> Are you sure your IPv6 traffic is labelled correctly indeed? 

Yes, traffic is labelled correctly, and P's are doing what they're supposed to.

The problem however is that I'm using the P's also as route-reflectors for distributing BGP throughout the network.  So, I need the RR's to make correct BGP best-path decisions, but they can't do that on 6PE routes without having inet6.3 table to reference the ipv4-mapped-in-v6 next-hops against.

I've tried importing the PE loopbacks (which are my 6PE next-hops) from inet.0 into inet.3 using rib-groups, but that doesn't create the ipv4-mapped-in-v6 (ffff::ipv4) conversions into inet6.3 table (yes, ipv6-tunneling under [ protocols mpls ] is enabled on the RR/P's).


> And are you sure the RRs are enabled for MPLS forwarding i.e. the label switched path between PEs crossing RRs is operational? 
> I mean this could have gone unnoticed for IPv4 as the RRs happened to have all the routing information necessary for the IPv4 traffic to be forward traffic across.

Yup absolutely, mpls forwarding is working correctly on the P's.   The issue I'm having is route-reflectors running on the same P boxes being unable to make best-path decisions on 6PE routes having quad-F's/ipv4-mapped-inv6 next-hops-- they don't exist in inet6.3 unless RR's themselves have LSPs heading out to PE's.. 

I suppose other people doing 6PE with 'bgp-free core' or topologies of similar import (i.e. oob route-reflectors) probably have dealt with similar situations, when it comes to RR's having to make best-path decision on 6PE prefixes having v4-mapped-in-v6 next-hops.

James