ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


O'Reilly Book Excerpts: BGP

Traffic Engineering: Specific Routes

Related Reading

BGP
Building Reliable Networks with the Border Gateway Protocol
By Iljitsch van Beijnum

by Iljitsch van Beijnum

Editor's Note: In this fourth installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to announce more specific routes in order to balance incoming traffic.

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 220.37.0.0/20 (16 Class C's: 220.37.0 through 220.37.15), you could announce 220.37.0.0/21 to ISP A and 220.37.8.0/21 to ISP B. This way, all traffic to the Class C nets 220.37.0 through 220.37.7 comes in over ISP A, and all traffic to Class C nets 220.37.8 through 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 220.37.0.0 mask 255.255.240.0
 network 220.37.0.0 mask 255.255.248.0
 network 220.37.8.0 mask 255.255.248.0
 neighbor 192.0.254.17 remote-as 40077
 neighbor 192.0.254.17 description BGP session to ISP A
 neighbor 192.0.254.17 prefix-list ispa-ms out
 neighbor 219.2.19.1 remote-as 50066
 neighbor 219.2.19.1 description BGP session to ISP B
 neighbor 219.2.19.1 prefix-list ispb-ms out
!
ip route 220.37.0.0 255.255.240.0 Null0
ip route 220.37.0.0 255.255.248.0 Null0
ip route 220.37.8.0 255.255.248.0 Null0
!
ip prefix-list ispa-ms description outbound filter for ISP A
ip prefix-list ispa-ms seq 5 permit 220.37.0.0/20
ip prefix-list ispa-ms seq 10 permit 220.37.0.0/21
ip prefix-list ispa-ms seq 15 deny   220.37.8.0/21
ip prefix-list ispb-ms description outbound filter for ISP B
ip prefix-list ispb-ms seq 5 permit 220.37.0.0/20
ip prefix-list ispb-ms seq 10 deny   220.37.0.0/21
ip prefix-list ispb-ms seq 15 permit 220.37.8.0/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 220.37.0.0/20 and 220.37.0.0/21, and those announced to ISP B to 220.37.0.0/20 and 220.37.8.0/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
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  195.30.2.198
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network        Next Hop      [...]  Path
*> 220.37.0.0/21  192.0.254.17  [...]  40077 60055 i
*> 220.37.0.0/20  192.0.254.17  [...]  40077 60055 i
*                 219.2.19.1    [...]  50066 30077 60055 i
*> 220.37.8.0/21  219.2.19.1    [...]  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 220.37.0.0
Routing entry for 220.37.0.0, 3 known subnets
  Variably subnetted with 2 masks
B       220.37.0.0/20 [20/0] via 192.0.254.17, 1d12h
B       220.37.0.0/21 [20/0] via 192.0.254.17, 1d12h
B       220.37.8.0/21 [20/0] via 219.2.19.1, 1d16h

In This Series

Traffic Engineering: Queuing, Traffic Shaping, and Policing
In the fifth and final installment in this series of excerpts on Traffic Engineering from O'Reilly's BGP, learn how to increase performance for certain protocols or sessions using special queuing strategies, traffic shaping, and rate limiting.

Traffic Engineering: Incoming Traffic
In this third installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to balance inbound traffic.

Traffic Engineering: Local Routing Policy
In this second installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to influence the BGP path-selection process.

Traffic Engineering: Finding the Right Route
In this first installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to find the best route in a multihomed setup--the one that will take advantage of all available bandwidth.

Note that the 220.37.0.0/20 route is actually in the routing table, although it will never be used for forwarding as long as both 220.37.0.0/21 and 220.37.8.0/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.

Copyright © 2009 O'Reilly Media, Inc.