Skip to content
Log in Sign up My account

1.11.e Filtering and Path Manipulation

Blueprint 1.11: Troubleshoot BGP (Interior and External)

  • 1.11.e Policies (inbound/outbound filtering, path manipulation)

Filtering: prefix-lists, distribute-lists, AS-path filter-lists and route-maps applied per neighbor in each direction. Path manipulation: weight, local preference, AS-path prepend and MED. Route-map logic in general is objective 1.2 (see Routing Control); this page covers how BGP uses it.

Where policy attaches

Every BGP policy is applied per neighbor (or peer group), per address family, in one direction. Inbound policy acts on updates received from that neighbor before they enter the BGP table. Outbound policy acts on updates sent to that neighbor.

graph LR
  P1["Neighbor A"] -->|"updates"| IN["Inbound:<br/>prefix-list or distribute-list<br/>filter-list<br/>route-map"]
  IN --> T["BGP table<br/>best path"]
  T --> OUT["Outbound:<br/>prefix-list or distribute-list<br/>filter-list<br/>route-map"]
  OUT -->|"updates"| P2["Neighbor B"]

A route must be permitted by every filter applied in that direction. IOS does not allow a prefix-list and a distribute-list on the same neighbor in the same direction; a filter-list and a route-map can be combined with either. See also diagram N20.

Tool Matches on Command
Prefix-list Prefix and length neighbor x prefix-list NAME in\|out
Distribute-list Standard or extended ACL neighbor x distribute-list 10 in\|out
Filter-list AS path, with an ip as-path access-list regex neighbor x filter-list 1 in\|out
Route-map Any combination of the above, plus communities, next hop, metric; can also set attributes neighbor x route-map NAME in\|out

Exam trap

Policy changes do not apply to routes already exchanged. After changing a prefix-list, AS-path list or route-map, run clear ip bgp <neighbor> soft in or soft out (see route refresh). An exhibit where the configuration is correct but the table still shows the old result is usually missing that step.

Prefix-lists

ip prefix-list ISPB-IN seq 5 permit 203.0.113.0/24
ip prefix-list ISPB-IN seq 10 permit 0.0.0.0/0
!
ip prefix-list NO-SMALL seq 5 permit 0.0.0.0/0 le 24      ! any prefix of length 0 to 24
ip prefix-list CUST seq 5 permit 192.0.2.0/24 ge 25 le 26 ! subnets of 192.0.2.0/24 with length 25 or 26
Entry Matches
permit 10.0.0.0/8 Exactly 10.0.0.0/8, nothing else
permit 10.0.0.0/8 le 32 10.0.0.0/8 and every subnet inside it
permit 10.0.0.0/8 ge 24 Subnets of 10.0.0.0/8 with length 24 to 32
permit 10.0.0.0/8 ge 16 le 24 Subnets of 10.0.0.0/8 with length 16 to 24
permit 0.0.0.0/0 Only the default route
permit 0.0.0.0/0 le 32 Everything

Rules: the network part is compared for the first len bits; ge must be greater than len, and le must be greater than or equal to ge. Entries are checked in sequence order, first match wins, and there is an implicit deny at the end. A prefix-list that exists but has no entry for a prefix denies it.

AS-path filter-lists and regular expressions

ip as-path access-list 1 permit ^$
router bgp 65010
 address-family ipv4
  neighbor 10.2.4.2 filter-list 1 out
Regex Matches AS paths that... Typical use
^$ are empty: routes originated in the local AS Outbound to ISPs: advertise only your own routes, never be transit
^65001$ contain exactly AS 65001 Routes originated by a directly connected neighbor AS
^65001_ start with 65001 Routes learned through neighbor AS 65001
_65001$ end with 65001 Routes originated by AS 65001, wherever they came from
_65001_ contain 65001 anywhere Routes that passed through AS 65001
.* anything Permit all, usually the last line of a deny list

_ matches a space, comma, start or end of string, so it stops _6500_ from matching inside 65001. The AS path is stored nearest AS first: a route originated by AS 65002 and passed through 65001 has the path 65001 65002. Test regexes against the live table before applying them:

R2# show ip bgp regexp ^65001_
     Network          Next Hop            Metric LocPrf Weight Path
 *>  198.51.100.0     10.2.4.2                 0             0 65001 i
 *>  203.0.113.0      10.2.4.2                 0             0 65001 i
R2# show ip bgp filter-list 1
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 192.0.2.0        10.255.255.1             0    100      0 i

Exam trap

The local AS is not in the AS path of a route inside the AS. It is prepended only when the route is sent to an eBGP peer, after outbound policy. So ^$ outbound matches your own routes, and a filter that matches ^65010$ (your own AS) outbound matches nothing. Also check where the filter sits: ^$ inbound from an ISP would drop everything, because every route from an ISP has a non-empty path.

Route-maps in BGP

ip prefix-list INTERNET seq 5 permit 203.0.113.0/24
!
route-map ISPA-IN permit 10
 match ip address prefix-list INTERNET
 set local-preference 200
route-map ISPA-IN permit 20
!
router bgp 65010
 address-family ipv4
  neighbor 10.2.4.2 route-map ISPA-IN in

How BGP evaluates it:

  1. Sequences are checked in order. The first sequence whose match clauses all match is used.
  2. A permit sequence accepts the route and applies its set clauses. A deny sequence drops the route.
  3. A sequence with no match clause matches every route. Sequence 20 above is the "permit everything else, unchanged" line.
  4. A route that matches no sequence is denied (implicit deny at the end).
  5. In a match ip address prefix-list clause, the prefix-list only selects routes. If the prefix-list denies a prefix, that sequence simply does not match it; the route moves on to the next sequence.
  6. Several match lines of different types in one sequence must all match (AND). Several values on one match line are alternatives (OR).

Exam trap

The most common BGP policy fault is a route-map written to change one prefix that forgets the final permit sequence. Every other prefix hits the implicit deny and disappears. In show ip bgp summary the neighbor's prefix count drops, and received-routes (with soft reconfiguration) still shows everything the neighbor sent.

Path manipulation

The direction rule is the key to every question: policy applied to routes you receive changes how your traffic leaves; policy applied to routes you send changes how traffic comes back to you.

Goal Attribute Applied on Direction Scope
This router prefers one exit Weight That router Inbound One router
The whole AS prefers one exit Local preference The edge router facing the preferred exit (or both edges) Inbound from eBGP Whole AS
Other ASes prefer one entry into your AS AS-path prepend The edge router facing the less preferred entry Outbound to eBGP Everyone who sees the path
A neighbor AS prefers one of several links to you MED Each edge router toward that same neighbor AS Outbound to eBGP That neighbor AS only 
router bgp 65010
 address-family ipv4
  neighbor 10.3.5.2 weight 200          ! every route from this neighbor
! or selectively
route-map R5-IN permit 10
 match ip address prefix-list INTERNET
 set weight 200
route-map R5-IN permit 20

route-map ISPA-IN permit 10
 set local-preference 200
router bgp 65010
 address-family ipv4
  neighbor 10.2.4.2 route-map ISPA-IN in

route-map ISPB-OUT permit 10
 set as-path prepend 65010 65010
router bgp 65010
 address-family ipv4
  neighbor 10.3.5.2 route-map ISPB-OUT out

route-map TO-ISPA-LINK2 permit 10
 set metric 100
router bgp 65010
 address-family ipv4
  neighbor 10.2.6.2 route-map TO-ISPA-LINK2 out

Rules that create wrong answers:

  • Weight set in an outbound route-map has no effect: weight is never sent.
  • Local preference set outbound toward an eBGP peer has no effect: it is not sent across AS boundaries. Set outbound toward an iBGP peer, it does work.
  • Prepend your own AS. Prepending another AS number, especially the neighbor's, makes the neighbor drop the route as a loop (it sees its own AS in the path). IOS also prepends to the path as sent, so prepending twice on top of the normal one gives the neighbor a path of three copies of your AS.
  • MED only helps when you have several links to the same neighbor AS; a different AS will not compare it by default.
  • Communities are not sent by default on IOS. A policy that depends on the neighbor seeing a community needs neighbor x send-community.
graph LR
  subgraph AS65010["AS 65010"]
    R2["R2: LP 200 inbound<br/>from ISP-A"]
    R3["R3: prepend 65010 65010<br/>outbound to ISP-B"]
  end
  R2 --- A["ISP-A AS 65001<br/>preferred both ways"]
  R3 --- B["ISP-B AS 65002<br/>backup"]

Diagnostic output for policy faults

show ip bgp neighbors lists what is attached, and its prefix-activity section counts what policy dropped.

R2# show ip bgp neighbors 10.2.4.2 | include policy|map|filter|prefix
  Inbound path policy configured
  Outbound path policy configured
  Route map for incoming advertisements is ISPA-IN
  Outgoing update AS path filter list is 1
Command Answers
show ip bgp neighbors x routes What survived inbound policy
show ip bgp neighbors x received-routes What was sent before inbound policy (needs soft-reconfiguration inbound)
show ip bgp neighbors x advertised-routes What passed outbound filtering toward the neighbor
show ip bgp prefix-list NAME Which BGP table entries a prefix-list matches
show ip bgp route-map NAME Which entries a route-map permits, and with what attributes
show ip bgp regexp <regex> / show ip bgp filter-list N Which entries an AS-path expression matches
debug ip bgp x updates Each update in or out, and why one was denied

A route the neighbor rejects is often invisible on your side. Check the neighbor if you can: its debug or its denied-prefix counters will name the reason, for example an AS-path loop.

R5# debug ip bgp 10.3.5.1 updates
BGP(0): 10.3.5.1 rcv UPDATE about 192.0.2.0/24 -- DENIED due to: AS-PATH contains our own AS;

Lab: apply the policy and fix tickets 9 and 10

Topology: the module topology with the baseline from the Sessions lab.

Policy to build:

Requirement Mechanism Where
All outbound traffic to 203.0.113.0/24 uses ISP-A Local preference 200 on 203.0.113.0/24 from ISP-A, all other ISP-A routes unchanged R2, inbound from R4
Inbound traffic to 192.0.2.0/24 prefers ISP-A Prepend 65010 twice R3, outbound to R5
AS 65010 is never transit Advertise only ^$ R2 and R3, outbound to the ISPs
Accept only 203.0.113.0/24 and a default route from ISP-B Prefix-list R3, inbound from R5

  1. Configure R2:

    ip prefix-list INTERNET seq 5 permit 203.0.113.0/24
ip as-path access-list 1 permit ^$
route-map ISPA-IN permit 10
 match ip address prefix-list INTERNET
 set local-preference 200
route-map ISPA-IN permit 20
router bgp 65010
 address-family ipv4
  neighbor 10.2.4.2 soft-reconfiguration inbound
  neighbor 10.2.4.2 route-map ISPA-IN in
  neighbor 10.2.4.2 filter-list 1 out

  2. Configure R3:

    ip prefix-list ISPB-IN seq 5 permit 203.0.113.0/24
ip prefix-list ISPB-IN seq 10 permit 0.0.0.0/0
ip as-path access-list 1 permit ^$
route-map ISPB-OUT permit 10
 set as-path prepend 65010 65010
router bgp 65010
 address-family ipv4
  neighbor 10.3.5.2 prefix-list ISPB-IN in
  neighbor 10.3.5.2 filter-list 1 out
  neighbor 10.3.5.2 route-map ISPB-OUT out

  3. Run clear ip bgp * soft on R2 and R3, then verify:

    R3# show ip bgp 203.0.113.0 | include localpref|from
    10.255.255.2 (metric 3) from 10.255.255.1 (10.255.255.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
    10.3.5.2 from 10.3.5.2 (10.255.255.5)
      Origin IGP, metric 0, localpref 100, valid, external
R5# show ip bgp 192.0.2.0 | include 65010
  65010 65010 65010
R5# show ip bgp | include 198.51.100
R5#

    R3 now prefers the iBGP path through R2 because local preference 200 beats its own eBGP path at step 2, before eBGP over iBGP is ever considered. R5 sees the prepended path. R5 no longer receives ISP-A's customer network 198.51.100.0/24 from AS 65010, because R3 only advertises routes with an empty AS path, so AS 65010 is not transit.

  4. Save this as the policy baseline (copy run flash:policy.cfg) and inject each ticket from it.

Fault injection, ticket 9 

! R2
no route-map ISPA-IN permit 20
Then clear ip bgp 10.2.4.2 soft in on R2.

Fault injection, ticket 10 

! R3
route-map ISPB-OUT permit 10
 no set as-path prepend 65010 65010
 set as-path prepend 65002 65002
Then clear ip bgp 10.3.5.2 soft out on R3.

Tickets

Ticket 9: "Nobody can reach 198.51.100.0/24 since this morning's policy change. Internet traffic is fine and still uses ISP-A." Ticket 10: "ISP-B says our prefix 192.0.2.0/24 is missing from their table. They want it back, with ISP-A still preferred for inbound traffic. Do not change anything on R5."

Ticket 9: root cause and fix

show ip bgp summary on R2 shows R4's prefix count down from 2 to 1. Because soft reconfiguration is on, show ip bgp neighbors 10.2.4.2 received-routes still lists 198.51.100.0/24, while show ip bgp neighbors 10.2.4.2 routes does not, so R2's inbound policy is dropping it. show route-map ISPA-IN shows only sequence 10, which matches the INTERNET prefix-list (203.0.113.0/24 only). 198.51.100.0/24 matches no sequence and hits the implicit deny.

Fix on R2: restore the catch-all sequence and refresh.

route-map ISPA-IN permit 20
!
R2# clear ip bgp 10.2.4.2 soft in

Do not add 198.51.100.0/24 to the INTERNET prefix-list: that would also give it local preference 200, which is not in the policy.

Ticket 10: root cause and fix

On R3, show ip bgp neighbors 10.3.5.2 advertised-routes still lists 192.0.2.0/24, so R3 is sending it. On R5 the prefix is absent, and debug ip bgp 10.3.5.1 updates shows DENIED due to: AS-PATH contains our own AS. show route-map ISPB-OUT on R3 shows set as-path prepend 65002 65002: the prepend uses ISP-B's AS number, so R5 sees its own AS in the path and discards the update by eBGP loop prevention.

Fix on R3:

route-map ISPB-OUT permit 10
 no set as-path prepend 65002 65002
 set as-path prepend 65010 65010
!
R3# clear ip bgp 10.3.5.2 soft out

Verify on R5 that 192.0.2.0/24 is back with the path 65010 65010 65010.

Quick check

Which prefix-list entry matches every subnet of 172.16.0.0/16 with a length of /24 or longer, but not 172.16.0.0/16 itself?

permit 172.16.0.0/16 ge 24. Without le, ge 24 means lengths 24 to 32.

You set local-preference 300 in a route-map applied outbound to an eBGP neighbor. What changes?

Nothing. Local preference is not sent to eBGP peers. Apply it inbound on routes received from that neighbor to influence your own outbound traffic.

What does ip as-path access-list 5 permit _65001$ match?

Routes originated by AS 65001, whichever AS they were learned through.

References

  • IP Routing: BGP Configuration Guide, Cisco IOS XE: "Connecting to a Service Provider Using External BGP" (filtering and path manipulation chapters) (search on cisco.com)
  • "Using Regular Expressions in BGP" and "BGP Case Studies", Cisco tech notes (search on cisco.com)
  • RFC 4271 (BGP-4), RFC 1997 (communities), RFC 7454 (BGP operations and security, filtering recommendations), at rfc-editor.org
  • Cisco Live On-Demand Library: search "BGP policy" or "Internet edge BGP"