Sometimes I find the information on the Internet that is so far from the facts that it might actually hurt someone. For example, the configuration in this post supposedly prevents you from becoming a transit AS (which is a really bad idea if you're a multi-homed end-user). Actually, it achieves the goal as it drops all incoming routes due to a malformed AS-path access-list that denies everything :) … but then, why do you need BGP in the first place?

Fortunately, someone provided correct configuration in the comments to the post, just made in unnecessarily complex with the introduction of a route-map.

It really pays off to study all the available BGP filtering mechanisms: AS-path access-list can be applied to updates directly with the neighbor filter-list command. The minimum configuration that guarantees you won't become a transit AS is thus as follows:

Of course you can make things really interesting by introducing BGP communities: if you mark all routes received from the EBGP peers with the NO_EXPORT community, they will be filtered out on other EBGP sessions automatically :) Here's a sample configuration:

@singh: I apologize for the brevity of my text, I shall write a follow-up one explaining the principles of the non-transit AS (and what you have to filter and where). However, here are the details as they relate to the text jdenoy included:

* Every as-path access-list has an implicit "deny all" at the end. The as-path access-list in the example thus matches nothing at all.

* The routes received from an EBGP neighbor always have at least one AS number in the AS path. The "deny ^$" pattern (which matches an empty AS-path) is thus irrelevant. But, as said above, everything else would be dropped as well.

* You cannot use an as-path access-list to match the origin code (even though it looks like the origin code is part of an AS-path, it's not).

* There is no such thing as incomplete AS-paths.

* The 'incomplete' origin code is a leftover of the past long gone and is mostly irrelevant these days. It definitely has nothing to do with (non)transit behavior.

* The route-map in the text supplied by jdenoy when applied to inbound updates from an EBGP peer would drop all inbound BGP prefixes.

I think the comment by jdenoy above just shows an ip as-path access list. if a person reading BGP article doesn't know that every acceess-list has implicit deny at the end then I am not sure how come reader is jumping his horses and learning about BGP communities :). anyway I used the as-path access list mentioned by jdenoy, and addedd

ip as-path aceess-list 1 permit any and it prevent AS from becoming the transit AS. so I think even if blogger has mistyped something, readers should use their brains while using it on production network.

Ivan Pepelnjak, CCIE#1354 Emeritus, is an independent network architect. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net,
has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.