Routing
Routing

Route Reflectors and hidden VPN prefixes

‎10-25-2019 01:55 AM

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,

 

 

5 REPLIES 5
Routing

Re: Route Reflectors and hidden VPN prefixes

‎10-25-2019 05:12 AM

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

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Route Reflectors and hidden VPN prefixes

‎11-04-2019 11:57 PM

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 Smiley Wink 

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...

 

 

 

Routing
Solution
Accepted by topic author damanloox
‎11-05-2019 02:49 AM

Re: Route Reflectors and hidden VPN prefixes

‎11-05-2019 02:12 AM

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

 

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Route Reflectors and hidden VPN prefixes

4 weeks ago

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...

Routing

Re: Route Reflectors and hidden VPN prefixes

[ Edited ]
4 weeks ago

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/...

Your lab behaviour is incorrect.

 

HTH

Thx

Alex

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !