next-hop-self
Explanation:
To determine the correct command, we need to analyze BGP behavior in a Hub-Spoke topology and how routes are advertised in MPLS VPN environments.
1. Understanding the Hub-Spoke BGP/MPLS VPN Topology
* The network consists of Hub-PE and Spoke-PE routers, which are MPLS VPN PEs.
* Hub-PE is responsible for distributing routes between Spoke-PE1 and Spoke-PE2.
* Spoke routers do not have direct IBGP peering with each other; instead, they rely on the Hub-PE to relay routes.
* BGP next-hop handling is critical for proper route advertisement.
2. Why is the "next-hop-self" Command Required?
* By default, when BGP advertises a route, the next-hop remains unchanged (i.e., the original next- hop is retained).
* In Hub-Spoke topology, Spoke routers would receive routes with a next-hop IP that belongs to another Spoke-PE, which is not reachable directly.
* To solve this issue, we use the next-hop-self command on the Hub-PE, so that:
* Hub-PE updates the next-hop to its own address before advertising routes to the Spoke-PEs.
* This ensures that Spoke-PE routers use the Hub-PE as the next-hop, making routes reachable and preventing blackholing.
3. Correct Command Usage
The administrator must run the following command under the BGP IPv4 address family of the BGP- VPN_out instance on Hub-PE:
shell
CopyEdit
peer 10.1.2.1 next-hop-self
This ensures that the next-hop for advertised routes is changed to the Hub-PE's IP, allowing proper route transmission in the Hub-Spoke MPLS VPN environment.