Supported NE routing policies
General Information
The following table describes the NE routing policies you can configure using the NFM-P. The table below describes the additional functions you can perform with routing policies.
Table 54-1: NFM-P supported NE routing policies
|
Routing policy type |
Purpose |
See |
|---|---|---|
|
Statement |
This policy defines the flow control actions taken if a route matches all the conditions specified by the policy. Flow control actions determine whether to accept or reject the route or whether to evaluate the next term or routing policy. In addition, you can configure a multicast redirection interface as part of the routing policy statement to ensure that multicast IGMP traffic coming from the access network is only passed onto downstream devices once. |
To configure a routing policy statement To configure a multicast redirect interface on a local routing policy statement |
|
Prefix List |
This policy defines a list of IP prefixes members used by the Routing policy statement that specifies the matching criteria used for incoming routes. A prefix list is a named list of IP addresses. You can specify an exact match with incoming routes and apply a common action to all matching prefixes in the list. |
|
|
Community |
This policy defines the community members used for routing policy entries and provide a means of grouping destinations to which routing decisions can be applied, for example, to change the community values of BGP AS path attributes. |
|
|
Damping |
This policy defines the damping mechanism used to control BGP route flapping which reduces the number of update messages sent between BGP peers, thereby reducing the load on these peers, without adversely affecting the route convergence time for stable routes. |
|
|
AS Path |
This policy defines the AS path to a destination and is used for both route selection and to prevent routing loops. An AS path consists of the AS numbers of the networks that a packet traverses if it takes the associated route to a destination. |
|
|
AS Path group |
This policy defines the match conditions based on an AS path group which consists of multiple AS paths to which a single routing policy can be applied. |
|
|
Accounting Template Policy |
This policy defines if accounting statistics are collected on IP interfaces for received packets and bytes that are sourced from or destined for routes marked with the class indexes contained in the policy. An accounting template policy can be associated with the following interfaces on base routers, IES services, and VPRN services: |
|
|
Administrative Group |
This policy defines the administrative groups that can be assigned to MPLS interfaces, LSPs, LSP paths, L3 interfaces for VPRN and IES services, or flexible algorithm definitions. You can also assign Administrative groups to network interfaces at the base routing instance. See Administrative Group policies for more information. |
|
|
Shared Risk Link Group |
This policy defines which links in a network share a common fiber which, in the event one link fails, other links in the group may fail therefore they have a shared risk. See Shared Risk Link Group policies for more information. In addition, you can create a static configuration for a SRLG Policy to manually enter the SRLG membership for links in the entire network into the SRLG database. |
|
|
Route Next Hop Template |
This policy defines the policy control for the Loop-Free Alternate Shortest Path First (LSA SPF) feature which is used to reduce the routing transition time in case of link/router failures. A Route Next Hop Template policy can be applied to OSPFv2, OSPFv3 and IS-IS interfaces on base routing instances and VPRN services. |
|
|
Re-Assembly Profile |
This policy defines the timers that assure all expected fragments of a packet are received within an expected time frame, on a per forwarding class basis. When the specified timer expires, all of the fragments of an incomplete frame are dropped. The system visits the reassembly queues every 64 ms in a constant loop, which causes up to a 63 ms variation between the user configured value and the actual detection time. For example, with the default configuration of 2000 ms, the system visits the reassembly queue timer at 1999 ms in which case there will not be a timeout. The timeout will occur during the next visitation at 2063 ms. |
|
|
Maintenance Policy |
This policy provides BFD template information to support segment routing seamless BFD sessions. The maintenance policy must be associated with a segment routing static policy for a seamless BFD session to be created; see To create a segment routing policy. |
|
|
Route Distinguisher |
This policy defines the route distinguisher (RD). A route distinguisher is an 8-byte value that is prepended to an IPv4 or IPv6 prefix to ensure that the resulting BGP NLRI is unique within the routing domain that propagates BGP routes for this prefix. An RD set is a list of one or more route-distinguisher entries. Each route-distinguisher entry matches one or more route-distinguisher values depending on the use of wildcards. |
Table 54-2: Additional routing policy functions
|
Policy function |
Purpose |
See |
|---|---|---|
|
View policy variable usage in a routing policy statement |
Allows you to view policy variable usage in a routing policy statement. Policy variables are defined in a (main) routing policy statement and are essentially pointers to certain other routing policy types. They are subsequently called by a subordinate routing policy statement that is specified in the main policy. |
|
|
View routing policy usage |
Allows you to display which NEs are currently using a global or local version of certain routing policy type. |
|
|
Shows the routing policy CLI configuration in the client GUI |
Allows you to display the output of the show router policy policy_type CLI command on the NFM-P GUI. |
To show a routing policy CLI configuration in the client GUI |
|
Verify BGP routes against a routing policy statement |
Allows you to verify BGP routes against a routing policy statement to identify the prefixes that are matched or not matched by the policy, before attaching the prefix to a routing neighbor or instance. |
|
|
Verify a BGP prefix list against a routing policy statement |
Allows you to verify a BGP prefix list against a routing policy statement to identify the accepted and rejected route entries. |
To verify a BGP prefix list against a routing policy statement |
|
Configure a global policy variable |
Global variables function similarly to policy variables, but allow for more efficient configuration, because they can be configured once, then selected in multiple routing policy statements. This eliminates having to manually configure a policy variable in every routing statement. Support for global variables depends on the NE and release; see the NE documentation for information. |
Administrative Group policies
Administrative group policies define administrative groups that can be assigned to MPLS interfaces, LSPs, LSP paths, and L3 interfaces in VPRN and IES services. You can also assign Administrative groups to network interfaces at the base routing instance, and to flexible algorithm definitions in NE global properties. After you configure the administrative groups, they can be assigned to interfaces and paths on their respective properties forms. Multiple administrative groups can be assigned to each of these objects.
When establishing LSP and LSP paths, devices only consider MPLS interfaces which are associated with the same administrative group as the LSP or LSP path. MPLS interfaces advertise administrative group associations using CSPF. This is done using the 32 bit mask which you configure using the Value parameter on the administrative group policy form.
An administrative group can also be assigned to be explicitly excluded from LSPs and LSP paths. The device cannot use MPLS interfaces in the administrative group to establish LSPs or LSP paths. Administrative group exclusion takes priority over administrative group inclusion.
CSPF must be enabled on LSPs for administrative groups to be relevant. You can enable and configure CSPF on the LSP properties form. When CSPF is enabled on an LSP, it is automatically enabled on associated LSP paths. LSP paths can be configured on the LSP path properties form to inherit additional CSPF, administrative group, and other parameters from LSPs.
The following table describes where to find information about assigning administrative groups.
Table 54-3: Administrative group assignments
|
To assign groups to |
See Procedure |
|---|---|
|
MPLS interfaces |
|
|
LSPs |
|
|
LSP paths |
|
|
L3 interfaces |
To create an L3 network interface on a routing instance in Chapter 27, NE routing and forwarding |
|
Flexible algorithm definitions |
To modify NE properties in Chapter 12, Device object configuration |
Shared Risk Link Group policies
SRLG policies defines which links in a network share a common fiber which, in the event one link fails, other links in the group may fail therefore they have a shared risk. SRLGs are constructs which allow you to perform two operations that enhance overall system reliability.
SRLGs policies are associated with MPLS interfaces; an MPLS interface can belong to multiple SRLGs. SRLGs can also assigned to network interface at base routing instance and to L3 access interface of VPRN & IES service.
You can use SRLGs to establish a FRR LSP path and you also use SRLGs to establish a secondary LSP path which is disjointed from the primary LSP path. SRLG avoids the need to define MPLS path hops for secondary LSPs and creation of static bypass tunnels and management of these LSPs to achieve the same result dynamically.
Links that are members of the same SRLG represent resources which share the same risk. For example, fiber links sharing the same conduit, or multiple wavelengths sharing the same fiber.
An SRLG is modeled as a policy object. It therefore follows the normal policy behavior for creation, listing, updating, deletion, distribution, and re synchronization.
The SRLGs are used by the CSPF when computing a FRR detour/bypass path, or a secondary LSP path. SRLGs indicate to the CSPF which interfaces to avoid in the path’s computation. CSPF can include the SRLG penalty weight in the computation of a FRR detour or bypass for the protection of the primary LSP path at a PLR NE. Configured SRLGs can be associated with MPLS interfaces, and network, tunnel, and L3 access interfaces on base routers, VPRN services, and IES services.
The following table describes where to find information about related MPLS and LSP procedures.
Table 54-4: Related MPLS and LSP procedures
|
To: |
See Procedure: |
|---|---|
|
Configure an MPLS instance |
|
|
Create an MPLS interface |
|
|
Configure LSP paths |
|
|
Configure L3 interfaces |
To create an L3 network interface on a routing instance in Chapter 27, NE routing and forwarding |