Why You Can’t Create Import Policies for OSPF

By Walter J. Goralski, Cathy Gadecki, Michael Bushong

The reason you can’t create import policies for OSPF (or IS-IS for that matter) is that OSPF is a link-state protocol. Link-state protocols work by ensuring that every node within the network shares the exact same view of the link-state database.

If you were to modify or filter inbound routes, you’d create a local copy of the link-state database that wouldn’t necessarily match the shared view of the database. If the databases aren’t identical, you can’t be sure that you’ve avoided putting routing loops in the topology.

If a route doesn’t match any of the terms’ conditions, the default action will kick in. Because this default action is dependent on the routing protocol and direction, it can be less than obvious what will happen to routes that don’t match your criteria. To avoid confusion, explicitly configure a final action that will be executed if a route doesn’t match any of your terms:

[edit policy-options]
policy-statement my-sample-policy {
  term my-first-term {
   from protocol static;
   then accept;
  term my-second-term {
   from neighbor;
   then reject;
  then reject;

In this example, a final action is configured to reject all routes. If a route doesn’t match any of the terms, the final action is evoked, and the route is rejected. This final action is evaluated before the default action for whatever protocol this policy is applied against.

So now you can clearly specify what default action to take without worrying about whether the policy is applied to OSPF or BGP traffic, to inbound or to outbound routes. Note that the final action is not bound to a specific term, but the policy itself, so the final action applies to all routes that do not match any of the terms.