O'Reilly Book Excerpts: BGP
Traffic Engineering: Specific Routes
Announcing More Specific Routes
When prepending the path and setting communities for outbound routes aren't enough to balance incoming traffic, there is a last resort: announcing more specific routes. This will inflate the global routing table, so announcing more specific routes should be done only when absolutely necessary. Because a more specific route always takes precedence over a less specific route, this technique always works, as long as the more specifics are accepted by your ISP and a reasonable number of their upstream (transit or peer) networks.
TIP: Announcing more specifics is also useful when someone else announces your address block (by mistake, or by your request but no longer needed) and you don't want to wait for them to fix this.
Consider the situation outlined back in Figure 6-4. If the routers for ISP A consistently use a lower router ID (which defaults to the highest IP address in the box) than those of ISP B, it's possible that nearly all traffic comes in over ISP A. The AS paths are all the same length, and the tie-breaking rules favor the route from the neighbor with the lowest router ID. Prepending the path won't help: all traffic then comes in over ISP B. If neither A nor B allows selective prepending using communities, balancing the traffic is possible only by announcing more specific routes. For instance, if your address block is
188.8.131.52/20 (16 Class C's:
220.37.15), you could announce
184.108.40.206/21 to ISP A and
220.127.116.11/21 to ISP B. This way, all traffic to the Class C nets
220.37.7 comes in over ISP A, and all traffic to Class C nets
220.37.15 over ISP B. Example 6-15 shows a configuration that accomplishes this.
Example 6-15: Announcing more specific routes
! router bgp 60055 network 18.104.22.168 mask 255.255.240.0 network 22.214.171.124 mask 255.255.248.0 network 126.96.36.199 mask 255.255.248.0 neighbor 188.8.131.52 remote-as 40077 neighbor 184.108.40.206 description BGP session to ISP A neighbor 220.127.116.11 prefix-list ispa-ms out neighbor 18.104.22.168 remote-as 50066 neighbor 22.214.171.124 description BGP session to ISP B neighbor 126.96.36.199 prefix-list ispb-ms out ! ip route 188.8.131.52 255.255.240.0 Null0 ip route 184.108.40.206 255.255.248.0 Null0 ip route 220.127.116.11 255.255.248.0 Null0 ! ip prefix-list ispa-ms description outbound filter for ISP A ip prefix-list ispa-ms seq 5 permit 18.104.22.168/20 ip prefix-list ispa-ms seq 10 permit 22.214.171.124/21 ip prefix-list ispa-ms seq 15 deny 126.96.36.199/21 ip prefix-list ispb-ms description outbound filter for ISP B ip prefix-list ispb-ms seq 5 permit 188.8.131.52/20 ip prefix-list ispb-ms seq 10 deny 184.108.40.206/21 ip prefix-list ispb-ms seq 15 permit 220.127.116.11/21 !
To announce the two more specific routes in addition to the original
/20 route (as a fallback in case the more specifics are filtered), each route must be listed in the BGP configuration with a network statement, and there must be matching local (pull up) routes, as provided by the ip route ... Null0 statements. The prefix lists limit the routes announced to ISP A to
18.104.22.168/21, and those announced to ISP B to
22.214.171.124/21. Having two routes with the same address part isn't a problem: the NLRI consists of both the address and the prefix parts of a route. Two routes are considered different if either differs.
Figure 6-6. Propagation of more specific routes
Figure 6-6 shows the propagation of routes, and Example 6-16 shows how these routes might show up in the BGP table of a remote AS. (Don't forget to register
ROUTE objects in the Routing Registry of your choice for the more specific routes.)
Example 6-16: More specific routes as seen by a remote AS
BR1#show ip bgp BGP table version is 933017, local router ID is 126.96.36.199 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop [...] Path *> 188.8.131.52/21 184.108.40.206 [...] 40077 60055 i *> 220.127.116.11/20 18.104.22.168 [...] 40077 60055 i * 22.214.171.124 [...] 50066 30077 60055 i *> 126.96.36.199/21 188.8.131.52 [...] 50066 123 456 60055 i
As you can see, there are two routes for the
/20, but only a single route for each of the more specifics. Also, the path over ISP B (AS 50066) for the
/20 is shorter than the path of the
/21: apparently, AS 30077 filters out the more specific route and allows only the
/20 from AS 50066. But ASes 123 and 456 don't filter, so there is still a route for the
/21. And since it's the most specific route, this is the one that is actually used, as the routing table for this remote network shows in Example 6-17.
Example 6-17: More specific routes in the routing table
BR1#show ip route 184.108.40.206 Routing entry for 220.127.116.11, 3 known subnets Variably subnetted with 2 masks B 18.104.22.168/20 [20/0] via 22.214.171.124, 1d12h B 126.96.36.199/21 [20/0] via 188.8.131.52, 1d12h B 184.108.40.206/21 [20/0] via 220.127.116.11, 1d16h
In This Series
Traffic Engineering: Queuing, Traffic Shaping, and Policing
Traffic Engineering: Finding the Right Route
Note that the
18.104.22.168/20 route is actually in the routing table, although it will never be used for forwarding as long as both
22.214.171.124/21 are available, because those cover the exact same address range. The "B" indicates that the route was learned from BGP, and 20/0 is the administrative distance (20, the default for eBGP) and metric (0, a missing MED).
TIP: When deploying IP addresses, try to avoid putting all high-bandwidth hosts in the same or nearby subnets. Putting half the high-bandwidth hosts in the first
/24 and the rest in the second is a better idea. If you ever need to announce more specifics to balance incoming traffic, it's a lot easier to announce two
/21s out of a
/20 or announce just a
/24 separately in addition to what's normally announced, rather than having to announce very specific routes (prefixes longer than
/24) or do some renumbering within your own address range in a hurry.
Even the most sophisticated traffic balancing techniques won't help you when there is just too much traffic. The best way to handle this would be to get more bandwidth, but with some smart queuing techniques, it's possible to increase performance for some protocols or sessions without hurting others very much. In the fifth and final installment in this series of excerpts on Traffic Engineering, learn how to increase performance using special queuing strategies, traffic shaping, and rate limiting.
Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996.
Return to ONLamp.com.