Cisco: BGP prevent transit
sumber: https://networkdirection.net/articles/routingandswitching/bgppreventtransitas/
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 granula
Referensi