BGP Essentials: Non-transit AS
One of the first things you have to do when configuring BGP with your ISP is to ensure you won’t become a transit AS. Decent ISPs filter out things that don’t belong to you from your updates, but not everyone cares (including some really big names), and so small organizations manage to bring down large parts of the Internet just with a few fat fingers.
Here’s the BGP configuration you should use on Cisco IOS: apply AS-path access-list to outbound updates with neighbor filter-list command:
router bgp 65000
neighbor 10.1.1.1 filter-list 1 out
!
ip as-path access-list 1 permit ^$
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:
router bgp 65001
neighbor 10.0.1.2 route-map setNoExport in
neighbor 10.0.1.3 route-map setNoExport in
!
route-map setNoExport permit 10
set community no-export additive
Preventing AS from becoming Transit AS
Published October 24, 2007 Access-lists , IP Routing , bgp
To prevent your AS from becoming a Transit AS, use following startegy
Create a route map say “transit” in config mode
route-map transit permit 10
match as-path 1
In config mode, use following command
ip as-path access-list 1 deny ^$
This command will only allow routes with origin code “i” and filter all routes with incomplete as-path.
Apply the above route-map with neighbor statement
router bgp 64000
neighbor 2.2.2.2 route-map transit in
Only routes with origin code” i” will enter your AS.
@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.
Hope this helps
Ivan
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.
router bgp 12345
[...]
neighbor 1.2.3.4 prefix-list AS12345 out
[...]
!
ip prefix-list AS12345 seq 5 permit 2.3.4.0/24
ip prefix-list AS12345 seq 10 permit 2.3.5.0/24
ip prefix-list AS12345 seq 15 permit 2.3.6.0/24
!
ip as-path access-list 100 deny _65000$
ip as-path access-list 100 permit .*
I would like to deny for 65000 but allowing all for the spokes.
I can see the dynamic tunnel is up however the BGP routing showing the next hop to reach destination still going to Hub IP, then only reach to destination. When I removed the IP AS-Path, then the spoke router getting the correct information on BGP and able traverse via dynamic tunnels to other spoke. Is this a limitation of DMVPN or IP AS-Path?