BGP Prevent Transit AS

Preventing Transit-AS in BGP

Last Updated: [last-modified] (UTC)

What is a Transit Area?

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?

This may not be a common occurrence with large ISPs, but it could happen as a result of a misconfiguration, or perhaps in the case where the routers are peering with another customer directly, rather than through an ISP.
 
 
 

Preventing Transit

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

 

Filter list with AS-PATH

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.

 

AS-Path Filtering
ip as-path access-list 1 permit ^$
neighbor x.x.x.x filter-list 1 out

 

No-export Community

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.

 

No-Export Community
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

 

Prefix-list Filtering

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.

 

Prefix-list Filtering
ip prefix-list NO-TRANSIT permit x.x.x.x/x
neighbor x.x.x.x prefix-list NO-TRANSIT out

 

Distribute List Filtering

Distribute list filtering uses the same principal as prefix-list filtering. It is just another way to achieve the same result.

Distribute List Filtering
access-list x deny x.x.x.x y.y.y.y
neighbor x.x.x.x distribute-list x out

 

 

Summary

There are several options available, but in most cases either AS-Path filtering or the no-export community will be the best solution

Method Scalable Complexity Notes
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

 

 

References

Network Lessons – BGP Prevent Transit AS

CCIE4All – BGP Transit AS

 

2 thoughts on “BGP Prevent Transit AS”

    1. admin

      Technically your AS can be used for transit whether you use a public AS or a private AS. This doesn’t just apply to internet traffic either. This can be within your internal network or WANs.
      However, to peer with an internet provider, you would likely be required to use a public AS. Some will let you use a private AS, and they will replace your AS with their own AS to make it public.

Leave a Reply