Hello,
In reviewing our BGP routing policies last week, I realized that we are advertising our address space upstream in slightly different ways to our two upstream providers. For example, we might advertise a /21 to one provider and break that into two /22s when advertising it to the other. (The reason this was done was to help with traffic engineering–we’d prepend one of the /22s to help balance the traffic. Prepending the entire /21 might have been too much.)
I’m just wondering if that’s acceptable practice, or if we should advertise consistent prefixes between providers?
Thanks,
Ben
While de-aggregating certainly puts pressure on the Internet, it's
reasonably acceptable if done conservatively. What you are doing is
acceptable, so it can be considered okay, particularly if your bandwidth
purchases from your upstreams is not symmetric.
Also, I recall prepending did have some material result as much as 10
years ago. I'm not sure whether it is as effective in 2019, considering
how well peering has grown globally. From my side, since about 2012,
it's a feature we haven't utilized in any way or form, even if we do
currently offer it to our customers via a BGP community.
YMMV...
Mark.
Thanks, Mark. So the discrepancy between what’s being advertised (/21 vs /22) shouldn’t cause any issues? That’s the part I got a bit confused about. I don’t see how it would, but I wanted to make sure.
Thanks,
Ben
Longest match always wins... so provided your /22's are in the global
table, traffic will follow the path toward them before the /21 is preferred.
So, for example, if the upstream to whom you are sending the /21 doesn't
do anything about how they learn the /22 from another source, (for their
network) they will also send traffic back to you via the /22 path. This
may or may not be preferred by you, or them. I suppose that's the main
thing to think about.
Mark.
Thanks, Mark, that makes sense.
Take care,
Ben
Hi Ben,
Prefix deaggregation and inconsistent announcements might work fine in
the US where all paths are mostly of equal quality, but is the bane of
my existence when it happens in regions like the Middle East or Africa
where one transit used by a target ISP might be connected locally and
the other connected in Europe. If you want to steer traffic you may be
better off using BGP action communities, I'll leave you with this
excellent presentation from RAS to provide some background on what might
be achieved with that:
https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
Best regards,
Martijn
Ben,
To make it a bit cleaner, you most likely want to send your aggregate (/21) to all service providers, and then if you choose to deaggregate and create more specific advertisements for traffic engineering purposes, you just advertise the relevant longer prefixes (/22’s for example) on the specific uplink you want the traffic to return on.
So for example, let’s say you have a /21, and you want to split the traffic across 2x /22’s, you advertise the /21 on both ISP links, and a single (different) /22 on each ISP link.
This way the more specific route (/22) will pull the traffic towards the ISP that is advertising it, but in case of a failure on one of those links, you still have the /21 aggregate that will pull all the traffic to the other link.
This should generally work, but may have strange edge cases, especially when ISPs do their own (not necessarily standard) traffic engineering.
For example ISP A, getting a /21 could set the local preference for that /21 higher than other peers (where they would be learning your other /22), so traffic originating from this local ISP would take the local path regardless of your policy. This is when you will have to start looking at their BGP communities…
Tnx
Arie
https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
Don’t let anyone send you Informational tags, these should only be set by you, and you should strip them from all BGP neighbors (customers, transits, peers, etc). Otherwise you have a massive security problem.
I often see informational tags propagated through multiple ASes. What is the security risk there?
https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
Don’t let anyone send you Informational tags, these should only be set by you, and you should strip them from all BGP neighbors (customers, transits, peers, etc). Otherwise you have a massive security problem.
* ross@tajvar.io (Ross Tajvar) [Mon 16 Sep 2019, 19:14 CEST]:
I often see informational tags propagated through multiple ASes. What is the security risk there?
Don't let anyone send you *your* informational tags.
-- Niels.
For any router which receives both announcements, longest match always wins over all other BGP tie-breaking criteria.
This is almost always summarized as “Longest Match always wins” because virtually any engineer recognizes that the
winner is selected only from the available contestants, not from unknown distant contestants not present at the router
in question.
Owen
Not always.
No, longest match ALWAYS wins.
E.g. imagine an ISP who has two connections to the outside world: one
through a major ISP and the other through an IX.
Such an ISP would be quite inclined both financially and technically
to import routes just from the IX and set the default to the upstream
ISP link. Therefore, an advertisement from the IX would always win no
matter the length.
Which is why I included, in my previous message:
So, for example, if the upstream to whom you are sending the /21 doesn't
do anything about how they learn the /22 from another source, \(for their
network\)\.\.\.
Mark.
It's not about the business reasons for wanting it, it's about what the
router does if it's presented with the options.
Like I said before, you can do things to your network to prevent your
router from installing a longer prefix. But if you do not, the longer
prefix will always be installed and used, first.
Mark.