Edit

BGP

BGP Best Path Algorithm

  1. Highest Weight: Local to router, Cisco specific,

  2. Highest Local Preference

  3. Locally originated via network/aggregate commands/redistribution from IGP > Local aggregates (by aggregate-address)

  4. Shortest AS-PATH

  5. Lowest Origin (IGP < EGP < Incomplete)

  6. Lowest Multi-Exist Discriminator (MED)

  7. Prefer eBGP over iBGP

  8. Lowest IGP metric to BGP next hop

  9. Determine if multiple path is required

  10. Both path are external, prefer oldest one

  11. Prefer route from lowest router ID

  12. If Router ID is the same, prefer route with mininum cluster list length

  13. Prefer path from lowest neighbor address

BGP Soft Reset and Route Refresh

  • The original BGPv4 specification did not specify any means by which a router could ask its BGP peer to resend its routes. Yet, this functionality is crucial whenever you update your inbound BGP policies because these policies have to be applied to all inbound route information from that neighbor. It would not be sufficient to subject the existing routes in your BGP RIB to the updated policies because the previous policy could have filtered some networks out, or changed their attributes, and you do not remember the original attributes or the filtered routes anymore. Therefore, the only reliable way of applying an updated inbound policy in BGP is to have the neighbor send all its routes again, and subject those routes to the updated policy.

  • The simplest way of accomplishing this is simply to tear down the BGP peering and let it come up again. This is what is described as a hard reset. However, this approach is rather heavyweight and causes outages in orders of seconds or minutes (and perhaps more) until the BGP peering comes up again and the routes are readvertised in both directions. In big BGP deployments, this is a no-no. Therefore, a more clever approach is required.

Soft Reconfiguration (Soft Reset)

  • Vendors have tried to work around this BGP deficiency by implementing a single hack: Keep a separate, unfiltered and unmodified copy of all routes received from a neighbor, and whenever an inbound policy for that neighbor is changed, take this unfiltered database and "distill" it through the updated inbound policy. This has the same effect as having the neighbor resend all routes again, yet it is accomplished purely by local means - storing the unmodified copy of all received routes in a separate place in memory and just reuse it whenever the inbound policy changes. This is what Cisco calls Soft Reconfiguration and is configured on a per-neighbor basis using the neighbor X.X.X.X soft-reconfiguration inbound command. The obvious advantage is that Soft Reconfiguration does not require any change to the BGP protocol itself and it is fast because the routes do not need to be downloaded again as you already have them. The major disadvantage is the huge memory footprint: For each neighbor configured for Soft Reconfiguration, you keep a separate unmodified database of all its routes, plus you keep your normal BGP RIB. With Soft Reconfiguration, you are unable to save RAM by filtering out unnecessary routes, as you will still keep them, and the routes you have accepted will be kept twice: First in the unmodified database for the neighbor, second in the RIB.

Route Refresh (dynamic inbound soft reset)

  • A different approach was chosen by authors of RFC 2918 that proposed a new BGP message called Route Refresh. This message can be used to ask a BGP peer to resend all routes of a particular address family (say, IPv4 or IPv6). As this was a new BGP message, its adoption required that vendors implemented the support for it into their products. However, the RFC is from September 2000 and now, all major vendors support it. If using the Route Refresh, a router does not need to store a separate unmodified copy of all routes from a BGP peer. Whenever it needs to reapply a new inbound policy, it simply sends the peer a Route Refresh message, and the peer will automatically resend all routes of a particular address family. Clearly, this is the way it should have been implemented in the first place.

  • The term soft reset refers to the use of either Soft Reconfiguration or Route Refresh - in any case, the ability to reapply an inbound policy without tearing down the BGP peering itself. More precisely, however, Cisco likes to use the term soft reset for Soft Reconfiguration (the separate unmodified database per neighbor), and dynamic inbound soft reset for Route Refresh. Confusing? I would say so :) That is why I like to call these features directly: either Soft Reconfig or Route Refresh, and you know what I mean.

  • The Soft Reconfig has to be explicitly configured for a neighbor, otherwise it is not performed. The Route Refresh is automatically negotiated between BGP peers as they establish a peering, and will be used automatically when both peers declare that they support it.

  • Many people are confusing these two, and more seriously, they keep configuring neighbor X.X.X.X soft-reconfig inbound all the time, perhaps thinking that this is the Route Refresh, or that if the neighbor supports Route Refresh, no separate unmodified database will be kept for it. However, this is a serious mistake. The Route Refresh requires no configuration and will be used automatically. If a neighbor is configured with Soft Reconfig, this Soft Reconfig will take precedence and the router will keep a separate database for it even if the neighbor supports Route Refresh, voiding all its advantages. I keep seeing people configuring the Soft Reconfig, unknowingly losing all advantages of Route Refresh as a direct result, even though their routers support Route Refresh for years.

  • So to sum up: Soft Reconfig maintains a separate unmodified database for a neighbor, and is used only when explicitly configured. Route Refresh adds another message to BGP allowing a router to ask its peer to resend the routes again, and requires no configuration whatsoever. Soft Reconfig should not be used anymore, as it was just a workaround. Simply do nothing, and you get Route Refresh

  • There is one exception where the soft-reconfiguration inboud might be useful: It allows to use the show ip bgp neighbor X.X.X.X received-routes to see all unfiltered and unmodified routes received from that neighbor. It can be a valuable troubleshooting and diagnostic tool, but the added value of this tool has to be carefully weighed against the potentially huge increase in the memory footprint.

BGP Attribute Manipulation

Replace ASN in AS-Path

  • Use route-map set as-path replace in IOS XE 17.1.1.

  • The asn to be replaced can be anywhere in as-path

  • Can replace single, string of asn or any (whole as path) with router's asn

Using As-override to replace ASN of received route with ASN of its own

  • use neighbor $address as-override

Receive Route with router's ASN in AS Path: Use allowas-in

  • use neighbor $address allowas-in in neighbor statement on the router that should accept route with asn in aspath

Change BGP Administrative Distance

Use Cases

  1. Prefer BGP over IGP or vice versa If BGP is configured alongside OSPF, EIGRP, or static routes, the default AD values determine which protocol’s route wins:

  • eBGP: 20

  • iBGP: 200

  • OSPF: 110

  • EIGRP: 90

  • Static: 1

  • Example: BGP-learned routes are preferred over OSPF routes for certain prefixes. Lowering BGP AD (e.g., to 80) ensures BGP wins in the RIB.

  1. Deprioritize iBGP routes

  • iBGP has a high default AD (200), which means it loses to most IGPs.

  • This is inherently enabled by default

  1. Selective route preference per neighbor

  • Set AD per neighbor or per prefix.

  • Example: Routes from one peer are trusted more than another (e.g., primary vs backup ISP). Assign a lower AD to the preferred peer’s routes.

  1. Traffic engineering and failover

  • AD tuning can be part of a broader traffic engineering strategy.

  • Example: steer traffic through a backup path only if the primary fails. Assigning higher AD to backup BGP routes ensures they’re only used when needed.

Using distance command in address family

  • ebgp-distance —20.

  • ibgp-distance —200.

  • local-distance —220. Local-distance is the administrative distance used for aggregate discard routes when they are installed in the RIB.

Policy-based AD for routes matching prefix-list using route-map

  • The policy-based administrative distance feature is useful when there are two or more different routes to the same destination from two different routing protocols.

  • Distance for external BGP (eBGP) and internal BGP (iBGP) routes can be configured by matching a policy described in the configured route map.

  • The distance configured in the route map is downloaded to the unicast RIB along with the matching routes. BGP uses the best path to determine the administrative distance when downloading next hops in the unicast RIB table.

  • If there is no match or a deny clause in the policy, BGP uses the distance configured in the distance command or the default distance for routes.

BGP Features

BGP Nexthop Address Tracking

  • For each route installed in the BGP table a next hop address must exist and this next hop must be reachable in terms of an IGP. If the next hop is not reachable the route will not be considered for the best path algorithm and will never be used by BGP.

  • One of the major functions of the BGP scanner is to check the rechability of the next-hops for the routes existing in the BGP table. The BGP scanner runs every 60 seconds by default to make this housekeeping, however during this 60 seconds routing black holes may occur if the next hop changed before the BGP scanner timer expires

  • The Next-hop address tracking feature was created to avoid black holing problems, provide faster convergence and stability. This feature is event driven and its role is to walk the routing table as soon as the IGP change is detected to adjust the BGP table information. The delay interval between routing table walks is 5 seconds by default, this is optimal for fast tuned IGP. This value can be changed to match the IGP convergnece timers for optimum performance.

  • The feature is enabled by default in almost all new IOS releases, but still can be disabled by using the command no bgp next-hop triggered enable

  • Adjusting the Delay Interval for BGP Next-Hop Address Tracking

  • Disabling BGP Next-Hop Address Tracking

BGP Fast-External-Fallover

  • BGP Fast-external-fallover command terminates external BGP sessions of any directly adjacent peer if the link used to reach the peer goes down; without waiting for the hold-down timer to expire.

  • Although this feature improves the BGP conversion time, it may lead to great instability in your BGP table due to a flapping interface. By default this feature is enabled in Cisco IOS.

  • https://community.cisco.com/t5/networking-knowledge-base/bgp-fast-external-fallover-command-overview/ta-p/3142577

BGP Neighbor Fallover

  • By default, the BGP hold timer is set to run every 180 seconds in Cisco IOS software. This timer value is set as default to protect the BGP routing process from instability that can be introduced by peering sessions with other routing protocols. BGP routers typically carry large routing tables, so frequent session resets are not desirable.

  • When “Neighbor fallover” is configured under BGP process, it monitors RIB and if route to peer is not present in routing table it will immediately deactivate peer session without waiting for hold down timer. This is usually configured for non-directly connected IBGP.

  • Sometime, default route might be configured on router, then the withdrawn of the route to BGP peer's address will not trigger the BGP session deactivation. If this is the case, a route-map can be used to track specific address:

  • https://community.cisco.com/t5/networking-knowledge-base/quot-bgp-neighbor-fall-over-command-overview/ta-p/3154490

BGP Conditional Advertisement

  • Advertise-map is the route-map matching prefix-list of routes to be advertised

  • Exist-Map: conditional check, advertise route in advertise-map when route in exist-map exists in BGP routing table

  • Non-Exist-Map: conditional check, advertise route in advertise-map when route in non-exist-map does not exist in BGP routing table

  • If the conditional routes are not in BGP table, they must be redistributed to BGP so BGP can check it

  • Can apply multiple commands to the same neighbor to advertise multiple routes and check multiple conditions

  • If neighbor route-map is also applied, advertise-map will be check first as conditional, and these routes will be passed to route-map filter to decide what routes to send to neighbor

  • If the bgp neighbor uses a non-existing route-map or prefix, it means it advertise all routes (matches all routes)

Sample Configuration

BGP Notification

  • The following subcodes are defined for the Cease NOTIFICATION message:

  • Subcode Symbolic Name 1 Maximum Number of Prefixes Reached 2 Administrative Shutdown 3 Peer De-configured 4 Administrative Reset 5 Connection Rejected 6 Other Configuration Change 7 Connection Collision Resolution 8 Out of Resources

  • Subcodes for BGP Cease Notification Message

Website to check BGP Routes

Reference

  • Select BGP Best Path Algorithm: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

  • Examine Border Gateway Protocol Case Studies: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

  • Configure the AIGP Metric Attribute for BGP: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/119001-configure-aigp-00.html

  • BGP Regular Expression Cheatsheet: http://gponsolution.com/bgp-regular-expressions-cheat-sheet.html

  • https://afrozahmad.com/blog/what-is-bgp-regular-expression-and-how-to-use-it/

  • BGP ASN Replace: https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-replace-ASNs.html.xml

  • Configure Allowas-in Feature in BGP: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/112236-allowas-in-bgp-config-example.html

  • BGP as-override: https://ipwithease.com/understanding-bgp-as-override-feature/

  • BGP Soft Reset vs Route Refresh: https://community.cisco.com/t5/switching/soft-reset-and-route-refresh-in-bgp/td-p/2674389

PreviousRoutingNextOSPF

Last updated