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 -- <https://img.beta.newoldstamp.com/r/13887/p> Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan@myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net <https://www.wilkes.net> myriverstreet.net <https://www.myriverstreet.net> <https://img.beta.newoldstamp.com/r/13833/facebook> <https://img.beta.newoldstamp.com/r/13833/twitter> <https://img.beta.newoldstamp.com/r/13887/youtube> <https://img.beta.newoldstamp.com/r/13833/linkedin> <https://img.beta.newoldstamp.com/r/13833/instagram> This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you.
On 16/Sep/19 13:35, Ben Logan wrote:
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?
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 On Mon, Sep 16, 2019 at 7:47 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Sep/19 13:35, Ben Logan wrote:
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?
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.
-- <https://img.beta.newoldstamp.com/r/13887/p> Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan@myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net <https://www.wilkes.net> myriverstreet.net <https://www.myriverstreet.net> <https://img.beta.newoldstamp.com/r/13833/facebook> <https://img.beta.newoldstamp.com/r/13833/twitter> <https://img.beta.newoldstamp.com/r/13887/youtube> <https://img.beta.newoldstamp.com/r/13833/linkedin> <https://img.beta.newoldstamp.com/r/13833/instagram> This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you.
On 16/Sep/19 14:47, Ben Logan wrote:
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.
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 On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Sep/19 14:47, Ben Logan wrote:
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.
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.
-- <https://img.beta.newoldstamp.com/r/13887/p> Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan@myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net <https://www.wilkes.net> myriverstreet.net <https://www.myriverstreet.net> <https://img.beta.newoldstamp.com/r/13833/facebook> <https://img.beta.newoldstamp.com/r/13833/twitter> <https://img.beta.newoldstamp.com/r/13887/youtube> <https://img.beta.newoldstamp.com/r/13833/linkedin> <https://img.beta.newoldstamp.com/r/13833/instagram> This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you.
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 On Mon, Sep 16, 2019 at 7:13 AM Ben Logan <benlogan@myriverstreet.net> wrote:
Thanks, Mark, that makes sense.
Take care, Ben
On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Sep/19 14:47, Ben Logan wrote:
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.
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.
-- <https://img.beta.newoldstamp.com/r/13887/p> Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks
Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan@myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net <https://www.wilkes.net> myriverstreet.net <https://www.myriverstreet.net> <https://img.beta.newoldstamp.com/r/13833/facebook> <https://img.beta.newoldstamp.com/r/13833/twitter> <https://img.beta.newoldstamp.com/r/13887/youtube> <https://img.beta.newoldstamp.com/r/13833/linkedin> <https://img.beta.newoldstamp.com/r/13833/instagram>
This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you.
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 On 9/16/19 3:05 PM, Mark Tinka wrote:
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. Longest match always wins... so provided your /22's are in the global
On 16/Sep/19 14:47, Ben Logan wrote: 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.
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.
Peace, On Mon, Sep 16, 2019, 6:06 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
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.
Not always. 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. There are more complicated cases as well. -- Töma
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
On Sep 16, 2019, at 11:26 , Töma Gavrichenkov <ximaera@gmail.com> wrote:
Peace,
On Mon, Sep 16, 2019, 6:06 AM Mark Tinka <mark.tinka@seacom.mu <mailto:mark.tinka@seacom.mu>> wrote: 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.
Not always.
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.
There are more complicated cases as well.
-- Töma
Peace, On Mon, Sep 16, 2019, 12:04 PM Owen DeLong <owen@delong.com> wrote:
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.
The point is that you must expect inbound traffic to any prefix you advertise to the outside world, even a more specific announcement is also being advertised. There are legitimate circumstances where an ISP would prefer the super-block. -- Töma
On 16/Sep/19 21:55, Töma Gavrichenkov wrote:
The point is that you must expect inbound traffic to any prefix you advertise to the outside world, even a more specific announcement is also being advertised. There are legitimate circumstances where an ISP would prefer the super-block.
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.
On 16/Sep/19 20:26, Töma Gavrichenkov wrote:
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.
participants (8)
-
Arie Vayner -
Ben Logan -
Mark Tinka -
Martijn Schmidt -
Niels Bakker -
Owen DeLong -
Ross Tajvar -
Töma Gavrichenkov