From the BGP Design point of view (HLD), there are four options to manipulate the inbound traffic, MED, AS-path prepending, using communities, and breaking aggregated routes.
MED
This is not really useful, as it has to meet some conditions:
- The AS-path of learned routes should be identical. Thus, this could be only useful when multihoming to the same AS.
- The BGP peer might use Local-Preference in the Path Selection process.
- Usually, Service Providers reset or strip received MED.
AS-Path Prepending
It’s not always helpful.
For instance, imagine Customer-A multi-homed to two different Service Providers, SP-1 & SP-2. Customer-A’s engineers prepend the as-path towards SP-2, assuming that all the traffic will enter into AS100 from AS200.
Here, in case SP-2 has set Local-Preference for Customer-A’s routes, then all the traffic sourced from AS300 will use the directly connected link, and the route via AS200 won’t be installed in RIB.
Though, Customer-Z, most likely treats all routes learned to destinations within AS100 equally, at least in terms of local preference; therefore will select routes via SP-1 to enter Customer-A.
Using Communities
By attaching a “Negotiated” community to the routes, it’s possible to instruct the Service Provider BGP peer to set Local-Preference for the received route. But as mentioned, this should be negotiated in advance. They generally will not allow their customers to go against the service provider’s best economic interest, which generally involves using their links to their directly connected customers as heavily as possible.
Breaking Aggregated Routes
The final, and generally most effective mechanism to influence the Entry Point into an Autonomous System is to break an aggregated subnet into longer-prefix components.
So, in case of the mentioned scenario, let’s say 8.8.8.0/23 will be advertised to SP-2 and 8.8.8.0/24 and 8.8.9.0/24 to SP-1.
