Just wondering if anyone else saw this yesterday afternoon ?
Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (567) More than configured MAXAS-LIMIT
Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 ... attribute length (568) More than configured MAXAS-LIMIT
Someone is having fun, creating weird and wonderful long AS paths based around AS 23456, we saw the same pattern of data from numerous upstream providers.
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
I currently have 27 prefixes in my Internet routing table with 40 or
more ASes in the AS path (show route aspath-regex ".{40,}").
I see no valid reason for such long AS paths. Time to update filters
here. I'm tempted to set the cutoff at 30 - can anybody see a good
reason to permit longer AS paths?
177.23.232.0/24 *[BGP/170] 00:52:40, MED 0, localpref 105 ...
...
I see no valid reason for such long AS paths.
[ assuming it is not the microtik thing ]
the /24 can not be sliced to steer inbound, so they're desperately
trying to push it away with prepend. of course, their upstreams all
prefer customers, so they keep adding prepends in some vain hope.
Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30
is OK for intra-planet routing, but when you start leaving the big blue
marble you will need to allow the packets to live longer.
> I see no valid reason for such long AS paths. Time to update filters
> here. I'm tempted to set the cutoff at 30 - can anybody see a good
> reason to permit longer AS paths?
Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30
is OK for intra-planet routing, but when you start leaving the big blue
marble you will need to allow the packets to live longer.
TTL != AS path length
I can certainly see the use for a TTL of 30. I cannot see the use for
an AS path length greater than 30 (especially not when 2 ASes are each
repeated 16 times).
What reason is there to filter them? They are not a significant fraction of BGP paths. They cause no harm. It's just your sense of tidiness.
You might consider contacting one of the operators to see if they do have a good reason you haven't considered. But absent a good reason *to* filter them, I would let BGP mechanics work as intended.
My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.
However, for this to be viable with plenty of unique prefixes to maintain
a large table, we have lots and lots of direct big and small peers and
much more than the usual amount of transit neighbors in our network.
Silicon Valley companies are very demanding for the fasted path with the
lowest number of router hops. ASN hops almost always lead to more router
hops in the trace. We have customers that call us if everything is fine
and they want to shave off milliseconds to favorite destinations. Picky,
picky, picky.
I am wondering how may other networks get requests (more like demands)
from customers wanting you to speed packets up to and from a specific
office in India or China. Customers knowing nothing about their office ISP
overseas. BTW, it's almost always they have the cheapest congested shared
office connection in the building overseas (especially in India). So they
can't do anything there except "pretend" about the bandwidth available.
About all they know is the IP address of the VPN and they were told they
have a full gig connection. Sure they have a gig port, but it's on a
switch together with 10 building neighbors that all also have a gig port
on a circuit to the building that no one can maintain a gig for more than
3 ms. Go ahead try and fix that latency packet dropping issue with a
firewall on both ends with SPI turned on in both directions. It's your
fault if you cant make it better. After all their VPN from London to
Bangalore works fine. And the ones in China all work fine to and from
Australia.
Anyways, I always wondered is it just me or do others get these kind of
requests?
There was a Cisco bug many years ago that caused lots of issues. Since then we have limited max-as to 50 and it has not caused any reported issues yet.
Uou're saying, you drop long AS_PATH, to improve customer observed
latency? Implication being, because you dropped the long AS_PATH
prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?
Absent of this policy, in which scenario would you have inserted the
filtered longer AS_PATH prefix to the FIB? I assume only scenario
where this happens is where there is larger aggregate route, which is
lower latency than the more specific route with longer as_path. Do you
have data how many of such paths exist and what is the latency delta?
I'm extremely skeptical that long AS_PATH rejection has any measurable
impact on aggregate path latencies.
Usually when someone starts griping about RTT between destinations more
than about 6 time zones apart, I start to talk to them about refraction
indicies, platform specific switching delay differences, stuff like that.
Normally I can chase them away or put them to sleep well before getting to
'I can break a lot of things, but physics is not one of them.'
A longer ASN path is not an automatic signifier of a longer latency path.
It can just as easily be a lower latency path that happens to traverse a
expensive link that AS doesn't like to use normally, but wants a backup. Or
maybe they have congestion inside their AS from that way in and want to
influence traffic away from it. Or maybe they just read that chapter and
thought it was a cool setting without knowing what it did.
Why not ask the operator why they are pretending this path? Perhaps they have a good explanation that you haven't thought of. Blindly limiting otherwise legal path lengths is not a defensible practice, in my opinion.
Why not ask the operator why they are pretending this path? Perhaps
> they have a good explanation that you haven't thought of. Blindly
> limiting otherwise legal path lengths is not a defensible practice, in
> my opinion.
> -mel beckman
A prepend like that is usually the result of someone using the IOS
syntax on a XR or Junos router.
Long ago, someone accidentally prepending 255 times hit a bug (or was it
a too strict bgp implementation? I don't remember) resulting in several
networks across the globe dropping neighbors. One has to protect against
these things somehow.
As a data point, here is how many prefixes I see on my network for each
as-path length, after removing prepends:
You do have to wonder, what was the thought process that resulted in 35
being the right number of prepends "accomplish" whatever TE they were
shooting for?
I don't mean to single out 55644. It's just the first/most obnoxiously
long as-path I found when looking for long ones.
I seriously doubt provider/customer/customer-of-customer relationships ever get much deeper than a handful or so of ASNs...so if prepending a few times doesn't get it done, 10-20-30 prepends are unlikely to help.
In the above case, that long path is actually our best path. We localpref peering above transit. So, it doesn't matter how many prepends, they add, we're never going to not use this path if its available. We have transit paths to these routes that are only a single handful of ASNs long.
I see 5+ prepends as maybe not reason to have your "BGP driving license
revoked" but if I can continue with the concept that you have your BGP
learners permit.
If I think back to when I learned to code or when making ACL's, we still
used line number and practice would be to give ourselves lots
of space 5 or 10 numbers in case we have to insert something in the middle.
ie I need 2 sets of prepends, I'm still learning this stuff
so I'll go with 5 and 10. We all started somewhere, we all did dumb stuff,
hopefully, we all learned.
12AS hops, I have to go see how they are connected now, maybe someone in
that chain needs to be invited by an IX to a NANOG or GPF or some such,
that can't be super efficient.
I think I understand the problem, and now I understand why prepends
didn't do much for me. Over the years, I tended two multi-homed sites.
In both cases, the two uplinks had different speeds. When I used
prepend to try to get the outside world to prefer the faster link, some
traffic was stubborn about coming in the slow one.
Difference in speeds? In the first network it was 45 mbps and 10 mbps.
In the second network it was 16 mbps and 1.5 mbps. Both network owners
were too stingy at the time to opt for harmonized rates.
Question: how could communities be used to "force" preference for one
uplink over another by the peers? I'm long past needing this, but
others might benefit. (And when you stop learning, you're dead.)
The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it.