In routing, the term “next hop” does not always mean the next hop is a physically adjacent interface. The next hop, as in this case, can be more than one router away.

BGP specifies that routes learned through IBGP are never propagated to other IBGP peers. SanJose1 has learned via EBGP about the 10.1.0.0/16 network from ISP1 with a next hop address of 192.168.1.1, the IP address of ISP1. SanJose1 uses this same next hop address of 192.168.1.1 in its IBGP update to SanJose3.

What are two solutions to this problem?

One solution is for SanJose1 to advertise the 192.168.1.0/30 network within the EIGRP routing domain. This can be done by either including an EIGRP network command for 192.168.1.0 or redistribute the connected network into EIGRP. The second solution is for SanJose1 to modify the next hop address for routes learned from ISP1. This needs to be address propagated by EIGRP such as its loopback0 address.

3. The decision is made to modify the behavior on SanJose1 so that it uses its loopback0 interface as the next hop address in its IBGP updates.

SanJose1(config)# router bgp 65000

SanJose1(config-router)# neighbor 172.17.4.1 next-hop-self

SanJose1(config-router)#

Note: For consistency, a similar configuration for SanJose3 is shown. You do not need to configure this. This would need to be done if ISP2 router actually existed in our lab topology.

SanJose3(config)# router bgp 65000

SanJose3(config-router)# neighbor 172.17.2.1 next-hop-self

SanJose3(config-router)#

4. Re-examine the BGP table on SanJose3 using the show ip bgp command to see if SanJose3 now has a valid next hop to the 10.1.0.0/16 network.

SanJose3# show ip bgp

BGP table version is 5, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*>i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i

r>i 172.16.2.0/24 172.17.2.1 0 100 0 i

*> 172.16.4.0/24 0.0.0.0 0 32768 i

SanJose3#

Notice that the next hope address has been changed to SanJose1’s loopback0 address 172.17.2.1 which is reachable because it being advertised in EIGRP updates from SanJose1.

5. Re-examine the routing table on SanJose3 using the show ip route command to see if SanJose3 now has a route to the 10.1.0.0/16 network.

SanJose3# show ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

a - application route

+ - replicated route, % - next hop override

Gateway of last resort is not set

10.0.0.0/16 is subnetted, 1 subnets

B 10.1.0.0 [200/0] via 172.17.2.1, 00:03:17

172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks

D 172.16.1.0/30 [90/2681856] via 172.16.1.5, 01:26:06, Serial0/0/0

C 172.16.1.4/30 is directly connected, Serial0/0/0

L 172.16.1.6/32 is directly connected, Serial0/0/0

D 172.16.2.0/24 [90/2684416] via 172.16.1.5, 01:26:06, Serial0/0/0

D 172.16.3.0/24 [90/2172416] via 172.16.1.5, 01:26:06, Serial0/0/0

C 172.16.4.0/24 is directly connected, GigabitEthernet0/0

L 172.16.4.1/32 is directly connected, GigabitEthernet0/0

172.17.0.0/16 is variably subnetted, 4 subnets, 2 masks

D 172.17.2.0/24 [90/2809856] via 172.16.1.5, 01:26:06, Serial0/0/0

D 172.17.3.0/24 [90/2297856] via 172.16.1.5, 01:26:06, Serial0/0/0

C 172.17.4.0/24 is directly connected, Loopback0

L 172.17.4.1/32 is directly connected, Loopback0

SanJose3#

6. In the previous output, SanJose3 shows a route to the 10.1.0.0/16 network. Verify reachability to this network by pinging ISP1’s G0/0 interface.

SanJose3# ping 10.1.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

SanJose3#

Notice that the ping was not successful. One reason is because SanJose3 is not advertising the network used as the source IP address in the ping, the 172.16.1.4/30 network.

SanJose3 is advertising its 172.16.4.0/24 network in its BGP updates using the network command in its initial BGP configuration. Use the ping command changing the source IP address for the ping to use SanJose3’s G0/0 IP address 172.16.4.1.

SanJose3# ping 10.1.0.1 source gig 0/0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:

Packet sent with a source address of 172.16.4.1

U.U.U

Success rate is 0 percent (0/5)

SanJose3#

Even with the correct source IP address the ping does not succeed.

Even though SanJose3 has a route to ISP1’s 10.1.0.0/16 network, why do the pings from SanJose3 fail to 10.1.0.1?

The problem lies with SanJose2. SanJose2 is completely unaware of the 10.1.0.0/16 network.