Chapter 11. Configuring Effective Internet Routing Policies
This chapter covers the following key topics:
- • Symmetry, Redundancy, and Load
Balancing
Configuration examples for dynamically and statically learned defaults, multihoming to single and multiple providers, load balancing, and customers sharing a backup link.- • Following Defaults Inside an AS
Configuration examples for setting defaults in a variety of architectures. This section examines a particular routing problem assuming a variety of different IGPs.- • Policy Routing
Configuration example for routing based on source rather than destination.- • Route Reflectors
A practical example of using route reflectors in conjunction with peer groups.- • Confederations
A practical example of how to configure confederations.- • Controlling Route and Cache Invalidation
Syntax and practical example of BGP’s soft reconfiguration feature.- • Route Dampening
Syntax and practical example of BGP’s route dampening feature. - • Following Defaults Inside an AS
The preceding chapter covered configuration examples for all the basic functions and attributes of BGP. In this chapter, we will consider examples that address the challenging, potentially conflicting design goals of routing architecture. We will also look at examples designed to help manage growing, complex ASs.
Perhaps the most challenging part of configuring your network's routing architecture is determining what your routing policies should be. This step, of course, must come before the actual configuration process, and there is no simple, lockstep method for determining your policies. A careful analysis of network needs, behavior, and potential growth will reveal a unique set of problems and optimal solutions for every network.
Redundancy, Symmetry, and Load Balancing
The following examples will illustrate the implementation of different route redundancy, symmetry, and load balancing scenarios. Please remember that these scenarios are not cast in stone. Many variations of these techniques can be used to fit your situation. The examples presented here should guide you to a better understanding of how policies are set. We will first go over a brief implementation of default routes.
Dynamically Learned Defaults
It is important to control defaults in BGP because, if they are originated randomly, they could cause everybody serious problems. Problems occur when a BGP speaker that intends to originate a default to a specific peer ends up flooding the default over all its neighbors. Cisco provides a way to target the default toward a specific neighbor.
In figure 11-1, RTA is originating a default route 0.0.0.0 0.0.0.0 toward RTC only. IBGP neighbors, such as RTF, will not get the default. RTA's configuration follows.
Figure 11-1 Dynamically
learned defaults.
RTA configuration:
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 default-originate
no auto-summary
The default-originate option of the neighbor router subcommand will cause 0/0 to be sent toward RTC. This is shown in the BGP and IP routing tables of RTC:
RTC#show ip bgp
BGP table version is 14, local router ID is 192.68.11.1
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
*> 0.0.0.0 172.16.20.2 0 3 i
*> 172.16.1.0/24 172.16.20.2 0 0 3 i
*> 192.68.11.0 0.0.0.0 0 32768 i
RTC#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
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
Gateway of last resort is 172.16.20.2 to network 0.0.0.0
C 192.68.11.0/24 is directly connected, Ethernet0/0
C 172.16.20.0/24 is directly connected, Serial2/1
B* 0.0.0.0/0 [20/0] via 172.16.20.2, 00:04:40
The routing table of RTC indicates that RTC has dynamically learned the 0/0 default from RTA and has set its gateway of last resort to 172.16.20.2, which is RTA.
Defaults can also be originated over all BGP peers by using the "network 0.0.0.0" router command, as long as the router advertising this default already has its own default. The following configuration can be used assuming that RTA has a default route itself (default could be created via a static route).
RTA configuration:
router bgp 3
no synchronization
network 0.0.0.0
network 172.16.1.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
no auto-summary
Statically Set Defaults
Instead of dynamically learning the 0/0 default, a router can set its own default statically. This is illustrated in figure 11-2. RTC is using the following command:
ip route network [mask] {address | interface} [distance]
Figure 11-2 Dealing with
0/0 default.
The 0/0 static route can point to a network number, a gateway address, or to a physical interface as being the default path. The distance is a means of giving preference to the static route in case multiple entries for the same network exist. Routes with a lower distance are preferred over routes with a higher distance.
The following configuration shows how RTC can set the default to point toward network 193.78.0.0/16.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 192.68.6.1 remote-as 2
no auto-summary
ip route 0.0.0.0 0.0.0.0 193.78.0.0
The following BGP table of RTC shows that 193.78.0.0/16 has been learned via two paths—the first via AS3 and the second via AS2. BGP has preferred the first path as being the best (BGP attributes can be used to influence which path BGP will use and hence influence the default path).
RTC#show ip bgp
BGP table version is 8, local router ID is 192.68.11.1
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.68.11.0 0.0.0.0 0 32768 i
*> 193.78.0.0/16 172.16.20.2 0 3 7 6 i
* 192.68.6.1 0 2 7 6 i
The following IP table of RTC shows how the gateway of last resort has been set to follow network 193.78.0.0/16. Recursive lookup in the IP routing table shows that 193.78.0.0/16 can be reached via 172.16.20.2, which is RTA.
RTC#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
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
Gateway of last resort is 193.78.0.0 to network 0.0.0.0
C 192.68.6.0/24 is directly connected, Ethernet0/1
C 192.68.11.0/24 is directly connected, Ethernet0/0
B 193.78.0.0/16 [20/0] via 172.16.20.2, 00:32:32
C 172.16.20.0/24 is directly connected, Serial2/1
S* 0.0.0.0/0 [1/0] via 193.78.0.0
In case you do not want to follow a single route, you can still use the ip route 0.0.0.0 0.0.0.0 command to point to multiple networks or IP addresses. The "distance" keyword will give you the ability to prefer one default over the other. This is illustrated in the following:
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 192.68.6.1 remote-as 2
no auto-summary
ip route 0.0.0.0 0.0.0.0 172.16.20.2 40
ip route 0.0.0.0 0.0.0.0 192.68.6.1 50
Note how RTC is pointing to two different IP addresses. These could also have been two different network numbers that exist in the IP routing table. The "distance" 40 of the first static route will make sure that the route is preferred. In case the route to 172.16.20.2 goes away, the static entry will go with it, and the second entry will kick in. The following shows the output of RTC's routing table.
RTC#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
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
Gateway of last resort is 172.16.20.2 to network 0.0.0.0
C 192.68.6.0/24 is directly connected, Ethernet0/1
C 192.68.11.0/24 is directly connected, Ethernet0/0
B 193.78.0.0/16 [20/0] via 172.16.20.2, 00:45:08
C 172.16.20.0/24 is directly connected, Serial2/1
S* 0.0.0.0/0 [40/0] via 172.16.20.2
The following shows the same output in case the link between RTC and RTA goes down:
RTC#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
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
Gateway of last resort is 192.68.6.1 to network 0.0.0.0
C 192.68.6.0/24 is directly connected, Ethernet0/1
C 192.68.11.0/24 is directly connected, Ethernet0/0
B 193.78.0.0/16 [20/0] via 192.68.6.1, 00:01:14
S* 0.0.0.0/0 [60/0] via 192.68.6.1
Note how the second static entry with distance 60 has now kicked in.
Multihoming to a Single Provider
For the case where one customer has multiple connections to the same provider, we will look at implementation examples that cover the following:
- • Default only, one primary, and one backup
link
- • Default, primary, and backup plus partial routing
- • Automatic load balancing
- • Default, primary, and backup plus partial routing
Default Only, One Primary, and One Backup Link
In figure 11-3, AS3 is multihomed to AS1. AS3 is not learning any BGP routes from AS1 and is sending its own routes via BGP. RTA will be running defaults toward AS1, with the NY link being the primary link and the SF link being the secondary link. The following policies should apply:
Figure 11-3 Multihoming
to a single provider (default only, one primary, and one back up
link).
- 1. Outbound traffic from AS3 should always
go on the NY link unless that link fails, in which case it should
switch to the other link.
This can be achieved by configuring two static routes in RTA pointing the defaults toward the two links. The default via the NY link will be set with a lower distance to be more preferred.- 2. Inbound traffic toward AS3 should always come on the NY link unless that link fails, in which case it should switch to the other link.
This can be achieved by having RTA send different metrics toward AS1 on both links, with a lower metric on the NY link. This way, inbound traffic coming from AS1 will always come via the NY link.- 3. Prevent any BGP updates from coming into AS3.
This can be achieved by having AS3 configure a route map or distribute list that will block all incoming BGP routing updates. Usually, the provider (AS1, in this case) will not send you any updates per your request. Nevertheless, you should always protect the AS against the unknown. The provider could make a mistake and send you all his routes, and your AS would be vulnerable. - 2. Inbound traffic toward AS3 should always come on the NY link unless that link fails, in which case it should switch to the other link.
RTA configuration:
router bgp 3
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 route-map BLOCK in
neighbor 172.16.20.1 route-map SETMETRIC1 out
neighbor 192.68.9.2 remote-as 1
neighbor 192.68.9.2 route-map BLOCK in
neighbor 192.68.9.2 route-map SETMETRIC2 out
no auto-summary
ip route 0.0.0.0 0.0.0.0 172.16.20.1 50
ip route 0.0.0.0 0.0.0.0 192.68.9.2 40
route-map SETMETRIC1 permit 10
set metric 100
route-map SETMETRIC2 permit 10
set metric 50
route-map BLOCK deny 10
In the preceding configuration, AS3 has used static routes to configure defaults toward AS1. The 0/0 toward RTD is given a distance of 40, lower than the distance of 50 toward RTC. The NY link will act as primary. Alternatively, AS3 could have accepted a single entry from AS1 and configured that entry as being the default.
Route maps SETMETRIC2 and SETMETRIC1 are used to set the outbound metric to 50 toward RTD and 100 toward RTC, respectively. Inbound traffic will prefer the NY link.
Route map BLOCK is used to block all incoming BGP updates from AS1.
The following RTA IP routing table shows how the default route is set. Note that distance 40 is being preferred over distance 50 for the 0/0 route, and the gateway of last resort is pointing to next hop 192.68.9.2.
RTA#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
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 192.68.9.2 to network 0.0.0.0
C 192.68.9.0 is directly connected, Ethernet0
172.16.0.0 255.255.255.0 is subnetted, 2 subnets
C 172.16.220.0 is directly connected, Ethernet1
C 172.16.20.0 is directly connected, Serial0
S* 0.0.0.0 0.0.0.0 [40/0] via 192.68.9.2
The following is RTC's BGP table, and it shows that AS3 is always accessed via the RTD-RTA link because of the lower metric 50. Prefix 172.16.220.0/24 can be reached via IBGP and EBGP. The IBGP route has been chosen as the best route. Note in this table that RTC's next hop to reach prefix 172.16.220.0/24 is 192.68.6.1. This is because RTD has configured its neighbor connection with RTC using the next-hop-self neighbor command.
RTC#show ip bgp
BGP table version is 11, local router ID is 192.68.11.1
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
*>i172.16.220.0/24 192.68.6.1 50 100 0 3 i
* 172.16.20.2 100 0 3 i
*> 192.68.11.0 0.0.0.0 0 32768 i
Default, Primary, and Backup Plus Partial Routing
This example shows how traffic can be manipulated in a situation where the AS is accepting partial routing from a single provider and running defaults toward the provider. Partial routes are usually the provider's local routes and its customers' routes. Figure 11-4 shows AS3 running IBGP internally and running EBGP at two different locations with its provider AS1. The following policies should apply:
Figure 11-4 Default,
primary, and backup plus partial routing.
- 1. AS3 will only accept AS1's local routes
and its customers' routes such as AS6. AS3 will also accept one
route from the Internet to set its default toward the provider
AS1.
- 2. For all outbound traffic toward AS1 and AS6 (the partial routes), AS3 should use the SF link. In case of failure, the other link is used.
- 3. For all other outbound traffic toward the Internet, AS3 should use the NY link as the primary link by following a default route. In case of failure, the default via the other link should be used.
- 4. For inbound traffic, AS3 will instruct AS1 to use the SF link for network 172.16.220.0/24.
- 5. For all other inbound traffic, the NY link is the primary.
- 2. For all outbound traffic toward AS1 and AS6 (the partial routes), AS3 should use the SF link. In case of failure, the other link is used.
The following partial configurations are needed for the BGP configuration in RTA and RTF:
RTA configuration:
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.1.2 next-hop-self
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 route-map SET_OUTBOUND_TRAFFIC in
neighbor 172.16.20.1 route-map SET_INBOUND_TRAFFIC out
neighbor 172.16.20.1 filter-list 10 out
no auto-summary
ip route 0.0.0.0 0.0.0.0 193.78.0.0
ip as-path access-list 10 permit ^$
ip as-path access-list 4 permit ^1 6$
ip as-path access-list 4 permit ^1$
access-list 2 permit 172.16.220.0 0.0.0.255
access-list 101 permit ip 193.78.0.0 0.0.255.
255 255.255.0.0 0.0.0.0
route-map SET_OUTBOUND_TRAFFIC permit 10
match ip address 101
set local-preference 200
route-map SET_OUTBOUND_TRAFFIC permit 20
match as-path 4
set local-preference 300
route-map SET_INBOUND_TRAFFIC permit 10
match ip address 2
set metric 200
route-map SET_INBOUND_TRAFFIC permit 20
set metric 300
RTF configuration:
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.2.254 remote-as 3
neighbor 172.16.2.254 next-hop-self
neighbor 192.68.5.2 remote-as 1
neighbor 192.68.5.2 route-map SET_OUTBOUND_TRAFFIC in
neighbor 192.68.5.2 route-map SET_INBOUND_TRAFFIC out
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip route 0.0.0.0 0.0.0.0 193.78.0.0
ip as-path access-list 10 permit ^$
ip as-path access-list 4 permit ^1 6$
ip as-path access-list 4 permit ^1$
access-list 101 permit ip 193.78.0.0 0.0.255.255 255.255.0.0 0.0.0.0
route-map SET_OUTBOUND_TRAFFIC permit 10
match ip address 101
set local-preference 250
route-map SET_OUTBOUND_TRAFFIC permit 20
match as-path 4
set local-preference 250
route-map SET_INBOUND_TRAFFIC permit 10
set metric 250
The preceding configuration of RTA shows the following:
- 1. Route map SET_OUTBOUND_TRAFFIC is applied
on RTA's EBGP link to AS1. This route map will help specify which
outbound traffic goes over which link. The first instance (10)
will allow only one network, 193.78.0.0/16, to be accepted from
the Internet. This network is used to set the default. This will
be given a local preference of 200, which is lower than the local
preference 250 coming from RTF. This will cause all traffic toward
the Internet to follow the default via the NY link.
The second instance (20) will set all prefixes coming from AS1 and AS6 with a local preference of 300, which is higher than local preference 250 coming from RTF. This will make the SF link the primary link to reach AS1 and its customer AS6. Note that this route map will allow only partial routes (AS1 and AS6) to be injected into AS3 by specifying the AS_path to be either AS1 (^1$) or AS6 (^1 6$).
Notes:
Instead of listing all the customers of AS1 one by one as we did in as-path access-list 4, a regular expression of the form ^1 ?[0-9]*$ could have been used to identify all the AS_paths that start with 1 and of length 2—that is, AS1 and its direct customers. The form of the access list would have been: ip as-path access-list 4 permit ^1 ?[0-9]*$ (to enter the "?" press CTRL-V first). Careful: In the case where AS1 is directly connected to another major provider with a direct link (rather than via a NAP), the preceding regular expression would also give you the local routes of that second provider.
- 2. Route map SET_INBOUND_TRAFFIC is also applied on RTA will cause prefix 172.16.220.0/24 to be sent with a metric of 200, which is lower than the metric 250 sent by RTF. This will make sure that traffic from AS1 toward this destination will take the SF link. All other updates will be sent with a metric of 300, which is higher than metric 250 sent by RTF. This will cause all other inbound traffic to take the NY link.
- 3. The filter-list 10 will prevent AS3 from becoming a transit AS.
- 4. The ip route 0/0 statement sets the default to be 193.78.0.0/16.
- 2. Route map SET_INBOUND_TRAFFIC is also applied on RTA will cause prefix 172.16.220.0/24 to be sent with a metric of 200, which is lower than the metric 250 sent by RTF. This will make sure that traffic from AS1 toward this destination will take the SF link. All other updates will be sent with a metric of 300, which is higher than metric 250 sent by RTF. This will cause all other inbound traffic to take the NY link.
RTA's BGP table would have the following entries:
RTA#sh ip bgp
BGP table version is 19, local router ID is 172.16.2.254
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
* i172.16.1.0/24 172.16.1.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i172.16.10.0/24 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.65.0/26 172.16.1.2 0 100 0 i
*> 172.16.1.2 20 32768 i
* i172.16.220.0/24 172.16.1.2 20 100 0 i
*> 0.0.0.0 0 32768 i
*> 192.68.10.0 172.16.20.1 300 0 1 i
*> 192.68.11.0 172.16.20.1 0 300 0 1 i
*> 192.68.40.0 172.16.20.1 300 0 1 6 i
*>i193.78.0.0/16172.16.1.2 250 0 1 7 8 i
* 172.16.20.1 200 0 1 7 8 i
Note how RTA only sees networks that belong to AS1 and its customer AS6 (except for the default route). For network 193.78.0.0/16, which is the default, RTA follows the NY link because of the local preference 250. For traffic toward AS1 and AS6, RTA follows the RTA-RTC link (local preference 300). The following IP routing table of RTA shows that RTA has set its default to 193.78.0.0/16, which is reachable via 172.16.1.2.
RTA#sh 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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 193.78.0.0 to network 0.0.0.0
B 192.68.10.0/24 [20/0] via 172.16.20.1, 00:07:34
B 192.68.11.0/24 [20/0] via 172.16.20.1, 00:07:34
B 192.68.40.0/24 [20/0] via 172.16.20.1, 00:07:34
172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
C 172.16.2.254/32 is directly connected, Loopback0
C 172.16.220.0/24 is directly connected, Ethernet0
C 172.16.20.0/24 is directly connected, Serial0
O 172.16.10.0/24 [110/20] via 172.16.1.2, 01:39:52, Ethernet1
C 172.16.1.0/24 is directly connected, Ethernet1
O 172.16.65.0/26 [110/20] via 172.16.1.2, 01:39:52, Ethernet1
S* 0.0.0.0/0 [1/0] via 193.78.0.0
B 193.78.0.0/16 [200/0] via 172.16.1.2, 00:03:07
The following is an output of RTD's BGP table:
RTD#sh ip bgp
BGP table version is 14, local router ID is 192.68.10.1
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
*> 172.16.1.0/24 192.68.5.1 250 0 3 i
*> 172.16.10.0/24 192.68.5.1 250 0 3 i
*> 172.16.65.0/26 192.68.5.1 250 0 3 i
*>i172.16.220.0/24 192.68.6.2 200 100 0 3 i
* 192.68.5.1 250 0 3 i
*> 192.68.10.0 0.0.0.0 0 32768 i
*>i192.68.11.0 192.68.6.2 0 100 0 i
*>i192.68.40.0 192.68.6.2 0 100 0 6 i
*> 193.78.0.0/16 192.68.10.2 0 7 8 i
RTD can reach all networks in AS3 via the RTD-RTF direct link except for prefix 172.16.220.0/24, which is reachable via the RTC-RTA link because of the better metric 200.
Automatic Load Balancing
Considering figure 11-5, we will show how the Cisco BGP implementation can do dynamic load balancing for identical updates received by the same router from the same autonomous system. RTA is EBGP peering with routers RTC and RTD in AS1. RTA is receiving identical updates about prefixes 192.68.11.0/24 and 192.68.40.0/24 from two links. We can configure RTA with the maximum-paths router subcommand to enable IP routing to load balance among up to six paths. In our example, the maximum-paths number is set to 2.
Figure 11-5 Automatic
load balancing.
RTA configuration:
router bgp 3
no synchronization
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.60.1 remote-as 1
neighbor 172.16.60.1 filter-list 10 out
maximum-paths 2
no auto-summary
ip as-path access-list 10 permit ^$
Looking at RTA's BGP table, we see that RTA has identical path information regarding 192.68.11.0/24 and 192.68.40.0/24. Normally, BGP will pick one of the entries as the "best" path and give it to the IP routing table.
RTA#show ip bgp
BGP table version is 8, local router ID is 172.16.2.254
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
*>i172.16.10.0/24 172.16.1.2 0 100 0 i
*> 192.68.11.0 172.16.20.1 0 0 1 i
* 172.16.60.1 0 1 i
*> 192.68.40.0 172.16.20.1 0 1 6 i
* 172.16.60.1 0 1 6 i
Using the maximum-paths command will instruct BGP to give all the identical paths (up to six) to the IP routing table. Note that the requirement for these paths is that they come from the same AS.
The following shows how RTA will keep multiple entries from the same destination in its IP routing table. Note how prefixes 192.68.11.0/24 and 192.68.40.0/24 are learned from both links.
RTA#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is not set
B 192.68.11.0/24 [20/0] via 172.16.60.1, 00:03:20
[20/0] via 172.16.20.1, 00:03:18
B 192.68.40.0/24 [20/0] via 172.16.60.1, 00:03:20
[20/0] via 172.16.20.1, 00:03:18
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.16.2.254/32 is directly connected, Loopback0
C 172.16.60.0/24 is directly connected, Ethernet0
C 172.16.20.0/24 is directly connected, Serial0
O 172.16.10.0/24 [110/20] via 172.16.1.2, 00:20:23, Ethernet1
C 172.16.1.0/24 is directly connected, Ethernet1
When dealing with IBGP peers, RTA will only advertise a single BGP entry out of the multiple identical entries with a next-hop-self. Because RTA is IBGP peered with RTF, RTA will advertise only one BGP update about 192.68.11.0/24 and 192.68.40.0/24 with a next-hop 172.16.2.254 rather than the external next hop; this is illustrated in the following BGP table. For external peers, BGP will still pass on the best path as usual.
RTF#show ip bgp
BGP table version is 56, local router ID is 172.16.10.1
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
*> 172.16.10.0/24 0.0.0.0 0 32768 i
*>i192.68.11.0 172.16.2.254 0 100 0 1 i
*>i192.68.40.0 172.16.2.254 100 0 1 6 i
Balancing Between Two Routers Sharing Multiple Paths
This example shows how load balancing can be achieved between two routers sharing multiple paths without having routing updates being duplicated over the two paths.
For the scenario in figure 11-6, we will configure loopback interfaces on RTA and RTC and run a single peering session between the two routers. Using static routes, we can point to the loopback interfaces via both of the physical interfaces. This way, the IP routing table will have two paths to reach the next hop and will load balance.
Figure 11-6 Balancing
between two routes sharing multiple paths.
RTA configuration:
interface Loopback0
ip address 172.16.2.254 255.255.255.255
router bgp 3
no synchronization
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.90.1 ebgp-multihop 2
neighbor 172.16.90.1 update-source Loopback0
no auto-summary
ip route 172.16.90.1 255.255.255.255 172.16.20.1
ip route 172.16.90.1 255.255.255.255 172.16.60.1
RTC configuration:
interface Loopback0
ip address 172.16.90.1 255.255.255.255
router bgp 1
network 192.68.11.0
neighbor 172.16.2.254 remote-as 3
neighbor 172.16.2.254 ebgp-multihop 2
neighbor 172.16.2.254 update-source Loopback0
no auto-summary
ip route 172.16.2.254 255.255.255.255 172.16.20.2
ip route 172.16.2.254 255.255.255.255 172.16.60.2
The following output shows how RTA is now learning BGP updates from RTC via next hop 172.16.90.1, the loopback address.
RTA#show ip bgp
BGP table version is 4, local router ID is 172.16.2.254
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
*>i172.16.10.0/24 172.16.1.2 0 100 0 i
*> 192.68.11.0 172.16.90.1 0 0 1 i
The two static routes in RTA's routing table will provide multiple paths to reach the next hop 172.16.90.1, and hence the router will load balance between the two paths.
RTA#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is not set
B 192.68.11.0/24 [20/0] via 172.16.90.1, 00:00:41
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C 172.16.2.254/32 is directly connected, Loopback0
C 172.16.60.0/24 is directly connected, Ethernet0
C 172.16.20.0/24 is directly connected, Serial0
O 172.16.10.0/24 [110/20] via 172.16.1.2, 02:17:34, Ethernet1
C 172.16.1.0/24 is directly connected, Ethernet1
S 172.16.90.1/32 [1/0] via 172.16.20.1
[1/0] via 172.16.60.1
Multihoming to Different Providers
For the case of one customer multihomed to multiple providers, we will discuss a scenario where updates are following a combination of defaults, partial, and full routing.
In figure 11-7, AS3 is multihomed to two different ASs, AS1 and AS2, which in turn exchange routing information and traffic with AS6 and each other via a network access point. AS6, AS2, and AS1 all peer with RTE, which is acting as a route server that has the function of only passing routing updates between all three ASs.
Figure 11-7 Multiple
providers (default, primary and backup, full/partial).
- 1. AS3 will be accepting AS1's local and
customer routes only via the SF link. All other Internet routes
will be accepted via the NY link (primary).
- 2. AS3 will accept a default route from AS1 just in case there is a failure in the NY link.
- 3. AS3 prefers that the SF network 172.16.220.0/24 be reachable by the outside world via the SF link, and the NY networks 172.16.10.0/24 and 172.16.65.0/26 be reachable via the NY link.
- 4. AS3 cannot be a transit network for AS1 and AS2, which means that under no circumstances will AS1 use AS3 to reach AS2.
- 2. AS3 will accept a default route from AS1 just in case there is a failure in the NY link.
The following configurations illustrate how to implement this routing arrangement.
RTA configuration:
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 update-source Loopback0
neighbor 172.16.1.2 next-hop-self
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 route-map ACCEPT_LOCAL in
neighbor 172.16.20.1 route-map PREPEND_PATH out
no auto-summary
ip as-path access-list 1 permit ^1 ?[0-9]*$
ip as-path access-list 2 permit ^$
access-list 1 permit 172.16.65.0 0.0.0.63
access-list 1 permit 172.16.10.0 0.0.0.255
route-map PREPEND_PATH permit 10
match ip address 1
set as-path prepend 3
route-map PREPEND_PATH permit 20
match as-path 2
route-map ACCEPT_LOCAL permit 10
match as-path 1
RTA uses a route map called ACCEPT_LOCAL that accepts partial routes from AS1. The route map will try to match on any path of the form ^1 ?[0-9]*$, which, as already explained, enables AS1's local and customer routes.
RTA uses toward RTC a route map called PREPEND_PATH that will prepend an additional AS number to all NY prefixes such as 172.16.10.0/24 and 172.16.65.0/26. This will make the AS_path length of these prefixes shorter via the NY link. Doing the AS_path prepend should always be coordinated with the provider. Your provider might have policies that conflict with your path information. AS1, for example, might have a policy that advertises AS3 to the NAP, for example, using the form ^3$, which means an AS_path that starts with 3 and ends with 3. If AS3 starts sending AS_path information of the form 3 3 3 3, the provider will drop the routes because the AS_path will not match its policy.
Note that instance 20 of the route-map PREPEND_PATH enables AS3's local routes to be advertised only. This is done by matching on the local prefixes with empty AS_path information represented by the ^$ regular expression.
In the same manner, RTF will be configured to announce the SF prefixes on the NY link with an extra path length. This would make inbound traffic toward these networks preferred via the SF link.
RTF configuration:
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.2.254 remote-as 3
neighbor 172.16.2.254 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 route-map PREPEND_PATH out
no auto-summary
ip as-path access-list 2 permit ^$
access-list 1 permit 172.16.220.0 0.0.0.255
route-map PREPEND_PATH permit 10
match ip address 1
set as-path prepend 3
route-map PREPEND_PATH permit 20
match as-path 2
Note that RTF is accepting all routes from AS2 and is advertising only the local routes ^$ with an extra path length added for the SF route 172.16.220.0/24.
The following is a snapshot of some of the BGP routing tables.
RTA#sh ip bgp
BGP table version is 13, local router ID is 172.16.2.254
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
*> 0.0.0.0 172.16.20.1 0 1 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
* i 172.16.1.2 0 100 0 i
*> 172.16.10.0/24 172.16.1.2 20 32768 i
* i 172.16.1.2 0 100 0 i
*> 172.16.65.0/26 172.16.1.2 20 32768 i
* i 172.16.1.2 0 100 0 i
*> 172.16.220.0/24 0.0.0.0 0 32768 i
* i 172.16.1.2 20 100 0 i
*>i192.68.6.0 172.16.1.2 0 100 0 2 i
*> 192.68.11.0 172.16.20.1 0 0 1 i
*>i193.78.0.0/16 172.16.1.2 100 0 2 7 8 i
Note how RTA is learning a default 0/0 from RTC. RTA is also learning AS1 and can reach those directly via the SF link. For all other routes, RTA will go via the NY link.
On the other hand, inbound traffic will follow the shortest path. The following table shows how an outside AS that falls behind the NAP, such as AS6, can reach AS3's networks.
RTG#sh ip bgp
BGP table version is 9, local router ID is 192.68.40.1
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
*> 172.16.1.0/24 192.68.10.1 0 7 2 3 i
*> 172.16.10.0/24 192.68.10.1 0 7 2 3 i
*> 172.16.65.0/26 192.68.10.1 0 7 2 3 i
*> 172.16.220.0/24 192.68.10.3 0 7 1 3 i
*> 192.68.6.0 192.68.10.1 0 7 2 i
*> 192.68.11.0 192.68.10.3 0 7 1 i
*> 192.68.40.0 0.0.0.0 0 32768 i
*> 193.78.0.0/16 192.68.10.2 0 7 8 i
Note that the NY prefixes 172.16.10.0/24 and 172.16.65.0/26 are reachable via the NY link (path 7 2 3). The SF prefix 172.16.220.0/24 is reachable via the SF link (path 7 1 3).
Customers of the Same Provider with a Backup Link
Customers of the same provider can, by mutual agreement, interconnect via a private link. The private link will serve as a backup in case the Internet connectivity of any of the customers is broken. The following scenario discusses a case where the private link is used as the primary link between the two ASs and as a backup in case of Internet connectivity failures.
In this example, we will switch roles a bit. In figure 11-8, AS3 is the provider offering services to two of its customers, AS1 and AS2. AS1 and AS2 agree to use each other as backup in case their links to AS3 fail. In normal conditions, AS1 and AS2 will use the private link only for traffic between AS1 and AS2; for all other Internet traffic, the direct link to the provider AS3 is used.
Figure
11-8 Backup—private link used as
primary.
We will assume that AS1 and AS2 are getting full Internet routes. AS1 and AS2 should advertise each other's routes to AS3 because, for the backup behavior to occur, AS3 should be able to reach AS1's routes via AS2 and AS2's routes via AS1. Normally, this scenario is handled automatically by the BGP default behavior. Due to the shortest path rule, AS1 and AS2 will always reach each other's networks over the private link. For the sake of experimenting with setting BGP policies we will attempt to solve this problem by manipulating the local preference attribute. We will concentrate on the router configuration of RTC; RTD's configuration should be similar.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 172.16.20.2 route-map PREF_FROM_AS3 in
neighbor 192.68.6.1 remote-as 2
neighbor 192.68.6.1 route-map PREF_FROM_AS2 in
no auto-summary
ip as-path access-list 1 permit _2_
route-map PREF_FROM_AS3 permit 10
match as-path 1
set local-preference 100
route-map PREF_FROM_AS3 permit 20
set local-preference 300
route-map PREF_FROM_AS2 permit 10
set local-preference 200
The preceding configuration shows a route map PREF_FROM_AS2, which sets all updates coming from AS2 with a local preference of 200. The other route map PREF_FROM_AS3 sets all updates coming from AS3 that have AS2 in them with a local preference of 100; all other updates will have a local preference of 300. Note the regular expression _2_, which indicates routes that have passed via AS2. With this configuration, all networks that originated from AS2 or customers of AS2 will be reachable directly via the private link. All other routes will be reachable via the provider AS3. The following is RTC's BGP table:
RTC#show ip bgp
BGP table version is 11, local router ID is 192.68.11.1
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
*> 172.16.1.0/24 172.16.20.2 0 300 0 3 i
* 192.68.6.1 200 0 2 3 i
*> 172.16.10.0/24 172.16.20.2 20 300 0 3 i
* 192.68.6.1 200 0 2 3 i
*> 172.16.65.0/26 172.16.20.2 20 300 0 3 i
* 192.68.6.1 200 0 2 3 i
*> 172.16.220.0/24 172.16.20.2 0 300 0 3 i
* 192.68.6.1 200 0 2 3 i
* 192.68.10.0 172.16.20.2 100 0 3 2 i
*> 192.68.6.1 0 200 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i
*> 192.68.40.0 172.16.20.2 300 0 3 6 i
* 192.68.6.1 200 0 2 3 6 i
Note that prefix 192.68.10.0/24 coming from AS3 has a local preference of 100 because its AS_path 3 2 contains 2. All other routes coming from AS3 have a local preference of 300.
Customers of Different Providers with a Backup Link
Providers prefer to use as little configuration as possible when dealing with adding and removing customers. Every time a customer is added or removed, the provider will have to add policies to accommodate the customer's requirement. In the following examples, we will show how an AS can use the community attribute or path manipulation techniques in such a way that a new customer can have the provider dynamically set the customer's policies.
The Community Approach
In figure 11-9, customer AS1 is getting its service from provider AS4. Customer AS2 is getting its service from provider AS3. AS1 and AS2 have a private link that will be used for internal use between the two ASs. For all other traffic, both customers would like to go out via their direct providers, AS1 via AS4 and AS2 via AS3. In case the private link goes down, the customers should be able to talk to one another via the providers. If a link to the provider fails, the other customer should be used to reach the Internet.
Figure 11-9 Multiple ASs
with multiple providers.
The following is the relevant configuration of RTA, RTF, and RTC. RTD should be a mirror image of RTC.
RTA configuration:
router bgp 4
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.1.2 remote-as 3
neighbor 172.16.1.2 route-map CHECK_COMMUNITY in
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 route-map CHECK_COMMUNITY in
no auto-summary
ip community-list 2 permit 4:40
ip community-list 3 permit 4:60
route-map CHECK_COMMUNITY permit 10
match community 2
set local-preference 40
route-map CHECK_COMMUNITY permit 20
match community 3
set local-preference 60
route-map CHECK_COMMUNITY permit 30
set local-preference 100
Note how RTA has configured the route map CHECK_COMMUNITY. The match community value statement under the route map corrolates with the ip community-list value list, which states the following:
- • Instance 10: For routes with community
4:40, set the local preference to 40.
- • Instance 20: For routes with community 4:60, set the local preference to 60.
- • Instance 30: For all other routes, set the preference to 100.
- • Instance 20: For routes with community 4:60, set the local preference to 60.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 4
neighbor 172.16.20.2 send-community
neighbor 172.16.20.2 route-map setcommunity out
neighbor 172.16.20.2 filter-list 10 out
neighbor 192.68.6.1 remote-as 2
no auto-summary
ip as-path access-list 2 permit _2_
ip as-path access-list 10 permit ^$
ip as-path access-list 10 permit ^2$
route-map setcommunity permit 10
match as-path 2
set community 4:40
route-map setcommunity permit 20
Note the route map "setcommunity," which is configured toward AS4. The route map states the following:
- • Instance 10: For all routes that have
passed via AS2 (_2_), set the community to 4:40.
- • Instance 20: All other routes will go through and do not have any community set.
RTC also has a "filter-list 10 out," which prevents AS4 from learning about AS3 via AS1. The filter list only permits AS1 and AS2 routes. In case the link between AS4 and AS3 goes down, AS4 cannot use AS1 to reach AS3.
RTF configuration:
router bgp 3
network 172.16.10.0 mask 255.255.255.0
network 172.16.65.0 mask 255.255.255.192
neighbor 172.16.1.1 remote-as 4
neighbor 172.16.1.1 send-community
neighbor 172.16.1.1 route-map setcommunity out
neighbor 192.68.5.2 remote-as 2
no auto-summary
route-map setcommunity permit 10
set community 4:60
In RTF, the route map, setcommunity neighbor command sets all updates toward AS4 with a community of 4:60.
Consider RTA's BGP table to see what we have achieved.
RTA#show ip bgp
BGP table version is 7, local router ID is 172.16.2.254
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
*> 172.16.10.0/24 172.16.1.2 0 60 0 3 i
*> 172.16.65.0/26 172.16.1.2 0 60 0 3 i
*> 172.16.220.0/24 0.0.0.0 0 32768 i
*> 192.68.10.0 172.16.1.2 60 0 3 2 i
* 172.16.20.1 40 0 1 2 i
*> 192.68.11.0 172.16.20.1 0 100 0 1 i
RTA has dynamically set the local preference for all routes from the provider AS3 to 60. All routes coming from AS2 via AS1 have a preference of 40, and routes local to AS1 have a preference of 100.
For all routes originated by AS1 (customer local routes) such as 192.68.11.0/24, AS4 will go directly to AS1. For routes belonging to AS2 (customer transit routes), such as 192.68.10.0/24, AS4 will use the other provider AS3. For other routes advertised by the provider (ISP routes), AS4 will go directly to AS3.
The AS_Path Approach
As an alternative to the community approach, AS_path can be be used to achieve the desired routing in figure 11-9. In our example, RTC will prepend an extra AS entry in its routing updates toward AS4 for all routes received from AS2. AS4 will see AS2's updates with a longer path via AS1 and will go via AS3.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 4
neighbor 172.16.20.2 route-map setpath out
neighbor 172.16.20.2 filter-list 10 out
neighbor 192.68.6.1 remote-as 2
no auto-summary
ip as-path access-list 2 permit _2_
ip as-path access-list 10 permit ^$
ip as-path access-list 10 permit ^2$
route-map setpath permit 10
match as-path 2
set as-path prepend 1
route-map setpath permit 20
RTC has prepended an additional AS number 1 to its updates toward RTA. This is how RTA's BGP table will look:
RTA#show ip bgp
BGP table version is 9, local router ID is 172.16.2.254
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
*> 172.16.10.0/24 172.16.1.2 0 0 3 i
*> 172.16.65.0/26 172.16.1.2 0 0 3 i
*> 172.16.220.0/24 0.0.0.0 0 32768 i
*> 192.68.10.0 172.16.1.2 0 3 2 i
* 172.16.20.1 100 0 1 1 2 i
*> 192.68.11.0 172.16.20.1 0 100 0 1 i
Note how RTA now prefers AS3 to reach prefix 192.68.10.0/24. Care must be taken to make sure that the provider AS1 is not using any access list to accept only routes of the form ^1$ or ^1 2$ from your AS. It is always good to coordinate with the provider regarding the changes you want to make.
Following Defaults Inside an AS
The following examples show how border routers can inject defaults inside your AS for your IGP to follow. Figure 11-10 illustrates the following scenario: AS3 is multihomed to two providers, AS1 and AS2. RTA is running EBGP with RTC, and RTF is running EBGP with RTD. Inside AS3, RTA and RTF are running IBGP. We will experiment with two situations: first, RTA and RTF having a direct physical connection and second, RTA and RTF not having a direct physical connection. The latter scenario is used to demonstrate what could go wrong if your IGP traffic is following a default that conflicts with your BGP policies. Finally, RTG is an interior router that is running an IGP; RTG is following the default route 0/0 to reach networks outside AS3.
Figure 11-10 Following
defaults inside the AS; border routers connected.
The scenario where RTA and RTF are directly connected is easy; it is very hard for things to go wrong. As long as RTA and RTF are injecting defaults inside the IGP, traffic that reaches any of the BGP routers will find its way outside the AS. It is important that outbound traffic that reaches a BGP router does not go back to the non-BGP routers to avoid possible routing loops.
In case the border routers are not carrying full routes, they can accept a default to the providers to which they are connected. Both links can be used at the same time, or one link could be used as primary and the second as backup. Whichever policy you use, traffic will find its way out.
In the following configuration, RTA and RTF are accepting full routes from their respective providers. RTA and RTF are injecting defaults inside the AS (they are not getting any defaults themselves because they carry full routes). We will use OSPF as an IGP (other IGPs will be used in different scenarios later on).
RTA configuration:
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.1.2 remote-as 3
no auto-summary
ip as-path access-list 10 permit ^$
RTF configuration:
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
router bgp 3
no synchronization
network 172.16.1.0 mask 255.255.255.0
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.1.1 remote-as 3
neighbor 172.16.1.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
RTG configuration:
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
Note that the RTA and RTF configurations use the router command default-information originate with the always keyword. This command forces OSPF to inject a 0/0 default route into the OSPF domain at all times. The internal router RTG, which is running OSPF only, will receive the default from multiple sources and will follow the shortest internal metric. Routers that are closer (metric-wise) to RTA will use RTA for default; routers closer to RTF will use RTF.
RTG#sh 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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.70.1 to network 0.0.0.0
172.16.0.0/16 is subnetted, 5 subnets
O 172.16.220.0/24 [110/74] via 172.16.70.1,
00:03:27, Serial0
C 172.16.50.0/24 is directly connected, Serial1
O 172.16.20.0/24 [110/74] via 172.16.70.1, 00:03:27, Serial0
O 172.16.1.0/24 [110/74] via 172.16.70.1, 00:03:27, Serial0
C 172.16.70.0/24 is directly connected, Serial0
O*E2 0.0.0.0/0 [110/1] via 172.16.70.1, 00:03:27, Serial0
Note how RTG has set its gateway of last resort to RTA (172.16.70.1), which happens to be at a shorter internal metric than RTF.
The second route map "setlocalpref" assigns a value of 300 to all the RTA's IBGP routes. This makes all IBGP routes preferred over EBGP routes.
RTF is also originating a default into OSPF only on the condition that RTF is learning the default from its exterior link (next hop 192.68.5.2). In case of a NY link failure, RTF will stop advertising a 0/0, even though it might be getting a 0/0 from RTA via IBGP.
RTF configuration:
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
default-information originate route-map SEND_DEFAULT_IF
router bgp 3
no synchronization
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 permit 0.0.0.0
access-list 2 permit 192.68.5.2
route-map SEND_DEFAULT_IF permit 10
match ip address 1
match ip next-hop 2
RTG is running OSPF only and following the 0/0 default for routes outside AS3.
RTG configuration:
router ospf 10
network 172.16.0.0 0.0.255.255 area 0
The following is RTA's IP routing table. Note that RTA is preferring the 0/0 default via its IBGP peer RTF with next hop 172.16.50.1. Because the next hop is different from 172.16.20.1 (the external peer), RTA will not inject any default inside OSPF.
RTA#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 0.0.0.0
B 192.68.6.0/24 [200/0] via 172.16.50.1, 00:03:06
B 192.68.11.0/24 [200/0] via 172.16.50.1, 00:03:06
B 193.78.0.0/16 [200/0] via 172.16.50.1, 00:03:06
172.16.0.0/16 subnetted, 4 subnets
C 172.16.20.0/24 is directly connected, Serial0
C 172.16.220.0/24 is directly connected, Ethernet1
O 172.16.50.0/24 [110/164] via 172.16.70.2, 02:17:37, Serial1
C 172.16.70.0/24 is directly connected, Serial1
B* 0.0.0.0/0 [200/0] via 172.16.50.1, 00:03:07
The following is RTG's IP routing table. Note how RTG is setting its default to RTF. Both the BGP policies and the IGP defaults are now in sync.
RTG#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 0.0.0.0
172.16.0.0/16 is subnetted, 4 subnets
O 172.16.20.0/24 [110/128] via 172.16.70.1, 02:21:04, Serial0
O 172.16.220.0/24 [110/74] via 172.16.70.1, 02:21:04, Serial0
C 172.16.50.0/24 is directly connected, Serial1
C 172.16.70.0/24 is directly connected, Serial0
O*E2 0.0.0.0/0 [110/1] via 172.16.50.1, 00:41:26, Serial1
In case the NY link fails, RTA will learn the BGP 0/0 via its external link with next hop 172.16.20.1 and will inject a default into OSPF.
Notes:
Redistributing the 0/0 from BGP into OSPF via the redistribute router command is not allowed or implemented.
Using RIP as IGP
The Cisco RIP implementation behaves differently from OSPF when dealing with the 0/0 defaults. The BGP-learned 0/0 default is automatically injected into RIP. A default-metric router command is required under the RIP process to assign a metric (hop count) to the default. In our example (figure 11-11, assume that RTA, RTF, and RTG are running RIP. We will set the metric of the 0/0 injected into RIP by RTA in such a way that the internal router (RTG) always prefers RTF.
RTA will set the 0/0 default metric to 5. Note that no redistribution was necessary to inject the BGP default into RIP.
RTA configuration:
router rip
passive-interface Serial0
network 172.16.0.0
default-metric 5
router bgp 3
no synchronization
network 172.16.220.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.50.1 remote-as 3
neighbor 172.16.50.1 route-map setlocalpref in
no auto-summary
ip as-path access-list 10 permit ^$
route-map setlocalpref permit 10
set local-preference 300
RTF will inject the 0/0 into RIP with a hop count of 1.
RTF configuration:
router rip
network 172.16.0.0
default-metric 1
router bgp 3
no synchronization
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
RTG is running RIP only and is following the 0/0 default for routes outside AS3.
RTG configuration:
router rip
network 172.16.0.0
The following is RTG's IP routing table. Note that RTG has set its default to RTF because of the lower metric of 1.
RTG#show
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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 0.0.0.0
172.16.0.0/16 is subnetted, 4 subnets
R 172.16.220.0/24 [120/1] via 172.16.70.1, 00:00:03, Serial0
C 172.16.50.0/24 is directly connected, Serial1
R 172.16.20.0/24 [120/1] via 172.16.70.1, 00:00:03, Serial0
C 172.16.70.0/24 is directly connected, Serial0
R* 0.0.0.0/0 [120/1] via 172.16.50.1, 00:00:22, Serial1
Notes:
If more conditions are needed to inject the 0/0 into RIP, redistribution and route maps could be used to inject the default from BGP into RIP.
Using EIGRP as the IGP
BGP-learned defaults are injected into EIGRP via redistribution. The 0/0 metric needs to be converted into an EIGRP-compatible metric by using the default-metric router command. RTA will inject its default with a high metric in such a way that the internal router (RTG) always gets a lower metric via RTF.
RTA configuration:
router eigrp 1
redistribute bgp 3 route-map DEFAULT_ONLY
passive-interface Serial0
network 172.16.0.0
default-metric 5 100 250 100 1500
router bgp 3
no synchronization
network 172.16.70.0 mask 255.255.255.0
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.50.1 remote-as 3
neighbor 172.16.50.1 route-map setlocalpref in
no auto-summary
ip as-path access-list 10 permit ^$
access-list 5 permit 0.0.0.0
route-map setlocalpref permit 10
set local-preference 300
route-map DEFAULT_ONLY permit 10
match ip address 5
RTA uses a route map DEFAULT_ONLY to match on the default route 0/0. Any other updates will be prevented from being redistributed into EIGRP. RTA also sets the metric by using the default-metric router command.
In the same manner, RTF is redistributing only the 0/0 into EIGRP using the route map DEFAULT_ONLY. RTF uses the default-metric 1000 100 250 100 1500 statement to set its default metric to an EIGRP-compatible metric. Note the bandwidth portion (1000) of the default-metric statement in RTF, which is much higher than the bandwidth (5) in RTA. This makes the metric from RTF much lower than the one from RTA.
RTF configuration:
router eigrp 1
redistribute bgp 3 route-map DEFAULT_ONLY
network 172.16.0.0
default-metric 1000 100 250 100 1500
router bgp 3
no synchronization
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 5 permit 0.0.0.0
route-map DEFAULT_ONLY permit 10
match ip address 5
RTG is running EIGRP only and is following the default for all routes outside AS3.
RTG configuration:
router eigrp 1
network 172.16.0.0
The following is the IP routing table of RTG. Note that RTG follows the default toward RTF.
RTG#sh 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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 0.0.0.0
172.16.0.0/16 is subnetted, 4 subnets
D 172.16.220.0/24 [90/2195456] via 172.16.70.1, 00:12:17, Serial0
C 172.16.50.0/24 is directly connected, Serial1
D 172.16.20.0/24 [90/2681856] via 172.16.70.1, 00:12:17, Serial0
C 172.16.70.0/24 is directly connected, Serial0
D*EX 0.0.0.0/0 [170/3097600] via 172.16.50.1, 00:07:40, Serial1
Using IGRP as IGP
IGRP does not understand the 0.0.0.0 default. To set a default inside IGRP, the ip default-network global command needs to be set on RTA and RTF. The default network used needs to be redistributed into IGRP to set the default on the internal routers. A default-metric needs to be set for successful redistribution.
RTA is setting network 192.68.6.0/24 (or any other classfull network learned via BGP) to be the default network. RTA will redistribute that network only into IGRP.
RTA configuration:
router igrp 1
passive-interface Serial0
redistribute bgp 3 route-map DEFAULT_ONLY
network 172.16.0.0
default-metric 5 100 250 100 1500
router bgp 3
no synchronization
network 172.16.70.0 mask 255.255.255.0
network 172.16.220.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.50.1 remote-as 3
neighbor 172.16.50.1 route-map setlocalpref in
no auto-summary
ip default-network 192.68.6.0
ip as-path access-list 10 permit ^$
access-list 5 permit 192.68.6.0 0.0.0.255
route-map setlocalpref permit 10
set local-preference 300
route-map DEFAULT_ONLY permit 10
match ip address 5
RTF is also setting its default, to 192.68.6.0/24, and redistributing the default, with a better metric, into IGRP.
RTF configuration:
router igrp 1
redistribute bgp 3 route-map DEFAULT_ONLY
network 172.16.0.0
default-metric 1000 100 250 100 1500
router bgp 3
no synchronization
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip default-network 192.68.6.0
ip as-path access-list 10 permit ^$
access-list 5 permit 192.68.6.0 0.0.0.255
route-map DEFAULT_ONLY permit 10
match ip address 5
RTG is running IGRP only and is following the default for all routes outside AS3.
RTG configuration:
router igrp 1
network 172.16.0.0
The following is the IP routing table of RTG. Note that RTG follows the default toward RTF.
RTG#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 192.68.6.0
I* 192.68.6.0/24 [100/8576] via 172.16.50.1, 00:00:32, Serial1
172.16.0.0/16 is subnetted, 4 subnets
I 172.16.220.0/24 [100/8576] via 172.16.70.1, 00:00:32, Serial0
C 172.16.50.0/24 is directly connected, Serial1
I 172.16.20.0/24 [100/10476] via 172.16.70.1, 00:00:32, Serial0
C 172.16.70.0/24 is directly connected, Serial0
Using ISIS as IGP
ISIS is similar to OSPF; it uses the default-information originate router command. RTA is originating a default into ISIS only on the condition that RTA is learning the default from its exterior link.
RTA configuration:
router isis 100
redistribute connected
default-information originate route-map SEND_DEFAULT_IF
net 49.0001.0000.0c00.000a.00
router bgp 3
no synchronization
network 172.16.220.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.50.1 remote-as 3
neighbor 172.16.50.1 route-map setlocalpref in
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 permit 0.0.0.0
access-list 2 permit 172.16.20.1
route-map SEND_DEFAULT_IF permit 10
match ip address 1
match ip next-hop 2
RTF is originating a default into ISIS on the condition that RTF is learning the default from its exterior link.
RTF configuration:
router isis 100
default-information originate route-map SEND_DEFAULT_IF
net 49.0001.0000.0c00.000c.00
router bgp 3
no synchronization
network 172.16.50.0 mask 255.255.255.0
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 next-hop-self
neighbor 192.68.5.2 remote-as 2
neighbor 192.68.5.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 permit 0.0.0.0
access-list 2 permit 192.68.5.2
route-map SEND_DEFAULT_IF permit 10
match ip address 1
match ip next-hop 2
RTG is running ISIS and following the 0/0 default for routes outside AS3.
RTG configuration:
router isis 100
net 49.0001.0000.0c00.000b.00
The following is RTG's IP routing table; note how RTG follows the default toward RTF.
RTG#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is 172.16.50.1 to network 0.0.0.0
172.16.0.0/16 is subnetted, 4 subnets
i L1 172.16.220.0/24 [115/20] via 172.16.70.1, Serial0
i L1 172.16.20.0/24 [115/20] via 172.16.70.1, Serial0
C 172.16.50.0/24 is directly connected, Serial1
C 172.16.70.0/24 is directly connected, Serial0
i*L2 0.0.0.0/0 [115/10] via 172.16.50.1, Serial1
Policy Routing
This example demonstrates how policy routing can be used to direct the traffic based on the source IP address rather than the destination IP address. Figure 11-12 shows a router RTA that is running BGP with two providers, AS1 and AS2. Internal routers such as RTG and RTF are running IGP only (OSPF) and are following a default route toward RTA.
Figure 11-12 Policy
routing scenario.
RTA wants to set policy routing in such a way that traffic coming over the serial line S1 from RTG is directed toward AS2 if the source is network 172.16.10.0/24. Traffic coming from RTG with source 172.16.112.0/24 is to be directed toward AS1; in case of a link failure to AS1, the traffic will go to AS2. For all other source IP addresses, follow normal routing.
RTA will be configured in the following manner:
RTA configuration:
interface Ethernet0
ip address 172.16.80.1 255.255.255.0
interface Serial1
ip address 172.16.70.1 255.255.255.0
ip policy route-map CHECK_SOURCE
router ospf 10
passive-interface Serial0
passive-interface Ethernet0
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
router bgp 3
network 172.16.50.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
network 172.16.10.0 mask 255.255.255.0
network 172.16.112.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.80.2 remote-as 2
neighbor 172.16.80.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
access-list 1 permit 172.16.10.0 0.0.0.255
access-list 2 permit 172.16.112.0 0.0.0.255
route-map CHECK_SOURCE permit 10
match ip address 1
set ip next-hop 172.16.80.2
route-map CHECK_SOURCE permit 20
match ip address 2
set ip next-hop 172.16.20.1 172.16.80.2
Policy routing is always applied to the incoming interface. Serial 1 is configured with the interface command ip policy route-map map-name. This will apply route map CHECK_SOURCE to all Serial 1 incoming traffic. The explanation of the route map follows:
- • Instance 10: For all source IP addresses
that come from 172.16.10.0/24, set the next hop to 172.16.80.2. If
next hop 172.16.80.2 is unreachable, drop the packet.
- • Instance 20: For all source IP addresses that come from 172.16.112.0/24, set the next hop to 172.16.20.1. If next hop 172.16.20.1 is unreachable, try sending the traffic to next hop 172.16.80.2.
For all other source IP addresses, follow normal routing.
The policy routing route maps give you the option to pick multiple next hops. This is necessary to always have a backup path. For all traffic that does not match the route maps, the router will follow normal routing. To illustrate, a trace route will be done from RTG to 192.68.10.1 from source IP address 172.16.112.1. The following is RTA's IP routing table:
RTA#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,
* - candidate default U - per-user static route, o - ODR
Gateway of last resort is not set
B 192.68.10.0/24 [20/0] via 172.16.80.2, 00:30:09
B 192.68.11.0/24 [20/0] via 172.16.20.1, 00:30:14
172.16.0.0/16 is subnetted, 5 subnets
O 172.16.50.0/24 [110/69] via 172.16.70.2, 00:27:27, Serial1
C 172.16.20.0/24 is directly connected, Serial0
C 172.16.80.0/24 is directly connected, Ethernet0
C 172.16.70.0/24 is directly connected, Serial1
Trace route from RTG with a source of 172.16.112.1 and a destination 192.68.10.1.
RTG#traceroute
Protocol [ip]:
Target IP address: 192.68.10.1
Source address: 172.16.112.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to gateway.aeg-aas.de (192.68.10.1)
1 172.16.70.1 4 msec 4 msec 0 msec
2 172.16.20.1 4 msec 4 msec 4 msec
3 192.68.6.1 4 msec 4 msec 4 msec
Note how RTA has taken next hop 172.16.20.1 (second line in the trace route output) to reach 192.68.10.0/24, even though RTA's routing table indicates that 192.68.10.0/24 should be reached with next hop 172.16.80.2.
This second attempt shows what will happen if Serial 0 is down, and next hop 172.16.20.1 is unreachable. Trace route from RTG with a source of 172.16.112.1 and a destination 192.68.10.1 while Serial 0 is down.
RTG#traceroute
Protocol [ip]:
Target IP address: 192.68.10.1
Source address: 172.16.112.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to gateway.aeg-aas.de (192.68.10.1)
1 172.16.70.1 0 msec 4 msec 4 msec
2 172.16.80.2 8 msec 4 msec 4 msec
RTA has taken the alternate next hop 172.16.80.2.
Route Reflectors
This example will illustrate a practical use of route reflectors and peer groups. In figure 11-13, RTG and RTA form one cluster where RTG is the route reflector. RTF, RTE, and RTD form another cluster where RTF is the route reflector. RTG and RTF are part of a peer group called REFLECTORS; if there are other route reflectors, all can be IBGP peered in a full mesh. RTF puts all its clients in a peer group called CLIENTS, where common policies can be applied.
Figure 11-13 Route
reflectors.
Clients are indicated by the route reflectors using the "route-reflector-client." Because clients are part of a peer group, client-to-client reflection needs to be turned off to avoid potential problems. Full IBGP mesh will be maintained inside the RTF-RTD-RTE cluster.
RTF configuration:
router bgp 3
no synchronization
no bgp client-to-client reflection
network 172.16.65.0 mask 255.255.255.192
network 172.16.50.0 mask 255.255.255.0
network 172.16.25.0 mask 255.255.255.0
network 172.16.30.0 mask 255.255.255.0
neighbor REFLECTORS peer-group
neighbor REFLECTORS remote-as 3
neighbor CLIENTS peer-group
neighbor CLIENTS remote-as 3
neighbor CLIENTS route-reflector-client
neighbor 172.16.25.2 peer-group CLIENTS
neighbor 172.16.30.2 peer-group CLIENTS
neighbor 172.16.50.2 peer-group REFLECTORS
no auto-summary
RTD is a client of RTF. From RTD's perspective, the BGP peering session with RTF is a normal IBGP session. Note in the following configuration how RTD has a full IBGP mesh with RTF and RTE. The same goes for RTE.
RTD configuration:
router bgp 3
no synchronization
network 172.16.90.0 mask 255.255.255.0
network 172.16.30.0 mask 255.255.255.0
neighbor 172.16.25.2 remote-as 3
neighbor 172.16.25.2 next-hop-self
neighbor 172.16.30.1 remote-as 3
neighbor 172.16.30.1 next-hop-self
neighbor 192.68.20.2 remote-as 2
neighbor 192.68.20.2 filter-list 10 out
no auto-summary
ip as-path access-list 10 permit ^$
RTG configuration:
router bgp 3
no synchronization
network 172.16.112.0 mask 255.255.255.0
network 172.16.50.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.50.1 remote-as 3
neighbor 172.16.70.1 remote-as 3
neighbor 172.16.70.1 route-reflector-client
no auto-summary
RTA configuration:
router bgp 3
no synchronization
network 172.16.220.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.70.2 remote-as 3
neighbor 172.16.70.2 next-hop-self
no auto-summary
ip as-path access-list 10 permit ^$
The following snapshot shows how RTD sees some of the routes that are being reflected into its own cluster. Note how RTD sees the originator of route 172.16.220.0/24 as 172.16.220.1, which is the router ID of RTA. The route also carries a cluster list that contains the router IDs of all the route reflectors that it passed through.
RTD#show ip bgp 172.16.220.0
BGP routing table entry for 172.16.220.0/24, version 52
Paths: (1 available, best #1)
Local
172.16.70.1 (metric 192) from 172.16.30.1 (172.16.220.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator : 172.16.220.1, Cluster list: 172.16.65.1,
172.16.112.1
In the case where multiple route reflectors are configured inside the cluster, all of them have to be configured with a common cluster-ID. This is needed to detect routing loops that might occur between clusters. If RTE, for example, were to be configured as a route reflector, then RTF's and RTE's configuration would need the additional router command bgp cluster-id number.
RTF configuration:
router bgp 3
no synchronization
no bgp client-to-client reflection
network 172.16.65.0 mask 255.255.255.192
network 172.16.50.0 mask 255.255.255.0
network 172.16.25.0 mask 255.255.255.0
network 172.16.30.0 mask 255.255.255.0
neighbor REFLECTORS peer-group
neighbor REFLECTORS remote-as 3
neighbor CLIENTS peer-group
neighbor CLIENTS remote-as 3
neighbor CLIENTS route-reflector-client
neighbor 172.16.25.2 peer-group CLIENTS
neighbor 172.16.30.2 peer-group CLIENTS
neighbor 172.16.50.2 peer-group REFLECTORS
bgp cluster-id 1000
no auto-summary
Confederations
For the scenario in figure 11-14, we want to divide AS3 into two smaller sub-ASs, AS65050 and AS65060. The AS numbers of the sub-ASs are chosen from within the private AS pool range of 64512-65535. OSPF is used as the IGP in each sub-AS. The OSPF within AS65050 is running independently from the OSPF in AS65060, which means that the area numbers used in AS65050 can be reused in AS65060. This is taking advantage of one of the benefits of BGP, namely that IGPs in one AS run independently of IGPs in other ASs.
Figure
11-14 Confederation.
RTA's configuration shows that RTA has all its interfaces in OSPF area 5. RTA is running EBGP with RTC in AS1 and is running IBGP with RTG in AS65050. Note that RTA uses the bgp confederation identifier 3 router command to present itself to RTC as being part of confederation 3.
RTA configuration:
router ospf 10
passive-interface Serial0
network 172.16.0.0 0.0.255.255 area 5
router bgp 65050
no synchronization
bgp confederation identifier 3
network 172.16.220.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.70.2 remote-as 65050
no auto-summary
ip as-path access-list 10 permit ^$
RTC is running normal EBGP when talking to RTA. According to RTC, RTA belongs to AS3. RTC has no visibility to the sub-ASs inside confederation 3. RTC is also running EBGP with RTH in AS2.
RTC configuration:
router bgp 1
network 192.68.11.0
neighbor 172.16.20.2 remote-as 3
neighbor 192.68.6.1 remote-as 2
no auto-summary
RTG is the sub-AS65050 border router that is running confederation EBGP with router RTF in sub-AS65060. RTG is also running IBGP with RTA. RTG is an OSPF area border router with a common area 5 with RTA and the rest of its interfaces in area 0. Note how RTG has disabled its OSPF processing on serial 1 (passive-interface Serial1), which is the common interface with RTF. Only EBGP is run on that link.
RTG also identifies itself as being part of confederation 3 (bgp confederation identifier 3). RTG uses the router command bgp confederation peers 65060 to preserve all the attributes, such as local preference and next hop when traversing the EBGP session to AS65060. This will make the confederation EBGP session with sub-AS65060 look like an IBGP session. The neighbor 172.16.50.1 next-hop-self command will set the next hop address of routes going from RTG to RTF to RTG's IP address. Without this command, the next hop address of all EBGP routes from AS1 will be sent to RTF with the external next hop 172.16.20.1, which is acceptable only as long as routers in sub-AS65060 can reach it from within the confederation.
RTG configuration:
router ospf 10
passive-interface Serial1
network 172.16.70.2 0.0.0.0 area 5
network 172.16.0.0 0.0.255.255 area 0
router bgp 65050
no synchronization
bgp confederation identifier 3
bgp confederation peers 65060
network 172.16.112.0 mask 255.255.255.0
network 172.16.50.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.50.1 remote-as 65060
neighbor 172.16.50.1 next-hop-self
neighbor 172.16.70.1 remote-as 65050
no auto-summary
The same configuration that is in RTG applies to RTF, which is the border router of sub-AS65060. RTF is also an area border router in areas 0 and 5. Areas 0 and 5 in AS65060 are totally independent from areas 0 and 5 in AS65050. The two IGPs are shielded from each other by BGP. Full mesh IBGP sessions are configured between RTE, RTD, and RTF by using the peer group SUB_AS_65060.
RTF configuration:
router ospf 10
passive-interface Serial2/1
network 172.16.25.1 0.0.0.0 area 5
network 172.16.0.0 0.0.255.255 area 0
router bgp 65060
no synchronization
bgp confederation identifier 3
bgp confederation peers 65050
network 172.16.65.0 mask 255.255.255.192
network 172.16.50.0 mask 255.255.255.0
network 172.16.25.0 mask 255.255.255.0
network 172.16.30.0 mask 255.255.255.0
neighbor SUB_AS_65060 peer-group
neighbor SUB_AS_65060 remote-as 65060
neighbor 172.16.25.2 peer-group SUB_AS_65060
neighbor 172.16.30.2 peer-group SUB_AS_65060
neighbor 172.16.50.2 remote-as 65050
neighbor 172.16.50.2 next-hop-self
Controlling Route and Cache Invalidation
A requirement of BGP is resetting the neighbors' TCP connection whenever a policy is changed for the new policy to take effect (clear ip bgp [* | address | peer-group] ). Clearing the sessions in this manner will restart the neighbor negotiations from scratch, invalidate the cache, and cause a major impact on the operation of live networks.
Soft reconfiguration is a new approach that enables policies to be configured and activated without resetting the BGP TCP session. This enables new policies to take effect without significantly affecting the network. Soft configuration can be applied in two different ways, inbound and outbound. Use the following exec command:
clear ip bgp [* | address | peer-group][soft [in|out]]
Outbound Soft Reconfiguration
Whenever outbound soft reconfiguration is applied, the new policies are automatically triggered, and appropriate updates are generated to enforce the new policy. Use the following exec command:
clear ip bgp [* | address | peer-group] soft out
Inbound Soft Reconfiguration
Inbound soft reconfiguration is a bit more involved. All inbound updates (whether accepted or not accepted) need to be tracked by the router. Additional memory is required just to store this information.
An additional router subcommand is needed to configure inbound soft reconfiguration:
neighbor {address | peer-group} soft-reconfiguration inbound
This command is required to start storing the received updates to do the soft reconfiguration. The exec command used to do the inbound reconfiguration is:
clear ip bgp [* | address | peer-group] soft in
To avoid the memory overhead needed for the inbound soft reconfiguration, the same outcome could be achieved by doing an outbound soft reconfiguration at the other end of the connection.
If the "in/out" option is not specified (clear ip bgp [* | address | peer-group] soft), both inbound and outbound soft reconfiguration will be applied.
The following example demonstrates the difference between clearing a BGP session between two routers without and with the soft configuration BGP feature. While the session is cleared, an output log will be displayed to show the actual session being established and the route updates being exchanged.
Referring still to figure 11-14, RTA will be configured to send its updates to RTC with a metric of 5000. The following is RTA's configuration. Note the neighbor 172.16.20.1 soft-reconfiguration inbound command. This is needed only if clearing the session needs to take effect on the inbound; that is, in case we have no control over the neighbor router to clear the session on the outbound.
RTA configuration:
router bgp 65050
no synchronization
bgp confederation identifier 3
network 172.16.220.0 mask 255.255.255.0
network 172.16.70.0 mask 255.255.255.0
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 soft-reconfiguration inbound
neighbor 172.16.20.1 filter-list 10 out
neighbor 172.16.20.1 route-map setmetric out
neighbor 172.16.70.2 remote-as 65050
no auto-summary
ip as-path access-list 10 permit ^$
route-map setmetric permit 10
set metric 5000
For this information to take effect, the BGP session would have to be cleared between the two routers. Note how much overhead is caused by actually killing the TCP session between the two routers and starting over from scratch. The log will show that the BGP peer session is being first reset, then the neighbor election goes from Idle to Established, and then the actual routing updates will flow.
RTA#clear ip bgp 172.16.20.1
BGP: 172.16.20.1 reset requested
BGP: no valid path for 192.68.11.0/24
BGP: 172.16.20.1 reset by 0x27B740
BGP: 172.16.20.1 went from Established to Idle
BGP: nettable_walker 192.68.11.0/255.255.255.0 no best
path selected
BGP: 172.16.20.1 went from Idle to Active
BGP: 172.16.70.2 computing updates, neighbor version 21, table
version 23, starting at 0.0.0.0
BGP: 172.16.70.2 send UPDATE 192.68.11.0/24 — unreachable
BGP: 172.16.70.2 1 updates enqueued (average=27, maximum=27)
BGP: 172.16.70.2 update run completed, ran for 0ms, neighbor
version 21, start version 23, throttled to 23, check point
net0.0.0.0
BGP: scanning routing tables
BGP: 172.16.20.1 went from Active to OpenSent
BGP: 172.16.20.1 went from OpenSent to OpenConfirm
BGP: 172.16.20.1 went from OpenConfirm to Established
BGP: 172.16.20.1 computing updates, neighbor version 0, table
version 23, starting at 0.0.0.0
BGP: 172.16.20.1 send UPDATE 172.16.25.0/24, next 172.16.20.2,
metric 5000, path 3
BGP: 172.16.20.1 send UPDATE 172.16.30.0/24, next 172.16.20.2,
path (65060)
BGP: 172.16.20.1 send UPDATE 172.16.50.0/24, next 172.16.20.2,
metric 5000, path 3
BGP: 172.16.20.1 send UPDATE 172.16.60.0/24, next 172.16.20.2,
path (65060)
BGP: 172.16.20.1 send UPDATE 172.16.70.0/24, next 172.16.20.2,
metric 5000, path 3
BGP: 172.16.20.1 send UPDATE 172.16.90.0/24, next 172.16.20.2,
path (65060)
BGP: 172.16.20.1 send UPDATE 172.16.65.0/26, next 172.16.20.2,
path (65060)
BGP: 172.16.20.1 send UPDATE 172.16.112.0/24, next 172.16.20.2,
path
BGP: 172.16.20.1 send UPDATE 172.16.220.0/24, next 172.16.20.2,
path
BGP: 172.16.20.1 send UPDATE 192.68.222.0/24, next 172.16.20.2,
metric 5000, path 3 2
BGP: 172.16.20.1 4 updates enqueued (average=58, maximum=68)
BGP: 172.16.20.1 update run completed, ran for 24ms,
neighborversion 0, start version 23, throttled to 23,
check point net 0.0.0.0
BGP: 172.16.20.1 rcv UPDATE about 192.68.11.0/24,
next hop 172.16.20.1, path 1 metric 2000
BGP: 172.16.20.1 rcv UPDATE about 192.68.222.0/24,
next hop 172.16.20.1, path 1 2 metric 2000
BGP: 172.16.20.1 rcv UPDATE about 172.16.25.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.30.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.50.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.60.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.70.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.90.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.65.0/26 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.112.0/24 — denied
BGP: 172.16.20.1 rcv UPDATE about 172.16.220.0/24 — denied
BGP: nettable_walker 192.68.11.0/255.255.255.0 calling
revise_route
BGP: revise route installing 192.68.11.0/255.255.255.0 ->
172.16.20.1
BGP: 172.16.70.2 computing updates, neighbor version 23,
table version 24, starting at 0.0.0.0
BGP: NEXT_HOP part 1 net 192.68.11.0/24, neigh 172.16.70.2,
next 172.16.20.1
BGP: 172.16.70.2 send UPDATE 192.68.11.0/24, next 172.16.20.1,
metric 2000, path 1
BGP: 172.16.70.2 1 updates enqueued (average=59, maximum=59)
BGP: 172.16.70.2 update run completed, ran for 4ms,
neighbor version 23, start version 24, throttled to 24,
check point net 0.0.0.0
BGP: 172.16.20.1 rcv UPDATE about 172.16.25.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.30.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.50.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.60.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.70.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.90.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.65.0/26 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.112.0/24 — withdrawn
BGP: 172.16.20.1 rcv UPDATE about 172.16.220.0/24 — withdrawn
BGP: 172.16.20.1 computing updates, neighbor version 23,
table version 24, starting at 0.0.0.0
BGP: 172.16.20.1 update run completed, ran for 0ms,
neighbor version 23, start version 24, throttled to 24,
check point net 0.0.0.0
BGP: scanning routing tables
The following shows the route after four flaps. The penalty is now 2851, which has exceeded the 2500 limit. The route is now suppressed (dampened) and will not be passed on to RTH. The route will be usable in 31 minutes and 40 seconds. At that time, the penalty would have decayed to the reuse limit of 950.
RTC#show ip bgp 172.16.220.0
BGP routing table entry for 172.16.220.0/24, version 329
Paths: (1 available, no best path, advertised over IBGP)
3, (suppressed due to dampening)
172.16.20.2 from 172.16.20.2 (172.16.220.1)
Origin IGP, metric 0, valid, external
Dampinfo: penalty 2851, flapped 4 times in 00:03:05, reuse
in 00:31:40
The following output shows the same route after six flaps. The differences are that the half-life-time has been set to 5 minutes instead of 20 minutes, and the maximum suppress-time is 20 minutes instead of 80. With a shorter half-life-time, the penalty will be decayed much faster, and the route will be used a lot sooner. Note the reuse time of 8 minutes and 10 secs.
RTC#show ip bgp 172.16.220.0
BGP routing table entry for 172.16.220.0/24, version 336
Paths: (1 available, no best path, advertised over IBGP)
3, (suppressed due to dampening)
172.16.20.2 from 172.16.20.2 (172.16.220.1)
Origin IGP, metric 0, valid, external
Dampinfo: penalty 2939, flapped 6 times in 00:08:21, reuse
in 00:08:10
Adjusting the dampening timers becomes essential when administators cannot afford to have a long outage for a specific route. BGP dampening with route maps is a powerful tool to selectively penalize ill-behaved routes in a user-configurable and controlled manner.
Looking Ahead
The Internet has come a long way from the NSFNET backbone to the information highway of the 21st century—and there are no signs of its slowing down. And how could the Internet slow down when hundreds and thousands of users come online every day, attracted by the most advanced applications technology affords?
Routing protocols have struggled to keep up with the demand, from the early days of EGP to the latest in BGP. BGP started as a simple exterior routing protocol and has evolved into a de facto standard, gluing the Internet together. Indeed, every hook and tweak that BGP can offer has been used, and still it seems that more capabilities are requested every day. As a result, new protocols and new techniques will emerge. Whether they will make routing easier or more complicated, more robust or more shaky is yet to be seen. One thing is certain: common sense will never go away, and as long as it is the basis of all your designs, you will be the master of your domain.