There are all sorts of options you can configure within BGP to influence how traffic is routed into, and out of, your network but what do they do and which are the most important?
Possible BGP Metrics
Within the BGP standard, there are specified path attributes, some of which must be understood and acted on by all BGP speakers and some of which are optional. The attribute types fall into one of these four categories — attribute type flags within the packet identify which type it is:
- Well-known mandatory
- Well-known discretionary
- Optional transitive
- Optional non-transitive
The well-known attributes must be recognised by anything that runs BGP. If it’s mandatory, then its value must be included in every BGP Update message sent: discretionary attributes do not have to always be sent. Well-known attributes, if included, must be passed along to the next BGP peer.
BGP implementations do not have to understand optional attributes, however if it’s a transitive attribute, it should still be passed to the next BGP peer, even if this one doesn’t know what to do with it. If it’s marked as non-transitive, then the router can simply ignore it, and shouldn’t pass it on, although if does understand it, it can act on it if it wants to.
Origin is a well-known mandatory attribute. It is generated by the AS that originates this particular routing update, and lets a BGP router know if that route came from inside its AS, outwith it, and learned via EBGP, or was redistributed in by some other process, so that it’s not too sure what the real origin was.
AS-Path is also a well-known mandatory attribute. This is simply a list of all the ASs that have been traversed in getting from the original address. If a router receives a route update from a router in a different AS, it will add its own AS number before passing it on. This prevents routing loops, since if the AS is already there, the router will drop the packet. It is possible to not display all ASs by using the Atomic Aggregate attribute, which in effect lets a router summarise routes and advertise a path to downstream routers without necessarily communicating the AS path followed, although you have to be careful if you’re configuring this that you do have a loop free topology here. Some vendors make provision for this by still passing AS information, although not listed as the AS path.
Next-hop is the third well-known attribute. It basically contains the IP address of the next hop router interface to which should be sent traffic for this route. Depending on whether a route is being passed from EBGP to IBGP, redistributed from BGP to an IGP, or being passed over a broadcast medium (a LAN, typically) this address may be altered as part of the router configuration.
Local Preference is a well-known discretionary attribute that lets routers within an AS basically weigh paths out of that AS to another, assuming that there are multiple ways out. If you have two BGP routers that can get to an external AS, you can set local preference values on the routers (either the router as a whole, to weigh all traffic, or for specific paths) so that one may be chosen by other routers in your AS over the other. It will have no effect on the behaviour of any routers outwith your AS.
The Multi-Exit Discriminator (MED) is an optional, non-transitive attribute, which can be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighbouring AS. It’s a bit like Local Preference in reverse—instead of you choosing which router you’d rather use to get out of your AS, you’re indicating to your neighbours (in other ASs) which of your routers you would prefer them to enter your network through. Watch the bit here about the same AS—the standard says that MED values should only be compared for two paths to the same route coming from the same AS. Vendors have taken liberties here a bit to add flexibility: Cisco for instance lets you configure routers to also compare MEDs even if the neighbouring ASs aren’t the same. And be aware that there is no guarantee that other routers will pay any attention to this setting—it’s a request only.
How BGP selects paths
BGP’s purpose in life is to route data from one AS to another. It doesn’t care much about what’s inside that AS—that’s up to the intra-domain, or internal gateway protocol—IGP—such as OSPF, RIP etc to deal with. If you use BGP to connect to the Internet via one or more ISPs, it’s important that you configure your side of things to make sure that the optimum path is used by the ISP, and you’ll need to understand how they may have tuned their setup too, so you know how your external traffic can be expected to leave your domain
BGP relies on the correct operation of the IGP that’s present within your network. A BGP router (BGP peer) won’t send traffic to a next-hop BGP router even although it has been told about it by BGP, unless it has a valid IGP route to it. Some vendors allow you to disable this checking, which you don’t necessarily need unless you’re advertising BGP routes to someone else that you need to be sure your own internal routing protocol can get to.
Assuming that the next hop is valid, the following are values are used by BGP, in this order, to make its decision whether to use that route or another possible one:
- Local preference—routers will prefer the path with the largest value.
- Local router—if local preferences are the same, the preferred route is one that was originated by the BGP process on this local router (it might have redistributed into BGP from an IGP also running on the router)
- AS path—if the route wasn’t originated here, then choose the path with the shortest list of ASs
- Origin code—if the path lengths are the same, prefer a route with lowest origin type, where IGP is less than EGP
- MED—if there’s still no difference, the path with the lowest Multi Exit Discriminator is preferred. Since MED is an optional configuration, this may not apply, and you’ll need to check whether a missing MED value is counted as worst or best case in your implementation of the protocol, as they differ
- EBGP vs. IBGP—a route learned via EBGP is preferred
- IGP neighbour—BGP will then prefer the route that can be reached via the closest (least cost) IGP neighbour, i.e. it will take the shortest internal path to get to the next BGP peer
If there are still multiple paths with exactly the same values for all of these, then BGP will load share (if that’s enabled)—failing that, it comes down to the lowest router ID (which is on of the reasons you’re advised to use a loopback address as router ID, not just let the router pick an interface address).
You’ll have to check with your specific vendor as to which optional attributes are supported, and what your configuration options are. Cisco IOS routers have a non-standard attribute that’s allows paths to be weighted local to each router—this is the first attribute that’s looked at in its BGP decision-making process, so if you set that, you may not need to change some of the others. If you want interoperability with other manufacturers’ though, you’ll have to ignore its effect.
If you understand how BGP makes its routing decisions, it’s much easier to see what you need to tune to suit your environment. You may have two routers to the Internet, but one is much more powerful than the other. Left to chance, and a default configuration, is your Internet traffic going through the wrong one? Now you may know why.