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