BGP Local-AS with Loop Prevention for ISP

[matt.malott]

Hello!

I work for a regional ISP and I have a pretty complicated problem that I would like some feedback on. I am in the process of migration our upstream internet peers to a new border VRF L3VPN in our MPLS core. Currently our public ASN is being advertised the "traditional" way from our border routers using our public AS. Our MPLS network's BGP configuration is using a private AS and is now deployed all across our state. I am working on moving upstream peers to our border VRF. I understand that I can use "local-as" to establish peers with upstream peers, however, I need to prevent the upstream peer from seeing our private AS in the path AND prevent our routers from accepting prefixes with our public AS in the path. I am currently using local-as no-prepend replace-as. I am finding that loop prevention is removed, which will not work when more than one peer is migrated. Is there a way to use a local-as with a peer while keeping our private AS from showing up in the path as well as preventing prefixes with our private AS (the local-as) from being accepted?

[Philip D'Ath · Accepted solution]

Have you considered using a BGP federation?

Then you can have the same single ASN everywhere - but inside of your ASN you can assign an additional number to each group of routers.

Then everything is aware of everything else, and the outside world doesn't see any changes.

[matt.malott]

I haven’t considered that, but will look into it. Currently I’m thinking the only way around my issue is to change the ASN configuration on all of our routers.

[Giuseppe Larosa · Accepted solution]

Hello Matt,

the use of BGP confederation as suggested by Philip should be the right one.

In this way you can separate the normal AS path segment from the confederation AS path segment and only the first is advertised to true eBGP peers.

your private AS becomes the mini AS and your public AS number is configured with bgp conferation identifier

the private AS has to be listed in the bgp confederation peer <private-as>.

However, be aware that VPNv4 prefixes use more memory then standard IPv4 unicast prefixes so receiving multiple full BGP tables (770,000 prefixes each) inside a VRF will use much more memory then current setup on border devices.

Also the system wll try to assign a label to each prefix locally. You can finish the MPLS space in the local node as there are one million labels available (20 bits for label field).

You should look at a way to assign a single label for the VRF. There should be a way to configure this in IOS XR.

Hope to help

Giuseppe

[matt.malott]

I am still reading up on it, as I am not familiar with confederations. Will this allow me to configure my border routers with the same VRFs that are being used in the MPLS core? Currently, all of the internet customers that we have are connected into a VRF (VRF PUB_INT). My plan is to peer upstream internet providers and CDNs with a different VRF that will function as a border routing table (multiple full tables). I am importing all routes from PUB_INT to BORDER, but I will only be leaking and default route from BORDER to PUB_INT. This way, I don't have to filter prefixes at all of my neighbors at our route reflectors. Will using a confederation allow me to configure BGP on our border routers with our public AS?

[matt.malott]

I was able to get around my problem. I configured a confederation ID on my upstream peering routers with my public AS. I only have one private AS in our network, so I didn't need to configure any additional confederation peer AS's. Neighbors using the same AS are still peering using that AS, but neighbors using any other AS are now using the confederation identifier. I am still looking for a way to make sure our label table doesn't fill up and I will be filtering some routes to address the memory implications. If I have missed anything please let me know! I really appreciate everyone that took the time to reply and help! Thank you very much!

[Giuseppe Larosa]

Hello Matt,

thanks for your kind marking.

yes the big advantage of BGP confederation in your scenario is that it has minimal impact allowing you to keep the private BGP AS number in all internal routers and at the same time build true eBGP sessions using the public AS number on border routers.

About the possible problem of filling up the MPLS label space in the border routers in VRF Border, I can tell you that in Juniper JUNOS there is a vrf table label command that performs this.

In Junos the original use of this command is not only to minimize the number of labels used by a VRF but also to give a chance for a second lookup allowing to reach LAN based VRF access links.

see the following command in IOS XR that enables per VRF label

mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

As explained in the following link:

http://wiki.kemot-net.com/mpls-vpn-per-vrf-label

I think you need it at least for VRF Border on the border routers.

you should look at something like

mpls label mode vrf Border protocol bgp-vpnv4 per-vrf

This will make the VRF Border scalable at MPLS forwarding level avoiding the problem of limits of MPLS label space.

Hope to help

Giuseppe

[matt.malott]

It seems that the global commands in the links have been changed (these particular routers are running ios-xr 64-bit 6.5.3), but i found that this can be set on the individual VRF. This way I should be able to make the change only for VRF BORDER, which will only exist on border routers and on our route reflectors (I am using route reflectors to redistribute pick-up null routes for our prefixes to the border routers for prefix advertisement). It seems that it does cause a BGP recalculation though, so I'll have to schedule a window to make the change.

[matt.malott]

It actually seems to only be assigning a label to prefixes learned locally on the router. Since this is the case, I am able to just make this change on our border routers, but I can leave our route reflectors as-is since they aren't locally learning any routes in this VRF. I went ahead and made the change to VRF BORDER and didn't even observe a recalculation. The output of "sh mpls label table summary" is certainly much lower though, so perhaps they have perfected this process in this version.

[Giuseppe Larosa]

Hello Matt,

this is good news I agree that the change is needed only on the border routers as the RR just do their job of reflecting VPNv4 prefixes between clients, and they don't care about VRFs they do not need to have vrf BORDER defined on them at all.

With the command moved to vrf context it provides granular control. Nice to know.

Hope to help

Giuseppe