AS21299 - 46.42.196.0/24 ASN prepending 255 times

Mailman List Mirror (Read Only)
1

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let’s say 20. Thanks!

This is a Kazakhstan register IP Block and ASN

Network Next Hop Metric LocPrf Weight Path

*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner.
Thank you.

2

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks!

This is a Kazakhstan register IP Block and ASN

Network Next Hop Metric LocPrf Weight Path
*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 <many prepends snipped>

3

I emailed all the contacts listed for their ASN in the RIPE Database. One of them just respond to me saying they will fix this, so there is some hope that this will get addressed.

Now that you mentioned it. I remember seeing the previous thread and responding to it.

Erik

4

:slight_smile: probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Regards
Paschal Masha | Engineering
Skype ID: paschal.masha

5

Paschal Masha <paschal.masha@ke.wananchi.com> writes:

:slight_smile: probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Don't think so. But there is this draft suggesting max 5:

Bjørn

6

Many popular BGP implementations have historically had weaknesses
with excessively long AS-paths. Best practice is to protect ones'
infrastructure so many networks drop paths over certain lengths
(at various times, 50 or 100 were common due to specific issues).
It is highly common for any filtering mechanism, once established,
to stay in place, so I fully expect this path to be invible to many
and fragile for the rest [see
https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self-inflicted-vulnerability/].

That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in

where a decent low number (5) is propsed.

Chers,

Joe

7

That is one way of viewing it. But prepending can also be used for traffic engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does not appear to discuss this at all. The depth of prepending used this way only relates to how many different classes of peers you can imagine in your setup and is not at all related to the “internet’s diameter”.

To someone on the other side of the planet, who are neither peers nor customers of peers, they will just observe that I am prepending 3 or 4 times and wondering why the extra prepends? The answer is that closer to my home there are people who are observing the same routes with 1 or 2 prepends and that it matters.

The draft RFC lists some alternatives to prepends of which none can do anything of the sort I just described.

Regards,

Baldur

8

The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer than say 10. Depending on the situation, might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train.

9

Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson@merlin.mb.ca
www.merlin.mb.ca

10

Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson@merlin.mb.ca
www.merlin.mb.ca

11

Tom, how exactly does someone “ride the 0/0” train in the DFZ?

It’s not so much “ride the 0/0 train” as much as it is
“treat excessive prepends as network-unreachable”

Think of prepends beyond say 10 prepends as a way
to signal “infinite” distance–essentially, “unreachable”
for that prefix along that path.

Anyone that is prepending to do traffic engineering is
doing differential prepending; that is, a longer number
of prepends along one path, with a shorter set of prepends
along a different path.

So, dropping the inbound announcement with 255 prepends
merely means your router will look for the advertisement with
a shorter number of prepends on it.

If you’re only announcing one path for your prefix, and it is
prepended 255 times, you’re fundamentally not understanding
how BGP works, and the only way to get a clue-by-four might
be to discover you’ve made your prefix invisible to a significant
portion of the internet.

I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in order to do traffic steering. If there’s another solution that affects global inbound traffic distributions, I’d love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the primary route went away… at which point you may as well have not dropped it in the first place.

You dump the excessively-long path based on the assumption that
the only reason for a long set of prepends out one path is to shift traffic
away from that path to one that you’re advertising out with a shorter
set of prepends.

The router doesn’t need to ‘look’ for or ‘keep track’ of the different
path; the human makes the decision that any sane BGP speaker
would only prepend 255 times on a path if there was a shorter
as-path advertisement they wanted people to use instead.

So, drop the excessively long prepended path, and make use
of the ‘should be in the table somewhere’ advertisement of the
prefix with fewer prepends.

Easy-peasy.

12

Hi Matthew and NANOG,

I don’t want to defend prepending 255 times, and can understand filtering of extra-prepended-announcements, but I think Matthew may not be correct here:

Anyone that is prepending to do traffic engineering is
doing differential prepending; that is, a longer number
of prepends along one path, with a shorter set of prepends
along a different path.

So, dropping the inbound announcement with 255 prepends
merely means your router will look for the advertisement with
a shorter number of prepends on it.

Right. But let’s consider the (typical) case where someone is prepending for traffic engineering. Now, if you’re not very near to the origin of the prepended announcement, and still received it (and not the shorter alternative), then it is quite likely that you received it since the alternate path failed - and the backup path was announced, instead (by upstreams of the origin). So your router is quite likely not to receive the shorter announcement.

After all, if your router received both short and long announcements (from same relationship, e.g., both from providers), then your router would probably select the shorter path anyway, without need to filter out the long one, right?

So, filtering announcements with many prepends may cause you to lose connectivity to these networks. Of course, you may not mind losing connectivity to Kazakhstan :slight_smile: …

best, Amir

13

Hi Matthew and NANOG,

I don’t want to defend prepending 255 times, and can understand filtering of extra-prepended-announcements, but I think Matthew may not be correct here:

Anyone that is prepending to do traffic engineering is
doing differential prepending; that is, a longer number
of prepends along one path, with a shorter set of prepends
along a different path.

So, dropping the inbound announcement with 255 prepends
merely means your router will look for the advertisement with
a shorter number of prepends on it.

Right. But let’s consider the (typical) case where someone is prepending for traffic engineering. Now, if you’re not very near to the origin of the prepended announcement, and still received it (and not the shorter alternative), then it is quite likely that you received it since the alternate path failed - and the backup path was announced, instead (by upstreams of the origin). So your router is quite likely not to receive the shorter announcement.

Note that as-path prepending only matters as a differential value.

Choosing between 5 and 8 prepends, for example, gives you 3 levels of
differentiation between the paths.

Prepending 255 times is equivalent to setting MAXCOST in OSPF; it’s an
overload setting, saying “don’t freaking use this path EVER”.

If you want to traffic engineer, you set your less preferred path with
say 5 prepends, and your more preferred path with 3 prepends, and
your really really preferred path with 1 prepend.

If you’re setting 255 prepends on a path, that’s not traffic engineering,
that’s equivalent to setting the overload bit; it’s the maximum metric
equivalent in a link-state routing protocol. It’s clearly a DO-NOT-USE
indicator, in the same category as community 0xFFFFFF04 or
65535:0

In short–if someone sends me 255 prepends, it’s going to
be treated the same way as LSInfinity in OSPF.

Matt

14

Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the DFZ, my mistake.)

Essentially, if ASN X is announcing a prefix with an excessive number of prepends, they are saying to the world ‘This path exists , but it is hot garbage.’ I’m more than happy to oblige those instructions and just drop that announcement completely. If ASN X announces that prefix with a reasonable number of prepends, happy to take it and use it.

If I get a prefix with an as-path longer than 10, (regardless of the state of prepends), I interpret that as :

  1. They have made a mistake.
  2. Someone else made a mistake.
  3. They think that’s a good idea, and have some things yet to learn. ( The old clue by four as Matt put it.)
  4. It’s malicious.
  5. They actually are somehow more than 10 ASNs away from me. ( I don’t even know if this is possible anymore without extreme effort. )

In any of those scenarios , I don’t really care about optimized routing to that destination. Perfectly happy to just follow 0/0 to a DFZ upstream and let it go how it’s going to go, or not. If there is a traffic impact such that an exception HAS to be made, that can be addressed as needed, but I can’t think of a single circumstance I have hit where the correction involved accepting an obnoxiously long as_path announcement. ( I don’t mean to imply none exist ; I’m sure someone has had to work though that. )

Maybe a length of 10 doesn’t work for some environments and use cases, but I still am a firm believer that at a certain point, there is a length that becomes straight ‘really don’t care’. I’d rather not discover a BGP implementation problem or acid trip memory pointer party by accepting announcements that are useless.

15

Is prepending used for any purpose other than TE? The point I think Joe was trying to make was prepending once or even a few times has uses. Prepending more than a few times is unlikely to accomplish anything a few prepends didn't get done.

Prepending 50, 100, 200+ times is kind of a universal "We have no clue what we're doing and you should reject our routes."

Once upon a time, such long prepends would break certain BGP implementations, causing session resets when a route like this was encountered. Hopefully, that's not a problem anymore, but enough networks likely still block excessive prepends that you shouldn't expect to be able to do this and have your route globally accepted...just like you can't advertise a v4 /25 and expect global reachability if there are no covering aggregate advertisements.

The interesting question here is, "did they really think a few more prepends would get the job done?" or did they misunderstand their router's prepend function, prepend 21299 (thinking they were telling it to prepend their ASN), and that got truncated because the syntax was actually telling it how many times to prepend the local AS? I'm guessing the latter, as they seem to have 254 prepends, and I'm guessing 255 is the max number of instances of their ASN their router is willing to put on an advertised route.

16

Is prepending used for any purpose other than TE? The point I think Joe
was trying to make was prepending once or even a few times has uses.
Prepending more than a few times is unlikely to accomplish anything a few
prepends didn’t get done.

I suppose so-called “backup routes” could also be called traffic engineering yet it is different from the use case I described.

I understand the “diameter of the internet” to mean the maximum number of unique AS numbers in an AS PATH observed in any route in my DFZ routing table. Say I have two IP transit uplinks and I want one to be strictly backup meaning I want to receive no traffic unless the other is down. I might then prepend at least “the diameter of the internet” and that would be enough. Any more prepends will do nothing. This could probably be proven mathematically for the worst case, although in reality you would not even need that many prepends to get the effect.

However using prepends for traffic engineering in the sense prioritizing my peers relatively to each other is completely different. Especially true when some are peers on internet exchanges (not IP transit). Here the diameter of the internet is completely irrelevant. What matters is the number of classes I can make up for my peers. I admit those two numbers might not be all that different, but I feel it is still worth pointing out the error in the logic.

The logic is wrong even for the backup case. Say I have an extreme of N x IP transits and I want all of them to be backups in a strict order. Such that all traffic comes in on transit A. If transit A is down, then everything should use B. If A and B are down then 100% to C etc. In that case I would need to prepend “the diameter of the internet” on B and “the diameter of the internet” times two on C etc. Why times two and not + 1? Because when A is down we have B with a number of prepends. C needs to have “the diameter of the internet” more than B to be sure no traffic goes that way when B is active.

Prepending 50, 100, 200+ times is kind of a universal “We have no clue
what we’re doing and you should reject our routes.”

That is likely yes.

Regards,

Baldur

17

I partially agree with you, but… 10 is way too aggressive. I’m already seeing a “true” internet diameter of up to 13 AS hops today. Here’s the data I’m using to form that opinion.

[ NOTE: my tooling didn’t handle BGP confederations in the RIB dump properly. It’s sufficiently rare (only 1009 routes in total) that I’m not going back to square one to compensate for that, the data’s not noticeably skewed because of it, with one exception: the len=15 and len=16 entries in the de-prepended tale are both bogus. I left them in in the spirit of full disclosure. ]

This is the AS path-length distribution in my RIB as of a few minutes ago. Like everyone else, I do some moderately strange things for including artificially locally prepending routes from some of my upstreams, so I’m quite certain no-one else’s will exactly match mine. The overall shape of the distribution, though, should be very similar, probably with the peak shifted left or right slightly.

18

Joe Provo wrote:

:slight_smile: probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in
draft-ietf-grow-as-path-prepending-06 - AS Path Prepending
where a decent low number (5) is propsed.

Chers,

Joe
  
So is there a good way to signal along with a BGP route that the originator of the route wants you to know that this route has very high suckage factor and even if you normally prefer your peers customers whatever, you should perhaps think twice about that for this route, cause its really last resort.

Because as-path is an overloaded multimeaning traffic influencing hammer that has imprecise and frequently undesirable results. And if that were not the case, than discussions of its relative size compared to internet diameter would be much more relevant.

Joe

19

Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer’s customers are done using a relatively big and heavy hammer.

LOCAL_PREF is, in my opinion, the wrong tool to use, but it’s what most
of the networks out there seem to have settled on, to the point of having
published BGP communities to use for controlling the LOCAL_PREF setting
on received routes: https://onestep.net/communities/

I’ve long practiced, and advocated for, the use of MEDs or tweaking origin
codes as a better way to nudge traffic towards customers, peers, customers
of peers, etc., because it still allows as-path to be a factor in nudging traffic
away. Prepend inbound 3 times on routes learned from your transit provider,
but not on your peers, listen to MEDs from your peers, and enable always-compare-med
and deterministic-med to allow values to be compared across different pathways.

That way, someone trying to say “don’t use this path” can do a simple triple-prepend,
and see their traffic shift. In our current world of using LOCAL_PREF, however, the
poor customer keeps prepending more and more, and never sees their traffic shift.
In desperation, they prepend the maximum number of times allowed, hoping that
maybe this will somehow do the trick…not understanding that no matter what they
do in the prepend realm, so long as their upstreams are using the LOCAL_PREF
hammer, their prepends will fall on deaf ears.

For the most part–if you think LOCAL_PREF is the right knob to use for moving
traffic, it probably means you need to go back and rethink your traffic engineering
approach. ^_^;

Matt

20

Matthew Petach wrote:

Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.

IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it

<very good advice snipped>

For the most part--if you think LOCAL_PREF is the right knob to use for moving
traffic, it probably means you need to go back and rethink your traffic engineering
approach. ^_^;

Matt

I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go through nowadays, how about a long call back to each AS in the path using some sort of standardized service, perhaps published via DNS, sort of an automated looking glass results compared to update-out. And then the receiver, however many AS's away starts to get a much clearer picture of the intent all the through and maybe perhaps some much better intelligent automated properly reactive internet wide traffic engineering standards will emerge.

Until then I think a slew of standardized communities that elicit near universal and predictable standard reactions is probably the best bet. The problem is that shifting too much control to the advertiser makes it a non-starter from the point of view of the receiver, and then you can forget about deployment.

Would be nice to be able to publish your community scheme as simply conforming with RFCX and the to configure peers with process-rfcX statement and be mostly done.

Joe