Hi, There is an interesting discussion going on in the IDR WG and i am cross posting a mail on Nanog to hear from the operators, if what is described below, a common practise followed by them:
I don't think its correct to advertise one while using both for forwarding. NOTE: I am assuming that the routes share the same path length but have different AS Paths (as mentioned by you earlier in this mail)
I think this is being done by many providers.
Consider two paths for nlri X
as_path 1 {x y z} next_hop n1 as_path 2 {m n z} next_hop n2
Are you suggesting that providers are installing ecmp routes for X with next-hops n1 and n2, while advertising only one of the paths to their IBGP peers?
Yes.
Do providers really do this? Would they install multiple BGP Paths with different AS Paths (but same length) in their FIB, and yet advertise only one? Is the the right thing to do? Glen
Hi Glenn, Glen Kent wrote:
Hi,
There is an interesting discussion going on in the IDR WG and i am cross posting a mail on Nanog to hear from the operators, if what is described below, a common practise followed by them:
I don't think its correct to advertise one while using both for forwarding. NOTE: I am assuming that the routes share the same path length but have different AS Paths (as mentioned by you earlier in this mail)
I think this is being done by many providers.
Consider two paths for nlri X
as_path 1 {x y z} next_hop n1 as_path 2 {m n z} next_hop n2
Are you suggesting that providers are installing ecmp routes for X with next-hops n1 and n2, while advertising only one of the paths to their IBGP peers?
Yes.
Do providers really do this? Would they install multiple BGP Paths with different AS Paths (but same length) in their FIB, and yet advertise only one?
Is the the right thing to do?
I believe the problem is with the BGP withdrawal mechanism. When BGP withdraws a route it only specifies the prefix being withdrawn and not the path. In this case, if the peer advertised both paths {x y z} and {m n z} for a single prefix it would be impossible to withdraw only one of the paths. I guess, even when using ECMP, BGP still really only considers there to be one best route. Everything else is local FIB manipulations based on local policy (in a similar vein to policy routing - the BGP advertisements don't always reflect which way the traffic will actually be routed). Sam
Do providers really do this? Would they install multiple BGP Paths with different AS Paths (but same length) in their FIB, and yet advertise only one?
Is the the right thing to do?
What you see in BGP is not necessarily what you get for actual routing. This isn't the only situation where advertisements do not match actual routing. Consider traffic engineering systems such as the Internap FCP (old NetVMG). Imagine I have two upstreams (A and B) and you advertise a /20. I might prefer path A for your /20. However, my traffic engineering system may inject a no-export /24 route into my network to shift a portion of your traffic to go out my upstream B. This is quite interesting/confusing from the customer perspective, where you only see the BGP path through upstream A advertised, yet in reality a /24 out of that /20 is going through a completely different path that you do not see via BGP. Is this wrong/evil? I guess that is up to each network to decide. Disclaimer: I use such a system and have many /24 no-export routes in my table. It works great and keeps my 7 upstream providers all nicely balanced with no manual intervention ever. However, I have no BGP downstreams so the above misrepresentation of BGP advertisements is not an issue since it never leaves my network.
What you see in BGP is not necessarily what you get for actual routing. This isn't the only situation where advertisements do not match actual routing. Consider traffic engineering systems such as the Internap FCP (old NetVMG). Imagine I have two upstreams (A and B) and you advertise a /20. I might prefer path A for your /20. However, my traffic engineering system may inject a no-export /24 route into my network to shift a portion of your traffic to go out my upstream B.
This is quite interesting/confusing from the customer perspective, where you only see the BGP path through upstream A advertised, yet in reality a /24 out of that /20 is going through a completely different path that you do not see via BGP.
Is this wrong/evil? I guess that is up to each network to decide.
This situation subverts BGP's basic loop prevention mechanism. If the /20 is ever deaggragated into more specifics, a forwarding loop may result. If you want to put rounds in the chamber before pointing the muzzle at your temple, you're free to do so. However, some of us would prefer to stand a long way away. Tony
This situation subverts BGP's basic loop prevention mechanism. If the
/20 is ever deaggragated into more specifics, a forwarding loop may result.
If you want to put rounds in the chamber before pointing the muzzle at your temple, you're free to do so. However, some of us would prefer to stand a long way away.
It seems to me that this is only true if there is ever a possibility of one of your next-hops believing the route to the destination is back through you - or perhaps if the upstream has no route at all to the destination. In the case of most non-tier-1 networks, any packet destined for anywhere outside my own ASN (and customer ASNs if you have BGP customers - which I do not) can be handed to any upstream transit provider without fear of looping. So, the device injecting the traffic engineering route needs to be smart enough to never inject a route that matches an announcement of you or your customers. Beyond that, looping (should) never happen simply by definition of the transit/customer relationship. So, it subverts BGP's loop detection - but the transit/customer relationship (hopefully combined with appropriate announcement filtering) avoids the issue. Of course, if you leak one transit provider to another, and that gets accepted, you might loop due to your traffic engineering routes - but at that point you've got plenty of problems anyway.
participants (4)
-
Glen Kent -
Matt Buford -
Sam Stickland -
Tony Li