Is there something silly going around? I doubt I'm the only one noticing these being triggered by our generous maxas-limit setting.
Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ...
Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ...
Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ...
Anyone have theories as to what these networks are trying to accomplish?
Yeah...prepending isn't a big deal...but when someone prepends their own AS 70+ times, I wonder WTF they're thinking.
Jon Lewis wrote:
Yeah...prepending isn't a big deal...but when someone prepends their own AS 70+ times, I wonder WTF they're thinking.
I'm sure they get the attention of NOCs around the world as messages like this show up on consoles
Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for aspath. Replenishing with malloc
This time I couldn't be bothered to dig too deeply into who was the cause.
You might consider something like bgp maxas-limit 75 to exchange that log message for the less scarey
Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ...
As an added bonus, you ignore their route while they're playing such games.
Jon Lewis <jlewis@lewis.org> writes:
You might consider something like bgp maxas-limit 75 to exchange that
log message for the less scarey
Oct 22 06:34:09: %BGP-6-ASPATH: Long AS path ...As an added bonus, you ignore their route while they're playing such
games.
Which is exactly what they want. What you *really* want to do is:
router bgp foo
neighbor bar route-map prepend-this-you-fool in
ip as-path access-list 66 permit _blah_blah_blah_blah_blah_blah_blah_blah_blah_
route-map prepend-this-you-fool permit 10
match as-path 66
set local-preference 1000
-r
Sounds like some automated scripts that didn't do any sanity checking.
Process pulls the current BGP table, checks for the longest path, and
then prepends the AS that many times to guarantee everyone takes the
other path. But if two ISPs are doing this, well, the paths get longer
and longer. I just checked our table for those ASs mentioned in your
log, they look short now. Guess they caught it.
Chuck
Jon Lewis said the following on 23/10/08 12:39:
Is there something silly going around? I doubt I'm the only one
noticing these being triggered by our generous maxas-limit setting.Oct 9 23:01:46: %BGP-6-ASPATH: ... 27754 27754 27754 ...
Oct 17 11:10:40: %BGP-6-ASPATH: ... 43413 43413 43413 ...
Oct 22 06:34:09: %BGP-6-ASPATH: ... 38230 38230 38230 ...Anyone have theories as to what these networks are trying to accomplish?
Theories include:
- trying to make a /20 announcement more important than a component /24
by prepending the /24 out of sight (i'm not joking, some people really
believe this!!)
- trying to over-ride policy that their upstream provider has applied
(e.g. my prepended /20 is a backup to my main /20 announcement but my
upstream on the backup path is local pref-ing high to make them look
more "peerable")
There are bound to be other reasons... 
philip
Not using that prepended route is exactly what the point of the prepend
is, so that's not "punishment".
It may, in fact, be exactly what they're trying to get you to do.
From: Jon Lewis [mailto:jlewis@lewis.org]
Sent: Wednesday, October 22, 2008 8:17 PM
To: Mike Lewinski
Cc: nanog@nanog.org
Subject: Re: What's with all the long aspaths?I'm sure they get the attention of NOCs around the world as messages
like
this show up on consoles
Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306)
for
Except when their primary path goes away and relatively few networks
install the prepended route. It's all conjecture, but I like the 'in
effort to defeat local pref' option.
My theory - some netadmin trying to see if anything bad happens when he does it. Sort of like the Darwin winner who's last words are "I wonder what would happen if I tri..."
-Hank