Hi Laz ,
Superb .
Thank you so much .
Tanmoy
1 Like
Hi Rene,
Will AS Override work inbound, outbound or both ways? Meaning, will PE1 replace AS 12 with its own upon receiving the advertisement from CE1? Or when advertising the prefix to CE1? I guess this second case would only occur if there was no AS Override on PE2âŚ
Thanks,
LP
Hello Luis
The AS override will replace the AS number of the advertised route before sharing it with the CE1 router. In the lesson topology, PE1 will receive a route to 5.5.5.5 with an AS of 12. Before advertising it to CE1, it will replace the AS of 12 with an AS of 234. So from the PE1 point of view, this occurs in an outgoing direction. This will not take place when CD1 advertises 1.1.1.1 to PE1 with AS12 as the AS. Because AS 234 will accept such an AS, there is no need to change this on an incoming direction from the point of view of PE1.
I hope this has been helpful!
Laz
Hi,
When you see your own AS number in the AS path, we do not accept the prefix. This mechanism is fine for Internet routing but there are some other scenarios where this might be an issue.
Can you show how this is ok for internt routing ?
Thanks
Hello Sims
The default behaviour of BGP is that a BGP router will not accept a path to a destination that contains its own AS number. This mechanism is not only OK for the Internet, but it is absolutely necessary. Take a look at the following diagram:
Letâs say that R1 shares a route to destination D with R2 via eBGP. If that route includes AS4 in its path, R2 will not accept it and wonât put it in the BGP table. Why? Because this means that somewhere along the line, BGP has created a loop.
If R2 does put this in its routing table, then when R2 wants to reach destination D it will send such packets to the installed route, but those packets are destined to reenter AS4 at some point (since AS4 is in the path) resulting in a loop.
By not accepting paths that include the local AS, BGP prevents loops which is vital for correct Internet routing.
The lesson here however, indicates a situation where this feature can cause problems, in particular, in a VPN environment such as the one described in the lesson.
I hope this has been helpful!
Laz
Hi,
Thanks for the reply . I did understand about the loop but what about the second part of the question . How it is ok for internet routing
Thanks
Hello Sims
Rene mentions in the lesson that:
This mechanism is fine for Internet routing
However, I will go further in saying that this mechanism is not only fine but is absolutely necessary. The example I shared in the post describes this default behavior and demonstrates that it is necessary for use on the Internet. Otherwise, we would have many routing loops, and the Internet as a whole will slow down considerably.
When Rene says âitâs fineâ for the Internet, he means that it works just fine simply because that is the expected, but also the required behavior.
I hope this has been helpful!
Laz
My other question is, why is BPG the preferred choice of routing between CE to PE? I understand many enterprise customers donât have public ASNâs, does the service provider provide their customers with private ASNâs? or how does it work? what can the service provider do to make sure they donât advertise the customerâs private ASN to another external tier 1 service providers?
Hello Walter
BGP as a routing protocol is a preferred choice for the edge network of enterprises in general, regardless of what the WAN technology being used is. This is because BGP has advantages such as dual and multihomed topologies as well as route advertisement options not made available through other routing protocols.
Now having said that, remember that MPLS is not a technology that typically connects users to the Internet, but interconnects multiple branch sites together. In such a scenario you donât need public ASNs to function. You can use your own ASN, but in most cases, you coordinate with the MPLS service provider for what ASN to use for your particular locations. This is because the MPLS provider will also be using private ASNs and you must make sure that youâre not duplicating ASNs in the MPLS network.
I hope this has been helpful!
Laz
1 Like
How can i filter and donât advertise to same asn in a different site if i am receiving the prefix from same asn from other site ??, i dont want to give those prefixes as an ISP to CE even if the customer is configured the allow as in .
Hello Narad
The purpose of not accepting a prefix via eBGP if it belongs to your own AS is to prevent loops. This is the default behavior. You can override this using the commands shown in the lesson.
Now having said that, if you as an ISP want to filter out some prefixes that are advertised to CE devices, you can always do this using the various filtering techniques shown in Unit 5 of the BGP course. But as an ISP, you donât want to do that because you want the customer to be able to advertise whatever they want to their other sites. Otherwise, you would be messing with their internal routing, and I canât think of a situation where you as an ISP would want to do that.
Now keep in mind that this scenario is valid only for situations where you are running eBGP between the CE and PE devices. If youâre using an IGP such as EIGRP or OSPF, this situation would not come upâŚ
I hope this has been helpful!
Laz
Any situation in MPLS L3VPN scenario where as-override can be harmful when used between BGP PE-CE routing?
Hello Muhammad
One of BGPâs loop prevention mechanisms is to deny the installation of a route that contains a routerâs own AS in the AS-PATH. This is very effective on networks such as the Internet. Using the as-override feature in such a case can be disastrous!
However, within a controlled private network, such as an MPLS network that a single ISP manages, the use of as-override is quite safe. This is because a typical MPLS network has one or more centralized core ASes from which customer ASes hang off of. This is kind of like a tree structure, where the core ASes are the roots. In such a topology, there is no case where you would have a series of ASes in a loop arrangement.
As a result, using the as-override is safe in such an environment.
I hope this has been helpful!
Laz
1 Like
Hi
I am able to see the 2.2.2.2 routes in âNOIDA_TCL_4â Routerâs routing table &
I am able to see the 4.4.4.4 routes in âACH_TCL_2â Routerâs routing table
But unable to ping to each other.
Trace is dropping in PE router.
Sharing the PE router configuration in the attached Pic.
Hello Pratik
You must make sure that the source of your ping is the loopback address of the CE router. As shown in the lesson as well, the pings are sourced from loopback 0 on the CE1 router and are destined for the 5.5.5.5 destination, which is the loopback on CE2.
If you just ping or traceroute, the router will use the IP address of the Gi0/0 interface, which is, in your topology, 10.124.2.78. However, your ACH_TCL_2 router doesnât know how to reach the 10.124.2.76/30 subnet, so the ping/traceroute fails at your PE router.
Issue the following command at your NOIDA_TCL_4 router:
NOIDA_TCL_4#ping 2.2.2.2 source loopback 0
Let us know how you get along!
I hope this has been helpful!
Laz
Thanks Team, It has been resolved after replacing the IOS in the EVE-NG.
Configuration was correct because of routers already placed in both routers
Hello Pratik
Great news! Thanks for letting us know!
Laz
Hello,
I understand how the command works and what it does. I have labbed it and all good. However, I cannot understand the use of this with the SoO feature in BGP. I have labbed also a MPLS L3 VPN topology like the one shown in the lesson, and when implementing the BGP SoO feature, then the prefixes advertised from one CE router donât get advertised by the PE routers to the other CE router, because the PE routers match the CE neighbor SoO with the SoO extended community attribute carried in the routes, and the routes donât get advertised to that CE neighbor. This worked well for loops that were being created because the routes were getting advertised all the way round to the original CE router via a backdoor link between CE routers. But this loops could be avoided simply by not using the as-override command on the PE routers.
However, I still want prefixes to get advertised from one CE to another via the MPLS VPN backbone, using eBGP between PE-CE and both CE routers in the same AS, which makes me use the AS-override feature. But then all the articles I have read say that we should implement the BGP SoO feature to prevent loops, which is completely understandable. But then, when I implement it, I am back in step 0 with no prefixes being advertised from CE to CE via the MPLS VPN backbone.
I cannot understand the purpose of the SoO then. Why is it needed if is going to block all the prefixes from the other CE router in the same customer group / site? Wouldnât be much easier to not use the BGP AS-Override feature then, and in case some prefixes need to get to the other CE via the MPLS VPN backbone, then just filter them? Am I doing things wrong by implementing both the as-override feature and the SoO feature at the same time in the same PE routers? Or is it meant for other purposes? I am very confused.
I know there must be a reason why the SoO feature exists, but I am confused. I can only see the feature undoing what the AS-override feature does, and the AS-override (or allowas-in) is needed to get prefixes to the other CE in the same AS via eBGP, so then I find no sense to use the SoO but at the same time I can get the loops. I am very confused.
Please if someone can clarify,
thanks
Pablo
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:
I hope this has been helpful!
Laz