Skip to content

BGP Route Filtering

Route Filtering in BGP Using Prefix Lists and Route Maps with FRR

In BGP, simply establishing a peering session and exchanging all routes is rarely enough. Network administrators need precise control over which routes are advertised to neighbors and which routes are accepted into the routing table.

This process—known as Route Filtering—prevents unintended transit traffic, protects against route leaks, and enforces routing policies. In FRRouting (FRR), route filtering is primarily accomplished using Prefix Lists and Route Maps.

Understanding the Tools

Prefix Lists

A Prefix List is used to match IP addresses and subnet masks. Unlike standard Access Control Lists (ACLs), prefix lists allow you to specify exact network prefixes alongside subnet mask length ranges using ge (greater than or equal to) and le (less than or equal to).

Route Maps

A Route Map acts like an if-then-else policy engine. It uses match clauses to evaluate criteria (such as prefix lists or AS-Paths) and set clauses to modify route attributes (such as local-preference, metric, or community).

Scenario Overview

We will configure Router-A (ASN 65001) to filter and manipulate routes exchanged with Router-B (ASN 65002):

  • Inbound Filter: Accept only 2.2.2.0/24 and its subnets up to /28 from Router-B; deny all other incoming prefixes.
  • Outbound Manipulation: Advertise 1.1.0.0/16 to Router-B, but modify its Local Preference or BGP MED to influence path selection.

Step 1: Configure Prefix Lists

Log in to FRR's vtysh on Router-A:

sudo vtysh
Router-A# configure terminal

Define an Inbound Prefix List

Allow 2.2.2.0/24 and any subnets with mask lengths between /24 and /28:

Router-A(config)# ip prefix-list ALLOW-ROUTER-B permit 2.2.2.0/24 ge 24 le 28
Router-A(config)# ip prefix-list ALLOW-ROUTER-B deny 0.0.0.0/0 le 32

Define an Outbound Prefix List

Allow only specific internal subnets to be advertised:

Router-A(config)# ip prefix-list MY-NETWORKS permit 1.1.0.0/16 ge 16 le 24

Step 2: Build Route Maps

Next, tie the prefix lists into route maps to define the policy action.

Inbound Route Map

Permit routes matching the inbound prefix list:

Router-A(config)# route-map MAP-IN-ROUTER-B permit 10
Router-A(config-route-map)# match ip address prefix-list ALLOW-ROUTER-B
Router-A(config-route-map)# exit

Outbound Route Map

Match local networks and set a custom BGP attribute (e.g., setting MED to 100):

Router-A(config)# route-map MAP-OUT-ROUTER-B permit 10
Router-A(config-route-map)# match ip address prefix-list MY-NETWORKS
Router-A(config-route-map)# set metric 100
Router-A(config-route-map)# exit

Step 3: Apply Route Maps to the BGP Neighbor

Apply the route maps to the BGP neighbor session under the appropriate address family:

Router-A(config)# router bgp 65001
Router-A(config-router)# address-family ipv4 unicast
Router-A(config-router-af)# neighbor 10.0.0.2 route-map MAP-IN-ROUTER-B in
Router-A(config-router-af)# neighbor 10.0.0.2 route-map MAP-OUT-ROUTER-B out
Router-A(config-router-af)# exit
Router-A(config-router)# exit
Router-A(config)# exit
Router-A# write memory

Step 4: Reset and Verify BGP Policies

BGP policies do not always apply retroactively to already received routes without clearing the session or triggering a soft reset.

1. Perform a Soft Reset

Trigger a soft clear to apply the new policy without dropping the TCP session:

Router-A# clear ip bgp 10.0.0.2 soft

2. Verify Filtered Routes

Check routes received from the neighbor to confirm that only permitted prefixes appear:

Router-A# show ip bgp neighbors 10.0.0.2 received-routes

3. Verify Advertised Routes

Confirm which routes Router-A is sending to Router-B:

Router-A# show ip bgp neighbors 10.0.0.2 advertised-routes

4. Check Detailed Route Information

Inspect attributes applied by the route map:

Router-A# show ip bgp 1.1.0.0/16

Best Practices for BGP Route Filtering

  1. Explicit Deny at the End: Always end prefix lists and route maps with an implicit or explicit deny rule to block unwanted traffic.
  2. Use Soft Reconfiguration: Use clear ip bgp <ip> soft during maintenance windows to test policies without disrupting connectivity.
  3. Filter Out Private Subnets: Ensure standard bogon filters (RFC 1918, RFC 6598) are enforced on eBGP edge peers to prevent bad routes from leaking to public peers.

Understanding ge and le in BGP Prefix Lists

When creating prefix lists in FRRouting (FRR) or standard network operating systems, matching just the network address and subnet length isn't always enough. The ge (greater than or equal to) and le (less than or equal to) operators allow you to define a range of prefix lengths (subnet masks) to match within a specific IP network block.

How do they work ?

  • ge <length>: Specifies the minimum allowed prefix mask length.
  • le <length>: Specifies the maximum allowed prefix mask length
ip prefix-list <NAME> [permit|deny] <NETWORK>/<BASE-MASK> ge <MIN-MASK> le <MAX-MASK>

Quick Rule of Thumb

The mask sizes must strictly follow this logical order:

\[\text{BASE-MASK} \le \text{MIN-MASK (ge)} \le \text{MAX-MASK (le)} \le 32 \]

Breakdown of Practical Examples

  • Exact Match (10.0.0.0/16) Without ge or le specified, the rule defaults to an exact match. It permits or denies only 10.0.0.0/16. Subnets like 10.0.1.0/24 or 10.0.0.0/8 are ignored.

  • Up to a Specific Length (10.0.0.0/16 le 24) This rule acts as a ceiling. It matches 10.0.0.0/16 and any smaller subnet carved out of it (e.g., 10.0.1.0/24, 10.0.10.0/20), as long as the subnet mask isn't longer than /24. Anything more specific, like a /28 or /30, is ignored.

  • Subnet Range Matching (10.0.0.0/16 ge 18 le 24) This creates a bounded range:

  • ge 18 acts as the floor (ignores /16 and /17).
  • le 24 acts as the ceiling (ignores /25 through /32).

This is useful when you want to block the summary network (/16) while permitting specific mid-sized subnets within that block[cite: 1, 2].

  • Catch-All / Permit Any (0.0.0.0/0 le 32) Starting at 0.0.0.0/0 with le 32 means "match any IP address with any subnet mask length from 0 to 32." This is commonly used as a final permit statement to allow all remaining traffic after filtering out specific networks[cite: 1, 2].