You should avoid configuring a network as a transit network between autonomous systems while using BGP. In a multi-homed BGP design, connecting your company network to two ISPs might result in a transit network. Route filtering is used to prevent the advertisement of private addresses and addresses that are outside the scope of the domain when BGP routes are exchanged with multiple Internet service providers (ISPs). Only the enterprise prefixes should be advertised to ISPs.
For example, let’s look at the diagram below. If the link between ISP-A and ISP-B goes down, you will become the TRANSIT for all the traffic. Keep in mind this is not just for Internet access, but also if you are running MPLS internally.
There are four ways to prevent a Transit AS:
1. Distribute-list Filtering
2. Filter-list with AS PATH access-list.
3. No-Export Community.
4. Prefix-list Filtering
#AS-PATH Filter
If you wish to filter the BGP routes you send or receive depending on AS Path information, this is the procedure.
Inbound and outbound AS Path filters can be used to filter the routes you transmit and receive accordingly. These filters must be applied to each peer separately.
Reg-ex is used to customize this, which can be challenging in more complicated scenarios. I hardly see this being used because I think it’s too complex, and it’s best to keep things simple.
Examples:
Matches ONLY AS1234. So if traffic passed through any other AS, this will not work. This is only good if you only flow though one AS which is 2222. So it basically locks you down to routing through one AS.
ip as-path access-list 1 permit ^1234$ route-map AS_PATH_FILTER permit 10 match as-path 1 router bgp 1 neighbor x.x.x.x remote-as 1234 neighbor x.x.x.x route-map AS_PATH_FILTER in
This one opens it up more. So now we can pass through other AS’s as long as there’s AS 1234 in the PATH.
ip as-path access-list 1 permit _1234_ route-map AS-PATH_FILTER permit 10 match as-path 1 router bgp 1 neighbor x.x.x.x remote-as 1234 neighbor x.x.x.x route-map AS-PATH_FILTER in
#NO-EXPORT COMMUNITY
The no-export community can be applied to incoming prefixes. This community informs BGP that the prefix can only be published within the AS, not to outside ASs. This is a straightforward solution that requires little setting and upkeep.
Incoming prefixes can be tagged with the no-export community. This is a simple solution with little configuration and maintenance.
This community must be specified on incoming prefixes to set up this. Each peer must have the send-community command enabled.
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 FILTERING
This one is commonly used and easy to implement.
Prefix-lists are commonly used to filter inbound and outgoing traffic. It may also be used to avoid transit regions, but it must first match all prefixes learned from internal sources before filtering any other prefixes outbound. As a result, it is highly detailed but not scalable.
Keep in mind that the configuration may need to be adjusted when prefixes are added, withdrawn, or altered on the network.
If it’s an internet setup, you want to advertise your /24 Subnet (Assuming you have a /24). If it’s MPLS internally, you typically want to advertise out all your local LAN subnets or summarized local LAN routes if you are summarizing.
ip prefix-list NO-TRANSIT_FILTER permit x.x.x.x/x neighbor x.x.x.x prefix-list NO-TRANSIT_FILTER out