Hands-On Lab: Configuring BGP Route Filtering with Prefix Lists

Lab Objective

Configure a prefix list permitting only specific networks, apply it as an inbound filter on a BGP session to reject unwanted routes, then configure a separate outbound prefix list restricting which of the local router's own networks are advertised.

Lab Purpose

Communities, covered in the previous lab, control policy after routes are already accepted into the BGP process. Prefix lists control something more fundamental: whether a route is accepted or advertised at all — essential for preventing a misconfigured or malicious peer from injecting unwanted routes, or for deliberately withholding certain internal networks from being advertised externally.

Lab Topology

R1 (AS 65080) ---- eBGP ---- R2 (AS 65090)

R2 is advertising three networks:
203.0.113.0/24 (legitimate)
10.0.0.0/8 (should be rejected -- private
            space, should never appear in
            eBGP from a legitimate peer)
198.51.100.0/24 (legitimate)

R1 has two internal networks:
192.168.80.0/24 (should be advertised)
192.168.99.0/24 (internal-only, should
                 NOT be advertised externally)

Task 1: Verify All Three Routes Are Initially Accepted

Confirm R1 currently accepts all three networks from R2, including the problematic 10.0.0.0/8.

Task 2: Configure an Inbound Prefix List Rejecting Private Space

Create a prefix list explicitly denying 10.0.0.0/8 while permitting everything else, and apply it inbound.

Task 3: Verify the Private Route Is Now Rejected

Confirm 10.0.0.0/8 no longer appears in R1's BGP table, while the two legitimate routes still do.

Task 4: Configure an Outbound Prefix List Withholding an Internal Network

Create a prefix list permitting only 192.168.80.0/24 and apply it outbound toward R2.

Task 5: Verify R2 Only Receives the Intended Network

Confirm R2 sees 192.168.80.0/24 but never 192.168.99.0/24.

Solution and Verification

R1# show ip bgp

   Network              Next Hop        Path
*> 10.0.0.0/8           [via R2]        65090 i
*> 198.51.100.0/24      [via R2]        65090 i
*> 203.0.113.0/24       [via R2]        65090 i
-- All three routes accepted initially,
-- including the problematic private range

R1(config)# ip prefix-list BLOCK-PRIVATE seq 5 deny 10.0.0.0/8
R1(config)# ip prefix-list BLOCK-PRIVATE seq 10 permit 0.0.0.0/0 le 32

-- The explicit deny comes first, then a
-- permit-all catches everything else --
-- prefix lists, like ACLs, have an implicit
-- deny at the end, so this final permit
-- line is required

R1(config)# router bgp 65080
R1(config-router)# neighbor [R2 address] prefix-list BLOCK-PRIVATE in

R1# clear ip bgp [R2 address] soft in

R1# show ip bgp

   Network              Next Hop        Path
*> 198.51.100.0/24      [via R2]        65090 i
*> 203.0.113.0/24       [via R2]        65090 i
-- 10.0.0.0/8 no longer appears -- the
-- two legitimate networks remain unaffected

R1(config)# ip prefix-list ADVERTISE-ONLY seq 5 permit 192.168.80.0/24

R1(config)# router bgp 65080
R1(config-router)# neighbor [R2 address] prefix-list ADVERTISE-ONLY out

R2# show ip bgp

   Network              Next Hop        Path
*> 192.168.80.0/24      [via R1]        65080 i
-- Only the intended network appears --
-- 192.168.99.0/24 was never advertised
-- at all, since the outbound prefix list
-- had no permit statement matching it,
-- so it fell to the implicit deny

Key Takeaway

Inbound and outbound prefix lists control fundamentally different things than the attribute-based tools covered in earlier labs: rather than influencing which of several already-accepted routes is preferred, they decide whether a route is accepted or advertised at all — an essential first line of defense against a misbehaving or misconfigured eBGP peer, and the correct tool whenever specific internal networks must never leave the local AS regardless of any other policy configured.