IBGP and EBGP peer relationships

1.5.a BGP peering (not on blueprint)

General information on “BGP peering”:

Valid for iBGP/eBGP:
- It’s always recommended to set the BGP router-id manually
- The network statement requires and exact match in the RIB
- BGP won’t use a default route to connect to peers but requires a more specific route in the RIB
- If an iBGP peer doesn’t have a route to the original next-hop in its RIB, the route won’t be installed in the RIB and therefor also not advertised to another connected AS
- This is because BGP needs to do successful route recursion of the next-hop address in order to install and advertise it
TTLs:
- iBGP: 255
- eBGP: 1
iBGP specialties:
- iBGP peerings should always be created between the Loopback interfaces because if there are multiple paths between two iBGP peers and the main path goes down, the peering will stay up
- iBGP peerings normally requires full mesh because iBGP isn’t allowed to advertise routes learned from an iBGP peer to another iBGP peer (split-horizon rule)
- The next-hop value of an BGP-learned route will always stay the same within an AS if it doesn’t get modified
- iBGP normally relies on an underlay IGP (like EIGRP, OSPF, IS-IS, …)
eBGP specialties:
- eBGP peerings should always be between the directly connected links (recommended)
- eBGP peers normally need to be directly connected
- eBGP peerings between two directly connected routers loopback interfaces won’t work by default and disable-connected-check needs to be used
- If two BGP peers are multiple hops away, the TTL value must be modified:
  - ebgp-multihop sets the maximum number allowed hops (outbound) and also automatically disables the connected check
  - ttl-security sets the exact number of hops (inbound)
  - Important: Both features are mutually exclusive (either, or)!
Options for “fixing” the next-hop address of a BGP route:
1. Advertisement of the next-hop link prefix throughout the AS
2. Applying the next-hop-self command towards iBGP peers
3. Override the next-hop value upon receiving the NLRI using an inbound route-map
Message types:
- OPEN:
  - Used to establish a BGP adjacency.
  - Includes information such as BGP version, ASN of originating router, Hold Time, BGP Identifier (RID), Authentication, …
- UPDATE:
  - Used to exchange NLRI.
  - Includes new NLRI, withdrawal for previous NLRI or both at the same time.
- KEEPALIVE:
  - Used to signal that a peer is still active.
  - Since BGP doesn’t rely on TCP connection state, KEEPALIVE messages are sent every 1/3 of the Hold Time (60 seconds by default).
- NOTIFICATION:
  - Used to signal a peer that an error was detected.
  - This can be caused by things such as Hold Time expires, peer capabilities changed or session is reset.
  - This causes a BGP peering to terminate.
- ROUTE-REFRESH:
  - Used to support the BGP Route Refresh capability.
  - Can be used to dynamically request a re-advertisement of already received NLRI without the need to hard reset the BGP peering.
Neighbor states:
- IDLE:
  - BGP process is initialized.
  - BGP tries to connect to configured peers and listens to inbound connection attempts from the configured peers.
- CONNECT:
  - The 3-way TCP handshake is tried to be completed.
  - If successful, BGP sends an OPEN message and moves to OpenSent state.
  - If unsuccessful, BGP moves to Active state.
- ACTIVE:
  - If the 3-way TCP handshake failed, another one is tried.
  - If successful, BGP sends an OPEN message and moves to OpenSent state.
  - If unsuccessful, BGP moves back to Idle state.
- OPENSENT:
  - An OPEN message is awaited from the peer router. The message is compared against the previously own sent OPEN message.
  - If successful, BGP sends a KEEPALIVE message and moves to OpenConfirm state.
  - If unsuccessful, BGP moves back to Idle state.
- OPENCONFIRM:
  - BGP waits for a KEEPALIVE or NOTIFICATION message from its peer.
  - If BGP receives a KEEPALIVE message it is successful and BGP moves to Established state.
  - If BGP receives a NOTIFICATION message it is unsuccessful (Hold time expires, stop event occurs, notification is received) and BGP moves back to Idle state.
- ESTABLISHED:
  - BGP session is established.
  - BGP peers exchange NLRI through UPDATE messages.
  - Every UPDATE/KEEPALIVE message resets the Hold timer.
  - If the Hold timer expires or an error is detected, BGP sends a NOTIFICATION message to its peer and moves back to Idle state.
Authentication:
- Authentication uses MD5 hashing and is done by specifying a password on both sides
- If authentication is configured after a BGP session is already established, it must be flapped in order to get authentication working (no automatic session flapping like in EIGRP/OSPF)
- To verify that authentication is enabled and working, the show tcp tcb <tcb-value> output must include “md5” in its “Option Flags”
RIB Failure:
- If BGP receives information for a route which is locally already known with a lower AD, the BGP route will get marked with r (= RIB failure) in the BGP table and won’t get installed in the RIB

“BGP Peering” CLI configuration commands:

## Configuring a BGP neighbor
Router(config)# router bgp <asn>
Router(config-router)# neighbor <ip> remote-as <asn>

## Configuring BGP authentication on a per-neighbor basis
Router(config-router)# neighbor <ip> password <key>

## Enabling MP-BGP
Router(config-router)# no bgp default ipv4-unicast

## Configuring MP-BGP
Router(config-router)# neighbor <ip> remote-as <asn>
Router(config-router)# neighbor <ip> password <key>
Router(config-router)# address-family [ipv4 | ipv6 | vpnv4 | ...]
Router(config-router-af)# neighbor <ip> activate

## Configuring an eBGP multi-hop neighbor
Router(config-router)# neighbor <ip> ebgp-multihop <ttl>

Router(config-router)# neighbor <ip> ttl-security <ttl>

## Additional configuration when configuring an eBGP neighbor using loopback interfaces
Router(config-router)# neighbor <ip> disable-connected-check

“BGP Peering” CLI show commands:

## Showing the BGP table for a specific address family
Router# show bgp [ipv4 | ipv6 | vpnv4 | vpnv6] unicast

## Showing the BGP neighbor status for a specific address family
Router# show bgp [vpnv4 | vpnv6 | ipv4 | ipv6] unicast summary

## Verifying that BGP authentication is enabled and working
Router# show tcp brief
Router# show tcp tcb <tcb-value>

1.5.a i Peer-group/update-group, template

Peer-group/update-group

General information on “BGP Peer-group/Update-group”:

A BGP router may have dozens of BGP neighbors
Many neighbors may require the same BGP configuration
Neighbors can be grouped to decrease configuration time and complexity
For all neighbors in a peer group, the same configuration parameters apply
Individual parameters can be overwritten on a per-neighbor basis

“BGP Peer-group/update-group” CLI configuration commands

## Configuring a BGP peer group:
Router(config)# router bgp <asn>
Router(config-router)# neighbor [NAME] peer-group
Router(config-router)# neighbor [NAME] remote-as <asn>
Router(config-router)# neighbor [NAME] [command]

## Adding a BGP neighbor to a peer group
Router(config-router)# neighbor <ip> peer-group [NAME]

Template

General information on “BGP Template”:

Templates are the „modern version“ of peer-groups which allow to split peering/session configurations and have the possibility of inheritance
Example: 100 peers have 5 out of 6 commands in common. Normally those 5 commands need to be configured under each peer. This means 18 lines of configuration overall.
Solution: A template can be created from which the peers can inherit. This reduces the number of configured lines drastically.
Two types of templates:
- Peer-session templates affect the actual BGP session
- Peer-policy templates affect the protocol-specific parameters
When using address-family:
- Peer-session templates are inherited under the router process
- Peer-policy templates are inherited under the address-family
Inheritance:
- Peer-session templates can inherit from a single other peer session template
- Peer-policy templates can inherit from multiple peer policy templates
Templates can be inherited by static/dynamic peers and peer-groups

“BGP Template” CLI configuration commands:

## Configuring a BGP template
Router(config)# router bgp <asn>
Router(config-router)# template [peer-policy | peer-session] [NAME]
Router(config-router-*tmp)# [command]

## Inheriting a BGP peer-session template
Router(config-router)# neighbor [IP | peer-group] inherit peer-session [NAME]

## Inheriting a BGP peer-policy template
Router(config-router)# address-family [ipv4 | ipv6 | vpnv4 | ...]
Router(config-router-af)# neighbor [IP | peer-group] inherit peer-policy [NAME]

1.5.a ii Active, passive

General information about “BGP Active, passive”:

Active = Router who initiates the connection
Passive = Router who “waits” for the connection
By default, the peer with the lowest BGP RID will be the active one and establish the connection
The source port is random, the destination port is tcp/179

“BGP Active, passive” CLI configuration commands:

## Configuring if the local router should be passive/active for a given BGP neighbor
Router(config)# router bgp <asn>
Router(config-router)# neighbor <ip> transport connection-mode [active | passive]

1.5.a iii Timers

General information on “Timers”:

There are two “main” timers:
- Keepalive: 60 seconds (default)
- Holdtime: 180 seconds (default)
Rule of thumb: Keepalive should be 1/3 of the Holdtime
Timers can be modified globally or on a per-neighbor basis

“BGP Timers” CLI configuration commands:

## Modifying the BGP timers globally
Router(config)# router bgp <asn>
Router(config-router)# timers bgp <keepalive> <hold>

## Modifying the BGP timers on a per-neighbor basis
Router(config)# router bgp <asn>
Router(config-router)# neighbor <ip> timers <keepalive> <hold>

1.5.a iv Dynamic neighbors

General information on “BGP Dynamic neighbors”:

Instead of specifying neighbors manually, it’s possible to configure them dynamically
Dynamic neighbor configuration consists of three parts:
- Mandatory: Defining a peer-group
- Mandatory: Defining a subnet range and associating it with the peer group
- Optional: Limiting the maximum amount of dynamic neighbors
Up to 6 remote-AS can be defined within the peer-group (one primary, five alternative)
Address-Family support depends on the IOS (IPv4 for everyone, IPv6 for IOS-XE since v16.3)

“BGP Dynamic neighbors” CLI configuration commands:

## Configuring BGP dynamic neighbors function:
Router(config-router)# neighbor [NAME] peer-group

Router(config-router)# bgp listen range <subnet/mask> peer-group <peer-group>
Router(config-router)# bgp listen limit <value>

Router(config-router)# neighbor <peer-group> remote-as <asn> alternate-as <asn, asn, ...>

Router(config-router)# address-family [ipv4 | ipv6 | vpnv4 | ...]
Router(config-router-af)# neighbor <peer-group> activate

1.5.a Public AS (not on blueprint)

General information on “BGP Public AS”:

Each public AS needs a unique ASN because BGP is a path-vector protocol
ASNs are used as a loop prevention mechanism
If an AS sees his own ASN in the AS_PATH of a route, he doesn’t accept it (loop prevention)
ASNs are controlled and assigned by the IANA (Internet Assigned Numbers Authority)

BGP ASN ranges:

Reserved: 0
Public: 1 to 64495
Reserved for use in documentation: 64495 to 64511
Private: 64512 to 65534
Reserved: 65535

1.5.a v 4-byte AS numbers

General information on “BGP 4-byte AS numbers”:

Introduced in 2009 to overcome the ASN shortness
Up until then, a ASN had 2 byte (0 - 65535)
With a 4-byte ASN, the same amount of ASNs as IPv4 addresses is possible

Ways of 4-byte ASN notation:

ASPLAIN:
- Regular decimal numbers
- Just like 2-byte ASN
ASDOT:
- Represents ASNs 65535 or lower
- First part is set to zero
- Second part is the ASN itself
- Separation is done with a dot
- Example: ASN 1234 becomes 0.1234
ASDOT+:
- Represents ASNs 65536 or higher
- Breaks number into two 16-bit (2-byte) parts
- First part is a high-order value
- Second part is a low-order value
- Separation is done with a dot
- Formula to calculate:
  - High-order value: (asplain / 65536)
  - Low-order value: asplain - (high-order value * 65536)
  - Result: High-order value.Low-order value

1.5.a vi Private AS

General information on “BGP Private AS”:

Can be used when connected to a single AS that uses a public ASN
Can be compared to NAT
The Single AS with the public ASN needs to remove the private ASN when forwarding a routing update