Routing

last person joined: 19 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Route Reflectors and hidden VPN prefixes

    Posted 10-25-2019 01:55

    I've a few RRs that are "out of path" and not running LDP. I'm exchanging inet and inet-vpn address families and also have inet.3 resolution set to inet.0:

    routing-options {
        forwarding-table {
            export no-fib;
        }
        resolution {
            rib bgp.l3vpn.0 {
                resolution-ribs inet.0;
            }
        }
    }
    

    That (I think) should allow reflection of vpn routes but it still doesn't work:

    > show route table bgp.l3vpn.0      
    bgp.l3vpn.0: 889 destinations, 1601 routes (0 active, 0 holddown, 1601 hidden)
    

    An example (next hop unusable):

    x.x.x.x:1:a.b.c.d/24 (3 entries, 0 announced)
             BGP    Preference: 170/-101
                    Route Distinguisher: x.x.x.x:1
                    Next hop type: Unusable, Next hop index: 0
                    Address: 0x278d15c
                    Next-hop reference count: 139697
                    State: <Hidden Int Ext ProtectionPath ProtectionCand>
                    Local AS: 1111 Peer AS: 1111
                    Age: 2d 0:04:55 
                    Validation State: unverified 
                    	MED-plus-IGP: 0 
                    Task: BGP_1111.x.x.x.x
                    AS path: I  (Originator)
                    Cluster list:  a.b.c.d x.y.z.v
                    Originator ID: x.x.x.x
                    Communities: target:11111:1
                    Accepted
                    VPN Label: 17
                    Localpref: 100
                    Router ID: x.x.x.x
    

    Does anybody have any idea why? Next hop is in inet.0 table (via OSPF) so it should be "usable"...

     

    Thanks,

     

     



  • 2.  RE: Route Reflectors and hidden VPN prefixes

    Posted 10-25-2019 05:13

    Hello,

     


    @damanloox wrote:

    Does anybody have any idea why? Next hop is in inet.0 table (via OSPF) so it should be "usable"...

     

     


     

    I do. You need to enable "family mpls" on RR interfaces.

     

    BTW, this approach of changing "resolution-rib" is good for the lab  but in production it breaks 6PE and 6VPE which use IPv4-mapped IPv6 /128 address (auto-constructed from remote PE' IPv4 loopback) as BGP NEXT_HOP .

     

    Better approach is to leak only /32 from inet.0 to inet.3 and inet6.3 as below and don't change "resolution-rib":

     

     

    routing-options {
        rib-groups {
            VPN-6PE-NH-RESOLUTION {
                import-rib [ inet.0 inet.3 inet6.3 ];
                import-policy HOST-ROUTES;
            }
        }
    }
    protocols {
    ospf {
    rib-group VPN-6PE-NH-RESOLUTION;
    }
    }

     

     

    Policy "HOST-ROUTES" should allow only /32 OSPF prefixes. The inet6.3 will be auto-populated with IPv4-mapped IPv6 /128 routes.

     

    HTH

    Thx

    Alex

     

     



  • 3.  RE: Route Reflectors and hidden VPN prefixes

    Posted 11-04-2019 23:57

    Thanks. 

    I thought "resolution-rib" was tghe way recommended by Juniper (and they reviewed my config...!). And I really like the concept (and dislike the concept of leaking routes between ribs - I guess I'm old fashioned)

    But yes - I will use 6PE/6VPE so thanks for heads up 😉 

    Is there any way of making 6PE work with "resolution-rib" idea? Something along the lines:

    resolution {
        rib inet6.3 {
            resolution-ribs inet6.0;
        }
    }

    I'm a newbie in Junos world (coming from ALU/Nokia and Cisco) so please forgive my ignorance...

     

     

     



  • 4.  RE: Route Reflectors and hidden VPN prefixes
    Best Answer

    Posted 11-05-2019 02:12

    Hello,

     


    @damanloox wrote:

    Thanks. 

    I thought "resolution-rib" was tghe way recommended by Juniper (and they reviewed my config...!).

     

     


     

    Definitely not the only one. This method was popular before advent of 6PE and 6VPE, sometime around 2001-ish.

     

     


    @damanloox wrote:

    Thanks. 

     

    Is there any way of making 6PE work with "resolution-rib" idea? Something along the lines:

    resolution {
        rib inet6.3 {
            resolution-ribs inet6.0;
        }
    }

     



     Short answer is no.

    Long answer is that the ipv4-mapped IPv6 addresses are still used in the MP-BGP Update NEXT_HOP field for 6PE and 6VPE AFI/SAFIs but they are not acceptable as src.IP, dst.IP and are not forwardable, see https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

     

    Which means one cannot use them in IGP/inet6.0 cannot have ipv4-mapped IPv6 prefixes sourced from IGP albeit JUNOS allows You to assign ipv4-mapped IPv6 addresses to links. That being said, assigning ipv4-mapped IPv6 addresses to links is only useful for inter-AS 6PE with eBGP-LU as transport.

     

    Your other option is to rewrite MP-BGP NEXT_HOP to global unicast IPv6 address assigned to PE loopbacks that exist in IGP  (and then You can use Your fav "resolution-rib" method)  but this is more trouble than it's worth:

    1/ MP-iBGP export policy is required to do that on EACH PE

    2/ be careful NOT to rewrite MP-BGP NEXT_HOP for IPv4 prefixes (otherwise these prefixes will be hidden), do it only for IPv6 prefixes.

     

    HTH

    Thx

    Alex

     

     

     



  • 5.  RE: Route Reflectors and hidden VPN prefixes

    Posted 11-11-2019 03:19

    So I've implemented the changes and I'm seeing "interesting" behaviour...

    In my lab (which is a vMX on 17.2R1.13) it works perfectly fine.

    In production (MX204, 18.1R3.3) - it's a diferent story. Exact same config (different IP addressing) and in the lab both inet-vpn and 6PE work fine. In production vpn next hops are still "unusable" (they are in inet.3 table though). Do I still need family mpls on the interfaces of the RR?

    I don't thave that in the lab and it works perfectly...



  • 6.  RE: Route Reflectors and hidden VPN prefixes

    Posted 11-11-2019 04:08

    Hello,

     


    @damanloox wrote:

    Do I still need family mpls on the interfaces of the RR?

    I don't thave that in the lab and it works perfectly...


     

     

    Yes You do.  See my earlier post https://forums.juniper.net/t5/Routing/Route-Reflectors-and-hidden-VPN-prefixes/m-p/469648/highlight/true#M20355

    Your lab behaviour is incorrect.

     

    HTH

    Thx

    Alex