Additional BGP stuff (not on blueprint)
General information on “BGP Network backdoor”:
- Used to change the AD of an eBGP route in order to allow the IGP to take precedence
- Example: AS10 and AS30 are connected to AS20. AS10 advertises 10.10.10.0/24 over BGP. There’s a backdoor-link between AS10 and AS30 running OSPF/EIGRP which also advertises 10.10.10.0/24. By default, AS30 would pick to route via BGP because of the lower AD (eBGP 20 < EIGRP 90 < OSPF 110). By using the network backdoor command, the AD of the eBGP route will get increased to 200 (just like iBGP) so that the IGP will take precedence.
- Important: The route which the neighbor router advertises must be configured under the network backdoor command.
“BGP Network backdoor” CLI configuration commands:
## Configuring BGP network backdoor for a specific eBGP prefix: Router(config-router-af)# network <prefix> mask <mask> backdoor
MED always-compare, deterministic
General information on “BGP MED always-compare, deterministic”:
- By default, the MED is only used as a path selection tie-breaker when a prefix is advertised by two or more peers of the same AS
- MED is always compared between two path entries, whereas the winner of the first two (#1, #2) path entries is compared against the third (#3) path entry (and so on) until the best path is found
- Ensures the comparison of the MED attribute for paths from peers in different AS.
- Routes from the same AS are grouped together (each AS is a group), and the best entries of each group are compared against each other.
- Cisco recommends enabling deterministic-med for all BGP deployment.
“BGP MED always-compare, deterministic” CLI configuration commands:
## Enabling/Disabling always-compare-med Router(config-router-af)# [no] bgp always-compare-med ## Enabling/Disabling deterministic-med Router(config-router-af)# [no] bgp deterministic-med
General information on “BGP Dampening”:
- Dampening prevents flapping BGP routes from being advertised:
- For each flap occurrence a penalty value will be added to the route
- When reaching the “Suppress Limit” threshold, the route won’t be advertised anymore
- If the route stays stable, the penalty will be cut in half after the “Half-Life time”
- When going below the “Reuse Limit”, BGP will start re-advertising the route
- There’s a “Maximum Suppress-Limit” value which limits the maximum suppression time
- The Max-Penalty value defines the maximum amount of penalty a route can “collect”
- Max-Penalty can’t be specified but is rather calculated = (reuse-limit) * 2^(max-suppress-time/half-life)
- Dampening isn’t recommended anymore because of the negative effects to the whole BGP network and because modern routers are much more powerful like back in the days (circa year 2000)
- If needed, RIPE recommends a “Suppress Threshold” of 6.000 and a “Maximum Suppress Threshold” of 50.000
“BGP Dampening” CLI configuration commands:
## Enabling/Disabling BGP dampening Router(config-router)# [no] bgp dampening
Next Hop Tracking (NHT)
General information on “BGP Next Hop Tracking (NHT)":
- Enabled by default
- When a route to a next-hop used within a BGP route is going down, the BGP process will be notified
- The default delay for the notification to happen is 5 seconds
- This results in an improved BGP overall convergence time because BGP won’t rely on the scan-timer (every 60 seconds by default) anymore when a next-hop changes (eg. interface goes down, …)
“BGP Next Hop Tracking (NHT)” CLI configuration commands:
## Enabling/Disabling BGP Next Hop Tracking Router(config-router)# [no] bgp nexthop trigger delay <sec>
Prefix Independent Convergence (PIC)
General information on “BGP Prefix Independent Convergence (PIC)":
- Normally implemented on the BGP Edge devices
- Installs next (backup) best route as a repair/backup path in the FIB
- Once a failure is detected, BGP will immediately switchover to the repair/backup path
- This allows for BGP sub-second convergence
- Either all prefixes or specific prefixes can be protected
“BGP Prefix Independent Convergence (PIC)” CLI configuration commands:
## Configuring BGP PIC Router(config-router-af)# bgp additional-paths install
Path MTU Discovery (PMTUD)
General information on “BGP Path MTU Discovery (PMTUD)":
- Enabled by default for all neighbors
- Implements classic TCP PMTUD into the BGP protocol
- Negative issues can occur for eBGP multi-hop peers
- Since PMTUD relies on ICMP (DF-Bit set to 1), an ICMP “Destination Unreachable” message needs to be returned if the MTU of a link on the path to the eBGP multi-hop peer is smaller
- If there’s a firewall or router in-between blocking ICMP, this can lead to connection issues (eg. session flapping)with the eBGP multi-hop peer since PMTUD is unsuccessful
- Can be disabled globally or on a per-peer basis
“BGP Path MTU Discovery (PMTUD)” CLI configuration commands:
## Enabling/Disabling BGP Path MTU Discovery (PMTUD) globally Router(config-router)# [no] bgp transport path-mtu-discovery ## Enabling/Disabling BGP Path MTU Discovery (PMTUD) on a per-neighbor basis Router(config-router-af)# [no] neighbor <ip> transport path-mtu-discovery
General information on “BGP Maximum Prefixes”:
- Can limit the number of prefixes a BGP peer can advertise
- Optional settings:
- <%-warning-value> = Defines, when warning log entries will be generated. Value is in relation to the maximum allowed prefixes value (default is 75%).
- restart <minute-interval> = Defines, when a terminated peer connection will be re-established (in minutes, disabled by default).
- warning-only = Peer connection won’t be terminated but rather only log entries will be generated.
“BGP Maximum Prefixes” CLI configuration commands:
## Configuring BGP maximum prefixes Router(config-router-af)# neighbor <ip> maximum-prefix <max-value> <%-warning-value> restart <minute-interval> [warning-only]
Site of Origin (SoO)
General information on “BGP Site of Origin (SoO)":
- Assigns each BGP route an extended community tag so that the origin site can be identified
- Useful for loop prevention and suboptimal routing on dual/multihomed sites
- Prevents advertised BGP prefixes from getting advertised back by the PEs to the originating site
- Important: Configuration of SoO must be done on the PE routers towards the CE routers!
“BGP Site of Origin (SoO)” CLI configuration commands:
## Configuring BGP Site of Origin (SoO) on a per-neighbor basis Router(config-router-af)# neighbor <ip> send-community both Router(config-router-af)# neighbor <ip> soo <rd>
IPvX routes over IPvX transport
General information on “IPvX routes over IPvX transport”:
- It’s always recommended to use the native IPvX transport whenever possible (IPv4 for IPv4 AF, IPv6 for IPv6 AF)
- But it’s also possible to transport IPvX routes over each others protocol (IPv4 over IPv6 and vice versa)
- What must be kept in mind is that next-hop attribute must be modified:
- Option A: Using an inbound route-map upon receiving the routes
- Option B: Using an outbound route-map upon sending the routes
- Important: A native IPvX connection between to BGP peers must exist in order for this to work. This means when sending IPv6 routes over the IPv4 peer-address, a native IPv6 connection must exist or else traffic won’t flow!