BGP Backdoor Routes

[jallen314 (Justin A)]

@joedmangonon08

ask, why the AD of 2.2.2.2 a

Hey, are you saying that somehow they have a physical link between each other, or that there is an isp that is connecting them?

[ReneMolenaar]

Hi @jallen314 ,

A backdoor is usually a physical link connecting two sites. On this link, we run an IGP. This link could be owned by an enterprise, or perhaps an ISP provides it.

Rene

[sambhaji.ipar (Sambhaji Ippar)]

I see. Just for the sake of failover then why prioritize the OSPF here we already know the limitations of IGPs why use it for external networks

[lagapidis (Lazarus Agapidis)]

Hello Sambhaji

The use of a BGP backdoor is not something that should be used often nor should it be applied as a best practice. It should only be used out of necessity, and with great care, to resolve issues of redundancy or as temporary measures during a merger or a network migration.

You are right that IGPs have limitations as far as routing on the Internet is concerned, and as far as extremely large networks go. BGP backdoors shouldn’t typically be applied on the Internet. They should only be applied within an enterprise network. In the lesson, the example described that AS1 and AS 2 belong to the same enterprise. These locations will typically be in the same building, in the same campus, or they may be remote but have an independent backup path between them. Only under such circumstances would you use this feature.

While BGP backdoor routes can offer benefits, they also require careful planning and management to avoid unintended routing behaviors or conflicts with existing routing policies. The decision to use a backdoor route should consider the specific needs and architecture of the network, as well as the potential impact on traffic patterns and network performance.

I hope this has been helpful!

Laz

[davidilles]

Hello, everyone.

I have a question about BGP SOO (Site of Origin).

I got into SOO while studying for MPLS L3 VPNs which can create loops if an enterprise is dual/multi-homed to an ISP and as-override or allowas-in are used.

R3 and R4 advertise the 3.3.3.3/32 prefix into BGP. From R3’s perspective, R1-XR receives it, advertises it to R2, who returns it to R3 and R3 will gladly accept it due to allowas-in being configured on it

I understand that this is problematic as we are returning the prefix the customer is advertising back to them.

My question is, being multi-homed and having allowas-in doesn’t necessarily mean that problems (route coming back, suboptimal routing) will always occur, does it?

For example, in terms of suboptimal routing, R3 does receive the route back but doesn’t prefer it. This makes sense because it’s also originating that route with a very high weight.

However, if it wasn’t R3 who was actually advertising this prefix but someone else instead, R3 would prefer this path via the MPLS core.

In this case, we have suboptimal routing.

My primary question was already stated above, but to clarify it, it’s not always necessary to use site of origin when being multihomed to our ISP running L3 VPN, right?

For example, if someone was multihomed only like this:

R1-XR would never advertise the customer prefix back to it and nor would R2. That’s because they consider the CE routers as the best way to reach 3.3.3.3/32. The only case where they would actually advertise the prefix back would be if R1-XR (or R2) prefered the path via themselves instead.

Also, R3 would not install the route here sent by R1-XR since its locally originating it..

There feels like a lot that goes into this and different design will create different considerations, so I just wanted to share my thoughts here.

Thank you!
David

[lagapidis (Lazarus Agapidis)]

Hello David

I think most of your questions here have been answered in this post here:

MPLS Layer 3 VPN Explained

Hello David allowas-in and as-override are not loop-prevention mechanisms. On the contrary, they disable BGP’s AS-path loop check so that the prefix can be accepted, and your feeling that these seemingly necessary commands can cause problems is correct. Now, whether the MPLS path then gets preferred over the local OSPF path depends on BGP best-path tie-breaking. By default, such a setup is “safe” from loops because of BGP’s default behavior. However, this “safety” is, at best, fragile in a …

@davidilles

There feels like a lot that goes into this and different design will create different considerations, so I just wanted to share my thoughts here.

Yes that is indeed the case. I think the most important thing here is that it is best practice to implement SoO regardless of whether or not you “need” it. You would never want to route traffic to the ISP that should be routed internally, so by implementing SoO you are safeguarding this behavior.

@davidilles

For example, in terms of suboptimal routing, R3 does receive the route back but doesn’t prefer it. This makes sense because it’s also originating that route with a very high weight.

Of course, that makes sense, but even having that unpreferred route being received can be problematic. If at some point in the future you change the weight or another configuration to influence traffic differently, you may inadvertently cause a loop or suboptimal routing, requiring you to troubleshoot until you find the culprit. By implementing SoO initially, you safeguard the correct behaivior regardless of what other configs you may apply.

I hope this has been helpful!

Laz

[davidilles]

Hello Laz,

Yes, you answered everything. Thank you once again!

David