BGP Next-Hop-Self

In the previous lesson, you established the iBGP session between R2 and R4.
The session is up, and R4 receives the prefix 192.168.1.0/24.

However, R4 does not install this route in its routing table.

Figure 1 – iBGP preserves the eBGP next hop

To understand why this happens, examine the Next Hop column in the BGP table on R4:

R4# show ip bgp
<output omitted>

     Network          Next Hop            Metric LocPrf Weight Path
 * i  192.168.1.0      10.0.12.1                0    100      0 65001 i

Look at the status flags.
The asterisk (*) indicates a valid route. However, the greater-than symbol (>) is missing.
The route is not selected as the best path because R4 cannot reach the Next Hop IP address (10.0.12.1).

Why does iBGP preserve the original Next Hop?

By design, eBGP and iBGP handle Next Hop attributes differently:

• eBGP: When an eBGP router forwards a route across AS boundaries, it changes the Next Hop address to its own IP address.

• iBGP: When an iBGP router forwards a route inside the same AS, it retains the original eBGP Next Hop address.

Figure 2 – Unreachable next hop on R4

R1 sent 192.168.1.0/24 to R2 with Next Hop 10.0.12.1.
When R2 forwarded this route to R4 via iBGP, R2 kept 10.0.12.1 as the Next Hop address.

How does Next-Hop reachability fail?

The IP address 10.0.12.1 belongs to the link between R1 and R2 (10.0.12.0/30).
In your core network, OSPF handles internal routing.

However, you intentionally excluded external customer links from OSPF.
Because OSPF does not know the 10.0.12.0/30 subnet, R4 has no internal path to reach 10.0.12.1.

Check the IP routing table on R4 to confirm:

R4# show ip route bgp
R4#

The output is empty.
R4 refuses to install the BGP route because a router never installs a BGP path if its Next Hop address is unreachable in the routing table.

You must fix Next-Hop reachability without flooding the core IGP with external subnets.
The next-hop-self command solves this issue at the edge router.