Understanding IP prefix lists

IOS prefix lists work like access lists for route advertisements (prefixes). While extended (and to a limited extent, standard) access lists can be employed to match prefix announcements, prefix lists are generally more graceful. Prefix lists work very similarly to access lists; a prefix list contains one or more ordered entries which are processed sequentially. As with access lists, the evaluation of a prefix against a prefix list ends as soon as a match is found.

Assume you wanted to prevent a route for 10.0.0.0/24 from being redistributed from OSPF to BGP. One way to accomplish this would be to define an extended ACL matching this prefix and reference it from the BGP redistribution route map:

router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
!
router bgp 65100
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 redistribute ospf 1 route-map OSPF->BGP
 neighbor 172.16.23.3 remote-as 65100
 no auto-summary
!
ip access-list extended OSPF_Redist
 deny   ip host 10.0.0.0 host 255.255.255.0
 permit ip any any
!
route-map OSPF->BGP permit 10
 match ip address OSPF_Redist

The above configuration prevents the exact prefix 10.0.0.0/24 from being advertised by denying the 10.0.0.0 network ("source" address) with a mask of 255.255.255.0 ("destination" address). All other prefixes are allowed by the permit ip any any statement.

This can be accomplished more intuitively by employing a prefix list:

router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
!
router bgp 65100
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 redistribute ospf 1 route-map OSPF->BGP
 neighbor 172.16.23.3 remote-as 65100
 no auto-summary
!
ip prefix-list OSPF_Redist seq 5 deny 10.0.0.0/24
ip prefix-list OSPF_Redist seq 10 permit 0.0.0.0/0 le 32
!
route-map OSPF->BGP permit 10
 match ip address prefix-list OSPF_Redist

As you can see, there are two entries in the prefix list defined above. These accomplish the same tasks as the two access list entries in the earlier example: deny 10.0.0.0/24 denies the exact prefix 10.0.0.0/24, and permit 0.0.0.0/0 le 32 allows all other prefixes.

The second prefix list entry warrants some explanation. Two keywords can be optionally appended to a prefix list entry: le (less than or equal to) and ge (greater than or equal to). Without either, an entry will match an exact prefix. The le parameter can be included to match all more-specific prefixes within a parent prefix up to a certain length. For example, 10.0.0.0/24 le 30 will match 10.0.0.0/24 and all prefixes contained therein with a length of 30 or less.

We can use le to create an entry to match "any" prefix: 0.0.0.0/0 le 32 matches any prefix with a length between 0 and 32 bits (inclusive). This matches all possible IPv4 prefixes.

The ge parameter works similarly to le but in the opposite direction; it specifies a minimum prefix length whereas le specifies a maximum length. For example, 10.0.0.0/8 ge 16 will match all prefixes within the 10.0.0.0/8 network that are at least 16 bits in length. The length specified by ge should naturally be longer than the length of the initial prefix as it is impossible to match anything larger than the initial prefix.

le and ge can also be combined. Continuing the ge example, 10.0.0.0/8 ge 16 le 24 will match all prefixes within the 10.0.0.0/8 network having a mask both a) greater than or equal to 16 bits, and b) less than or equal to 24 bits in length. For instance, 10.42.0.0/18 would be matched, because its length is between 16 and 24 (inclusive), but neither 10.16.0.0/12 nor 10.123.77.128/25 would be matched.

Prefix lists take some getting used to, but can be very helpful in expressing routing policy within IOS configuration once you've gotten the hang of them.