BGP Route Reflectors

iBGP Split-Horizon Rule: Understanding the BGP Split-Horizon Principle

Introduction to iBGP Split-Horizon Rule

• The iBGP (Internal Border Gateway Protocol) split-horizon rule is a fundamental concept in BGP (Border Gateway Protocol) that governs the distribution of routing information between internal BGP peers. While the network community commonly refers to it as the iBGP split-horizon rule, the RFC (Request for Comments) uses different terminology to describe this rule's behavior. This rule is detailed in RFC 4271, which defines the operation of BGP.

The iBGP Split-Horizon Rule

• The iBGP split-horizon rule can be understood by examining an excerpt from RFC 4271, specifically from section 9.2, which outlines the "Update-Send Process." This section states:
  • When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker SHALL NOT re-distribute the routing information contained in that UPDATE message to other internal peers (unless the speaker acts as a BGP Route Reflector [RFC2796]). In essence, the iBGP split-horizon rule dictates that when a BGP router receives an UPDATE message from an internal peer, it should not advertise the routing information contained in that message to other internal peers. There is an exception to this rule when the BGP speaker acts as a BGP Route Reflector.

Understanding the AS_PATH Attribute

To comprehend why the iBGP split-horizon rule is crucial, it's essential to delve into how BGP detects routing information loops. When BGP routers advertise paths between Autonomous Systems (ASes), they prepend their own ASN to the AS_PATH attribute of the advertised path. The receiving router checks the AS_PATH attribute for every path it receives from a BGP neighbor. If it finds its own ASN in the AS_PATH, the router will reject the prefix. This mechanism forms the basis for BGP loop prevention.

BGP primarily focuses on routing between ASes, treating each AS as a single router. ASNs (Autonomous System Numbers) play a pivotal role as loop prevention mechanisms, akin to router names or IDs. For example, a path with ASNs 100, 300, and 200 in the AS_PATH attribute means that the path has passed through routers 100, 300, and 200.

The Challenge with Internal Peers

The problem arises when applying this mechanism to internal BGP peers. If a BGP-speaking router adds its local ASN to the AS_PATH attribute of a path being advertised to an internal peer, the internal peer would reject the path because the AS_PATH contains the local ASN. The internal peer would incorrectly assume that the path had previously been advertised to the local AS and was being returned in error. In reality, the advertising router is merely relaying the path for the first time. Furthermore, this approach presents an inaccurate representation of the actual ASN hops the path traverses.

To illustrate this, consider both routers within the same ASN. They are akin to interfaces directly connected to the "router" ASN. There's no reason for a router to inform one of its receiving interfaces that it has received a packet from itself.

The iBGP Split-Horizon Resolution

The solution to this issue is to avoid updating the AS_PATH information when advertising routes to internal peers. This means that within an AS, BGP does not modify the AS_PATH attribute when sending updates to internal peers. Consequently, BGP's primary loop prevention mechanism is eliminated for paths advertised among internal peers.

With the AS_PATH left unaltered for paths exchanged among iBGP peers, BGP routers lose the ability to detect if a particular path has looped among other internal peers. To prevent loops, the safest approach is to advertise a path internally to a single router hop away. This eliminates the possibility of a looping BGP update message within the AS.

This explains why all iBGP configurations often specify full-mesh peering sessions. When internal paths are propagated only from the originating router to its directly-peered iBGP peers, ensuring that all routers receive the path requires establishing direct iBGP peering sessions among all internal routers.

Cisco BGP AS-Override Split-Horizon (opens in a new tab)

Introduction to BGP Route Reflectors

In Border Gateway Protocol (BGP) deployments, establishing full mesh connectivity among internal BGP (iBGP) peers can become impractical as the network scales. This is where BGP Route Reflectors come into play. Route Reflectors offer a scalable and efficient solution for managing iBGP peering, making large-scale BGP networks more manageable.

Calculating a full mesh BGP peering sessions:

• Calculating iBGP Peering Sessions: The number of sessions required for a full-mesh iBGP design can be determined using the formula N(N-1)/2, where N represents the number of internal BGP routers.
• Example Scenario: In this context, there are expected to be 23 internal BGP routers (3 existing plus 20 additional). Applying the aforementioned formula indicates that there would be a requirement for 253 peering sessions to achieve a full-mesh of iBGP peers once the 20 additional routers are online.
• Considerations: It's important to note that a large number of iBGP peering sessions can lead to bandwidth and operational challenges within the network. This is due to the exchange of BGP updates among all the neighbors.
• This is why we need BGP Route Reflectors

What Are BGP Route Reflectors? RFC 4456 (opens in a new tab)

• BGP Route Reflector Solution: To address the scalability challenge in iBGP, a solution known as the BGP Route Reflector is introduced. This concept was originally defined in RFC 1966 and later revised in RFC 4456.
• Operation: The BGP route reflector configuration allows a BGP router to relax the iBGP split-horizon rule. Instead of each iBGP peer connecting to every other iBGP peer, all iBGP peers establish peering sessions with a single designated router.
• Reflection Process: When the designated router receives an internal path from one of its iBGP peers, it has the capability to advertise (or reflect) that path to all of its other configured iBGP peers. This approach significantly reduces the number of internal peer sessions required for all routers to receive all internal paths.

Roles in Route Reflection

In the context of Route Reflection, there are specific roles that routers can assume:

• Route Reflector Server (RR): The RR is a designated router that acts as a hub within a cluster of iBGP peers. It receives BGP updates from its clients and reflects those updates to other clients and non-client peers within the same cluster.

• Route Reflector Client (RC): RCs are the iBGP peers that connect to the RR. They receive updates from the RR and relay those updates to their local iBGP peers. An RR and its associated RCs form a BGP cluster.

• RR + RC = A Cluster: The combination of a Route Reflector Server and its connected Route Reflector Clients constitutes a BGP cluster, simplifying the management of iBGP peers within a network.

• NON-Client (Regular iBGP Speaker): These are iBGP peers that do not connect to a Route Reflector. They interact directly with other iBGP peers or RRs in a traditional full mesh configuration.

Additional BGP Attributes To avoid Routing Information loops RFC 4456 Section 9 (opens in a new tab)

To enable efficient route reflection and to prevent routing loops through misconfiguration, two additional BGP attributes were introduced to detect and avoid routing information loops:

1. ORIGINATOR_ID: ORIGINATOR_ID is a newly introduced, optional, non-transitive BGP attribute with Type code 9. This attribute consists of 4 bytes and is generated by a Route Reflector (RR) when reflecting a route. The purpose of this attribute is to carry the BGP Identifier of the originator of the route within the local Autonomous System (AS).
   • Attribute Handling: A BGP speaker should refrain from creating an ORIGINATOR_ID attribute if one is already present in the route. Additionally, when a router identifies the ORIGINATOR_ID attribute, it should disregard any route that has its own BGP Identifier as the ORIGINATOR_ID.

2. CLUSTER_LIST: CLUSTER_LIST is a newly introduced, optional, non-transitive BGP attribute with Type code 10. It represents a sequence of CLUSTER_ID values that indicate the reflection path that a route has traversed.
   • Attribute Usage: When a Route Reflector (RR) reflects a route, it is required to prepend the local CLUSTER_ID to the existing CLUSTER_LIST. If the CLUSTER_LIST is empty, the RR must create a new one. This attribute serves the purpose of allowing an RR to detect if routing information has looped back to the same cluster due to misconfiguration. If the local CLUSTER_ID is found in the CLUSTER_LIST, the received advertisement should be disregarded.

Route Reflector attributes:

To address looping within an Autonomous System (AS), ORIGINATOR and CLUSTER_LIST attributes are utilized. However, these attributes are not present by default in standard BGP path UPDATES. The route reflector serves as the logical insertion point for these attributes.

When reflecting routes to clients, the route reflector follows these steps:

1. Attribute Generation:

   • If ORIGINATOR and CLUSTER_LIST are absent, the router creates them.
     • ORIGINATOR is set to the BGP router ID of the original path advertiser.
     • Its own CLUSTER_ID (default: BGP router ID) is added to CLUSTER_LIST.

2. Attribute Prepending:

   • If the reflected route already has ORIGINATOR and CLUSTER_LIST:
     • Retain the existing ORIGINATOR attribute.
     • Prepend its own CLUSTER_ID to the CLUSTER_LIST attribute.

Scenarios:

• First Case:

  • Indicates the path did not pass through a route reflector cluster.
  • Attributes are added before reflecting the path according to route reflection rules.

• Second Case:

  • Verifies against ORIGINATOR and CLUSTER_LIST to prevent looping.
  • Prepend its own CLUSTER_ID before reflecting the route based on route reflection rules.

BGP CLUSTER_ID Configuration

• The CLUSTER_ID is automatically configured to the route reflector's BGP router ID by default. However, it can be modified using the bgp cluster-id cluster-id command in BGP router configuration mode.

• If this command is employed to set the CLUSTER_ID on two routers to the same value, paths with that CLUSTER_ID in the CLUSTER_LIST attribute will be dropped by both routers. An example is illustrated below, where both routers are configured with the CLUSTER_ID 21.21.21.21:

• Two paths would be received, each from a different route reflector. Notably, the CLUSTER_LIST attribute lists the same CLUSTER_ID for both paths. This indicates that the routers are using the same CLUSTER_ID, establishing that all routers participate in the same route reflector CLUSTER.

• This capability to use redundant route reflectors based on CLUSTER_ID configuration offers significant flexibility for various route reflector design scenarios.

Route Reflection Configuration:

• Route Reflection Configuration: Unlike an explicit global configuration command that designates a router as a route reflector for all its neighbors, route reflection is configured on a peer-by-peer basis.

• Configuration Command: Route reflection is achieved using the neighbor neighbor-address route-reflector-client BGP router configuration command. By using this command, a specific neighbor is designated as a route reflector client of the local router.

• Flexibility: This configuration approach offers flexibility, allowing a router to become a route reflector for only a subset of its iBGP peers if the network design requires such a setup.

• With that said let us look at the commands to configure RR

• R1:

router bgp 100
neighbor 20.1.1.2 remote-as 100
neighbor 30.1.1.2 remote-as 100
neighbor 20.1.1.2 route-reflector-client
neighbor 30.1.1.2 route-reflector-client

• R2:

router bgp 100
neighbor 10.1.1.1 remote-as 100

• R3:

router bgp 100
neighbor 10.1.1.1 remote-as 100

In the above configuration:

• Upon successfully completing the previously described configuration steps, the BGP peering sessions are established between R1 - R2 and R1 - R3.
• Additionally, R1 creates an update group for its new route reflector clients to facilitate the routing updates.
• On R1 our Route Reflector if we check out the output of the show ip bgp update-group which provides information on the update group and its settings.

• If we check out the output of show ip route 3.0.0.0 and show ip route 2.0.0.0 on each R2 and R3 respectively we will see that the "% Network not in table"

• if we issue the command show ip bgpon each R2 and R3 respectively we will see that the loopback addresses of each router do no have the ">" symbol besides them

• On R2 and R3 (RC) if we check the output of show ip bgp 3.0.0.0 and show ip bgp 2.0.0.0 We can see that the router next-hop to reach the destination is inaccessible.

Recap of what is happening so far:

• Inaccessible Next-Hops: R1 advertises the next-hops to R2 and R3 for specific prefixes, but these next-hops are marked as inaccessible on R2 (for 3.0.0.0) and R3 (for 2.0.0.0).

• Role of Next-Hop: Every BGP path is associated with a next-hop address. This address is crucial for routers to determine the exit interface when forwarding packets based on BGP-learned routes in the routing table.

• Route Recursion: The process of determining the exit interface involves route recursion, where the router performs a secondary route lookup to reach the next-hop address in the routing table. If no route to the next-hop is found, it is considered unresolved.

• Unresolved Next-Hops: An unresolved next-hop cannot be used for packet forwarding since the recursive process fails without a route to the next-hop. Consequently, these paths with unresolved next-hops are considered invalid and cannot be considered in BGP's best path selection process.

• Topology Specifics: In this topology, R2 lacks reachability to the 13.1.1.3 address, which is the next hop for the 3.0.0.0 network. Similarly, R3 lacks reachability to the 12.1.1.2 address, which serves as the next hop for the 2.0.0.0 network. Consequently, with these unresolvable next-hop addresses, they are listed as inaccessible in the BGP table.

• Retention of Original Next-Hops: The question that arises is why the original next-hop addresses are retained, considering their inaccessibility.

• Next-Hop Behavior in BGP: When a BGP router advertises a path to an external BGP (eBGP) peer, it includes its own peering address as the next-hop. In contrast, when advertising a path to an internal BGP (iBGP) peer, the router retains the original next-hop address. This behavior represents the default route advertisement in BGP.

• Customizing Next-Hop Behavior: Routers can be configured to set themselves as the next-hop on a peer-by-peer basis using the neighbor neighbor-address next-hop-self command.

• Route Reflector Consistency: Route reflectors follow a similar pattern and do not modify the next-hop addresses when advertising an iBGP route to clients or non-clients. They simply reflect the route with the original next-hop address. Even if configured with the neighbor neighbor-address next-hop-self command, the route reflector will only set itself as the next-hop for routes it originates.

• BGP Path Attribute Preservation: According to RFC 4456, when a Route Reflector (RR) reflects a route, it is advised not to modify certain path attributes, including NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Modifying these attributes could potentially lead to routing loops.

• How to solve this issue: To address the challenge, R2 and R3 must be able to reach the next-hop addresses for each other's loopback 0 networks, learned from R1 through BGP. Achieving this typically involves running an Interior Gateway Protocol (IGP) like OSPF to provide reachability information. However, the task specifically mentions the removal of OSPF as an option. Additionally, as noted earlier, using the neighbor next-hop-self command is not suitable for this purpose.

• Alternative Approach: An alternative approach is to explicitly configure the route reflector to set the next-hop address to itself for iBGP paths it reflects using a route-map. In this way, when R1 reflects routes from R2 to R3 and vice versa, the next-hop attribute in the BGP update will carry R1’s peering address, which is directly connected to R2 and R3. Consequently, the next-hops can be resolved using directly-connected routes on R2 and R3, enabling them to be marked as the "best" in the BGP table.

• Next-Hop Modification: The next-hop modification can be accomplished using the set ip next-hop sub-command within a route map.

• Solution Steps: To solve the task, two route-maps are created on R1, named "R2" and "R3." Under the route-map "R2," the command set ip next-hop 12.1.1.1 is issued to set the next-hop to 12.1.1.1 for the paths that R1 reflects to R2. Similarly, under the route-map "R3," the command set ip next-hop 13.1.1.1 is issued to set the next-hop to 13.1.1.1 for the paths that R1 reflects to R3.

• R1:

route-map NEXT-HOP-R2
 set ip next-hop 12.1.1.1
!
route-map NEXT-HOP-R3
 set ip next-hop 13.1.1.1
 
! Now we apply the route map to our neighbor statements for R2 and R3 in the outbound direction 
neighbor 12.1.1.2 remote-as 100
neighbor 13.1.1.2 remote-as 100
 

• First we will take a look at a packet capture between R1 and R2 before we apply the route-map. Notice how as discussed earlier that when R2 sends an update message to R1 the Next_HOP path attribute is set to R2s IP address 12.1.1.2 and R1 will advertise it to R3 as is.

• After we apply the route-map now R1 taking a look at a packet capture between R1 and R3 we can see that when R1 goes to send R3 and update message for R2's loopback interface it now shows R1 as the next hop address thus giving us reachability to R2's loopback 2.2.2.2 from R3

• Sources:
  • Cisco IOS IP Routing: BGP Command Reference (opens in a new tab)
  • IP Routing Configuration Guide, Cisco IOS XE 17.x-BGP Diverse Path Using a Diverse-Path Route Reflector (opens in a new tab)
  • This resource from catch point is great and also has a lab: BGP Monitoring Guide from catchpoint (opens in a new tab)

Verification and Validation

To verify and validate the configuration and operation of BGP Route Reflectors, network administrators can use the following commands:

• show ip bgp neighbors | inc Route-Reflector|neighbor: This command displays information about Route Reflectors and iBGP neighbors.

• show ip bgp [prefix/prefix-length]: Use this command to inspect BGP routing information related to specific prefixes.

• debug ip bgp update: The debug command allows for real-time tracking and debugging of BGP updates.

Conclusion

BGP Route Reflectors are an essential tool for simplifying iBGP peering within large-scale networks. By intelligently redistributing BGP updates among iBGP peers, they provide scalability and manageability, ultimately contributing to a more efficient and reliable BGP infrastructure.