BGP injecting long ASN path

[Danilo Dy]

Has anyone experience this? I saw ASN 39625 and 47868

[Mohamed Sobair]

Hello Maria,

Your describtion seems to be very useful..

From my point, its a sign for an AS being a transit.

Applying the appropriate filtering in place besides limiting the AS path length should be sufficent.

HTH

Mohamed

[marikakis]

The most common reasoning behind this is to prepend enough times so that nobody prefers it, until your primary path fails. It is an extreme way of controlling the incoming traffic to the AS (no inbound traffic at all), which is the hardest thing to control on the internet with conflicting interests between parties. But here is the thing: if internet goes down, you won't be receiving traffic on your primary path either ;-)

[marikakis]

Mohamed, I do not agree that this is a sign of an AS being a transit. For this to happen, the AS should attract traffic by advertising blocks that have not been assigned to it. This is more severely controlled (or I hope so). There were not many blocks advertised in this case, as far as I understand up to now.

[Mohamed Sobair]

Maria,

Prepending the AS-path will certainly cause this.. But dont you agree that IF the AS being transit AS will cause similar behaviour?

HTH

Mohamed

[marikakis]

Being unintentionally transit is not good either. Causes blackholing of traffic and hopefully brings down the AS that attracted the traffic fast enough to alert its own administrators to fix their configuration ;-) In this case, they had to be alerted by others.

[marikakis]

It seems that we have yet another good article by Ivan Pepelnjak about this issue:

http://blog.ioshints.info/2009/02/protect-your-network-with-bgp-maxas.html

Greg, I would not be in a hurry to upgrade IOS, because it seems there are unresolved issues associated with this problem even in later versions. Those are reported here:

http://www.gossamer-threads.com/lists/cisco/nsp/103840#103840

http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length

As a first step, I would say that your version should be recent enough for you to be able to set the bgp maxas-limit. Note that it might be a hidden command in some older IOS (neighbor maxas-limit ).

I suppose cisco might soon provide an answer for this and ISPs will try to enforce some sanity checks for their clients. This prepend might have been extreme, but the entire responsibility for the end result does not belong to a single person I believe.

[Giuseppe Larosa · Accepted solution]

Hello Maria,

just a little note:

there is a process level command

router bgp xxx

bgp maxas-limit ?

<1-2000> Number of ASes in the AS-PATH attribute

this is from a GSR with prp and 12.0.32SY6

this makes the application of the command easier.

I'm suggesting my customer to implement it with value 75 as reported in the forums you have linked

to see the effects of this issue see

Just as a follow-up -- and in case anyone hasn't read these yet:

http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml

http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-global-r

outing-instability/

this command should become part of BGP best practice even if it doesn't resolve any case as explained by Ivan Pepelnjak

Hope to help

Giuseppe

[marikakis]

Guiseppe,

Yes, I suggested the process level command too in my first post, and I agree that it makes life easier in many cases. A more granular approach per neighbor would be targeted towards environments with very specific needs. The per-neighbor command I referred to in my previous post has to do with the potential of a hidden command in older IOS versions, in case anyone needs to explore the possibility of applying a temporary workaround without changing IOS. This per-neighbor hidden command is mentioned in ISP Essentials, which has been published for some years now and I don't know if a process level hidden command is also available in those versions.

The best practices are known to ISP communities for years, but it seems that a push is always needed for actual measures to be taken.

Kind Regards,

Maria

[marikakis]

Guiseppe,

I just read the first thread you posted. OK, the first reaction of most people would be to blame the originating AS or people who do not maintain their router's software and suggest that some people get a BGP licence (like we get a driver's licence). They could also blame cisco and the IETF. I would expect in any of the threads I read up to now to see a little bit more sense of responsibility from SPs in general. If SPs had done the right thing (and they knew what is reasonable and what is not), it would be impossible for such routes to propagate no matter how reckless a single AS is. I think the suggestion of everyone becoming a BGP expert is unreasonable. After all, a common saying in SP related material is the following: "do not expect that everyone will play by your rules". As long as this attitude of not accepting responsibility goes on, we will keep seeing such things happening. If people that know the best practice do not enforce it, how can they possibly ask for others to know what they know? If "knowing" does not mean "doing", it is useless anyway.

Kind Regards,

Maria

p.s. And just for the case some SPs did not know, it seems there will be many candidates for the suggested BGP licence. Still, the messages in the forums suggest the ISP engineers see the warnings on their consoles and even get bored to explore who sents insane updates at any given time.

[marikakis]

And just for the case anyone wonders what I mean by ISP engineers being bored, have a look at the following messages:

http://www.gossamer-threads.com/lists/nanog/users/109411#109411

http://www.gossamer-threads.com/lists/nanog/users/112589#112589