101
0/240
Loading content...
The Internet is not merely a technical infrastructure—it's a complex ecosystem of business relationships. ISPs pay for transit. Content providers pay for connectivity. Networks peer settlement-free when mutually beneficial. These business arrangements must somehow be translated into routing behavior.
Policy routing in BGP provides the mechanisms to encode business logic into routing decisions. Which routes should we prefer? Which routes should we accept at all? How should we influence where traffic enters and exits our network? Policy routing answers these questions through communities, route maps, local preferences, and sophisticated filtering mechanisms.
By the end of this page, you will understand how to implement BGP policies using communities and route maps, master Route Reflector and Confederation architectures for iBGP scaling, comprehend traffic engineering techniques for inbound and outbound traffic, and appreciate how policy translates business relationships into routing behavior.
BGP policy routing encompasses all mechanisms that allow operators to control route acceptance, preference, and advertisement. Understanding the policy toolkit is essential for effective network operations.
The Policy Toolkit:
| Tool | Purpose | Application Point |
|---|---|---|
| Prefix Lists | Filter by prefix/length | Inbound/Outbound |
| AS-Path Filters | Filter by AS path content | Inbound/Outbound |
| Community Filters | Match routes by community tags | Inbound/Outbound |
| Route Maps | Combine criteria, modify attributes | Inbound/Outbound/Redistribution |
| LOCAL_PREF | Set egress preference | Inbound (from eBGP) |
| MED | Influence neighbor's ingress | Outbound (to eBGP) |
| AS-Path Prepending | Make path less attractive | Outbound |
| Weight | Local router preference | Inbound |
Policy Processing Order:
When a BGP UPDATE is received:
Route Maps Deep Dive:
Route maps are the Swiss Army knife of BGP policy. They combine match conditions with set actions:
route-map CUSTOMER-IN permit 10
match ip address prefix-list CUSTOMER-PREFIXES
match as-path 1
set local-preference 200
set community 65001:1000 additive
route-map CUSTOMER-IN deny 20
! Implicit deny for everything else
neighbor 10.0.0.2 route-map CUSTOMER-IN in
Route Map Clauses:
| Clause Type | Purpose |
|---|---|
| permit | If all match conditions are true, apply set actions and accept |
| deny | If all match conditions are true, reject the route |
Match Conditions:
match ip address prefix-list NAME — Match prefixmatch as-path ACCESS-LIST — Match AS pathmatch community COMMUNITY-LIST — Match communitymatch ip next-hop prefix-list NAME — Match NEXT_HOPSet Actions:
set local-preference VALUE — Set LOCAL_PREFset community VALUE [additive] — Set/add communityset as-path prepend AS... — Prepend to AS_PATHset weight VALUE — Set weightset metric VALUE — Set MEDAlways verify policy behavior before deploying to production. Use 'show ip bgp neighbor X.X.X.X advertised-routes' and 'received-routes' to see what's being sent and received. Test route-maps offline where possible. A single missing permit clause can filter your entire routing table.
BGP Communities are the primary mechanism for tagging routes with policy-relevant information. They enable flexible, scalable policy implementation across large networks.
Community Fundamentals:
A standard community is a 32-bit value, typically expressed as AS:value:
65001:1000 → High 16 bits: 65001 Low 16 bits: 1000
Community Types:
| Type | Size | Format | RFC |
|---|---|---|---|
| Standard | 32 bits | AS:value | 1997 |
| Extended | 64 bits | Type:Value | 4360 |
| Large | 96 bits | GlobalAdmin:LD1:LD2 | 8092 |
Well-Known Communities:
| Community | Value | Meaning |
|---|---|---|
| NO_EXPORT | 0xFFFFFF01 | Don't export beyond AS/confederation |
| NO_ADVERTISE | 0xFFFFFF02 | Don't advertise to any peer |
| NO_EXPORT_SUBCONFED | 0xFFFFFF03 | Don't export beyond sub-confederation |
| NOPEER | 0xFFFFFF04 | Don't advertise to bilateral peers |
Community Use Cases:
| Community | Meaning | Resulting Action |
|---|---|---|
| 65001:100 | Customer route | LOCAL_PREF 200, advertise to all |
| 65001:200 | Peer route | LOCAL_PREF 100, NO_EXPORT to peers |
| 65001:300 | Transit route | LOCAL_PREF 50, advertise to customers only |
| 65001:666 | Blackhole | Install as discard route, NO_EXPORT |
| 65001:1000 | Originated in NYC | Geographic tagging |
| 65001:2000 | Originated in LON | Geographic tagging |
| 65001:3001 | Prepend 1x to AS 65003 | Selective prepending |
| 65001:3002 | Prepend 2x to AS 65003 | Selective prepending |
| 65001:4000 | Do not announce to AS 65004 | Selective filtering |
Implementing Community-Based Policy:
! Step 1: Define community lists
ip community-list standard CUSTOMER permit 65001:100
ip community-list standard PEER permit 65001:200
ip community-list standard BLACKHOLE permit 65001:666
! Step 2: Set communities on ingress
route-map CUSTOMER-IN permit 10
set community 65001:100 additive
set local-preference 200
! Step 3: Match communities on egress
route-map PEER-OUT permit 10
match community CUSTOMER
! Advertise customer routes to peers
route-map PEER-OUT deny 20
match community PEER
! Don't advertise peer routes to other peers
route-map PEER-OUT permit 30
! Allow other routes (transit)
! Step 4: Apply to neighbors
neighbor 192.0.2.1 route-map CUSTOMER-IN in
neighbor 198.51.100.1 route-map PEER-OUT out
Action Communities (Customer-Triggered):
Many providers offer action communities that customers can attach to influence provider behavior:
! Provider AS 65000 community documentation:
! 65000:666 - Blackhole this prefix
! 65000:100 - Set LOCAL_PREF to 100
! 65000:200 - Set LOCAL_PREF to 200
! 65000:3NNN - Prepend N times to AS NNN
! 65000:0NNN - Do not announce to AS NNN
This enables customers to influence traffic engineering without direct provider coordination.
Always scrub unexpected communities on ingress from external peers. A misconfigured customer or malicious actor could attach your internal communities to their routes, triggering unintended behavior. Use 'set community X delete community INTERNAL-LIST' to remove internal communities from inbound external routes.
The iBGP full-mesh requirement becomes unmanageable in large networks. With n BGP speakers, you need n(n-1)/2 iBGP sessions. For 100 routers: 4,950 sessions. For 500 routers: 124,750 sessions.
Route Reflectors (RFC 4456) solve this by relaxing the iBGP split-horizon rule. Designated routers can re-advertise iBGP-learned routes to other iBGP peers.
Route Reflector Concepts:
| Term | Definition |
|---|---|
| Route Reflector (RR) | Router that reflects routes between clients and non-clients |
| Client | iBGP peer that receives reflected routes |
| Non-Client | iBGP peer that follows normal iBGP rules |
| Cluster | RR and its clients |
| Cluster ID | Identifier for loop prevention |
Reflection Rules:
| Route Source | Advertisement To | Action |
|---|---|---|
| Client | Other Clients | Reflect |
| Client | Non-Clients | Reflect |
| Non-Client | Clients | Reflect |
| Non-Client | Other Non-Clients | Do NOT reflect |
| eBGP | All iBGP (Clients/Non-Clients) | Advertise (normal) |
Loop Prevention Mechanisms:
Route reflection introduces the possibility of routing loops. Two attributes prevent this:
1. ORIGINATOR_ID:
2. CLUSTER_LIST:
Configuration Example:
! Route Reflector configuration
router bgp 65001
bgp cluster-id 1.1.1.1
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-reflector-client
neighbor 10.0.0.2 remote-as 65001
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.3 remote-as 65001
! 10.0.0.3 is non-client (no route-reflector-client)
RR Design Considerations:
Because RRs only advertise their best path, clients may not learn all available paths. The RR's location affects its best path selection (IGP metric to NEXT_HOP), potentially hiding paths that would be better for clients. This can cause suboptimal routing and is a key consideration in RR placement.
BGP Confederations (RFC 5065) provide an alternative to Route Reflectors for iBGP scaling. Instead of violating the iBGP split-horizon rule, confederations subdivide the AS into smaller sub-ASes.
Confederation Concepts:
| Term | Definition |
|---|---|
| Confederation | The overall AS as seen from outside |
| Member AS (Sub-AS) | Internal division of the confederation |
| Confederation ID | The public AS number |
| Member AS Numbers | Private AS numbers for internal use |
How Confederations Work:
Confederation eBGP (Intra-Confederation) Behavior:
| Aspect | Normal eBGP | Confederation eBGP |
|---|---|---|
| AS_PATH prepend | Local AS | Member AS (stripped externally) |
| NEXT_HOP | Changes | Preserved (like iBGP) |
| LOCAL_PREF | Stripped | Preserved |
| MED | Preserved | Preserved |
Configuration Example:
! Router in Member AS 65100 (within Confederation 65001)
router bgp 65100
bgp confederation identifier 65001
bgp confederation peers 65200 65300
neighbor 10.0.0.1 remote-as 65100 ! iBGP within member AS
neighbor 10.0.0.2 remote-as 65200 ! Confederation eBGP
neighbor 10.0.0.3 remote-as 65002 ! True eBGP
AS_PATH with Confederations:
The AS_PATH uses special segment types:
Importantly, confederation segment lengths do not count toward AS_PATH length in best path selection.
Example:
Internal AS_PATH: (65100 65200) 65002 65003
External AS_PATH: 65001 65002 65003
(65100 65200) is stripped when advertising externally
Route Reflector vs Confederation:
| Aspect | Route Reflector | Confederation |
|---|---|---|
| Complexity | Lower—incremental deployment | Higher—requires AS restructuring |
| Loop Prevention | ORIGINATOR_ID, CLUSTER_LIST | AS_PATH (member AS) |
| Attribute Handling | Standard iBGP | eBGP-like but preserves LOCAL_PREF |
| Path Hiding | Yes (RR only announces best) | Less—full path visible between members |
| Migration | Easy—add RR clients | Hard—re-number ASes |
Route Reflectors are the dominant solution in modern networks due to simpler deployment. Confederations are sometimes used when organizational boundaries align with routing domains, or when the path hiding issue of RRs is unacceptable. Many large networks combine both—confederations for major divisions, RRs within each member AS.
Controlling how traffic enters your network is challenging because the decision is made by remote networks based on their own policies. However, BGP provides several mechanisms to influence these decisions.
Inbound Traffic Control Mechanisms:
| Mechanism | How It Works | Effectiveness |
|---|---|---|
| AS_PATH Prepending | Makes path less attractive by appearing longer | Medium—can be overridden by LOCAL_PREF |
| MED | Signals preference between your entry points | Low—only compared within same AS, often ignored |
| More Specifics | Longest prefix match wins forwarding | High—but grows routing tables |
| Selective Announcement | Don't advertise to unwanted paths | Medium—limits diversity |
| Communities | Signal preferred handling to neighbors | Varies—depends on neighbor's implementation |
AS_PATH Prepending for Inbound:
! Make link to AS 65002 less preferred
route-map PREPEND-65002 permit 10
set as-path prepend 65001 65001 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map PREPEND-65002 out
Result: Remote networks see longer AS_PATH via AS 65002, preferring other paths.
Limitations:
More Specific Prefixes:
Advertising more-specific prefixes forces traffic to the desired path because longest-prefix match wins:
Scenario: You own 192.0.0.0/22
Default: Advertise 192.0.0.0/22 via both providers
Result: Traffic split based on remote best path selection
With More Specifics:
- Advertise 192.0.0.0/23 via Provider A
- Advertise 192.0.2.0/23 via Provider B
- Advertise 192.0.0.0/22 via both (backup)
Result: Precise control—each /23 goes via designated provider
Trade-offs:
Using Communities for Inbound Traffic:
Many transit providers offer traffic engineering communities:
! Provider AS 65000 community reference:
! 65000:3NNN - Prepend N times toward AS NNN
! 65000:0NNN - Do not announce to AS NNN
! 65000:2NNN - Lower LOCAL_PREF toward AS NNN
! Your configuration to avoid traffic via AS 65003:
route-map TO-TRANSIT permit 10
set community 65000:0003 additive
neighbor 10.0.0.1 route-map TO-TRANSIT out
This uses the transit provider's policy machinery to influence their route advertisements.
Inbound traffic engineering is iterative—you make changes and observe results. Use NetFlow/sFlow to monitor traffic entry points. Check public looking glass servers to see how your routes appear from various networks. Tools like RIPE RIS and RouteViews show BGP announcements from multiple vantage points.
Controlling how traffic exits your network is much easier than inbound control—you directly control the decision through local BGP configuration.
Outbound Traffic Control Mechanisms:
| Mechanism | Scope | Best For |
|---|---|---|
| LOCAL_PREF | Entire AS | Primary policy tool |
| Weight | Single router | Per-router override |
| AS_PATH manipulation (accept) | Affect selection | Rare, avoid |
| MED acceptance | Selection criteria | Honor neighbor's preference |
| IGP metric manipulation | Hot potato tuning | Exit point selection |
LOCAL_PREF-Based Policy (Most Common):
! Prefer customer routes over peer over transit
route-map CUSTOMER-IN permit 10
set local-preference 200
route-map PEER-IN permit 10
set local-preference 100
route-map TRANSIT-IN permit 10
set local-preference 50
This ensures:
| Route Source | LOCAL_PREF | Rationale |
|---|---|---|
| Customer | 200+ | Prefer paid incoming traffic |
| Peer (IXP) | 100-150 | Settlement-free, good for ratio |
| Peer (PNI) | 120-180 | Private peering, often better quality |
| Transit (Primary) | 50-80 | Paid, use when needed |
| Transit (Backup) | 20-40 | Expensive, avoid if possible |
| Blackhole | 10 | Last resort, traffic dropped |
Prefix-Specific Policy:
Sometimes you want different policies for different destinations:
! Always use Transit A for destinations in AS 65099
route-map TRANSIT-A-IN permit 5
match as-path AS65099
set local-preference 300
route-map TRANSIT-A-IN permit 10
set local-preference 50
! Content provider has better path to AS 65050
route-map CDN-IN permit 5
match community CDN-OPTIMIZED
set local-preference 250
Cold Potato Routing:
By default, BGP uses "hot potato" routing—exit at the closest point (lowest IGP cost to NEXT_HOP). "Cold potato" routing keeps traffic on your network longer, exiting closer to the destination:
! Force traffic to exit via specific router
route-map PREFER-NYC permit 10
match ip address prefix-list EAST-COAST-DESTINATIONS
set ip next-hop 10.1.1.1 ! NYC router
Cold potato trading requires agreement with peers (you carry traffic longer for both).
Outbound policy must be consistent across all edge routers. Inconsistent LOCAL_PREF causes traffic to exit at locations based on which router processes the packet first, leading to unpredictable routing. Use centralized policy management or automation to ensure consistency.
BGP was designed in an era of trust. Any AS could announce any prefix, and neighbors would accept it. This trust model has led to countless routing incidents—from accidental leaks to intentional hijacking. Resource Public Key Infrastructure (RPKI) addresses this vulnerability.
The Problem: Unauthorized Route Announcements
RPKI Overview:
RPKI provides cryptographic verification of route origin:
| Component | Purpose |
|---|---|
| ROA (Route Origin Authorization) | Signed statement: "AS X is authorized to announce prefix Y" |
| Trust Anchor | Root certificate (RIR: ARIN, RIPE, APNIC, etc.) |
| Validation | Compare BGP route against ROAs |
| RPKI-to-Router Protocol | Deliver validation data to routers |
RPKI Validation States:
| State | Meaning | Action |
|---|---|---|
| Valid | Route matches ROA | Accept |
| Invalid | Route conflicts with ROA (wrong AS, too specific) | Reject or deprioritize |
| NotFound | No ROA exists for prefix | Accept (conservative) or deprioritize |
Deploying RPKI Validation:
! Configure RPKI server connection
router bgp 65001
rpki server 10.0.0.100
transport tcp port 8323
refresh-interval 300
! Apply RPKI-based policy
route-map EBGP-IN permit 10
match rpki valid
set local-preference 200
route-map EBGP-IN permit 20
match rpki not-found
set local-preference 100
route-map EBGP-IN deny 30
match rpki invalid
Creating ROAs:
ROAs are created through your RIR (ARIN, RIPE, APNIC, etc.):
Example ROA:
Prefix: 192.0.2.0/24
Max Length: 24
Origin AS: 65001
This ROA allows:
- AS 65001 to announce 192.0.2.0/24 ✓
This ROA BLOCKS:
- AS 65002 announcing 192.0.2.0/24 ✗ (wrong AS)
- AS 65001 announcing 192.0.2.0/25 ✗ (too specific, max is /24)
ROA creation requires careful planning. A too-restrictive maxLength can block legitimate more-specific announcements (traffic engineering). A too-permissive maxLength can allow hijacking of unused more-specifics. Always create ROAs before using the prefix, and update ROAs before changing origin AS.
Let's implement a complete BGP policy for a small ISP (AS 65001) with:
Policy Requirements:
Prefix Lists:
! Our address space
ip prefix-list OUR-SPACE permit 192.0.2.0/24
ip prefix-list OUR-SPACE permit 198.51.100.0/24
! Customer 1 space (verified against their allocation)
ip prefix-list CUSTOMER1-SPACE permit 203.0.113.0/24
ip prefix-list CUSTOMER1-SPACE permit 203.0.114.0/24
! Default route (accept from transit)
ip prefix-list DEFAULT permit 0.0.0.0/0
! Bogons to reject
ip prefix-list BOGONS deny 0.0.0.0/8 le 32
ip prefix-list BOGONS deny 10.0.0.0/8 le 32
ip prefix-list BOGONS deny 127.0.0.0/8 le 32
ip prefix-list BOGONS deny 172.16.0.0/12 le 32
ip prefix-list BOGONS deny 192.168.0.0/16 le 32
ip prefix-list BOGONS permit 0.0.0.0/0 le 24
Community Lists:
ip community-list standard CUSTOMER permit 65001:100
ip community-list standard PEER permit 65001:200
ip community-list standard TRANSIT permit 65001:300
ip community-list standard BLACKHOLE permit 65001:666
ip community-list standard NO-ADVERTISE-65003 permit 65001:4003
ip community-list standard PREPEND-65003-1X permit 65001:3103
Customer Inbound Policy:
route-map CUSTOMER1-IN deny 5
match rpki invalid
route-map CUSTOMER1-IN permit 10
match ip address prefix-list CUSTOMER1-SPACE
match rpki valid
set local-preference 250
set community 65001:100 additive
route-map CUSTOMER1-IN permit 20
match ip address prefix-list CUSTOMER1-SPACE
match rpki not-found
set local-preference 200
set community 65001:100 additive
route-map CUSTOMER1-IN deny 30
! Reject everything else
Peer Inbound Policy:
route-map PEER-IN deny 5
match ip address prefix-list BOGONS
route-map PEER-IN deny 10
match rpki invalid
route-map PEER-IN permit 20
match rpki valid
set local-preference 150
set community 65001:200 additive
route-map PEER-IN permit 30
set local-preference 100
set community 65001:200 additive
Peer Outbound Policy:
route-map PEER-OUT deny 5
match community NO-ADVERTISE-65003
! Customer requested no announcement to this peer
route-map PEER-OUT permit 10
match community CUSTOMER
match community PREPEND-65003-1X
set as-path prepend 65001
route-map PEER-OUT permit 20
match ip address prefix-list OUR-SPACE
! Announce our space
route-map PEER-OUT permit 30
match community CUSTOMER
! Announce customer space (default)
route-map PEER-OUT deny 40
! Don't announce transit or peer routes to peers
Transit Outbound Policy:
route-map TRANSIT-OUT permit 10
match ip address prefix-list OUR-SPACE
route-map TRANSIT-OUT permit 20
match community CUSTOMER
route-map TRANSIT-OUT deny 30
! Don't advertise transit/peer routes back to transit
Neighbor Configuration:
router bgp 65001
! Customer
neighbor 10.0.1.1 remote-as 65100
neighbor 10.0.1.1 route-map CUSTOMER1-IN in
neighbor 10.0.1.1 route-map CUSTOMER-OUT out
neighbor 10.0.1.1 maximum-prefix 10 80 restart 15
! Peer
neighbor 10.0.2.1 remote-as 65003
neighbor 10.0.2.1 route-map PEER-IN in
neighbor 10.0.2.1 route-map PEER-OUT out
! Transit
neighbor 10.0.3.1 remote-as 701
neighbor 10.0.3.1 route-map TRANSIT-IN in
neighbor 10.0.3.1 route-map TRANSIT-OUT out
Always test policy changes in a lab or using route-map simulation features before production deployment. Verify expected routes are permitted and unexpected routes are denied. Check that LOCAL_PREF and other attributes are set correctly using 'show ip bgp <prefix>' output.
BGP policy routing translates business relationships and traffic engineering requirements into routing behavior. Mastering these mechanisms is essential for operating production networks.
What's Next:
With policy routing mastered, the final page explores BGP's role in the Internet backbone—how the protocol enables global connectivity through Internet Exchange Points, tier-1 networks, and the complex mesh of peering and transit relationships that form the modern Internet.
You now understand BGP policy routing comprehensively—from basic communities and route maps through Route Reflectors and Confederations to sophisticated traffic engineering and RPKI security. This knowledge enables you to design and implement routing policies for production networks.