Description

RFC 4271 defines Next-Hop attribute as:

5.1.3 NEXT_HOP

The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the destinations listed in the UPDATE message.

When sending the UPDATE message to an internal BGP peer, if the route is not locally originated, there can be reachability issues from Internal BGP peer because it cannot reach the next-hop.

Solution

In the figure below, EBGP peering is established between R1 and R2, while IBGP peering is established between R2 and R3.

alt

Configuration of R1: 

set interfaces xe-0/0/17 unit 0 family inet address 1.1.1.1/30
set interfaces lo0 unit 0 family inet address 3.3.3.3/24

set protocols bgp group EBGP type external
set protocols bgp group EBGP export EBGP-ADVERTISEMENT
set protocols bgp group EBGP peer-as 20
set protocols bgp group EBGP neighbor 1.1.1.2

set routing-options autonomous-system 10

set policy-options policy-statement EBGP-ADVERTISEMENT term 1 from route-filter 3.3.3.3/32 exact
set policy-options policy-statement EBGP-ADVERTISEMENT term 1 then accept
set policy-options policy-statement EBGP-ADVERTISEMENT term 2 then reject

Configuration of R2: 

set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24
set interfaces xe-0/0/17 unit 0 family inet address 1.1.1.2/30
set interfaces lo0 unit 0 family inet address 2.2.2.2/24

set protocols bgp group EBGP type external
set protocols bgp group EBGP peer-as 10
set protocols bgp group EBGP neighbor 1.1.1.1
set protocols bgp group IBGP type internal
set protocols bgp group IBGP neighbor 192.168.1.1

set routing-options autonomous-system 20

Configuration of R3: 

set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces fxp0 unit 0 family inet address 10.85.241.63/25

set protocols bgp group IBGP type internal
set protocols bgp group IBGP neighbor 192.168.1.2

set routing-options autonomous-system 20

 

At this point, when EBGP peer R1 advertises the prefix 3.3.3.3/32 towards its EBGP peer R2, R2 advertises the same towards R3 which is IBGP peer. This is due to the functionality of BGP where route advertisements are automatically performed from EBGP peer to IBGP peer.

In the output below, we can verify that R1 is advertising the prefix 3.3.3.3/32 while R2 and R3 are receiving the same. However, observing the output of R3, the route is actually placed as a hidden route. The reason is that R3 was unable to reach the next-hop 1.1.1.1, so it will place this route neither in the BGP table nor in the Routing table.   

root@R1> show route advertising-protocol bgp 1.1.1.2

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3.3.3.3/32              Self                                    I

root@R2> show route receive-protocol bgp 1.1.1.1

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3.3.3.3/32              1.1.1.1                                 10 I

root@R3> show route receive-protocol bgp 192.168.1.2 hidden

inet.0: 5 destinations, 5 routes (4 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  3.3.3.3/32              1.1.1.1                      100        10 I

 

There are 2 ways to resolve the above issue:

  1. Advertise next-hop via IGP - OSPF, IS-IS, RIP, etc. ( Not explained in this KB )
  2. Using next-hop "self" under policy-options    

The next-hop "self" has to be configured on R2 under policy-options hierarchy like specified below: 

set protocols bgp group IBGP export EBGP-TO-IBGP
set policy-options policy-statement EBGP-TO-IBGP term 1 from protocol bgp
set policy-options policy-statement EBGP-TO-IBGP term 1 then next-hop self
set policy-options policy-statement EBGP-TO-IBGP term 1 then accept
set policy-options policy-statement EBGP-TO-IBGP term 2 then reject

 

Once the above configuration is done on R2, verify the status of the route in R3.

The route is installed in both the BGP table as well on the Routing table and post that the prefix is reachable from R3 to R1.

Verification: 

root@R3> show route receive-protocol bgp 192.168.1.2

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3.3.3.3/32              192.168.1.2                  100        10 I

root@R3> show route 3.3.3.3

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3.3.3.3/32         *[BGP/170] 00:02:33, localpref 100
                      AS path: 10 I, validation-state: unverified
                    > to 192.168.1.2 via ge-0/0/0.0       

root@R3> ping 3.3.3.3 count 4
PING 3.3.3.3 (3.3.3.3): 56 data bytes
64 bytes from 3.3.3.3: icmp_seq=0 ttl=63 time=1.504 ms
64 bytes from 3.3.3.3: icmp_seq=1 ttl=63 time=1.328 ms
64 bytes from 3.3.3.3: icmp_seq=2 ttl=63 time=1.314 ms
64 bytes from 3.3.3.3: icmp_seq=3 ttl=63 time=1.308 ms

--- 3.3.3.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.308/1.363/1.504/0.081 ms

Related Information