IT Log

Record various IT issues and difficulties.

I volunteer to be your BGP neighbor, committing to propagate every route for you endlessly. An In-Depth Exploration of BGP Confederation and Route Reflectors Based on Huawei ENSP

Current Technical Blog Abstract 🌟

  • Route Reflector Overview:

    • Role Definition: Introduces Route Reflectors (RR) and their clients, with RR acting as the central node responsible for reflecting route information within a BGP network.
    • Route Reflector Reflection Rules: Through multiple examples, explains the reflection rules of route reflectors in route propagation and illustrates how to configure route reflectors.
    • Route Reflector Loop Prevention Mechanisms: Further discusses how Origin ID and cluster lists are utilized to prevent BGP loops and ensure routing validity and security.

  • Route Reflector Networking Scheme:

  • BGP Federation:

    • Application and Configuration of AS Numbers: Explains the special role of AS numbers in BGP federation, including how to effectively manage and configure AS numbers to optimize route information propagation.
    • EBGP Split Horizon and AS-Path Mechanism: Combines the AS-Path mechanism with EBGP split horizon to explain their joint impact on BGP routing selection, providing better controllability and flexibility.
    • BGP Federation Configuration Practical: Through specific configuration examples (including R1 to R6 configuration examples), demonstrates how to actually operate and deploy BGP federation to enhance network efficiency and stability.

    • Introduction 📘

    ​

    1.BGP Route Reflectors in the AS

    • BGP routes propagate within the AS, functioning as a single hop transfer

    image-20230330030639351

    1.1 Roles:

    RR—Route Reflector

    • RR acts like a mirror, reflecting the BGP route information it receives to other BGP peers.

     

    Client—-RR Client

    • All devices can be RR clients, but this needs to be specified by RR.

    • Only the IBGP peers of RR can be considered its clients.

    • We refer to the system consisting of RR and its clients as a routing reflection cluster. Each routing reflection cluster will use RR’s RID as its cluster ID to identify different clusters.  

    ​

    1.2 The Reflection Rules of Route Reflectors

    • If RR receives a non-client IBGP route information from its own, it can forward it to its client.

    • If RR receives a client IBGP route information from its own, it can forward it to all of its non-clients and exclude the customer that sent the route.

    • If RR learns a routing information from its own eBGP peer, it can forward it to everyone.

    • RR can only reflect the available and preferred route information that is present on itself.

    Reflection Rule Example (1)

    • If a route reflector learns a route from its non-customer peer via IBGP, it reflects that route to all its customers.

    •  If a route reflector learns an IBGP route from its own customer, it reflects that route to all non-customers and to all other customers except that particular customer.
    Reflection Rules Example (2)

     Note:
    • Here, “sending” refers to the traditional BGP route propagation behavior (equivalent to scenarios where RR does not exist), while “reflection” refers to the routing transmission actions performed by RR in accordance with route reflection rules. Routes that are reflected out will have special path attributes inserted by RR.

    Route Reflector Configuring RR with an Example:

    image-20240514211811926

    [r3-bgp]peer 2.2.2.2 reflect-client   --- Designates R2 as a local RR client

     Advancements in Route Reflectors

    • The introduction of route reflectors resolved the issue of IBGP route transmission and eliminated the IGRP split-horizon principle.
    • The IGRP split-horizon principle was designed to prevent BGP loops; its elimination may introduce loop risks.

     

    Please see the image displayed here.

    1.3 Route Reflector Anti-loop in Scenario

    image-20221012205639893

    Originator ID

    • If a BGP route is reflected to other routers by the RR, and the route already carries an Originator ID attribute, this attribute is retained.
    • Otherwise, the RR device adds the Originator ID attribute to this route information and sets its value to the RID of the originating router within the local AS.

    image-20230330161649363

    • If a router receives an IBGP route from an IBGP peer and the originator ID attribute carried by the route matches the local BGP Router ID, the router will recognize that the route information originated locally and ignore the update of this route information, thus avoiding loops.。
    • This attribute parameter is only transmitted within the AS and is not propagated outside the AS.

    Cluster List

    image-20230331102626869

    • If a BGP route is reflected by a Route Reflector, and the route already has a Cluster List attribute, the local Cluster ID of the Route Reflector will be appended before the existing cluster IDs in the Cluster List. If the route does not have a Cluster List attribute, the Route Reflector will create a new Cluster List attribute for the route and add its local Cluster ID to it.
    • When a Route Reflector receives a BGP route, if the route carries a Cluster List and the list contains its own local Cluster ID, it will ignore the update for that route information..—-This loop-prevention effect is similar to the AS_Path attribute.
    Note:

    • When RR learns a route from EBGP and propagates it to its own IBGP peers, it does not create the originator ID or cluster list attributes because this is essentially not part of the route reflection behavior.

    • These two attributes are only transmitted within the AS. Once outside the AS, these two attributes are removed.

    • When a route reflector performs route reflection, apart from these two attributes, no other path attributes are modified.

    2. Reflector Networking Solution

    2.1 Backup RR Network Grouping

    image-20230331145241950

    • When Client 1 receives a BGP route from an EBGP peer, it will advertise this route to RR1 and RR2 via IBGP.
    • Upon receiving the updated route, RR1 and RR2 add their local cluster ID to the cluster list and reflect it to other clients while mutually reflecting between themselves.
    • When RR1 and RR2 receive routes from mutual reflection, they check the cluster list. If the cluster ID matches their own, they ignore the route update to prevent loop issues.

    2.2 If we need to build a backup RR network, all RR devices must use the same cluster ID..

    [r2-bgp]reflector cluster-id 2.2.2.2 --- Configure on RR, after configuration, it will overwrite the original cluster ID and use 2.2.2.2 as the new cluster ID value.

    2.3 Multi-Cluster Route Reflection Federation

    • Let the reflector clusters’ RR establish iBGP peer relationships with each other

     

    3.BGP Federation

    3.1 The Mystery of AS Numbers in BGP Federation

    image-20230403014022615

    • The real AS 3456 is known as the federation ASN.
    • While the
      • Member ASes within the confederation are invisible to external entities outside the confederation.
      Note:

      3.2 EBGP Horizontal Split Mechanism and AS-Path‘s Synergistic Relationship

      • The EBGP horizontal split mechanism relies on the AS-Path attribute to complete, which records all the ASes that the route has passed through. For confederation ASes, within the confederation AS, the member AS numbers are carried normally for loop prevention, and when transmitting out of the confederation AS, the member AS numbers are removed and the confederation AS number is added normally.

      3.3 BGP Confederation Configuration Practical

      Route Reflector:
      • In large BGP networks, route reflectors are used as supplementary technology alongside federal technology.
      • The reason is: if member ASes in a federation are single-homed, they can only have two devices; if there are multiple devices on a single-homed connection, it will lead to split horizon issues within the member AS for IBGP.

      Image-20240516204009044

      R1:

      [r1]bgp 100
[r1-bgp]router-id 1.1.1.1
[r1-bgp]peer 10.1.13.3 as-number 3456  ----Using the confederation AS number to establish a BGP peer, because R1 doesn't know the contents of the member AS.

      R3:

      [r1]bgp 100
[r1-bgp]router-id 1.1.1.1
[r1-bgp]peer 10.1.13.3 as-number 3456  ----Using the confederation AS number to establish a BGP peer, because R1 doesn't know the contents of the member AS.

      R4:

      [r4]bgp 64512
[r4-bgp]router-id 4.4.4.4
[r4-bgp]confederation id 3456
[r4-bgp]peer 3.3.3.3 as-number 64512
[r4-bgp]peer 3.3.3.3 connect-interface LoopBack 0
[r4-bgp]confederation peer-as 64513 - Specify on EBGP peer devices to inform the device of the member AS number with which it establishes neighborship; if not specified, the neighbor relationship cannot be established normally.
[r4-bgp]peer 5.5.5.5 as-number 64513
[r4-bgp]peer 5.5.5.5 connect-interface LoopBack 0
[r4-bgp]peer 5.5.5.5 ebgp-max-hop - Modified to the maximum value, as within an AS, it is impossible to determine the number of hops required for neighborship

      R5:

      [r5]bgp 64513
[r5-bgp]router-id 5.5.5.5
[r5-bgp]confederation id 3456
[r5-bgp]confederation peer-as 64512
[r5-bgp]peer 4.4.4.4 as-number 64512
[r5-bgp]peer 4.4.4.4 connect-interface LoopBack 0
[r5-bgp]peer 4.4.4.4 ebgp-max-hop
[r5-bgp]peer 4.4.4.4 next-hop-local
[r5-bgp]peer 6.6.6.6 as-number 64513
[r5-bgp]peer 6.6.6.6 connect-interface LoopBack 0
[r5-bgp]peer 6.6.6.6 next-hop-local
[r5-bgp]peer 10.1.25.2 as-number 200

      R6:

      [r6]bgp 64513
[r6-bgp]router-id 6.6.6.6
[r6-bgp]confederation id 3456
[r6-bgp]peer 5.5.5.5 as-number 64513
[r6-bgp]peer 5.5.5.5 connect-interface Loopback 0

      R2:

      [r6]bgp 64513
[r6-bgp]router-id 6.6.6.6
[r6-bgp]confederation id 3456
[r6-bgp]peer 5.5.5.5 as-number 64513
[r6-bgp]peer 5.5.5.5 connect-interface Loopback 0

      ​

    , , , , , , , , ,

    10 responses to “I volunteer to be your BGP neighbor, committing to propagate every route for you endlessly. An In-Depth Exploration of BGP Confederation and Route Reflectors Based on Huawei ENSP”

    1. Overall, this article serves as a valuable guide for both beginners and experts in mastering BGP confederation and route reflector techniques.

    2. I found the discussion on loop prevention mechanisms, such as Origin ID and cluster lists, to be crucial for maintaining network integrity.

    3. The article’s focus on AS number management and its impact on route propagation is particularly insightful for advanced BGP configurations.

    4. This in-depth exploration of BGP confederation and route reflectors is a must-read for anyone aiming to optimize their network routing strategies.

    5. The inclusion of specific Huawei ENSP examples adds real-world applicability to the theoretical concepts discussed.

    6. Learning about the backup RR network and multi-cluster setups has significantly improved my understanding of BGP redundancy and scalability.

    7. The article effectively breaks down complex concepts like EBGP split horizon and AS-Path mechanism, making them easier to grasp.

    8. I appreciate the practical examples provided, especially the configuration details for R1 to R6, which offer clear guidance for implementing BGP federation.

    9. The detailed explanation of route reflector rules and loop prevention mechanisms is invaluable for designing a secure and efficient BGP network.

    10. This article provides a comprehensive understanding of BGP route reflectors and confederation, making it an excellent resource for network professionals looking to enhance their knowledge in BGP configurations.

    Leave a Reply