A junior engineer has configured eBGP between two CX switches (Agg-1 and Agg-2) using the configuration below, and tells you that the neighbors are in the ‘Active’ state.
What can you tell them?
A.
When configuring eBGP the AS numbers must match.
B.
The eBGP multi-hop feature must be configured.
C.
Peering using loopback addresses is not supported.
D.
The BGP peers are advertising and learning routes.
The term "Active" in BGP is one of the most misunderstood states. It sounds positive, but it actually indicates that the switch is " actively " trying to establish a TCP connection and failing.
eBGP Default Behavior: By default, External BGP (eBGP) expects neighbors to be directly connected. Because of this, eBGP packets are sent with a Time to Live (TTL) of 1 .
The Loopback Problem: In the exhibit, the switches are peering using their Loopback 0 addresses (update-source loopback 0). Even if the switches are physically connected, the Loopback interface is considered a " hop " away from the physical interface.
TTL Expiry: When Agg-1 sends a BGP packet to Agg-2 ' s loopback, the TTL of 1 expires before the packet can reach the logical loopback interface. This causes the TCP connection to fail, keeping the session in the Active state.
The Solution (eBGP Multihop): To fix this, you must configure ebgp-multihop (usually with a value of 2 or more). This increases the TTL, allowing the BGP packets to reach the loopback address.
Side Note on the Exhibit: If you look closely at Agg-1 ' s configuration, there is a typo: the neighbor is defined as 10.3.0.3 but the address-family activation is for 10.3.0.2. While this would also cause a failure, the core architectural concept being tested here regarding " Active " state and loopbacks is the TTL/Multihop requirement.
Contribute your Thoughts:
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit