The BGP route is hidden on R5 because the BGP next-hop address (192.168.1.1, the IP of R1) is not reachable from R5's perspective. By default, when R4 advertises an EBGP-learned route to an IBGP peer (R5), it does not change the next-hop attribute.

There are two standard solutions to this problem:

1. Modify the next-hop attribute on R4 before advertising to R5. R4 can change the next-hop to its own IP address, a feature known as "next-hop-self". This makes the next-hop directly reachable for R5.

2. Ensure the original next-hop is reachable. This is done by advertising the external link prefix (192.168.1.0/30) into the Interior Gateway Protocol (IGP), allowing R5 to learn a route to 192.168.1.1.

A. This is a specific implementation of "next-hop-self" (Option B). While it would work, Option B describes the general, more common solution and is a better choice alongside the distinct method in Option D.

C. Advertising the internal IBGP link prefix into BGP does not help R5 resolve the unreachable external next-hop address (192.168.1.1).

1. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

BGP Feature Guide

next-hop-self: "By default

BGP advertises routes that it learns from an external BGP (EBGP) peer to an internal BGP (IBGP) peer without modifying the next-hop address... To change the next-hop address

include the next-hop-self statement... This statement causes the advertising routing device to substitute its own IP address for the third-party next-hop address." This reference directly supports option B.

2. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

OSPF Feature Guide

"Example: Redistributing Routes into OSPF": This documentation provides examples of configuring a routing policy to redistribute routes from other protocols (such as direct interface routes) into an IGP like OSPF. Applying this concept

R4 could redistribute its external link (192.168.1.0/30) into the IGP

making the BGP next-hop 192.168.1.1 reachable for R5. This reference supports the methodology in option D.

3. RFC 4271 - A Border Gateway Protocol 4 (BGP-4)

Section 5.1.3. NEXTHOP: This RFC specifies the behavior of the NEXTHOP attribute. It states

"The NEXTHOP attribute for a route learned via IBGP is the IP address of the BGP speaker that advertised the route to the local BGP speaker." This confirms that without intervention

R5 will receive the original next-hop from R4

which is the source of the problem.