When shared peer-group policy leaks into IX sessions

Introduction to Route-Maps and Peer-Groups

A route‑map is an ordered list of permit/deny statements; each statement contains match and set clauses. When a BGP update is evaluated, the router processes statements sequentially—the first match determines the action (permit/deny) and applies any set attributes. Route‑maps are used for filtering, attribute manipulation, and policy injection, and they are applied after the BGP decision process but before RIB/FIB installation.

A BGP peer‑group groups neighbors that share identical configuration (remote‑AS, timers, update‑source, route‑map, etc.). Changes to the peer‑group propagate to all members, reducing repetitive CLI and CPU overhead. Per‑neighbor settings (e.g., a neighbor‑specific route‑map) override the peer‑group value for that neighbor only. Understanding this inheritance/override model is essential when a single route‑map must serve heterogeneous peers such as transit and IX routers.

Configuring Route‑Maps for Shared Peer‑Groups

Attaching a Route‑Map to a Peer‑Group

In Cisco IOS/IOS‑XR the command is:

neighbor <peer-group-name> route-map <map-name> {in|out}

The same command under an address‑family context limits the map to that family. When attached to a peer‑group, the route‑map is evaluated for each inheriting neighbor unless the neighbor has its own conflicting neighbor <ip> route-map … statement, which takes precedence.

Example (IOS)

router bgp 65000
  neighbor TRANSIT-IX peer-group
  neighbor TRANSIT-IX remote-as 65001
  neighbor TRANSIT-IX route-map RM-TRANSIT-IX out
!
address-family ipv4 unicast
  neighbor TRANSIT-IX activate
exit-address-family

All members of TRANSIT-IX receive the outbound route‑map RM-TRANSIT-IX unless overridden.

Route‑Map Statement Structure

Each sequence contains match clauses (e.g., match ip address prefix-list, match community, match as-path) and set clauses (e.g., set local-preference, set weight, set community, set origin). The continue keyword allows jumping to another sequence after a match, enabling modular policies.

Example

route-map RM-TRANSIT-IX permit 10
  match ip address prefix-list PFX-TRANSIT
  set local-preference 200
!
route-map RM-TRANSIT-IX permit 20
  match ip address prefix-list PFX-IX
  set community 65000:900 additive
!
route-map RM-TRANSIT-IX deny 30

Sequence 10 raises local‑preference for transit prefixes; sequence 20 adds a community for IX prefixes; sequence 30 implicitly denies everything else.

Boundary Crossing Between Transit and IX Peers

Transit Peers

Provide full or partial Internet routing. Policies typically:

Accept most inbound prefixes (basic sanity filters only).
Prefer locally originated routes via high local‑preference or weight.
Strip or modify IX‑only communities.

IX Peers

Members of a shared LAN; they usually:

Exchange only explicitly permitted prefixes (customer/peer routes).
Avoid full transit tables to limit forwarding‑to reduce forwarding‑plane load and prevent accidental transit leakage.
Require specific communities (e.g., NO_EXPORT, LOCAL_AS) to contain propagation.

Route‑Map Configuration for a Shared Peer‑Group

When a single route‑map is attached to a peer‑group containing both transit and IX members, the map must differentiate the two types. If a statement intended for transit (e.g., set local-preference 200) lacks a proper match, it will also apply to IX peers, causing them to prefer routes that should be deprioritized or to advertise routes they should not.

Common mistake: using a single match ip address prefix-list that matches both transit and IX prefixes, or omitting a match clause entirely, turning the map into a blanket pass‑through.

Correct approach: create distinct prefix‑lists (or community‑lists) for transit‑only and IX‑only sets, then use separate sequences in the route‑map to apply the appropriate actions.

Troubleshooting Route‑Map Issues

Identifying Configuration Mistakes

Symptoms include unexpected transit prefixes in an IX peer’s routing table, missing community tags on locally‑originated routes, or incorrect attribute values on transit peers. Verify the route‑map application and its match criteria.

CLI Commands for Verification

Show commands

show route-map [map-name]               # view sequences, match/set clauses, hit counters
show ip bgp neighbors <addr> received-routes   # pre‑policy routes
show ip bgp neighbors <addr> routes          # post‑policy routes
show ip bgp peer-group [group-name]          # list members and overrides
show ip bgp                                 # inspect BGP table for unexpected attributes

A discrepancy between received‑routes and post‑policy route counts indicates filtering or attribute changes.

Debug commands (use sparingly)

debug ip bgp updates                      # see raw UPDATE messages
debug ip bgp peer-group <group-name>      # limit debug to the peer‑group
debug ip bgp dampening                    # optional, shows attribute‑change effects

Filter by neighbor or prefix when possible to reduce CPU impact.

Code Examples

Transit‑Only Peer‑Group

ip prefix-list PFX-TRANSIT seq 5 permit 0.0.0.0/0 le 32
!
route-map RM-TRANSIT-OUT permit 10
  match ip address prefix-list PFX-TRANSIT
  set local-preference 200
  set community 65000:100 additive
!
route-map RM-TRANSIT-OUT permit 20
  description "Drop everything else"
!
router bgp 65000
  neighbor TRANSIT peer-group
  neighbor TRANSIT remote-as 65001
  neighbor TRANSIT route-map RM-TRANSIT-OUT out
!
address-family ipv4 unicast
  neighbor TRANSIT activate
exit-address-family

IX‑Only Peer‑Group

ip prefix-list PFX-IX seq 5 permit 203.0.113.0/24 le 32
ip prefix-list PFX-IX seq 10 permit 198.51.100.0/24 le 32
!
route-map RM-IX-OUT permit 10
  match ip address prefix-list PFX-IX
  set community 65000:900 additive
!
route-map RM-IX-OUT permit 20
  description "Drop non‑IX prefixes"
!
router bgp 65000
  neighbor IX peer-group
  neighbor IX remote-as 65002
  neighbor IX route-map RM-IX-OUT out
!
address-family ipv4 unicast
  neighbor IX activate
exit-address-family

Problematic Shared Peer‑Group (Illustrates the Mistake)

ip prefix-list PFX-ALL seq 5 permit 0.0.0.0/0 le 32
!
route-map RM-SHARED permit 10
  match ip address prefix-list PFX-ALL
  set local-preference 200
!
router bgp 65000
  neighbor SHARED peer-group
  neighbor SHARED remote-as 65003
  neighbor SHARED route-map RM-SHARED out
!
address-family ipv4 unicast
  neighbor SHARED activate
  neighbor 203.0.113.1 peer-group SHARED   ! IX peer
  neighbor 198.51.100.1 peer-group SHARED   ! Transit peer
exit-address-family

Because RM-SHARED matches all prefixes and sets a high local‑preference, the IX peer (203.0.113.1) will prefer routes that should be deprioritized, potentially advertising them to other IX members and causing unintended transit leakage.

Design Patterns for Limiting Blast Radius

Use Precise Prefix‑Lists

Ensure each route‑map sequence’s match criteria exactly matches the set of prefixes that should receive the associated set actions. Separate transit‑only and IX‑only prefix‑lists prevent overlap, allowing a single route‑map to contain distinct, non‑conflicting sequences.

Implement Route‑Map Statements Cautiously

Avoid empty match clauses – a route‑map with no match acts as permit‑all, applying set actions to every route.
Add explicit deny sequences – place a deny at the end (or after specific sequences) to drop any route that does not match a defined intent.
Leverage continue – modularize common actions (e.g., setting a base community) and then continue to transit‑ or IX‑specific sequences, reducing duplication and contradictory sets.
Apply neighbor‑specific overrides – if a small subset needs different treatment, configure a neighbor‑level route-map … in|out that overrides the peer‑group map for that neighbor only.

Peer‑Group Best Practices

Homogenize peers – only group neighbors that truly share identical policy requirements. If heterogeneity is unavoidable, ensure the attached route‑map is sufficiently granular.
Document each sequence – use description to clarify intent for future operators.
Validate with hit counters – after changes, confirm that expected sequences increment and no unintended sequences are hit.
Test before production – use a shutdown neighbor or a test session to verify behavior.

Scaling Limitations of Route‑Maps and Peer‑Groups

Understanding the Limits

Peer‑groups reduce the number of separate neighbor data structures, but route‑map evaluation is still performed per neighbor. Each inbound or outbound update walks the route‑map’s sequences until a match is found. In large‑scale environments (hundreds of peers, tens of thousands of prefixes), a complex route‑map with many sequences can become a CPU hotspot, especially if match clauses rely on expensive operations like match as-path with long regexes.

Optimizing Route‑Map Configuration

Minimize sequences – combine similar actions using continue or broaden match criteria where safe.
Prefer prefix‑list matches – prefix‑list lookups are O(log n) via a trie; AS‑path or community regex matching can be O(m) per update.
Use community‑based policies – tag routes at the source with a community and match on that community; community matches are inexpensive.
Leverage BGP update groups – modern IOS/XR automatically forms update groups for peers with identical outbound policy; peers sharing the same outbound route‑map belong to the same update group, reducing redundant processing.
Consider peer‑templates (IOS‑XR) or inheritance‑based peer‑groups – templates allow fine‑grained policy without duplicating configuration, and the system can compute a single effective policy per neighbor.

Advanced Features to Mitigate Scaling Issues

BGP Conditional Advertisement (advertise-map) – suppress or advertise routes based on the existence of another prefix, reducing the need for complex route‑maps.
BGP Unnumbered Peer‑Groups – in data‑center fabrics, unnumbered interfaces with a single peer‑group limit policy evaluations.
Flowspec Route‑Maps – isolate flowspec policy in a dedicated route‑map to avoid mixing with unicast policy.
Offload to Route‑Servers or Controllers – delegate heavy policy computation to external systems when feasible.

End of document.