An enterprise will often want to peer with more than one internet provider, usually for redundancy, but also for some type of load balancing. An example of this is shown below, where the enterprise (AS 555) is peering with provider-A and provider-B (AS 100 and AS 200 respectively). These providers are then used to access other customers networks, such as AS 444 and AS 333.
Providers will have high speed links between each other, so a customer on one provider (such as AS 444) can access networks for another customer (such as AS 333) on another provider.
In the minimal BGP configuration, routers in AS 555 (CE routers) will peer with the provider routers (PE routers). The PE routers will then send all their prefixes to the CE routers, allowing the Enterprise to decide the best path to each route. The enterprise will then add it's AS number to the AS path for each of the prefixes that it learned, and then advertise them to other peers.
But what would happen if the link between the providers were to go down, as shown below?
Imagine customer AS 444 wants to access a network in AS 333. It will have learned the path to this network from it's provider, and know that AS 100 will be the next-hop. When AS 100 receives the traffic, it will see AS 555 as being a valid path and send traffic that way. If this happens with enough traffic, the links into AS 555 will likely get overwhelmed. This is not a good situation for an enterprise customer to be in, and should be avoided.
Is This a Likely Scenario?
There are four methods which may be used to prevent transit AS:
- Filtering based on the AS-PATH, so routes received from one AS will not be advertised to another AS
- Using the no-export community, so prefixes received from an AS are tagged, and prevented from being advertised outside the AS
- Prefix-list filtering, which identifies all the prefixes that shouldn't be advertised to a peer
- Distribute list filtering, which also identifies each prefix that should not be advertised
The idea behind AS-Path filtering, is that the AS-Path is checked to be sure that only routes originating within the local AS are advertised. This means that nothing learned from Provider-A can be advertised to Provider-B.
This is configured using reg-ex, which can get tricky in more advanced cases. However, this is highly scalable, as adding and removing routes will not affect this configuration.
The example below shows the filter-list matching ^$, which is an empty AS-Path (which covers locally originated routes). If there is a value in the AS-Path, this is denied from being advertised out.
ip as-path access-list 1 permit ^$ neighbor x.x.x.x filter-list 1 out
Incoming prefixes can be tagged with the no-export community. This community tells BGP that the prefix can only bet advertised within the AS, and not to external AS's. This is a simple solution with little configuration and maintenance.
To configure this, incoming prefixes need to have this community set. The send-community command needs to be enabled on each peer.
ip bgp-community new-format route-map NO-EXPORT set community no-export neighbor x.x.x.x route-map NO-EXPORT in neighbor x.x.x.x send-community
Using prefix-lists for filtering inbound and outbound is quite common. It can also be used to prevent transit areas, however it needs to match all prefixes that are learned from internal sources, then filter any other prefixes in an outbound direction. For this reason, it is very granular, but is not very scalable.
The configuration may need to be changed every time prefixes are added, removed, or changed on the network.
ip prefix-list NO-TRANSIT permit x.x.x.x/x neighbor x.x.x.x prefix-list NO-TRANSIT out
Distribute list filtering uses the same principal as prefix-list filtering. It is just another way to achieve the same result.
access-list x deny x.x.x.x y.y.y.y neighbor x.x.x.x distribute-list x out
There are several options available, but in most cases either AS-Path filtering or the no-export community will be the best solution
|AS-Path Filtering||Yes||Potentially Complex||Simple for Enterprises, harder for providers|
|No-Export Community||Yes||Simple||Easy to use, scalable, but not very granular|
|Prefix-list Filtering||No||High||Highly granular|
|Distribute List Filtering||No||High||Highly granular|
Network Lessons - BGP Prevent Transit AS
CCIE4All - BGP Transit AS
Last update 2017-08-29 08:57