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

[Ivan Ivanov]

Hi James,

Importing from inet.0 to inet6.3 with rib-groups should do the trick. See
the example below (replace OSPF with IS-IS if needed):

routing-options {

   rib-groups {

      to-inet.3-inet6.3 {

         import-rib [inet.0 inet.3 inet6.3];

         import-policy loopbacks-only

      }

   }

}

protocols {

   ospf {

     rib-group to-inet.3-inet6.3;

   }

}



policy-options {

  policy-statement loopbacks-only {

    term 1 {

        from {

            route-filter 0.0.0.0/0 prefix-length-range /32-/32;

        }

        to rib inet.3;

        then accept;

    }

    term 2 {

        from {

            route-filter 0::0/0 prefix-length-range /128-/128;

        }

        to rib inet6.3;

        then accept;

    }

    term last {

        then reject;

    }

  }

}

Ivan,


On Sat, May 16, 2015 at 4:20 PM, James Jun <james at towardex.com> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Best Regards!

Ivan Ivanov