ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


O'Reilly Book Excerpts: BGP

Traffic Engineering: Incoming Traffic

Related Reading

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

by Iljitsch van Beijnum

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

Traffic Engineering for Incoming Traffic

Because the local router determines the route taken by outgoing packets, it isn't difficult to balance outbound traffic over multiple connections. The situation for inbound traffic is different. There are only a few routes you can influence to shift incoming traffic patterns: one for each address block for each ISP you connect to, instead of tens of thousands for outgoing traffic. In the typical multihoming case, with one address block and two ISPs, this leaves you with just two routes that can be manipulated to change inbound traffic distribution. This manipulation can take the form of:

  • Setting the MED

  • Prepending the AS path

  • Setting outbound communities

You can also decide to "cheat" and break up a single address block that would normally be announced as a single route into several smaller blocks, so you can announce each separately, with different properties, for more fine-grained control.

Setting the MED

The MED metric is intended to be used only between two neighboring ASes. It isn't communicated to ASes beyond the neighboring AS. For this reason, the use of the MED in balancing incoming traffic is limited to the situation where there is more than one connection between two ASes: setting a higher MED for one route will make the traffic flow over the other. This is useful when one of the connections is of a much higher bandwidth, and the second one is a lower-bandwidth backup. Because you don't know whether the bgp bestpath med missing-as-worst command is in effect on the router terminating your connections at the other end, always set MEDs for the routes over both connections, as is shown in Example 6-11.

Example 6-11: Setting outbound MED values

!
router bgp 60055
 neighbor 192.0.254.17 remote-as 40077
 neighbor 192.0.254.17 route-map ispa-out out
 neighbor 219.2.19.1 remote-as 50066
 neighbor 219.2.19.1 route-map ispb-out out
!
route-map ispa-out permit 10
 set metric 10
!
route-map ispb-out permit 10
 set metric 20
!

We are now trying to influence incoming traffic, so we have to manipulate outgoing routing updates and apply the route maps to the neighbors using the neighbor ... route-map ... out command.

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: Specific Routes
In this fourth installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to balance incoming traffic by announcing more specific routes.

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.

TIP: The MED metric you see in the BGP table is never announced to eBGP neighbors. If you want a neighbor to receive a MED, you have to configure an outbound route map to set the MED for this neighbor.

Prepending Outbound AS Paths

When you bring up your second BGP session, you soon get to see how much traffic your routes attract over both ISPs. In many cases, the traffic will be distributed fairly equally over both connections, or one connection receives more traffic but there is enough spare capacity (for inbound traffic) so this isn't a problem. But maybe one connection attracts more traffic than it can handle, or you have one big pipe and a smaller one, and the traffic volumes are equal (or at least they try to be). Under these circumstances, you'll want to shift part of the incoming traffic load from one connection to the other. The most powerful option to change incoming traffic patters is making the AS path longer. This is effective, because the path is preserved between ASes, and BGP implementations use the path length early in the route selection algorithm. The biggest problem with making the AS path longer by prepending your own AS number to the path one or more extra times is that it may be too effective. Example 6-12 shows a configuration that prepends the path for the routes announced to an upstream ISP.

Example 6-12: Prepending the path for outbound routes

!
router bgp 60055
 neighbor 219.2.19.1 remote-as 50066
 neighbor 219.2.19.1 route-map ispb-out out
!
route-map ispb-out permit 10
 set as-path prepend 60055
!

The way the route map works should be familiar by now. Rather than applying the route map for incoming routes, the ispb-out permit 10 route map is used for outbound route updates. The number 10 is superfluous here, because there is only a single route map, but the router adds it to the configuration if you don't type it in yourself. The set clause adds 60055 to all routes.

Make sure all routes with prepended paths are accepted by your ISP and upstream networks. It isn't uncommon for the AS path filters that ISPs use to filter routes from customers not to allow path prepending. There usually isn't a good reason for this; it's just that allowing path prepending makes for more complex filters. If, after configuring path prepending, you use one or more looking glasses to see if they now receive your route in its prepended state, you may see only the unprepended route over your other ISP. It isn't always clear whether this means the route wasn't accepted, or routers further upstream just prefer the unprepended path over your other ISP because of the shorter AS path. The only way to make sure is to temporarily disable the BGP session to the nonprepended ISP:

!
router bgp 60055
 neighbor 192.0.254.17 shutdown
!

If the prepended route doesn't show up on remote looking glasses, or remote destinations on the Net become unreachable after shutting down your unprepended ISP, there must be a filter somewhere. Don't forget to let route propagation settle for a minute or two before drawing conclusions. You can determine where filtering takes place by tracerouting to an unreachable destination. The ASes that show up in the traceroute don't filter the prepended AS path. The filter must be between the last AS that shows up in the traceroute and the first one that doesn't. If your ISP is the one filtering out prepended routes, you can ask them to change their filters, but if the problem is further upstream, there is probably not a lot you can do. Don't forget to reenable the BGP session to your other ISP:

!
router bgp 60055
 no neighbor 192.0.254.17 shutdown
!

TIP: The filter that prohibits routes with prepended paths from finding their way may be located inside your own router. It's best always to allow prepending your own AS, even if you don't plan on prepending in the near future:

ip as-path access-list 2 permit ^(60055_)*$

This regular expression matches all AS paths consisting of the beginning of the line (^), zero or more (()*) times the AS number, a space (_), and then the end of the line ($). In other words: an empty AS path or an AS path with just the AS number 60055.

Pages: 1, 2

Next Pagearrow





Sponsored by: