11.5 Route Redistribution and Filtering

Another important use of a routing policy on a Juniper Networks router is in route redistribution. You have seen examples of route redistribution for IGP and EGP in Chapters 9 and 10. Those of you familiar with Cisco routers are likely to be aware of the redistribute command. There is no equivalent redistribute command in JUNOS. All redistribution of routes between protocols is done through the creation of a routing policy through the use of import and export statements. This provides much more flexibility in that a policy can also be designed to modify route parameters as they are being redistributed.

11.5.1 Route Redistribution

A common example is that you want to redistribute RIP routes into OSPF. You may also want to modify the metric on the RIP routes prior to redistributing them. The resulting policy would look similar to the following:

 policy-statement rip-2-ospf {          from protocol rip;         then {             metric 5;             accept;         }     } } ospf {     export rip-2-ospf;      } 

In JUNOS, the BGP protocol often relies on having routes put into the protocol through a redistribution export policy. It is common to redistribute OSPF or static routes into BGP so they are seen as IBGP routes. This can be achieved using the following policy:

 policy-statement ospf-2-bgp {      term match-ospf {         from protocol ospf;         then accept;         }     } 

Another common redistribution policy is importing static routes into BGP, while modifying the next -hop address in the process:

 policy-statement static-2-bgp {      term match-static {         from protocol static;         then {             next-hop self;             accept;         }     } 

An important observation from the above example is that the from protocol static statement is used. JUNOS considers local, static, direct, and aggregate routes as separate protocols among other obvious choices like RIP, OSPF, IS-IS, BGP, DVMRP, Protocol Independent Multicast (PIM), and MSDP:

 user@Chicago# set policy-options policy-statement policy-name from protocol ?  Possible completions:   [                    Open a set of values   aggregate            Aggregate routes   bgp                  BGP   direct               Directly connected routes   dvmrp                DVMRP   isis                 IS-IS   local                Local system addresses   msdp                 Multicast Source Discovery   ospf                 OSPF   pim                  PIM   rip                  RIP   static               Statically defined addresses 

Sometimes when routes are being redistributed from one protocol to another, you might want to limit the routes to a certain subset. Route filters were specifically designed for this purpose, as is discussed in the following section.

11.5.2 Route Filtering

Route filtering is a way of identifying a specific route or a group of routes and performing a common action on them. Common actions include setting route metrics, preference values, or BGP communities. The ability to modify route parameters increases the scalability of IP. By controlling routing parameters, such as metrics and protocol preferences, network data paths can be customized at the discretion of the network administrator.

Route filtering is a very useful feature that enables a policy to be implemented in a number of stages. At each point, specific groups of routes are selected and receive a set of actions. Actions may include the modification of metrics or route rejection to deny routes from entering or passing through the network. Route rejection could be used to prevent a neighboring AS from using the local network as a transit AS for nonlocal traffic that is not covered under a neighboring peering agreement.

A route filter operates in much the same way as any other type of filter. Consider the analogy of a rock quarry for limestone or asphalt. In a quarry, rock is blasted from a rock face and then passed through rock filters. Each filter removes a different size of rock, and at the finest filter, you are left with small stones useful for a sidewalk or driveway . Figure 11-8 shows how such a filter would operate .

Figure 11-8. Analogy: Rock Filtering and Route Filtering

Now, imagine that instead of rocks, you want to filter routes prior to their redistribution into another protocol. The coarse filter could operate on aggregate routes, the medium filter on more specific routes, and the fine filter on the most specific routes. Because the routes are removed at different levels, different actions can be performed once a match is made.

Route filters reside under the from statement in policy configuration and are designed to operate on routes that a router has learned prior to importing them into the routing table or passing them to other routers. JUNOS permits standard route filtering and source address filtering.

Source address filtering is used to pick out prefixes from PIM sessions and either allow an address to join a multicast tree by accepting a session from a specific source address or not allow the session to join the tree by rejecting the session. More examples of this will be presented in Chapter 14.

A route filter looks for a route or group of routes using a set of match conditions. The first match condition is the network address. This address needs additional information in the form of a match type to determine if it matches or not. In addition to the network address, one of the following match types is required:

 [edit]  user@Chicago# set policyoptions policy-statement policyname from route-filter 192.168.1.0/24 ? Possible completions:   exact                Exactly match the prefix length   longer               Mask is greater than the prefix length   orlonger             Mask is greater than or equal to the prefix length   prefix-length-range  Mask falls between two prefix lengths   through              Route falls between two prefixes   upto                 Mask falls between two prefix lengths 

It is possible to specify multiple route filters in a single from statement. In fact, this is standard practice. In the case of multiple route filters matching a route within a from statement, a longest-prefix match rule applies. That is, the longest match prevails over all other matches. Match actions can also be specified as part of the route-filter statement. If a match action exists on the same line, then it overrules any match actions listed in the then portion of the policy. Some of these features are best observed in an example.

 policy-statement filter {      term all-route-filter {         from {             route-filter 192.168.0.0/24 longer reject;             route-filter 10.0.0.0/8 orlonger reject;             route-filter 10.10.0.0/16 exact;         }         then {             metric 10;             accept;         }     }     term final-term {         then reject;     } } 

Three filter statements are listed above. If you pass the route 192.168.10.1/32 through the filter, it will be rejected because all routes with prefixes larger than this network have been rejected by the first route-filter statement. The route 10.10.10.10 would match both the 10.0.0.0/8 and 10.10.0.0/16 filters. It does not matter which of these filters is defined first in the configuration. Keep in mind that when multiple filters exist in a from statement, the longest match always wins. In this case, the 10.10.0.0/16 match prevails due to a longer prefix match. Since no action is specified at the end of the filter statement, the action in the then statement is taken. That is, the route's metric is set to 10, and the route is accepted.

The following example illustrates the use of route filters by rejecting all private addresses (RFC 1918) from external BGP peers.

 policy-statement rfc-1918 {      from {         route-filter 10.0.0.0/8 orlonger;         route-filter 172.16.0.0/12 orlonger;         route-filter 192.168.0.0/16 orlonger;     }     then reject; }