Redundancy, Symmetry, and Load Balancing
The examples in this section 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 serious problems. Problems occur when a BGP speaker that intends to originate a default to a specific peer floods the default to all its neighbors. Cisco provides a way to target the default toward a specific neighbor.
In Figure 12-1, RTA originates a default route 0.0.0.0/0 toward RTC only. IBGP neighbors, such as RTF, will not get the default.
Figure 12-1. Dynamically Learned Defaults
Example 12-1 shows the configuration for RTA.
Example 12-1. RTA Configuration for Dynamically Learned Defaults
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 (the default) to be sent toward RTC. The BGP and IP routing tables of RTC displayed in Example 12-2 illustrate this.
Example 12-2. BGP/IP Routing Tables for 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 RTC routing table in Example 12-2 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. You can use the configuration in Example 12-3, assuming that RTA has a default route itself (the default could be created via a static route).
Example 12-3. Originating Defaults Over All BGP Peers: 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. Figure 12-2 demonstrates how to accomplish this.
Figure 12-2. Dealing with the 0/0 Default
RTC uses the following command:
ip route prefix mask {address | interface} [distance]
The 0/0 static route can point to a network number, to 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 shorter distance are preferred over routes with a longer distance.
The configuration in Example 12-4 shows how RTC can set the default to point toward network 193.78.0.0/16.
Example 12-4. RTC Configuration: Setting the Default to Point to Network 193.78.0.0/16
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 BGP table for RTC in Example 12-5 shows that 193.78.0.0/16 has been learned via two paths—the first via AS3 and the second via AS2. BGP prefers the first path as being the best. (BGP attribute manipulation can be used to influence which path BGP will use and hence influence the default path.)
Example 12-5. RTC BGP Table
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 IP table for RTC in Example 12-6 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.
Example 12-6. RTC IP 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 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 gives you the ability to prefer one default over another, as demonstrated in Example 12-7.
Example 12-7. Using distance to Prefer One Default Over Another: 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 of 40 in the first static route will ensure that as long as 172.16.20.2 is available, it will be 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. Example 12-8 shows the output of RTC's routing table.
Example 12-8. RTC 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
|
Example 12-9 shows the same output in case the link between RTC and RTA goes down.
Example 12-9. RTC Routing Table After RTC-RTA Link Failure
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
|
Notice that the second static entry with a distance of 60 has now kicked in.
Multihoming to a Single Provider
For the case in which one customer has multiple connections to the same provider, we will look at implementation examples that cover the following:
-
Default only, one primary link, and one backup link
-
Default, primary, and backup, plus partial routing
-
Automatic load balancing
Default Only, One Primary Link, and One Backup Link
In Figure 12-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.
Figure 12-3. Multihoming to a Single Provider (Default Only, One Primary Link, and One Backup Link)
The following policies apply to this network scenario:
-
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.
-
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. Other attributes can also be used to accomplish this (that is, BGP communities and associated remote ingress policies).
-
Prevent any BGP updates from coming into AS3.
This can be achieved by having AS3 configure a route map or prefix 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 your AS against the unknown. The provider could make a mistake and send you all his routes, and your AS would be vulnerable.
Example 12-10 shows the configuration used by RTA with default only, one primary link, and one backup link.
Example 12-10. Default Only, One Primary Link, and One Backup 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 this configuration, AS3 uses 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 the default.
Route maps SETMETRIC1 and SETMETRIC2 are used to set the outbound metric to 50 toward RTD and 100 toward RTC, respectively, thereby manipulating inbound traffic to prefer the NY link.
Route map BLOCK is used to block all incoming BGP updates from AS1.
The RTA IP routing table in Example 12-11 shows how the default route is set. Notice that distance 40 is preferred over distance 50 for the 0/0 route, and the gateway of last resort is pointing to next hop 192.68.9.2.
Example 12-11. RTA 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
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
|
Example 12-12 shows RTC's BGP table, which reveals 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.
Example 12-12. RTC 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
*>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 is running defaults toward the provider. Partial routes are usually the provider's local routes and its customers' routes. Figure 12-4 shows AS3 running IBGP internally and running EBGP at two different locations with its provider AS1.
Figure 12-4. Default, Primary, and Backup, Plus Partial Routing
The following policies apply to the network scenario illustrated in Figure 12-4:
-
AS3 will accept only AS1’s local routes and its customer’s routes, such as AS6. AS3 will also accept one route from the Internet to set its default toward the provider AS1.
-
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.
-
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.
-
For inbound traffic, AS3 will instruct AS1 to use the SF link for network 172.16.220.0/24.
-
For all other inbound traffic, the NY link is the primary.
Example 12-13 and Example 12-14 show partial configurations needed for the BGP configuration in RTA and RTF.
Example 12-13. Default, Primary, and Backup, Plus Partial Routing: 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 ip 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 |
Example 12-14. Default, Primary, and Backup, Plus Partial Routing: 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 configuration of RTA in Example 12-13 shows the following:
-
Route map SET_OUTBOUND_TRAFFIC is applied on RTA's EBGP session 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 of 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$).
Instead of listing all the customers of AS1 one by one as was done 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 that are 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). Be careful, though. 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.
-
Route map SET_INBOUND_TRAFFIC is also applied on RTA's EBGP link to AS1. The first instance (10) 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 ensure 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.
-
The filter list 10 will prevent AS3 from becoming a transit AS.
-
The ip route 0.0.0.0 0.0.0.0 statement sets the default to 193.78.0.0/16.
RTA's BGP table would have the entries listed in Example 12-15.
Example 12-15. RTA BGP Table
RTA#show 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/16 172.16.1.2 250 0 1 7 8 i
* 172.16.20.1 200 0 1 7 8 i
|
Note how RTA sees only 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 IP routing table of RTA in Example 12-16 shows that RTA has set its default to 193.78.0.0/16, which is reachable via 172.16.1.2.
Example 12-16. RTA 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 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
|
Example 12-17 shows RTD's BGP table.
Example 12-17. RTD BGP Table
RTD#show 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 can be reached via the RTC-RTA link because of the better metric 200.
Load Balancing with BGP Multipath
Before I begin the load-balancing discussion, it's important for you to understand that actual packet-switching functions performed by the router are entirely dependent upon the enabled Cisco switching mode (that is, CEF per-packet, CEF per-destination, fast switching, process switching, and so on). A detailed discussion of switching modes is beyond the scope of this book, but it is extremely important to understand that it will have a profound effect on load balancing. For additional information on Cisco switching modes, consult the appropriate Cisco documentation or read Inside Cisco IOS Software Architecture.
That said, let's begin our load-balancing discussion. Under normal conditions, when a BGP speaker receives identical paths for a prefix from an adjacent AS, only one path will be selected as the best path (normally the one with the lowest BGP ROUTER_ID value) and will be installed in the routing table. If BGP multipath is enabled, multiple paths (up to six) can be installed in the IP routing table.
In Figure 12-5, you can see how the Cisco BGP implementation can do dynamic load balancing for identical paths to the same destination received from the same adjacent autonomous system.
Figure 12-5. Automatic Load Balancing
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. You can configure RTA with the maximum-paths BGP router subcommand to enable IP routing to load balance among up to six paths. In Example 12-18, the maximum-paths number is set to 2.
Example 12-18. Enabling IP Routing to Load Balance: 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 in Example 12-19, you see that RTA has identical path information regarding 192.68.11.0/24 and 192.68.40.0/24. Normally, BGP will pick only one of the entries as the "best" path and give it to the IP routing table.
Example 12-19. RTA BGP 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, depending on the configured value) to the IP routing table. Note that the requirement for these paths is that they come from the same AS.
Example 12-20 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.
Example 12-20. RTA 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.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 advertise only a single BGP entry out of the multiple identical entries that have 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 of 172.16.2.254 rather than the external NEXT_HOP; this is illustrated in the BGP table in Example 12-21. For external peers, BGP will still pass on the best path as usual.
Example 12-21. RTF BGP Table
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 section 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 12-6, you will configure loopback interfaces on RTA and RTC (see Example 12-22 and Example 12-23) and run a single peering session between the two routers. Using static routes, you 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 12-6. Balancing Between Two Routers Sharing Multiple Paths
Example 12-22. Balancing Between Two Routers 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 next-hop-self neighbor 172.16.1.2 remote-as 3 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.90.1 remote-as 1 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 |
Example 12-23. Balancing Between Two Routers Sharing Multiple Paths: 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 output in Example 12-24 shows how RTA is now learning BGP updates from RTC via NEXT_HOP 172.16.90.1, the loopback address. Notice that update-source is configured as a BGP neighbor parameter. This sets the source IP address of the BGP TCP connection to that of the specified interface. If this weren't specified, the egress interface used to reach the peer would be the source address, and the peer would reject the connection.
Example 12-24. RTA BGP Table
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 (see Example 12-25) will provide multiple paths to reach the NEXT_HOP 172.16.90.1, so the router will load balance between the two paths.
Example 12-25. RTA 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.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
|
Similar configurations are required on the remote side of the connection as well. This will be discussed in the next couple of sections.
Multihoming to Different Providers
For the case of one customer multihomed to multiple providers, we will discuss a scenario in which updates follow a combination of defaults, partial routing, and full routing.
In Figure 12-7, AS3 is multihomed to two different ASs, AS1 and AS2, which in turn exchange routing information and traffic with AS6, as well as one another, 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. The desired policy is as follows:
-
AS3 will accept AS1's local and customer routes only via the SF link. All other Internet routes will be accepted via the NY link (primary).
-
AS3 will accept a default route from AS1 just in case there is a failure in the NY link.
AS3 prefers that the SF network 172.16.220.0/24 be reachable by the outside world via the SF link and that the NY networks 172.16.10.0/24 and 172.16.65.0/26 be reachable via the NY link.
-
AS3 cannot be a transit network for AS1 and AS2, which means that under no circumstances will AS1 use AS3 to reach AS2.
Figure 12-7. Multiple Providers (Default, Primary and Backup, Full/Partial)
The configurations in Examples 12-26 through 12-29 illustrate how to implement this routing arrangement. Example 12-26 begins with the configuration for RTA.
Example 12-26. Multiple Providers (Default, Primary and Backup, Full/Partial): 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 defines a route map toward RTC 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 associate your prefix with the path information. AS1, for example, might have a policy that advertises AS3 to the NAP using the form ^3$, which represents 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 lets AS3's local routes 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, Example 12-27 configures RTF to announce the SF prefixes on the NY link with an additional AS in the AS_PATH information. This would make inbound traffic toward these networks preferred via the SF link.
Example 12-27. Multiple Providers (Default, Primary and Backup, Full/Partial): 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 accepts all routes from AS2 and advertises only the local routes (^$), with an extra AS added to the AS_PATH information for the SF route 172.16.220.0/24.
Example 12-28 provides a snapshot of some of the BGP routing tables for RTA.
Example 12-28. RTA BGP Table
RTA#show 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 that RTA learns a default (0.0.0.0) from RTC. RTA also learns AS1's local routes (such as 192.68.11.0/24) 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 BGP table for RTG in Example 12-29 shows how an outside AS that falls behind the NAP, such as AS6, can reach AS3's networks.
Example 12-29. RTG BGP Table
RTG#show 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) can be reached via the NY link (path 7 2 3). The SF prefix 172.16.220.0/24 can be reached 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 scenario in this section discusses a case in which 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 12-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 12-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 networks via AS2 and AS2's networks 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_PREF attribute. In Example 12-30, we will concentrate on the router configuration of RTC; RTD's configuration should be similar.
Example 12-30. Backup Private Link Used as Primary: 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 configuration in Example 12-30 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 (the default); 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. Example 12-31 shows RTC's BGP table.
Example 12-31. Backup Private Link Used as Primary: RTC 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, because lots of hacks will reduce scalability. 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, you will see 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 12-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 12-9. Multiple ASs with Multiple Providers
Examples 12-32 through 12-34 show the relevant configuration of RTA, RTC, and RTF, respectively. RTD should be a mirror image of RTC.
Example 12-32. Backup Links for Multiple ASs with Multiple Providers Via COMMUNITY: 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 |
Notice how RTA has configured the route map CHECK_COMMUNITY. The match community value statement under the route map correlates 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 (default).
Example 12-33. Backup Links for Multiple ASs with Multiple Providers Via COMMUNITY: 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 |
Notice 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 that prevents AS4 from learning about AS3 via AS1. The filter list permits only AS1 and AS2 routes. In case the link between AS4 and AS3 goes down, AS4 cannot use AS1 to reach AS3.
Example 12-34. Backup Links for Multiple ASs with Multiple Providers Via COMMUNITY: 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, applied via the BGP neighbor command, sets all updates toward AS4 with a community of 4:60.
Consider RTA's BGP table in Example 12-35 to see what you have achieved.
Example 12-35. Backup Links for Multiple ASs with Multiple Providers Via COMMUNITY: RTA BGP Table
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, you can manipulate the AS_PATH value to achieve the desired routing shown in Figure 12-9. Also, because LOCAL_PREF is not a transitive attribute, AS_PATH manipulation will affect route selection in not only the adjacent AS, but in downstream ASs as well.
In Example 12-36, 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.
Example 12-36. Achieving Desired Routing Behavior Via AS_PATH Manipulation: 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. Example 12-37 shows how RTA's BGP table will look.
Example 12-37. Achieving Desired Routing Behavior Via AS_PATH Manipulation: RTA BGP Table
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
|
Notice how RTA now prefers AS3 to reach prefix 192.68.10.0/24. You must take care to ensure that the provider AS1 is not using any AS_PATH access lists and is accepting only routes of the form ^1$ or ^1 2$ from your AS. Otherwise, AS prepending could result in your provider's filtering your routes. It is always good to coordinate with your provider regarding the changes you want to make.