BGP Peer Session Establishment

Border Gateway Protocol (BGP), distinct from other routing protocols like OSPF and EIGRP, doesn't introduce its proprietary transport for creating neighbor relationships, which are referred to as peer relationships in BGP terminology. Instead, BGP relies on TCP as its transport protocol, running over the well-known BGP TCP port 179. As a result, the initiation of a BGP peering session involves a two-step process, where the first step is the establishment of a TCP session, and the second step is the exchange of BGP-specific information to form the BGP peering session.

The Role of TCP:

• TCP Session Initialization: BGP peers initiate a TCP session, a connection-oriented protocol, for communication. This begins with the client-server model, where the server listens on a specific TCP port number (port 179 for BGP). The client, aiming to establish a connection, sends a TCP synchronization (TCP SYN) message to the server, indicating its intention to send data. The server replies with a TCP synchronization acknowledgment (TCP SYN-ACK) message to confirm its readiness to receive data. The client finalizes the connection with a simple TCP acknowledgment (TCP ACK) message, starting the data exchange process, known as the TCP three-way handshake.

BGP Peer Session Initialization:

• TCP Server for BGP: When BGP is enabled on a router, it begins listening for incoming TCP server connection attempts on port 179.

• Active Open Attempt: To peer with a configured neighbor, the router, acting as a TCP client, initiates a TCP connection by sending a TCP SYN to the potential neighbor. This step is known as an active open attempt.

• Server Response: The remote neighbor listens on TCP port 179 and responds with a TCP SYN-ACK message if the connection attempt is from an IP address designated as a potential BGP peer in its own BGP configuration. Otherwise, the TCP session is reset. Concurrently, the server also sends its TCP SYN packets to its configured neighbors to establish BGP peering sessions.

• Bidirectional Communication: BGP routers actively establish TCP connections and passively listen for incoming TCP connections, making them function as both TCP clients and servers during the TCP exchange. In case both neighbors receive and send TCP SYN connections to each other, the one with the higher BGP identifier or BGP router ID becomes the TCP client, while the other becomes the TCP server.

• BGP Peering Session: Once the TCP session is established, the routers proceed to the BGP peering session establishment phase, determining whether the peering is internal BGP (iBGP) or external BGP (eBGP) based on ASN matches. They also exchange BGP capabilities to negotiate session parameters such as keepalive intervals and hold timer values. The BGP peering session may fail if the receiving peer finds any unacceptable parameters.

In summary, BGP relies on TCP for its transport, and BGP session establishment involves two distinct phases: TCP session establishment and BGP peering session establishment. It's essential to grasp the role of TCP and its interaction with BGP when comprehending how BGP sessions are formed.

Peer Example

• Initializing BGP Process:

  • BGP process initiation begins with the "router BGP ASN" command in global configuration mode, activating BGP processes on the router.
  • Notably, the execution of these processes only takes place once at least one neighbor is configured within the BGP process.

• Configuring Neighbors:

  • Neighbors are configured using the "neighbor neighbor-address remote-as ASN" commands.
  • These commands establish passive TCP listening sockets on the router for the specified neighbor IP addresses.
  • The existence of these sockets can be verified with the "show tcp brief all" command.

• Passive Listening Ports:

  • The output confirms the successful establishment of passive listening ports on R1 and R2, enabling them to accept connections from their configured neighbor IP addresses in the BGP router configuration.
  • R1 and R2 accept TCP packets exclusively on TCP port 179 (BGP) from their respective configured IP addresses.

• Configured Listening Addresses:

  • R1 only accepts TCP packets from the IP address 2.2.2.2, while R2 accepts TCP packets exclusively from the IP address 1.1.1.1.
  • These designated listening addresses correspond to the IP addresses explicitly configured in R1 and R2's "neighbor neighbor-address remote-as ASN" commands.

• Update Source Configuration:

  • The "neighbor neighbor-address update-source interface" command allows routers to use a specific interface's IP address as the source for BGP updates.
  • This prevents the router from using the default IP address on its exit interfaces.

• Challenges in TCP Connection:

  • When "debug ip bgp" is executed, it becomes apparent that R1 and R2 face difficulties in establishing a TCP connection between them.
  • This issue arises from the absence of a valid route to their respective peering addresses (2.2.2.2 and 1.1.1.1) despite OSPF providing reachability.

• Understanding BGP Peering Types:

  • BGP peers can be categorized into external (eBGP) and internal (iBGP) peers.
  • eBGP peers exist between routers in different Autonomous Systems (ASNs).
  • The "connected check" ensures that the local router's route to the peer's IP address is recognized as a directly-connected route for eBGP peers.

• Resolution with "disable-connected-check":

  • The "neighbor neighbor-address disable-connected-check" command suspends the connected check, allowing the router to employ any route from the routing table to initiate the active open process, except for a default route.

• Successful eBGP Peering:

  • The effectiveness of this configuration is demonstrated when "neighbor neighbor-address disable-connected-check" is applied to both R1 and R2.
  • This results in the successful establishment of eBGP peerings between R1 and R2.

• TTL Value Consideration:

  • By default, the TTL value is set to one, which may seem problematic when using loopbacks.
  • However, the successful creation of an adjacency disproves this theory.

• eBGP Peering Over Loopback Interfaces:

  • R1 and R2 establish an eBGP peering without requiring alterations to the TTL (Time-to-Live) value.
  • The TTL value restriction pertains exclusively to actual router hops, and loopback interfaces do not incur this TTL decrement.
  • This ensures the smooth operation of their BGP connection over loopback interfaces.

ebgp multihop

• eBGP Peering Over Multiple Hops:

  • In certain eBGP peering scenarios, the local router may need to connect with a remote BGP-speaking router situated multiple router hops away.
  • Configuring the TTL (Time-to-Live) value appropriately is crucial to ensure BGP messages can reach their destination.

• Using "neighbor ebgp-multihop hop-count":

  • The "neighbor ebgp-multihop hop-count" command is utilized to address this requirement.
  • It allows you to specify the number of router hops to reach the remote peer and adjusts the TTL value in the IP header of transmitted BGP messages accordingly.
  • This ensures that BGP messages traverse the necessary distance to reach the remote peer.

• Simplified Configuration:

  • When the "neighbor ebgp-multihop" command is configured with a value of 2 or higher (the default is 255 if no value is entered), it eliminates the need for the "neighbor neighbor-address disable-connected-check" command.
  • The "neighbor ebgp-multihop" command effectively resolves TTL-related concerns, eliminating the reliance on directly connected routes for peering IP addresses.
  • This simplifies the configuration, ensuring that eBGP peering can successfully occur over multiple router hops.

• Rationale for eBGP Peering with "eBGP multihop":

  • The establishment of an eBGP peering session with an "eBGP multihop" setting of 2 is driven by the need to establish connections over multiple hops.
  • It's important to note that this setting is not related to TTL modifications. In a previous example, successful eBGP peering between R1 and R2 occurred without TTL adjustments.

• Maximum Distance and Connected Checks:

  • From a BGP perspective, the "eBGP multihop" setting implies that the neighboring router is considered reachable within a maximum distance of 2 router hops.
  • Importantly, in this configuration, the routers have disabled the connected checks for the neighbor. This is confirmed by examining the "show ip bgp neighbors 2.2.2.2" output.

• Flexible eBGP Peering:

  • This approach provides flexibility in eBGP peering, accommodating scenarios where the remote neighbor may be located further away in terms of router hops.
  • It ensures the successful establishment of the BGP peering session, even when dealing with such multi-hop scenarios.

• Verification with "show ip bgp neighbors 2.2.2.2":

  • When the command "show ip bgp neighbors 2.2.2.2" is executed, specific output details are provided to confirm the configuration and its impact on the peering session.
  • The output presented in this context has been selectively extracted to focus on the relevant information.

Generalized TTL Security Feature (GTSM)

• GTSM Introduction:

  • GTSM (Generic TTL Security Mechanism) is defined in RFC 5082.
  • RFC 7454 outlines the application of GTSM to BGP as a security mechanism to prevent BGP session spoofing.

• Enabling GTSM in BGP:

  • GTSM is enabled using the "neighbor x.x.x.x ttl-security hops hop-count" command.
  • This command sets a minimum expectation on the TTL value in the IP header for potential neighbors.
  • GTSM ensures that incoming protocol packets are accepted only if their TTL values meet or exceed the specified threshold.

• Acceptance or Rejection:

  • A router accepts and processes the connection attempt when the TTL value in the received IP header is equal to or greater than the configured expectation.
  • If the received TTL value falls short of the configured threshold, the router rejects the connection attempt.

• GTSM Configuration Effects:

  • When GTSM is enabled using the "neighbor x.x.x.x ttl-security hops hops" command, the router makes two significant changes:
    1. Sets the TTL of outgoing packets to 255.
    2. Only accepts BGP packets with a TTL equal to or greater than the expected TTL value.
  • The TTL setting to 255 is crucial for accurate hop counting and TTL comparisons.
  • The router configures its interface not to accept a BGP packet with a TTL value indicating a distance greater than the configured hop count.
  • The expected TTL is calculated by subtracting the hop count value from 255.
  • The router accepts the packet only if the received TTL value is equal to or greater than the expected TTL value.

• Peer Configuration:

  • By default, BGP routers originate BGP packets with a default hop count of 1 for eBGP neighbors.
  • For proper GTSM operation and consistent TTL values, both BGP peers should be configured for GTSM.
  • Configuring both peers for GTSM ensures that routers originate BGP packets with a TTL of 255, facilitating GTSM's effectiveness.
  • On Cisco devices ebgp-multi-hop should be disabled before configuring GTSM or you will get an error message

• Comparison with ebgp-multihop:

  • The BGP GTSM hop count setting functions similarly to the ebgp-multihop setting, allowing routers to establish connections over multiple hops.
  • If the hop count is set to 2 or greater, the BGP connected check is silently disabled.
  • When set to 1, the BGP connected check remains enabled.
  • to confirm use the command sh ip bgp neigh X.X.X.X | in external|External|Minimum

Summary of BGP Peering Commands:

1. Neighbor Disable-Connected-Check Command:

   • Purpose: Disables the BGP connected check when establishing eBGP peers using loopback interfaces.
   • Key Points:
     • TTL of resulting BGP packets remains set to 1.
     • Most beneficial for directly-connected eBGP peers using loopback interfaces for peering.

2. Neighbor EBGP-Multihop Command:

   • Purpose: Indicates the number of hops separating a BGP peer and sets the TTL value in the BGP packet accordingly.
   • Key Points:
     • If set to a value greater than 1, it automatically disables the BGP connected check.
     • Ideal for scenarios where prospective eBGP peers are separated by multiple router hops.
     • Suitable for directly-connected eBGP peers using loopback interfaces for peering. In such cases, the hop count should be 2 or greater for successful peering.

3. Neighbor TTL-Security Hops Command:

   • Purpose: A security mechanism setting a minimum TTL value for received BGP packets from a configured neighbor.
   • Key Points:
     • If the hops value is set to a value greater than 1, it automatically disables the BGP connected check.
     • Provides security against BGP spoofing attacks by dropping spoofed packets with TTL values below the minimum.
     • Imposes a maximum hop count, limiting the configured peer to a maximum of hops away from the router.
     • Configuration on both eBGP peers is necessary for compatibility.
     • Suitable for directly-connected eBGP peers using loopback interfaces for peering. In such cases, the hops value should be 2 or greater for successful peering.

These commands offer versatile options for configuring and securing BGP peering relationships, catering to different network scenarios and requirements.

Another way to allow the 2 neighbors to establish connectivity without changing the default behavior of BGP is by using either L2VPN or GRE Tunnelling, PPPOE or IPnIP tunneling

Alternative Solutions with MPLS:

In situations where traditional Layer 3 approaches, such as GRE tunneling and IPnIP tunneling, are not viable options to address the connectivity issue between routers, alternative Layer 2 solutions can come to the rescue. One such solution involves the use of Multiprotocol Label Switching (MPLS).

• MPLS Technology Overview:

  • MPLS inserts a header, known as an MPLS label, between the Layer 2 and Layer 3 headers of an IP packet.
  • Multiple labels can be attached to a single packet, forming an MPLS label stack.
  • Routers use the information in the MPLS labels to determine forwarding instructions, and this process is referred to as label switching.
  • Label switching occurs without making traditional routing decisions, making MPLS a Layer 2.5 protocol due to its unique header insertion.

• MPLS Label Creation and Distribution:

  • MPLS labels have numeric values that identify specific label-switched paths (LSPs) that packets should follow.
  • Routers generate unique label values for each IP prefix in their routing tables.
  • Label distribution protocols, like the Label Distribution Protocol (LDP), are used to exchange label information between routers.
  • Routers discover LDP neighbors and share label information with each other.

• MPLS Implementation:

  • MPLS is typically enabled on most versions of Cisco IOS automatically.
  • To participate in MPLS forwarding, designate specific interfaces using the "mpls ip" command in interface configuration mode.
  • Enabling this command initializes the necessary data structures for label forwarding and facilitates LDP hello message exchange with neighboring routers.
  • Routers equipped for MPLS forwarding are known as Label Switched Routers (LSRs).

• MPLS Forwarding and Label Header:

  • In MPLS, forwarding decisions are based on MPLS label headers, not the IP header.
  • The MPLS header has its own TTL value, separate from the IP TTL.
  • The ingress LSR (the first router to receive an unlabeled packet) creates the MPLS label stack, copying the IP TTL to the MPLS label header TTL.
  • The packet is forwarded to the next-hop router, which examines the MPLS label header TTL and performs various operations based on its value.

• Final Destination-Based Routing:

  • MPLS effectively tunnels the IP packet through routers along its path.
  • The IP packet is exposed for traditional destination-based IP routing only at the final LSR along the route, known as the egress LSR.

• Example Scenario:

  • Configuring MPLS on on each router along the path using the "mpls ip" command on their directly-connected interfaces can help illustrate the practical implementation of MPLS to address specific connectivity challenges.
  • on each R1 and R3 routers we are trying to establish a BGP session with we can enter the command show mpls ldp binding x.x.x.x [ distination Mask or Mask length] 32 is the prefix-length MPLS provides a powerful alternative approach, allowing efficient and flexible handling of network traffic, especially when traditional Layer 3 methods are not suitable for solving connectivity issues between routers.

Label Assignment and MPLS Efficiency:

In the context of Multiprotocol Label Switching (MPLS), routers assign labels to IP prefixes to optimize packet forwarding. Understanding the concept of "local binding" and the role of labels can shed light on how MPLS contributes to network efficiency.

On R1:

On R3:

• Local Binding in MPLS:

  • "Local binding" refers to the label assigned by a router to an IP prefix within its own network.
  • This label value is not only used for internal packet forwarding but also shared with Label Distribution Protocol (LDP) neighbors.
  • For instance, a router like R1 might assign an "implicit null label" to its 1.1.1.1 prefix and assign a label value of 17 to the 3.3.3.3 prefix.

• Implicit Null Label:

  • The "implicit null label" is a unique label used to enhance MPLS forwarding efficiency.
  • Consider a scenario where R1 is directly connected to the 1.1.1.1/32 prefix.
  • If R1 advertises a typical MPLS label to R2, R2 would send MPLS-labeled packets for that destination.
  • R1, not configured with the "mpls ip" command on its outgoing interface (lo0), would need to remove the label stack and perform a destination-based IP lookup.
  • To optimize this process, R1 advertises the "implicit null label" to R2 for that prefix.
  • The "implicit null label" instructs R2 to remove the label stack before forwarding the packet to R1.
  • This approach allows R1 to perform a straightforward destination-based IP lookup, avoiding unnecessary MPLS label operations.
  • This optimization at the penultimate hop is known as "Penultimate Hop Popping" (PHP).

• Marking "Pop" Operation:

  • R2, upon receiving the packet with the "implicit null label," marks it as a "pop" operation in its MPLS forwarding table.
  • This action ensures that R2 knows to remove the label stack before forwarding the packet to its final destination.

Understanding local binding, the implicit null label, and the PHP concept in MPLS sheds light on how routers optimize packet forwarding within MPLS networks. These practices contribute to more efficient and streamlined data transmission.

Optimizing MPLS Label Handling:

Within Multiprotocol Label Switching (MPLS) networks, a crucial consideration is ensuring that the inner IP packet is not exposed prematurely, as this can lead to issues like early decrementation of the IP Time-to-Live (TTL) value. To address this concern and maintain efficient MPLS label handling, routers can be configured to use explicit null labels instead of implicit null labels.

• The Challenge:

  • Exposing the inner IP packet too early can be problematic since the IP TTL value of 1 might be decremented, potentially leading to packet drops.
  • To overcome this challenge, routers like R1 and R3 can be configured to advertise an explicit null label.

• Using Explicit Null Labels:

  • The "explicit null label" enforces the retention of the MPLS label stack on the IP packet until it reaches its final destination.
  • Instead of removing the label stack prematurely, routers are instructed to keep it intact.
  • This ensures that the inner IP packet remains protected, and the IP TTL value is not prematurely decremented.

• Configuration Example:

  • To implement this solution, the following configuration can be applied:
    • On R1 and R3, use the command "mpls ldp explicit-null."

• Impact on R2:
  • When this configuration is applied, R2's MPLS forwarding behavior is affected:
    • The "show mpls ldp binding 1.1.1.1 32" command output on R2 reflects the change, showing an explicit null label instead of an implicit null label in the remote binding received from R1.
    • R2's MPLS forwarding table is updated accordingly.

By configuring routers to use explicit null labels, MPLS networks can ensure that inner IP packets are handled more efficiently, reducing the risk of TTL decrementation and related issues. This optimization contributes to smoother MPLS packet forwarding.

Ensuring Proper MPLS TTL Handling:

After enabling and confirming the functionality of Multiprotocol Label Switching (MPLS) in the network, the next critical step is to guarantee that packets are switched with the correct TTL values in the MPLS headers. By default, routers replicate the Time-to-Live (TTL) value from the IP header to the MPLS label TTL field. However, for efficient packet transit within the MPLS network, it's essential to disable this default TTL copying on all routers.

We can see in the below packet capture of a TCP ACK this behavior:

• The MPLS header is (in Red)

• We can see the TTL fields have a value of 1 for the MPLS and IP header (in light blue)

• Default TTL Copying:

  • Routers typically mirror the TTL value from the IP header into the MPLS label TTL field by default.
  • This behavior is illustrated in packet captures, where both the IP header and MPLS header TTL fields have the same value, often 1.
  • This copying is done to maintain TTL consistency but can impact the successful transit of packets between routers in the MPLS network.

• Disabling Default TTL Copying:

  • To resolve this issue and ensure proper packet transit beyond intermediate routers like R2, the "no mpls ip propagate-ttl" command should be configured.
  • This command, applied in global configuration mode, effectively disables the default copying of TTL values within the MPLS headers.

• Configuration Impact:

  • The "no mpls ip propagate-ttl" command should be applied to all routers within the MPLS network to achieve uniform TTL handling.

By implementing this configuration across all routers in the MPLS network, the default TTL copying is disabled. This ensures that packets maintain the correct TTL values within the MPLS headers, facilitating seamless transit and effective MPLS packet forwarding as shown below:

Here is the new packet capture of an ACK between R3 and R1:

MPLS TTL Handling and Forwarding:

In an MPLS-enabled network, the handling of Time-to-Live (TTL) values is crucial for maintaining effective packet forwarding. Unlike the default behavior, where the MPLS TTL is set to 1, proper MPLS TTL handling involves routers ensuring the correct TTL values are used within MPLS headers.

• Default MPLS TTL Handling:

  • By default, when MPLS is enabled, routers typically set the MPLS TTL to 1.
  • As a result, when a router like R1 initiates a TCP SYN with a TTL of 1, it appends an MPLS label with a TTL of 255 between the Ethernet and IP headers.
  • When the packet reaches R2, the forwarding decision is made based on the MPLS label rather than the inner IP header.

• Modified MPLS TTL Handling:

  • In this scenario, R2 does not alter the inner IP header's TTL value, preserving it as 1.
  • R2 performs its label operation and forwards the packet to R3, which receives the packet with the unaltered IP header and a TTL value of 1.
  • Consequently, R3 treats the received TCP packet as if R1 were directly connected to it.

• Bi-Directional Handling:

  • The same TTL handling principles apply to packets sent from R3 to R1, ensuring consistent behavior for both directions of communication.

By configuring routers to maintain proper MPLS TTL handling, MPLS networks can ensure that TTL values within MPLS headers are appropriately preserved. This optimization facilitates seamless and efficient packet forwarding, both when initiating communication and when responding to it.

Layer 3 Transparency in an MPLS Network:

In the context of an MPLS (Multiprotocol Label Switching) network, Layer 3 routing perspectives can be dramatically altered. Routers like R1 and R3 may appear to be merely a single hop away, with intermediate router R2 becoming essentially transparent thanks to the implementation of MPLS.

• Single Hop Illusion:
  • From a Layer 3 routing perspective, R1 and R3 may seem like they are directly connected, akin to a single hop in the network.
  • This perception arises due to the MPLS infrastructure, which introduces a level of abstraction that simplifies the view of the network.
• Transparency of R2:
  • R2, functioning as an intermediate router in the MPLS network, effectively becomes transparent to Layer 3 routing decisions.
  • MPLS enables R2 to efficiently handle packet forwarding based on MPLS labels, making it appear as if it doesn't add complexity to the routing path between R1 and R3.

We can confirm this by doing a traceroute between R3 and R1: