Case Study IBGP Over an IGP

Last Updated on Wed, 08 Nov 2023 | Routing TCP IP

In Figure 3-6, the routers within AS 100 have been reconfigured. In this topology, OSPF is running as the autonomous system's IGP, and IBGP runs only between Vail and Telluride.

Figure :i f> OSPF Is Added to the Routers in AS 100

as 100

Aspen 192.168.1.198/30 OSPF

192.168.1.197/30

/ïeUbride as 100

Aspen 192.168.1.198/30 OSPF

192.168.1.197/30

/ïeUbride

ebgp

192.168.100.0/24 192.168.200.0/24 192.168.1.216/30

192.168.50.0/24

192.168.75.0/24 Alta

192.168.1.200/30

ebgp

192.168.100.0/24 192.168.200.0/24 192.168.1.216/30

as 200

192.168.50.0/24

192.168.75.0/24 Alta

192.168.1.200/30

as 400

Example 3-35 shows the configurations of the three routers in AS 100.

Example3-35 Configurations for Vail, Aspen, and Telluride in AS 100

Vail
router ospf 100
redistribute bgp 100 subnets
network 192.168.1.221 ( i	9.0.0.0 area 0
router bgp 100
neighbor 192.168.1.197	remote-as 100
neighbor 192.168.1.197	next-hop-self
neighbor 192.168.1.210	remote-as 300
neighbor 192.168.1.225	remote-as 200
Aspen
router ospf 100
network 192.168.1.0 0.<	).0.255 area 0
Telluride
router ospf 100
redistribute bgp 100 subnets
network 192.168.1.197 C	).0.0.0 area 0
router bgp 100
neighbor 192.168.1.205	remote-as 400
neighbor 192.168.1.221	remote-as 100
neighbor 192.168.1.221	next-hop-self

In the BGP configurations, synchronization is enabled and EBGP routes are redistributed into OSPF. (Synchronization enabled is the default, so no command appears in the configuration.) These two configuration steps are integral to the correct operation of the IBGP link. The redistribution serves the same purpose as the IBGP links to Aspen in the preceding case study. If Aspen receives a packet originated in AS 400 and destined for AS 200, and it does not know the route, it drops the packet.

Synchronization serves as insurance that the redistribution works correctly. If the route to 192.168.100.0/24 is not redistributed into OSPF at Vail, for instance, it will not show up in Telluride's routing table. Telluride knows about the route from the IBGP connection, but because the route is not in its routing table, the router cannot advertise the route to Alta. No traffic to that destination is forwarded from AS 400 to AS 100. If there is an alternative path from AS 400 to AS 200 (not shown in Figure 3-6), that path can be used.

Example 3-36 shows Telluride's BGP table and routing table, and Example 3-37 shows Alta's routing table. Notice from Telluride's configuration that no routes are redistributed from OSPF into BGP, and no BGP network commands are used. All necessary routes are already in Telluride's BGP table, and these are the routes that are advertised to Alta. The routes in Telluride's routing table serve only to satisfy the requirements of synchronization

Example 3-36 The BGP and Routing Tables of Telluride in Figure 3-6

Telluride#show ip bgp

BGP table version is 9, local router ID is 192.168.1.206

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

Telluride#show ip bgp

BGP table version is 9, local router ID is 192.168.1.206

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

*> 192.	,168,	.1.200/30	192.	,168.	,1	.205	0		400	i
*>i192.	,168,	.1.212/30	192.	,168.	,1	.221	0	100	300	i
*>i192.	,168,	.1.216/30	192.	,168.	,1	.221	0	100	200	i
*> 192.	,168,	.50.0	192.	,168.	,1	.205	0		400	i
*> 192,	,168,	.75.0	192.	,168.	,1	.205	0		400	i
*>i192,	,168,	.100.0	192.	,168.	,1	.221	0	100	200	i
*>i192,	,168,	.200.0	192.	,168.	,1	.221	409600	100	200	i
*>i192.	,168,	.250.0	192.	,168.	,1	.221	0	100	300	i

Telluride#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 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, * - candidate default U - per-user static route, o - 0DR T - traffic engineered route

Telluride#show ip route

Gateway of last resort is not set

B 192.168.75.0/24 [20/0] via 192.168.1.205, 15:16:37

0 E2 192.168.200.0/24 [110/1] via 192.168.1.198, 15:15:38, Ethernet©

0 E2 192.168.250.0/24 [110/1] via 192.168.1.198, 15:15:38, Ethernet©

Example 3-36 The BGP and Routing Tables ofTelluride in Figure 3-6 (Continued)

B 192.168.50.0/24 [20/0] via 192.168.1.205, 15:16:38

192.168.1.0/30 is subnetted, 6 subnets B 192.168.1.200 [20/0] via 192.168.1.205, 15:16:38

C 192.168.1.204 is directly connected, Serial©

C 192.168.1.196 is directly connected, Ethernet0

0 E2 192.168.1.216 [110/1] via 192.168.1.198, 15:15:38, Ethernet© 0 192.168.1.220 [110/20] via 192.168.1.198, 15:18:22, Ethernet©

0 E2 192.168.1.212 [110/1] via 192.168.1.198, 15:15:38, Ethernet© 0 E2 192.168.100.0/24 [110/1] via 192.168.1.198, 15:15:39, Ethernet©

Telluride#

Example 3-37 Alta's Routing Table in Figure 3-6

Alta#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 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, * - candidate default Gateway of last resort is not set

B 192.168.100.0 [20/0] via 192.168.1.206, 15:34:05

C 192.168.75.0 is directly connected, Ethernetl

C 192.168.50.0 is directly connected, Loopback0

192.168.1.0 255.255.255.252 is subnetted, 4 subnets C 192.168.1.200 is directly connected, Ethernet2

C 192.168.1.204 is directly connected, Serial©

B 192.168.1.216 [20/0] via 192.168.1.206, 15:33:37

B 192.168.1.212 [20/0] via 192.168.1.206, 15:33:37

B 192.168.250.0 [20/0] via 192.168.1.206, 15:34:05

B 192.168.200.0 [20/0] via 192.168.1.206, 15:34:05

The topology of Figure 3-6 contains a major vulnerability. If Aspen or one of its links fails, AS 400 is isolated from the rest of the internetwork. In Figure 3-7, a link is added between Vail and Telluride for redundancy, and a second IBGP session is established over the link.

Figure 3-7 A New Link and a Second IBGP Session Are Added Between Vail and Telluride for Redundancy

AS 100

Aspen -,92.168.1.198/30 OSPF

192 68.1.197/30

/Telluride

Figure 3-7 A New Link and a Second IBGP Session Are Added Between Vail and Telluride for Redundancy

AS 100

Aspen -,92.168.1.198/30 OSPF

192 68.1.197/30

/Telluride

EBGP

192.168.100.0/24 192.168.200.0/24 192.168.1.216/30

AS 400

EBGP

192.168.100.0/24 192.168.200.0/24 192.168.1.216/30

AS 200

192.168.50.0/24 192.168.75.0/24 Alta 192.168.1.200/30

AS 400

Example 3-38 shows the configurations of Vail and Telluride.

Example 3-38 Configurations for Vail and Telluride in AS 100

Vail router ospf 100 redistribute bgp 100 subnets network 192.168.1.193 0.0.0.0 area 0 network 192.168.1.221 0.0.0.0 area 0

router bgp 100 neighbor 192.168.1.194 remote-as 100 neighbor 192.168.1.194 next-hop-self neighbor 192.168.1.197 remote-as 100 neighbor 192.168.1.197 next-hop-self neighbor 192.168.1.210 remote-as 300 neighbor 192.168.1.225 remote-as 200

Telluride router ospf 100 redistribute bgp 100 subnets network 192.168.1.194 0.0.0.0 area 0 network 192.168.1.197 0.0.0.0 area 0

i router bgp 100 neighbor 192.168.1.193 remote-as 100 neighbor 192.168.1.193 next-hop-self neighbor 192.168.1.205 remote-as 400 neighbor 192.168.1.221 remote-as 100 neighbor 192.168.1.221 next-hop-self

Example 3-39 shows the resulting BGP table at Telluride. All the routes learned from Vail indicate two next-hop addresses, representing the two IBGP connections. A > indicates the path currently being used. If the link fails, the other link is used.

Example 3-39 Telluride's Routing Table Shows Alternative Paths for the Routes from Vail

Telluride#show ip bgp

BGP table version is 17, local router ID is 192.168.255.253

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

Network

Next Hop

Metric

LocPrf Weight

Path

*> 192.

,168.

,1.200/30

192.

168.

.205

400

*>i192.

.168.

,1.212/30

192.

168.

.193

100

300

* i

192.

168.

.221

100

300

*>i192.

.168.

,1.216/30

192.

168.

.193

100

200

* i

192.

168.

.221

100

200

*> 192.

,168.

,50.0

192.

168.

.205

400

*> 192.

,168.

,75.0

192.

168.

.205

400

*>i192.

,168.

,100.0

192.

168.

.193

100

200

* i

192.

168.

.221

100

200

*>i192.

,168.

,200.0

192.

168.

.193

409600

100

200

* i

192.

168.

.221

409600

100

200

*>i192.

,168.

,250.0

192.

168.

.193

100

300

* i

192.

168.

.221

100

300

Telluride#

Although the configuration illustrated in Figure 3-7 provides redundancy, the failover can be slow. By default, the BGP keepalive interval is 60 seconds and the hold time is 180 seconds, as shown in Example 3-40. Potentially, 180 seconds could pass before BGP detects a failed IBGP connection and switches to the other link. You can improve the failover time by resetting the BGP keepalive and hold times with the timers bgp command. For example, timers bgp 3 9 sets the keepalive interval to 3 seconds and the hold time to 9 seconds.

Example 3-40 The Default BGP Keepalive Time Is 60 Seconds, and the Default Hold Time Is 180 Seconds

Telluride#show ip bgp neighbor 192.168.1.193

BGP neighbor is 192.168.1.193, remote AS 100, internal link Index 2, Offset 0, Mask 0x4 NEXT_H0P is always this router BGP version 4, remote router ID 192.168.255.254 BGP state = Established, table version = 14, up for 00:01:30 Last read 00:00:31, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 5 seconds Received 6 messages, 0 notifications, 0 in queue Sent 5 messages, 0 notifications, 0 in queue Prefix advertised 3, suppressed 0, withdrawn 0 Connections established 1 ; dropped 0

continues

Example 3-40 The Default BGP Keepalive Time Is 60 Seconds, and the Default Hold Time Is 180 Seconds (Continued)

Last reset 00:02:51, due to User reset 3 accepted prefixes consume 96 bytes 0 history paths consume 0 bytes --More- -

Figure 3-8 shows a better way to add redundancy. Instead of creating two IBGP sessions over the alternative paths, a single IBGP session is created between the loopback interfaces of the routers. OSPF takes care of finding the best path for the IBGP session and reroutes the session much faster if a link fails.

Figure 3-8 A Single IBGP Session Is Established Between Vail's and Telluride's Loopback Interfaces

Example 3-41 shows the configurations of Vail and Telluride for the setup in Figure 3-8.

Example 3-41 Configuring a Single IBGP Session Between the Loopback Interfaces of Vail and Telluride

Example 3-41 shows the configurations of Vail and Telluride for the setup in Figure 3-8.

Example 3-41 Configuring a Single IBGP Session Between the Loopback Interfaces of Vail and Telluride

router ospf 100 redistribute bgp 100 subnets network 192.168.1.193 0.0.0.0 area 0 network 192.168.1.221 0.0.0.0 area 0 network 192.168.255.254 0.0.0.0 area 0

i router bgp 100 neighbor 192.168.1.210 remote-as 300

Example* \ 41 (\mfiguring a Single IBGP Session Between the Loopback Interfaces of Vail and Telluride (Continued)

neighbor 192.168.1.225 remote-as 200

neighbor 192.168.255.253 remote-as 100

neighbor 192.168.255.253 update-source Loopback0

neighbor 192.168.255.253 next-hop-self

Telluride interface Loopback0 ip address 192.168.255.253 255.255.255.255

i router ospf 100 redistribute bgp 100 subnets network 192.168.1.194 0.0.0.0 area 0 network 192.168.1.197 0.0.0.0 area 0 network 192.168.255.253 0.0.0.0 area 0

i router bgp 100 neighbor 192.168.1.205 remote-as 400 neighbor 192.168.255.254 remote-as 100 neighbor 192.168.255.254 update-source Loopback0 neighbor 192.168.255.254 next-hop-self

The significant difference in these configurations, beyond the obvious creation of loopback addresses, is the neighbor update-source statement. This command causes the BGP messages to be sourced from the IP address of the loopback interface rather than from the physical interface the message is sent on. Without it, the TCP source of the TCP sessions would be the outgoing interface address. The end points of the TCP sessions would not match and would therefore not come up. Also important is the additional network statement under OSPF, advertising the loopback address. Without it, the address is unreachable, and the IBGP session is not created. Example 3-42 shows Telluride's BGP table after the reconfiguration.

Example 3-42 The Next-Hop Address of the Routes from Vail Is VaiVs Loopback Address

Telluride#show ip bgp
BGP table version is 7, local router				ID	is 192.	168.255.253
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
*> 192.	,168	.1.200/30	192.168.1.205		0		0	400	i
*>i192.	.168,	.1.212/30	192.168.255.254		0	100	0	300	i
*>i192.	,168,	.1.216/30	192.168.255.254		0	100	0	200	i
*> 192.	,168,	.50.0	192.168.1.205		0		0	400	i
*> 192.	,168,	.75.0	192.168.1.205		0		0	400	i
*>i192.	,168,	.100.0	192.168.255.254		0	100	0	200	i
*>i192.	,168,	.200.0	192.168.255.254		409600	100	0	200	i
*>i192.	168.	.250.0	192.168.255.254		0	100	0	300	i
Telluride#

CAUTION The examples in this section use BGP-to-IGP redistribution to better demonstrate basic IBGP behavior. However, it is worth noting one more time that if you are receiving a large number of routes from an external BGP peer, redistribution into your IGP can be very dangerous. In a topology such as the one in Figure 3-8, the safe approach is to configure ;i full IBGP mesh—IBGP sessions between the loopback interfaces of all three routers in AS 100. Aspen then learns the necessary information for packet forwarding directly from BGR and no redistribution is necessary.

Continue reading here: Case Study EBGP Multihop

Was this article helpful?

Case Study IBGP Over an IGP

Related Posts