Filtering Routes by IP Address

Problem

You need to reject all routes to certain IP addresses because you don't want to install them into the routing table.

Solution

Create a list of all the IP address prefixes:

	[edit policy-options]
	aviva@router1# set prefix-list PREFIX-LIST-1 10.0.0.1/24
	aviva@router1# set prefix-list PREFIX-LIST-1 10.10.0.0/16
	aviva@router1# show
	prefix-list PREFIX-LIST-1 {
	 10.0.0.1/24;
	 10.10.0.0/16;
	}

Then create a policy that references the list of prefixes:

	[edit policy options policy-statement addresses-to-reject ]
	aviva@router1# set term 1 from prefix-list PREFIX-LIST-1 
	aviva@router1# set term 1 then reject 

Finally, apply the policy to a protocol, here to EBGP:

	[edit protocols bgp]
	aviva@router1# set group external-group import addresses-to-reject

 

Discussion

One of the most common uses of routing policies is to filter routes based on the IP address prefix. You create a prefix list and then reference it in the from clause of a routing policy. Instead of looking at the protocol information in routes, the policy examines the route prefix itself. This provides you with fine-grained control for identifying routes that you want to act on. A prefix list is simply a list, so it contains no information about what actions to take. You can create various lists in the [edit policy-options] hierarchy and then reference them as needed in different routing policies and also in firewall filters.

Prefix lists are a great way to reuse IP addresses in a JUNOS configuration. They are handy for keeping lists of all your customers or separate lists of customers to whom you apply the same routing policies. For firewall filters, prefix lists are handy for listing network servers, such as DNS, NTP, and RADIUS or TACACS+ servers, in a single place. They are also handy for keeping a single list of your BGP peers and SNMP systems. Because the lists are defined only once, they help restrict the number of places you have to change, add, or manipulate IP addresses for network management and other tasks. Both routing policies and firewall filters can reference the same prefix lists.

This recipe creates a list of prefixes that are rejected when they are received from EBGP peers. They are prefixes BGP should never install in the routing table or advertise to its peers. As a first step, create a list of prefixes by creating a named prefix list in the [edit policy-options] hierarchy. In this recipe, the prefix list named PREFIX-LIST-1 has two prefixes.

Then define a policy that references the prefix list and specifies the action to take when a match occurs. This recipe creates a policy named addresses-to-reject. The from clause references the prefix list, which consists of the prefixes to match. If the prefix in a received packet exactly matches one of the prefixes, the action in the then clause is taken. This behavior is similar to a logical OR operation and differs from how matching is done for routing information, where all the conditions in the from clause have to match before an action is taken (similar to a logical AND operation). With a prefix list, when the packet's prefix matches one of the listed prefixes, the action in the then clause is taken. When the JUNOS software evaluates a prefix to see if it matches one in the list, it searches through the entire list for the longest prefix (called longest-match lookup), so the order of the prefixes in the list does not matter. This is different from how the JUNOS software handles policy evaluation, which is to look at policy terms and chained policies in order, from beginning to end, and perform the action immediately when a match occurs.

The then clause in this recipe has a reject action, which rejects the route. When applying this policy with a set import command, the routes will not be installed into the routing table. When applying it with a set export command, the routes will not be advertised to peer routers. The set import command in this recipe applies the policy to routes received from neighbors in an EBGP peer group, so the routes are not installed in the inet.0 routing table.