Short answer: BGP filtering is a set of explicit import and export policies that limits which routes a neighbor can send you and which routes you advertise. Use prefix filters for exact route authorization, AS-path filters for path-pattern checks, and maximum-prefix limits as a safety guard—not as a substitute for either filter.[1][2]
Why BGP filtering matters
A BGP session can be Established while exchanging routes you never intended to accept or announce. A mistaken export can leak transit routes; a mistaken import can install an unauthorized or overly specific route. RFC 7454 recommends filtering prefixes, AS paths and excessive route counts as operational safeguards.[1]
For every eBGP address family, define both import and export policy. RFC 8212 specifies default-reject behavior when explicit policies are absent; implementations and deployed configurations vary, so verify your platform's actual behavior rather than relying on assumptions.[2]
Three controls, three different jobs
1. Prefix lists: authorize destinations
A prefix-list entry matches a network and, optionally, an allowed prefix-length range. For a customer that owns 198.51.100.0/24, an exact /24 permit is narrower than permitting every more-specific prefix. For an ISP customer, maintain an explicit allowed-prefix list (often generated from an IRR/RPKI-aware source and reviewed) and reject the rest.
2. AS-path filters: inspect the path pattern
AS-path regular expressions can match routes originated by a customer, routes containing your own ASN, or paths that violate a peer's expected relationship. They are useful as a second check, but regex syntax and anchoring vary between platforms. Do not treat an AS-path match as proof that the origin is authorized.
3. Maximum-prefix: bound route volume
A maximum-prefix threshold limits the number of prefixes accepted from a neighbor and can warn or tear down a session, depending on configuration. It can contain a sudden route explosion or a full-table leak, but it does not identify which individual prefixes are legitimate. Choose thresholds based on the service contract and observed route count, allow measured headroom, and monitor before enabling session shutdown.[1][3]
Traffic-engineering impact and limits
- Outbound traffic: import filters decide which paths are eligible for your routing table. Combine them with LOCAL_PREF and other policy to choose among accepted routes.
- Inbound influence: export filters choose which of your routes are advertised to each provider or peer. Selective advertisement can influence reachability, but remote networks choose their own paths.
- Cannot control: filtering cannot force another AS's local preference, guarantee symmetric paths, or replace authorization/route-origin validation. Filtering is a control-plane policy, not a packet firewall.
Example: a dual-ISP edge
Illustrative Cisco IOS/IOS XE-style configuration. The documentation-prefix addresses and ASNs are placeholders; replace them with your authorized production values. Syntax and address-family attachment vary by release.
ip prefix-list CUSTOMER-EXPORT seq 10 permit 198.51.100.0/24
ip prefix-list ISP1-IN seq 10 permit 0.0.0.0/0
ip prefix-list ISP1-IN seq 100 deny 0.0.0.0/0 le 32
!
route-map ISP1-IN permit 10
match ip address prefix-list ISP1-IN
route-map ISP1-OUT permit 10
match ip address prefix-list CUSTOMER-EXPORT
!
router bgp 65010
neighbor 192.0.2.1 remote-as 64496
neighbor 192.0.2.1 maximum-prefix 10 80 restart 5
address-family ipv4
neighbor 192.0.2.1 route-map ISP1-IN in
neighbor 192.0.2.1 route-map ISP1-OUT out
neighbor 192.0.2.1 activate
This example accepts only a default route from ISP1 and advertises only the organization's /24. The illustrative maximum of 10 is deliberately small for a default-only service; set an appropriate value for the provider's actual feed and platform semantics. If accepting full routes, use a maintained prefix policy rather than copying this default-only filter.
AS-path policy example
To permit a directly connected customer-originated route only when the path consists of that customer's ASN (Cisco-style regular-expression form):
ip as-path access-list 10 permit ^64497$
route-map CUSTOMER-IN permit 10
match ip address prefix-list CUSTOMER-PREFIXES
match as-path 10
route-map CUSTOMER-IN deny 100
Use the AS-path condition only when the expected topology really is a single-origin customer path. If the customer uses downstream ASNs or prepends, define the accepted pattern deliberately. Prefix authorization remains essential.
Walkthrough: what happens to an update
- The neighbor advertises a prefix and attributes.
- Import policy evaluates the prefix, path and any other configured conditions.
- Disallowed routes are rejected before they become eligible for best-path selection; permitted routes may then compete under LOCAL_PREF, AS_PATH and the remaining decision process.
- Export policy independently decides whether a selected route may be sent to each neighbor.
- The maximum-prefix counter tracks route quantity and enforces its configured threshold; it does not validate route content.
Verification commands
show ip prefix-list
show ip as-path-access-list
show route-map
show ip bgp neighbors 192.0.2.1 received-routes
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp summary
show logging | include BGP|PREFIXExpected logic: the accepted-route count matches the designed feed; the received-routes view contains only authorized input; advertised-routes contains only your permitted announcements; and the neighbor remains Established without maximum-prefix warnings. Some platforms require inbound soft-reconfiguration or route-refresh support to display received routes. Junos equivalents include show route receive-protocol bgp <peer>, show route advertising-protocol bgp <peer>, and policy inspection commands.[4]
Troubleshooting checklist
- Confirm policy is attached in the correct direction and address family.
- Check for implicit deny at the end of a prefix-list, route map or policy chain.
- Validate prefix length operators: an exact route and a permitted range are not equivalent.
- Check whether the peer is sending a default-only, partial or full table.
- Inspect route-refresh/soft-reconfiguration requirements before trusting received-route output.
- Review maximum-prefix warning, shutdown and restart behavior; avoid automatic teardown with an untested threshold.
- Test both inbound acceptance and outbound advertisement after policy changes.
- Keep filters synchronized with authorized prefixes and review changes before deployment.
Where this fits in modern networks
At a data-center or EVPN/VXLAN border, apply import/export policy to the relevant BGP address families and VRFs. A route-target policy or EVPN route-type filter solves a different problem from an IPv4 unicast prefix list; validate each address family independently. In Cisco ACI-like fabrics, route control is mediated by fabric policy constructs, so map the intended prefix authorization to the platform's route-control policy rather than pasting a classic edge configuration blindly. For cloud and dual-ISP edges, explicitly allow only the expected cloud/on-prem prefixes and bound route counts to the provider's documented feed.
Interview answer
“I use prefix filters to authorize exact routes, AS-path filters as a supplementary topology check, and maximum-prefix as a route-volume guard. I apply explicit import and export policies per eBGP address family, verify both received and advertised routes, and remember that max-prefix is not a content filter.”
Post a Comment