Let’s put into play AS-Override feature in BGP: see when it applies and how it works.
First, AS-Override feature applies to sites that have the same AS number but are linked by another different domain with different AS number, as in the next figure. In our example AS number 1 has neighborship (E-BGP links) to two AS with the same number…
We recall that in BGP, loop prevention would prevent any site from learning other site routes due to the presence of the same AS number in the AS_PATH of the advertised routes. Thus any route (route information) received by CE2 that has originated in CE1 would be rejected (by CE2 BGP processing configured with ID 65001, the same) due to the presence of AS number 65001 in the AS-PATH attribute attached to this route.
When AS Override is applied under the VPNv4 address-family, any site AS number occurrence in the announced AS_PATH would be replaced by the linking AS (here AS number 1) number and thus, allowing routes to be learnt at the other site.
Let us check step-by-step how this feature could help in a situation similar to the network of figure 1. Routers are Cisco 7206VXR GNS3 emulated and run C7200 ADVENTERPRISEK9-M IOS version 15.3(3)XB12.
The PE routers are in the same AS and establish a neighborship directly under the VPNv4 address-family. The PE-CE neighborships are configured under the corresponding IPv4 VRF address-families.
We check as in figure 2, that RT57 related updates are being dropped at CE2 due to “AS-PATH contains our own AS”.
In figure 3, we check that RT57 is learnt at PE2 from PE1 with CE1’s AS#65001 prepended.
We configure next, as-override feature on PE2 neighborship to CE2. In figure 4, we can check under the corresponding neighbor statement that the feature is enabled.
RT57 corresponding update is now being accepted by CE2 from PE2 as in figure 5.
We change CE1 AS number to 65002 and and configure it to open a session to PE as if it was from AS#65001 (local-AS feature).
At the same time we build an eBGP neighborship between CE1b and CE1. CE1b is in AS#65001 like in figure 6. We annouce RT75: 75.0.0.0/24 from CE1b to the rest of the network.
We check in figure 7 that all occurrences of CE1 AS, that is the same AS as CE2, numbers in RT57 are being replaced by PE2 AS number.
In figure 8, we change CE2 AS number to 65002.
In figure 9, we check that AS#65002 gets replaced by PE2 AS number independently of its position in the advertised AS-PATH to CE2.
As a conclusion, PE2 replaces all occurrences of its peer CE2 AS number in the updates it sends by its own number and independently of their occurrence position in AS_PATH.
It is to note that this feature applies only to the VPNv4 address-family either by configuring a PE-to-PE neighborship directly under the VPNv4 address-family or on the corresponding IPv4 VRF address-family in VRF-Lite fashion.
The latter case would require PE-to-PE dedicated links to VRFs. The PE-CE neighborships are still configured in both cases under the corresponding IPv4 VRF address-families.
It could seem contradictory to see that this feature is not supported on IPv4 address-family and at the same time being supported on a VRF-Lite similar to IPv4 address-family deployment.
In figure 10, we check that this feature is not supported on test routers and installed IOS versions.
In this case, one could argue that this is an enhancement to the actual BGP implementation but the 4271 RFC states clearly that AS_PATH is modified based on the location of the BGP speaker and in our case by prepending its own AS number as the last element of the sequence to updates sent on an eBGP neighborship.
This feature could prevent CE router detect BGP routing loops in case sites are configured with backdoor links (iBGP as an example). Site-Of-Origin feature implementation could help tag those routes and prevent their re-announcement.
To achieve the same result, we could configure the Allow-AS feature on CE. As in the previous case, some filtering is required to prevent routing loops.
Another possibility is to use iBGP to build CE-PE links. The advantage of such configuration is that the same AS number is used transparently among all VRFs. PE-PE neighborship is built under VPNv4 address-family. However, we still need control over iBGP route-reflection and next-hop advertisements.
