Filtering Long Prefixes

Problem

You do not want to install IP address prefixes longer than 172.18.20.0/19 in the routing table.

Solution

Create a filter that identifies the long prefixes:

	[edit policy-options policy-statement long-prefixes  term 1]
	aviva@router1#  
set from route-filter 172.18.20.0/19 longer 
	aviva@router1#  
set then reject 

Then apply the policy to an EBGP group:

	[edit protocols bgp]
	aviva@router1# set group external-group import long-prefixes

 

Discussion

A second way to filter routes based on their IP address prefixes is to create a route list. Unlike prefix lists, route lists are embedded in the routing policy, not maintained in a separate list, so it can be somewhat harder to maintain them because the same prefixes may be used in different policies. This recipe creates a simple policy that an EBGP group uses to reject all incoming prefixes longer than 172.18.20.0/19. This policy keeps longer prefixes out of the routing table and is somewhat similar to aggregating routes.

In the recipe, the set from route-filter command defines the prefix (172.18.20.0/19) and how to match it (longer). The set then command is a simple action clause to reject matching prefixes. We apply the policy with a set import command to an EBGP group to prevent BGP from installing the long prefixes into the routing table.

Route lists have two advantages over prefix lists. The first is that route lists match prefix ranges instead of the exact matching performed by prefix lists. This recipe uses the longer option to match all prefixes longer than 172.18.20.0/19for example, 172.18.20.0/24. A variation of this uses the orlonger keyword instead of the longer keyword to match the specified prefix and all longer prefixes:

	[edit policy-options policy-statement long-prefixes term 1]
	aviva@router1# set route-filter 172.18.20.0/19 orlonger

The difference between this command and the one in the recipe is that this command will match 172.18.20.0/19, while the set from route-filter 172.18.20.0/19 longer command will not.

There are two other ways to specify address ranges. The upto keyword is, in some sense, the opposite of the longer and orlonger keywords, looking at the high-order bits of the IP address instead of the low-order bits:

	[edit policy-options policy-statement prefixes-to-exclude  term 1]
	aviva@router1# set route-filter 0.0.0.0/0 upto /7 

The following command matches prefixes 0.0.0.0/0, 0.0.0.0/1, and so on, up to 0.0.0.0/7. The final keyword is prefix-length-range:

	[edit policy-options policy-statement prefixes-to-exclude term 1]
	aviva@router1# set route-filter 0.0.0.0/0 prefix-length-range /25-/30

The following command matches IP prefixes in the range 0.0.0.0/25, 0.0.0.0/26, 0.0.0.0/27, 0.0.0.0/28, 0.0.0.0/29, and 0.0.0.0/30 only.

Route lists can also match exactly one prefix, just as prefix lists can:

	[edit policy-options policy-statement long-prefixes  term 1 ]
	aviva@router1# set route-filter 172.18.20.0/24 exact 

A second advantage of route lists over prefix lists is that each prefix can include an action. When a match occurs, the action is taken immediately instead of waiting to reach the then clause. (The action can be any of those listed in Table 9-3.) When the list of prefixes is long, this speeds up the processing of routing traffic. The following simple policy illustrates how this works:

	[edit policy-options policy-statement prefix-policy term 1 ]
	aviva@router1# set from route-filter 0.0.0.0/0 upto /7 accept 
	aviva@router1# set from route-filter 0.0.0.0/0 or longer 
	aviva@router1# set then reject 

This policy accepts prefixes up to /7 and rejects everything longer.

You can also use route lists as another way to manipulate the routing information in a route. Instead of screening routes by protocol or by other routing information they contain, you filter by destination prefix:

	[edit policy-statement set-metric-igp]
	aviva@router1# set term 1 from route-filter 10.12.0.0/16 exact
	aviva@router1# set term 1 from route-filter 172.64.0.0/16 exact
	aviva@router1# set term 1 from route-filter 192.168.0.0/24 exact
	aviva@router1# set term 1 then local-preference 300
	aviva@router1# set term 1 then accept
	aviva@router1# set term 2 then reject
	aviva@router1# show
	policy-statement set-metric-igp {
	 term 1 {
	 from {
	 route-filter 10.12.0.0/16 exact;
	 route-filter 172.64.0.0/16 exact;
	 route-filter 192.168.0.0/24 exact;
	 }
	 then {
	 preference 300;
	 accept;
	 }
	 }
	 term 2 {
	 then reject;
	 }
	}

This configuration sets the BGP local preference value on three specific prefixes and rejects any other prefixes.