Understanding Routing Policy Tests
Routing policy tests provide a method for verifying the effectiveness
of your policies before applying them on the routing device. Before
applying a routing policy, you can issue the test policy command to ensure that the policy produces the results that you
expect:
user@host> test policy policy-name prefix
Keep in mind that different protocols have different default
policies that get applied if the prefix does not match the configured
policy. For BGP this is accept, but for RIP it is reject. The test policy command always uses accept as the default policy,
so unless you explicitly reject all routes that you do not want to
match you might see more routes matching than you want.
The default policy of the test policy command accepts
all routes from all protocols. Test output can be misleading when
you are evaluating protocol-specific conditions. For example, if you
define a policy for BGP that accepts routes of a specified prefix
and apply it to BGP as an export policy, BGP routes that match the
prefix are advertised to BGP peers. However, if you test the same
policy using the test policy command, the test output might
indicate that non-BGP routes have been accepted.
Example: Testing a Routing Policy
Test the following policy, which looks for unwanted routes and rejects them:
[edit policy-options]
policy-statement reject-unwanted-routes {
term drop-these-routes {
from {
route-filter 0/0 exact;
route-filter 10/8 orlonger;
route-filter 172.16/12 orlonger;
route-filter 192.168/16 orlonger;
route-filter 224/3 orlonger;
}
then reject;
}
}
Test this policy against all routes in the routing table:
user@host> test policy reject-unwanted-routes 0/0
Test this policy against a specific set of routes:
user@host> test policy reject-unwanted-routes 10.49.0.0/16