Only local route leaking

[saccom]

Hello,

i would like to leak a route locally from vrf to another without passing it to other vpnv4 neighbors.

For example: i have two PEs and one P RR. On both PEs i have the same VRF (vrf A) with same RT (for example Import 1:1 and export 1:1). On both PEs i have a second VRF (vrf B) with other RTs (for example import 2:2 and no export (they learn some prefixes from CEs)). I would like to import, in vrf A on both PEs, one prefix that is inside vrf B... but i would like to import it without sending this NLRI inside the VPNv4 address-family (PE1 should not be aware of PE2's imported prefix and vice versa).

I would like to do this without use different RTs (wasting them), but i'm asking: is there any way to locally leak (in the same PE) some prefixes without sending them to the vpnv4 address-family? Maybe using only local RT (that are not exported in vpnv4) or other things?

Thank you in advice

[Leo Gal]

Hi,Try using this

ip vrf A
rd 65432:20130
route-replicate from vrf B unicast connected route-map rm-b-2-a

obviously, this is for connected routes, in vrf B.

But there are other options, so try to play with it.

My exp is, that it wont get advertised to vpnv4.

let me know, if it worked pls.

[saccom]

Hello, thanks for your reply.

I would like to replicate this on XR routers (i've seen that on XRv is possibile to import routes only from global RIB), and it must work for learned eBGP prefixes.

I was thinking about a possibile solution:
Is there any way to export a prefix with two RTs, where the prefix marked with one RT can have a community while the other one cannot have it? (the prefix must be the same)

Thanks a lot.

[Adam Vitkovsky · Accepted solution]

Hi,

First of all, don’t worry about wasting RT.

RTs are meant to be used for exactly the use case you’re describing here.

So what you could do on each PE is:

-----------------

on PE-1

-----------------

vrf VRFB

vrf VRFB address-family ipv4 unicast

vrf VRFB address-family ipv4 unicast import route-target 2:2

vrf VRFB address-family ipv4 unicast export route-policy RP_VRFB_EXP

//match specific prefix you want to leak from VRF-A to VRF-B

prefix-set CS_VRFB_TO_VRFA_LEAK_RT

  192.0.2.0/24

end-set

//tag specific prefix you want to leak from VRF-A to VRF-B with special community specific to PE-1

extcommunity-set rt CS_VRFB_TO_VRFA_LEAK_RT

  2:11

end-set

//tag all other prefixes in VRF-B with standard RT for VRF-B

extcommunity-set rt CS_VRFB_RT

  2:2

end-set

route-policy RP_VRFB_EXP

  if destination in PS_VRFB_TO_VRFA_LEAK then

    set community CS_VRFB_TO_VRFA_LEAK_RT additive

       done

  else

       set community CS_VRFB_RT additive

  endif

end-policy

vrf VRFA

vrf VRFA address-family ipv4 unicast

vrf VRFA address-family ipv4 unicast import route-target 1:1

vrf VRFA address-family ipv4 unicast import route-target 1:11

vrf VRFA address-family ipv4 unicast export route-target 1:1

-----------------

on PE-2

-----------------

use the same config just replace 2:11 with 2:12

To your specific request,

To my knowledge in XR there’s no concept of direct VRF-to-VRF route leaking (like Junos auto-export) and that’s a good thing in my opinion keeps things simple, consistent and most importantly fast with MP-BGP RIBs (VPNv4 and VPNv6) as common repository for all VPN prefixes and a single place to manage and perform walks upon if one needs to leak a route from VRF-A to VRF-B.

One drawback as you outlined is that prefixes in MP-BGP RIBs are automatically advertised to other iBGP peers (RRs in your example), however you can prevent this from happening if you for instance use filters towards your iBGP infrastructure and allow only specific prefixes to be advertised from your PE to other PEs.

-but this should concern you only if you’re leaking massive amount of prefixes between VRF-A and VRF-B –and it bothers the RRs

Alternatively you can use the new fancy RT-Filter functionality to instruct RR not to advertise prefixes to PEs for which PEs do not have any matching RTs. (but the prefixes would still end up on the RR)  

As Leo mentioned in XE there’s the concept of direct VRF-to-VRF route leaking but limited only to handful of IGP protocols (so to me this seems more like Junos rib-groups).

adam  

[saccom]

Thanks a lot