11.5 Route Redistribution and FilteringAnother 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 RedistributionA 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 FilteringRoute 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 controllingrouting 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

the10.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; }