Cisco’s BGP decision process basically decides which BGP route to take when comparing multiple prefixes to the same destination. It is a rather long process and somewhat tricky. Below, I created a quick reference to its steps.
Before I talk about each step I would like to discuss in what order are multiple prefixes compared. For example if you have three prefixes to 10.2.0.0/16 how do you compare all three at once? By default Cisco’s algorithm will compare the younger prefixes to the older and finally compare the oldest to the winner.
The rest of this post are my notes on the BGP decision process. Hopefully you’ll find it useful.
For any path to be considered valid it has to meet these requirements.
- Next-hop IP address of that path is reachable.
- The local AS number is not part of the AS_PATH (basic loop prevention).
- If BGP synchronization is enabled, the candidate prefix is in the IGP routing table. If using OSPF, router-ID have to match for the OSPF and BGP process.
- The BGP prefix is not dampened.
- With inbound soft resets enabled, make sure that no BGP polices are filtering the candidate prefix.
1 – WEIGHT
- A parameter only locally significant to the router.
- Usually this method is used on a device that has multiple uplinks and prefers one over the other.
- Preference of is give to a higher value (I’m heavier).
- Paths that the BGP process locally originates, use the weight of 32,768 and other routes use weight of 0.
- Weight can be configured per neighbor or using a route-map.
- neighbor (ip) weight (0-65535)
- In route-map set weight (0-65535), but only the as-path can be matched in its match statement.
2 – LOCAL-PREF
- This BGP attribute is only significant to the Local AS.
- Preference is given to a higher value.
- By default it is set to 100. Can be changed it with the command bgp default local-preference (value) or in a route-map using the command set local-preference.
- The bgp default local-preference (value) can be used to make one router preferred for all routes it advertises into the local AS. This command does not modify LOCAL_PREF already set.
3 – Locally Generated
- Preference is given to locally originated routes over externally. This preference is accomplished by assigning a weight of 32768 to locally generated routes.
- These routes could be generated three different ways: network command, redistribute command and aggregate-address command.
- Any routes received from a BGP router will not be selected as best if either one of these commands was used on a local router for the same prefix.
- Local paths that are sourced by the network command is more preferred over the redistribute commands and redistribute command is more preferred over local aggregate-address command.
- See below for example of 126.96.36.199/32 locally generated (AS100) vs generated at AS200. Locally generated are always preferred, but with different results.
- In this example the network 188.8.131.52 is advertised locally using the network command.
router bgp 100 network 184.108.40.206 mask 255.255.255.255 R1#sh ip bgp 220.127.116.11 BGP routing table entry for 18.104.22.168/32, version 36 Paths: (2 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 1 2 3 4 Local 0.0.0.0 from 0.0.0.0 (10.1.1.1) Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best 200 10.1.12.2 from 10.1.12.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, external
- The next example demonstrates using the redistribute command.
router bgp 100 redistribute static sh ip bgp 22.214.171.124 BGP routing table entry for 126.96.36.199/32, version 39 Paths: (3 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 1 2 3 4 Local 0.0.0.0 from 0.0.0.0 (10.1.1.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best 300 200 10.1.13.3 from 10.1.13.3 (10.3.3.3) Origin IGP, localpref 100, valid, external 200 10.1.12.2 from 10.1.12.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, external
- The next example uses aggregate-address. The Origin is based on the component route, if the component route was injected using redistribution, Origin would be unknown, in this case it uses the network command so Origin is set to IGP.
router bgp 100 aggregate-address 188.8.131.52 255.255.255.0 summary-only network 184.108.40.206 mask 255.255.255.255 sh ip bgp 220.127.116.11/24 BGP routing table entry for 18.104.22.168/24, version 48 Paths: (2 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 1 2 3 4 Local, (aggregated by 100 10.1.1.1) 0.0.0.0 from 0.0.0.0 (10.1.1.1) Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best 200 10.1.12.2 from 10.1.12.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, external
4 – AS-PATH Length
- Preference is given to the shortest AS_PATHs.
- AS_PATH check can be disabled with the hidden command bgp bestpath as-path ignore.
- AS_PATHs with AS_SET segments always counts as 1 even if multiple ASNs are in the set. AS_SET are used with aggregation.
- AS_CONFED-SEQUENCE is not included in the AS_PATH length.
- Prepending is used to make AS_PATH length longer and less preferable. Prepending adds the same ASN multiple times to the AS_PATH.
- AS_PATH can be modified with a route-map using the command set as-path prepend or set as-path prepend last-as . Last-as has a different behaviors depending on the direction applied inbound vs. outbound.
- Inbound – Modifies the neighboring ASN X times.
- Outbound – Modifies only the last ASN X times, but not the current ASN. For example, if AS 100 has outbound prepend last-as 3 times, it will not prepend AS 100 x 3, but only the previous ASN that’s using AS 100 for transit.
- You could also filter prefixes by prepending it with ASN of the next AS, for example if a prefix is being advertised to AS 100, you can prepend it with AS 100 and the loop detection will discard that route.
- One example of where you might want to ignore the AS-PATH, is within a BGP Confederation. Since Confederation ASes count as 1, the external AS_PATH controls best path, without any regard on the number of Confederation ASes it has to traverse. When AS-PATH check is disabled you can rely on the IGP metric to find the best way out without the control of external AS-PATH length.
5 – ORIGIN
- Preference to the lowest origin: 0 – IGP , 1 – EGP, 2 – INCOMPLETE
- Basically prefer routes that were generated through BGP instead of redistribution or other protocols.
- In this case EBG references the External Gateway Protocol, which now obsolete, not the family group of external protocol that BGP belongs to.
6 – MED
- Preference is given to the lowest MED metric.
- Using the MED value for routing decision is called cold-potato routing or best-exit routing. Most networks will use hot-potato as they want to get rid of foreign traffic and not utilize their internal resources.
- MED can be affected significantly by these commands:
- bgp always-compare-med – disables the check that all paths have to come from the same neighboring AS.
- bgp med-deterministic – paths are sorted by AS and compared one by one, instead of by their arrival time.
- bgp bestpath as-path ignore – ignores as-path for path’s decision process, path could be of different AS_Length and still get to the consideration of MED attribute skipping the 4th step.
- bgp bestpath med missing-as-worst – decides what value to set if MED is not set.
- bgp best-path med-confed – used between confederations, it enables checking MED values, which by default is turned off.
- The first AS has to be the same (unless bgp always-compare-med command is used) then it ignores the first ASN.
- By default it only compares MED for paths that have the same neighboring AS i.e. first AS is the same in the AS_SEQUENCE only. This can be modified with the bgp always-compare-med command. It checks the MED for routes that come from different ASNs. This feature should be configured either on all or no devices as it can cause routing loops.
- If you only have bgp med-deterministic configured without bgp always-compare-med, if two paths come from different neighboring ASes, than MED comparison is ignored.
- Regular behavior of bgp med-deterministic is to sort routes by AS, and compare them, instead of comparing them in the order of their arrival time.
bgp bestpath as-path ignore
- Multiple paths have to be of the same AS_PATH length, unless you use the hidden command bgp bestpath as-path ignore, which will ignore the as-path comparison within in the whole BGP decision process.
bgp bestpath med missing-as-worst
- If MED value is not set on a router, Cisco considers it as having the value 0 (most preferred MED value)
- Some other vendor implementations conside a MED value not set as 4,294,967,294 (least preferred MED value).
- For More info go to MED BGP MED NOT SET
- The value assigned by IOS to prefixes without MED attribute set, can be modified with the command bgp bestpath med missing-as-worst.
This command will set any unset MED values to be 4,294,967,294 instead of 0.
- Default-metric (value) command sets the default MED.
bgp best-path med-confed
- By default AS_CONFED_SEQUENCE is ignored in MED comparison. To compare MED in confederations use the command bgp best-path med-confed.
- With this feature enabled, only paths originated from within the confederation are compared and not external paths.
7 – eBGP vs iBGP
- eBGP is preferred over iBGP
- AS_CONFED_SEQ are considered as internal paths.
- There is no distinction between Confederation External and Confederation Internal.
- Pay close attention to the AS_Length when advertising a prefix internally and receiving it externally.
8 – IGP Metric Next-Hop
- Preference is given to the lowest IGP metric of the NEXT_HOP.
- Local topology (i.e metric to the NEXT_HOP) is considered for closest-exit routing or hot-potato routing, when an AS tries to find the closest exit point.
9 – MULTIPATHS (optional)
- If the maximum-paths [ibgp] command is enable multiple paths can be inserted into the routing table. Load balancing will occur over the links.
- Only one route will be advertised to peers and only one route will be marked as the best.
10 – Oldest Path (eBGP paths only)
- This step is skipped if bgp bestpath compare-routerid is enabled (by default not enabled).
- This step is skipped if multiple paths contain the same Router ID, i.e. if the route came from the same router.
- Preference is given to the oldest path.
- This check only applies to paths learned from eBGP not iBGP.
11 – Router-ID
- Preference is given to the lowest router-id.
- This is checked for eBGP routes if the bgp bestpath compare-routerid command is configured or the path contains the same RouterIDs.
- Router-ID can be modified manually with the bgp router-id a.b.c.d command.
- If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.
12 – Cluster List (only RR-clients)
- Preference to the shortest cluster-list.
- This check only applies to route reflector clients.
13 – Neighbor IP
- Preference to the lowest BGP neighbor IP address.
- Neighbor IP address is the IP address used by the BGP process. These IP addresses are used for TCP sessions (show tcp brief | i 179)
- This is the ultimate tie breaker as each router’s IP address should be unique.
- This situation applies, when two routers have 2 BGP peering sessions configured between them, where the route-id is the same.
- This test applies to eBGP routes that have the same Router-ID.