BGP Traffic Engineering

Identify the problem before changing attributes

An uneven traffic graph is not necessarily evidence of a fault. Different destinations, flow sizes and remote routing decisions can naturally produce an unequal split. We first establish what needs improving: congestion, cost, resilience, path predictability or access to a particular service. The target should be something the business can recognise, not simply two identical utilisation charts.

We collect the relevant route views and traffic evidence, with an agreed handling process for sensitive network information. Interface utilisation alone rarely explains why traffic uses a path. Where available, flow records and application observations help distinguish a small number of large transfers from widespread routing behaviour. This baseline gives subsequent changes something meaningful to be compared against.

Treat inbound traffic as a negotiated outcome

Inbound path selection depends on other autonomous systems. Provider communities, selective advertisements and AS-path prepending may influence it, subject to what the provider supports and how remote networks choose routes. We obtain the applicable provider policy rather than copying community values from an unrelated service.

We also consider the effect on resilience. Advertising more-specific prefixes to attract traffic can create additional operational obligations and acceptance limits. A preference that works under normal conditions must not make the backup path unusable. Where a precise inbound outcome cannot be guaranteed, we state that limitation and identify how the result will be observed after the change.

Make a small, testable change

The implementation plan identifies the exact prefixes or peers affected, the expected policy result and the rollback condition. We prefer a limited initial change where the network permits it. This reduces the chance that several simultaneous adjustments obscure which one produced the observed result.

After application, we inspect accepted and advertised attributes, selected next hops and actual traffic. Supported route-refresh behaviour may be useful, but we assess whether a particular change requires a more disruptive action. We avoid resetting every neighbour simply to make a policy take effect. Any interruption belongs in the approved change plan.

Keep policy understandable

MCI’s handover records the business reason for each preference, the provider dependencies and the conditions that would justify revisiting it. Obsolete exceptions are candidates for removal through a controlled change. For related work, see BGP communities and policy and BGP multihoming design. Our objective is a routing policy that engineers can explain during an incident, not an increasingly intricate set of undocumented overrides.