Routing policy design considerations

General information

Careful planning is essential to implementing routing policies that affect the flow of routing information or packets traversing managed devices. Before configuring and applying a routing policy, consider the following:

• Develop an overall plan and strategy to accomplish your intended routing actions.

• Analyze the effect of what happens to a packet that meets the specified criteria in a routing policy statement entry to ensure the proper action is executed and that no routing loops are created.

• Ensure that routing policy statement entries are properly numbered, so they will be compared to packets in the correct order. Entries are compared in the numerical sequence of the Entry IDs, from lowest to highest. Nokia recommends staggering the numerical Entry ID values (for example, using 10, 20, 30… instead of 1, 2, 3…), to allow insertion of additional entries. The NFM-P supports renumbering existing entries on supporting NEs.

• When possible, redistribute from a lower-level routing protocol to a higher-level routing protocol; for example, from RIP to OSPF.

• Redistribute exported routes at a single device, when possible.

• To ensure routing configuration flexibility, the following routing policies can be configured as separate policies or can be cross-referenced to form a framework of policies depending on the network requirements:

  • Policy Statement

  • Prefix List

  • Community

  • Damping

  • AS Path

• Policies that are cross-referenced are distributed together. For example, a Policy Statement can reference the Prefix List policy by matching the From Criteria and the To Criteria for each policy type. In addition, policy variables can be defined in an upper-level routing Policy Statement, and then called by a specified subordinate routing Policy Statement. The variables are pointers to certain types of routing policies, including Community Lists, AS Paths, AS Path Groups, and Prefix Lists. To improve configuration efficiency, you can create global policy variables (for supporting NEs) and assign them to multiple routing policy statements. This routing policy parameterization allows operators a powerful and flexible approach to the configuration of routing policies.

• When IGMP join requests originate from subscriber host sessions, the NE can use a multicast redirection policy to redirect the requests to a plain (non-ESM) L3 access interface. Additionally, individual local routing policy statements can be configured with a multicast redirect action to redirect specific IGMP join requests for processing at the subscriber level.

• Imported BGF, OSPF, and RIP learned routes can be altered using import and export route policies. For example, for devices learning about routes from BGP or OSPF, you can create an import route policy that can limit the number and types of routes accepted and added to the routing tables. For exporting routes, some default behaviors exist:

  • internally learned routes are redistributed using the same protocol

  • externally learned routes are not automatically advertised to all neighbors or peers

• In the case of externally learned routes, you can create an export policy to determine how the routes are advertised; for example, configuring something learned by BGP to be redistributed using OSPF. This is useful in cases:

  • where legacy equipment does not support a specific protocol

  • when companies merge and they use different routing protocols on the devices