Fault Tolerant Peers

Loopback 0 6.6.6.6/24

Loopback 0 6.6.6.6/24

Loopback 0 4.4.4.4/24

.isc.0 com

Loopback 0 5.5.5.5/24

Loopback 0 4.4.4.4/24

• Use update-source keyword to point to a loopback interface

• Allows communication even if a physical interface goes down

© 2002. Cisco Systems. Inc. All rights reserved.

Cisco CCIE Prep v1.0—Module 8-32

neighbor {ip-address / peer-group-name} update-source interface-name

Using the update-source keyword for a peer allows iBGP sessions to use any operational interface for TCP connections. iBGP neighbor relationships can occur as long as there is TCP connection between peers. Using physical interfaces can create problems when they go down and another link is active to the peer. In other words, there is no fault-tolerance. Using loopback interfaces can allow fault tolerance in the BGP domain even when a link fails.

Using a loopback interface to define neighbors is common with iBGP, but not with eBGP. Normally the loopback interface is used to make sure the IP address of the neighbor stays up and is independent of properly functioning hardware. In the case of eBGP, the peer routers are directly connected frequently, and loopback does not apply.

The example shows a configuration where using loopback interfaces will allow fault tolerance.

In this scenario, R4, R5, and R6 are running a common IGP and have full routing tables for all routes including the loopbacks. They also are running iBGP in a full mesh.

R4(config)# int loopback 0

R4(config-if)# ip address 4.4.4.4 255.255.255.0 R4(config-if)# router bgp 100

R4(config-router)# neighbor 5.5.5.5 remote-as 100

R4(config-router)# neighbor 5.5.5.5 update-source loopback 0

R4(config-router)# neighbor 6.6.6.6 remote-as 100

R4(config-router)# neighbor 6.6.6.6 update-source loopback 0

R5(config)# int loopback 0

R5(config-if)# ip address 5.5.5.5 255.255.255.0

R5(config-if)# router bgp 100

R5(config-router)# neighbor 4.4.4.4 remote-as 100 R5(config-router)# neighbor 4.4.4.4 update-source loopback 0 R5(config-router)# neighbor 6.6.6.6 remote-as 100 R5(config-router)# neighbor 6.6.6.6 update-source loopback 0

R6(config)# int loopback 0

R6(config-if)# ip address 6.6.6.6 255.255.255.0 R6(config-if)# router bgp 100

R6(config-router)# neighbor 4.4.4.4 remote-as 100 R6(config-router)# neighbor 4.4.4.4 update-source loopback 0 R6(config-router)# neighbor 5.5.5.5 remote-as 100 R6(config-router)# neighbor 5.5.5.5 update-source loopback 0

Look at the configuration leading to the use of R4's loopback address as the peer IP address. Notice that R5 and R6 are referring to R4's loopback address in their neighbor statements. R4 is telling both R5 and R6 that it is using its loopback 0 as its update source.

neighbor {ip-address / peer-group-name} next-hop-self

RFC1771 Section 5.1.3 NEXT_HOP

"When a BGP speaker advertises the route to a BGP speaker located in its own autonomous system, the advertising speaker shall not modify the NEXTHOP attribute associated with the route."

Basically, this is saying if a border router receives an update from its eBGP neighbor, it will send an update to its iBGP peers with the next hop attribute unchanged. Now, look at an example.

In this example, neither AS is advertising the Demilitarized Zone (DMZ) network (172.16.23.0/24) in its IGP. R2 is configured as an eBGP peer with R3. R3 is configured as an iBGP peer with R7. R2 is advertising the network 10.2.2.0/24 to AS100.

R2(config)# router bgp 200

R2(config-router)# neighbor 172.16.23.3 remote-as 100 R2(config-router)# network 10.2.2.0 mask 255.255.255.0

R3(config)# router bgp 100

R3(config-router)# neighbor 172.16.23.2 remote-as 200

R3(config-router)# neighbor 172.16.70.7 remote-as 100

R7(config)# router bgp 100

R7(config-router)# neighbor 172.16.70.3 remote-as 100

Look at the BGP table on R3: R3#show ip bgp

BGP table version is 2, local router ID is 172.16.70.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Here, you see the network 10.2.2.0 is reachable via AS200, using the next hop 172.16.23.2, which is what you would expect to see. Because you learned this route via eBGP and you satisfied the requirement that the next hop is known to the IGP, you can place the route to 10.2.2.0/24 in the routing table. You can verify this by the *> status codes on the 10.2.2.0/24 network. This can be verified with the show command of the routing table.

R3#show ip route

Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, 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

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets C 172.16.23.0 is directly connected, Serial1

C 172.16.70.0 is directly connected, Serial0

10.0.0.0/24 is subnetted, 1 subnets B 10.2.2.0 [20/0] via 172.16.23.2, 00:15:41

Now, look at R7's BGP table. R7#show ip bgp

BGP table version is 1, local router ID is 172.16.70.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Here on R7, you have received the route to 10.2.2.0/24 in our BGP table, and you see the same next hop information. Even though this route is in our BGP table, it has not been inserted in the IP routing table. Notice the ">" best status code is missing after the *. You can verify this by performing a show ip route on R7.

R7#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, 0 - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 El - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, 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

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets C 172.16.70.0 is directly connected, Serial0/1

Two important items must be met before this route 10.2.2.0/24 can be placed in the IP routing table. The synchronization rule must be met, and the next hop requirement must be met. Neither of which are met on R7 at this time.

The next hop requirement is not met because R7 does not have a route to 172.16.23.0/24. This will be fixed when you add the next-hop-self option to R3 for its neighbor R7.

The synchronization rule can be met by either redistributing BGP into the IGP, or by using the no synchronization option on R7.

Now, it is time to concentrate on the next hop requirement, which has not been satisfied. You have a few options that would allow you to pass the next hop requirement:

■ Advertise the DMZ network in our IGP

■ Create a static route to the DMZ network

■ Use the next-hop-self attribute on R3

You will issue the next-hop-self command on R3 in its neighbor command to R7.

R3(config)# router bgp 100

R3(config-router)# neighbor 172.16.70.7 next-hop-self

Since you modified the BGP attributes to a neighbor, you must also clear the BGP connections to have the new policy updated. Issue the following command: R3# clear ip bgp *

Now, look at R7's BGP table again. R7#show ip bgp

BGP table version is 2, local router ID is 172.16.70.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Notice that the next hop is R3's serial interface 172.16.70.3, just as you expected, but you are still not placing this route in the routing table. This is because the IGP is not aware of a route to 10.2.2.0/24. If you issue the command no synchronization on R7, this will by-pass the synchronization requirement and install the route in the routing table.

R7(config)# router bgp 100 R7(config-router)# no synchronization

Now that both the next hop requirement and the synchronization requirement have been met, R7 should install the route to 10.2.2.0/24 in its IP routing table. First, clear the BGP connection to allow the no synchronization policy to take effect. Then look at R7's BGP table again.

R7#clear ip bgp * R7#show ip bgp

BGP table version is 2, local router ID is 172.16.70.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Now, you should have the route to 10.2.2.0/24 in R7's IP routing table. R7#show ip route

Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, 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 Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets C 172.16.70.0 is directly connected, Serial0/1

10.0.0.0/24 is subnetted, 1 subnets B 10.2.2.0 [200/0] via 172.16.70.3, 00:11:39

Normally, unless you are advertising your DMZ into the IGP, you will be setting the next-hop attribute on your border router going to each of your iBGP peers.

Was this article helpful?

0 0

Post a comment