BGP Routing Policies

BGP routing policies are used to control the flow of routing information and influence path selection. They are implemented using various tools like route maps, prefix lists, and AS-path access lists.

Common Policy Tools

  • Route Maps: Flexible tools for matching and setting attributes.
  • Prefix Lists: Used to filter routes based on IP prefixes.
  • AS-Path Access Lists: Used to filter routes based on the AS_PATH attribute.

Route Map Example

ip prefix-list MY_PREFIXES seq 5 permit 10.0.0.0/8
route-map SET_LOCAL_PREF permit 10
 match ip address prefix-list MY_PREFIXES
 set local-preference 200
router bgp 65000
 neighbor 192.168.1.2 route-map SET_LOCAL_PREF in

Inbound vs Outbound Policy

BGP policy must be planned by direction. An inbound route-map controls routes as they are learned from a neighbor. This is commonly used to set local preference, tag communities, filter unwanted prefixes, or reject overly specific routes. An outbound route-map controls what your router advertises to a neighbor. This is commonly used to limit advertised prefixes, prepend your AS path, set MED, or attach communities requested by a provider.

Always define the goal before choosing the tool. If you want your AS to send outbound traffic through one provider, local preference is usually the cleanest option. If you want other networks to prefer one inbound path, you may advertise more specific prefixes, prepend on the less preferred path, or use provider communities where available. The remote AS still makes the final inbound decision.

Policy Tools and Use Cases

  • Prefix lists: Permit or deny specific network prefixes and prefix lengths.
  • AS-path filters: Match routes based on the autonomous systems listed in AS_PATH.
  • Route maps: Combine match conditions with set actions such as local preference, MED, communities, or AS-path prepending.
  • Communities: Tag routes so policies can be reused cleanly across many neighbors and prefixes.
  • Maximum-prefix limits: Protect a router from accepting an unexpected number of routes from a neighbor.

Verification Checklist

  • Confirm the prefix list matches the intended prefixes and prefix lengths.
  • Check route-map sequence order because the first matching sequence controls the result.
  • Verify whether the policy is applied inbound or outbound on the correct neighbor.
  • Use show ip bgp to confirm attributes changed as expected.
  • Refresh or clear BGP sessions carefully when policy changes need to be reprocessed.

Related BGP Resources

When documenting a BGP policy, record the business reason, neighbor, direction, match condition, set action, and verification command. Good documentation prevents future engineers from removing a route-map that was intentionally controlling traffic flow.

In production, test policies with a narrow prefix first whenever possible. A broad route-map or prefix-list mistake can hide important routes, leak private prefixes, or shift traffic to an expensive backup link.

Include a rollback condition as well: define which prefix count, reachability test, latency change, or traffic shift means the policy should be removed. Clear success and rollback criteria keep route changes measurable.

Build Policy from an Explicit Intent

Before writing a prefix list or route map, describe the desired result in plain language: which prefixes may enter, which prefixes may leave, which path should be preferred, and what must happen when a route does not match. This prevents an apparently simple filter from accidentally accepting or rejecting more routes than intended.

Inbound policy controls what the router accepts from a neighbor and which attributes are changed before best-path selection. Outbound policy controls what the router advertises and how those advertisements are presented. A prefix denied inbound cannot be used locally or passed onward. A prefix denied outbound can still exist in the local BGP table but is hidden from that neighbor.

Safer Policy Practices

  • Match exact approved prefixes and intentional ranges instead of using broad permits.
  • Remember the implicit deny at the end of prefix lists and route maps.
  • Use sequence numbers and descriptions so changes can be reviewed safely.
  • Apply maximum-prefix limits as protection against unexpected route volume.
  • Test policy in a lab and record routes before and after the change.

After applying policy, inspect the neighbor configuration, route-map and prefix-list counters, BGP table, selected paths and advertised routes. A soft inbound refresh may be required when policy changes and route refresh is supported. Continue with the path attribute guide, configuration lab, and troubleshooting workflow.