Route-target import scale ASBR

[kma-rt]

Hi,

We have two ASR 1001-HX's connected back-to-back as ASBR's using MPLS VPN Inter-AS option B to exchange MPLS VPN prefixes. Let's call them ASBR A and ASBR B. ASBR A is inside ISP network A and ASBR B is in ISP network B. ISP B needs access to a subset of the total number of MPLS VPN's inside ISP A's network. ISP B needs to import about 2600 of ISP A's MPLS VPN's. What would be the most scalable way to import only the 2600 MPLS VPN's into ISP B's network? I am aware of these options to get the MPLS VPN prefixes into the ASBR's:

1) disable defult route-target filter on both ASBR A and ASBR B so that they have all the MPLS VPN prefixes in BGP table and then create VRF's in ISP B's network where needed. This does not seem like a very scalable option because ASBR B will get all the VPN prefixes even if it doesn't need them.

2) create VRF's on ASBR B and on ASBR A to have only the VPN prefixes imported that are needed in ISP B's network. This would however involve creating the 2600 VRF's on both ASBR's which seems like an awful lot and I don't know how the ASR 1001-HX's will handle that, control-plane wise and convergence wise. 1001-HX datasheet does mention that the 1001-HX supports more than 3x that number but still...because the ASBR's mainly just need the prefixes in the RIB and don't need the hardware programming into FIB, i also figure that I can filter the prefixes by using table filter on ASBR per VRF to prevent from installing into FIB.

3) create single VRF on ASBR A and ASBR B and apply the 2600 route-target imports into the VRF's to import the VPN routes and combine this with the table filter to increase scale.

I am leaning towards option 3, but does anyone know the implications of applying 2600 route-target import on single VRF? Are there any limits that I should be aware of? I couldn't find anything in the doc's to clearly explain.

Would love to hear someone's thoughts on this.

Thanks,

K

[Harold Ritter · Accepted solution]

In my view, option 1 coupled with running route target constraint (RTC) would be the most scalable way to do this.

Please refer to the following document for more details on RTC;

https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116062-technologies-technote-restraint-00.html

Regards,

[kma-rt]

Hi Harold,

Thanks for your suggestion. Actually, I came across RTC too, but unfortunately RTC seems not able to co-exist with disabling RT filter on ASBR's. When disabling RT filter and enabling RTC, the ASBR drops all VPN prefixes because there are no VRF's importing route-targets on the ASBR's. Creating VRF on PE node inside ISP B network is not enough to signal ASBR B (which is running IOS XE 16.6.1) to import the required route-target from ASBR A (which is running IOS version 15.6(3)M2). It is only after creating the VRF on both ASBR's and applying the route-target import, that the wanted VPN prefixes for the MPLS VPN are imported on both ASBR's and propagated to the PE inside ISP B, which is why I started experimenting with option 2 and 3 in the lab. Option 2 and 3 could also be combined with RTC to increase scale but that still leaves with additional scalability question about the 2600 RT imports or the creation of 2600 VRF's on the ASBR's.

Regards,

K

[Harold Ritter]

I just tried and it works just fine for me. The ASBR drops the prefixes for which there is no RT advertisement and keeps the ones for which there is. I am using IOS 15.6(2)T on both ASBRs.

Regards,

[kma-rt]

You're right. Further troubleshooting in my specific setup revealed that I neglected to enable the RTC in a couple of places in ISP B side. The setup of ISP B is different from ISP A in that ISP B is constructed as an eBGP DC fabric which required me to enable the RTC across the entire fabric to get it working. On ISP A side, traditional route reflector iBGP topology is used so RTC only had to be enabled on route reflector and ASBR A. It's working now. Thanks for your help.

[Adam Vitkovsky]

Hi,

But still I don't understand how come this works

See:

...RR only sends wanted VPN4/6 prefixes to the PE. 'Wanted' means that the PE has VRF importing the specific prefixes.

And:

The Route Target (RT) filtering information is obtained from the VPN RT import list from all the VRFs on the PE router. 

Now if there are no VPNs (or VRF import policies for that matter) defined on the ASBR then how come it knows what to signal in an RTC update to upstream BGP speakers (RRs and eBGP peers)

[kma-rt]

BGP update propagation is causing the signalling. When you import an RT on a PE, the PE signals the RR that it wants the VPN prefixes with that RT attached. The RR signals the RRC's with BGP update. The RRC would be the ASBR in this case. The ASBR would then, because it has eBGP peering with other ASBR, propagate the update to other ASBR due to the way standard BGP propagation works.

The reason why the ASBR is able to signal to other ASBR about which prefixes to send, even when VRF is not importing RT locally on ASBR, is because of disabling default RT filtering with "no bgp default route-target filter" under BGP proces. So the ASBR is telling the other ASBR to send everything, then the RTC adjacency between ASBR's is allowing them to filter what is needed.

[Adam Vitkovsky]

Aaah of course,

Right so basically as the RTC update travels across the BGP infrastructure it creates state in form of export policies, so if enabled end to end it allows for edge nodes (PEs) to instruct the infrastructure in between to rely only a specific set of prefixes.

Interesting, when enabled end to end it then essentially turns BGP update advertisement mechanism into very much like multicast dense-mode type of operation for m-cast groups, (i.e BGP VPN updates flooded everywhere for all VPNs unless speakers signal they don’t want to receive updates for a given VPN).

Hmm but there might be some ramifications, since BGP advertises only best path (by default) this might result in some path hiding (like if you have two ASBRs, then depending on topology,  PEs might learn only about BGP path via one of these ASBRs)  

-makes me wonder whether RTC works with BGP Add-Path

adam

netconsultings.com

::carrier-class solutions for the telecommunications industry::

[kma-rt]

---

@Adam Vitkovsky wrote:

Aaah of course,

Right so basically as the RTC update travels across the BGP infrastructure it creates state in form of export policies, so if enabled end to end it allows for edge nodes (PEs) to instruct the infrastructure in between to rely only a specific set of prefixes

.

What I see happening, export filters are created between RTC adjacent peers and filters are populated based on route-target.

Interesting, when enabled end to end it then essentially turns BGP update advertisement mechanism into very much like multicast dense-mode type of operation for m-cast groups, (i.e BGP VPN updates flooded everywhere for all VPNs unless speakers signal they don’t want to receive updates for a given VPN).

Hmm but there might be some ramifications, since BGP advertises only best path (by default) this might result in some path hiding (like if you have two ASBRs, then depending on topology,  PEs might learn only about BGP path via one of these ASBRs)  

This is correct, path hiding occurs in this case, as is by BGP design. This has implications for ECMP. Diverse or shadow route reflector could probably help with this.

-makes me wonder whether RTC works with BGP Add-Path

Sadly, add-path send/receive does not appear supported under VPNv4 AF (IOS 15.6(3)M2 / IOS XE 16.06.01):

dc-wan1(config-router-af)# address-family vpnv4
dc-wan1(config-router-af)#bgp
dc-wan1(config-router-af)#bgp add
dc-wan1(config-router-af)#bgp additional-paths ?
  install  Additional paths to install into RIB
  select   Selection criteria to pick the paths

dc-wan1(config-router-af)#bgp additional-paths

So I'm going to have to conclude that it's not supported (yet) on IOS/XE.  

 XR does appear to support under VPNv4 AF.

adam

netconsultings.com

::carrier-class solutions for the telecommunications industry::

---