Hello Pablo
The issue that you are dealing with has to do with the interaction between BGP AS-Override and SoO, especially in the context of MPLS L3 VPNs, where CE devices in the same AS might create a looping situation. Let’s unpack this a bit:
AS-Override as shown in the lesson is used when we have CEs in remote locations from each other that are in the same AS as in the lesson. This feature allows us to overcome the default behavior of eBGP, which is not accepting a prefix from its own AS.
The SoO feature is intended to prevent routing loops in MPLS L3 VPNs, particularly in multi-homed CE environments, where multiple CE routers connect to the MPLS cloud via multiple PE routers or where there’s a backdoor link between CE routers. The SoO prevents a PE router from advertising routes back to the site they originated from (to avoid loops), based on the SoO extended community. It is applied on the PE routers to tag prefixes from a CE, and the SoO is then used to prevent those prefixes from being advertised back to the same site.
When you use AS-Override and SoO together, here’s the core issue you’re encountering:
- AS-Override rewrites the AS path to allow prefixes from one CE to be accepted by another CE in the same AS.
- SoO kicks in and blocks the prefixes from being advertised back to the CE, as it sees them as originating from the same site (based on the SoO value). This is useful in a multi-homed or backdoor link scenario to prevent loops but becomes problematic when you do want to advertise prefixes between CEs in the same site.
Why Use Both?
You’re correct in thinking that these two features can appear to “undo” each other. Here’s why they are often used together:
- AS-Override is necessary to allow routing between CEs in the same AS across the MPLS backbone as in the lesson.
- SoO is necessary to prevent routing loops in topologies where multiple PEs connect to the same CE site (especially in multi-homed setups) or where there are backdoor links between CE routers that could introduce loops.
What to Do?
- Use AS-Override where needed: This ensures that routes from one CE can be accepted by another CE in the same AS.
- Adjust SoO implementation carefully: You may need to modify the application of SoO based on the specific topology. For example, if the PE-CE connection is the only connection between sites and there’s no risk of loops, you may not need SoO at all, as is the case in the lesson. If there are backdoor links or multi-homing, you could implement route filters or adjust SoO application only to those interfaces where loops are a concern.
In essence, AS-Override is useful for eBGP between CEs in the same AS, while SoO is vital for loop prevention in multi-homed scenarios or when there are backdoor links. If you don’t have a risk of loops, you might not need SoO in your setup. Otherwise, careful SoO placement combined with filters may give you the best result.
An excellent explanation and analysis can also be found at this site which may be helpful for you:
https://learningnetwork.cisco.com/s/article/bgp-site-of-origin-soo-concepts-amp-configuration
I hope this has been helpful!
Laz