BGP traffic engineering: how to shape inbound and outbound traffic

BGP traffic engineering is the deliberate control of which links traffic uses to leave and enter your autonomous system, done by manipulating BGP attributes. You steer outbound traffic mainly with local-preference, because you choose the route. Inbound traffic is harder, because remote networks decide the path. You influence it indirectly through AS-path prepending, the MED attribute and communities. For a multihomed operator this is the core toolkit you use to balance link load, cut transit costs and improve quality.

Local-preference: steering outbound traffic

Local-preference is an attribute meaningful only inside your own network. It is propagated within iBGP but never sent to other autonomous systems. It is evaluated very early in the BGP decision process, right after the weight attribute on Cisco devices, so it overrides AS-path length. The default value is 100 and a higher value wins. When you set a higher local-preference on routes learned from peering and a lower value on transit routes, you push outbound traffic where it is cheaper and closer, regardless of path length.

• Local-preference is local only and never leaves your AS.
• Higher wins. A common convention is 100 for transit and more for peering.
• It is evaluated before AS-path length, so it overrides the natural route choice.
• Most common use: prefer peering over transit, and a cheaper upstream over a costlier one.

AS-path prepending: influencing inbound traffic

Because you do not control the policy of foreign networks, you shape inbound traffic indirectly. The simplest method is AS-path prepending: artificially lengthening the path by inserting your own AS number several times in the advertisement. A longer AS-path is less attractive in the BGP decision, so remote networks pick the shorter route through another upstream. Prepending is a blunt instrument, because it affects the whole internet at once and does not always override another network's local-preference. One or two prepends usually suffice, and excessive lengthening yields no further effect.

MED and communities: fine-grained tuning

MED (Multi-Exit Discriminator) is an attribute by which you suggest to a neighbour which of several shared links it should use to reach you. A lower MED is preferred. It only works between two directly connected networks and is compared near the end of the decision process, so it is frequently ignored. BGP communities (RFC 1997) and large communities (RFC 8092) offer more. When you tag a route with a community your upstream understands, you ask it to act on your behalf on its side: raise or lower local-preference, prepend toward selected regions, or not advertise the prefix to specific networks. This gives precise control without waiting for manual changes at the provider.

• MED influences inbound traffic only between two directly connected networks; lower wins.
• Standard communities (RFC 1997) are 32 bits in the format ASN:value, e.g. 64500:120.
• Large communities (RFC 8092) solve the 4-byte ASN problem with the format ASN:function:parameter.
• Typical provider community actions: change local-pref, conditional prepending, suppress a prefix advertisement.
• Most transit operators publish their community documentation in PeeringDB or the IRR.

Traffic engineering on the AS202520 SkyPass network

On AS202520 SkyPass we give IP transit and peering customers a set of BGP communities for self-service traffic engineering: local-preference control, conditional prepending and selective prefix advertisement. With PoPs in Warsaw and Wrocław and peering at THINX, TPIX, WRIX and 1-IX, you can prefer local paths for Polish traffic and keep transit as a fallback. You can verify the effect of changes in our Looking Glass, and our NOC will help you tune prepending and MED policies for your multihoming scenario.