Additional BGP stuff (not on blueprint)

Network backdoor

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
• always-compare-med:
  • Ensures the comparison of the MED attribute for paths from peers in different AS.
• deterministic-med:
  • 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

Dampening

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

Maximum Prefixes

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!