3.12. OSPF Command Reference

This command administratively disables the entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many entities must be explicitly enabled using the no shutdown command.

Unlike other commands and parameters where the default state is not indicated in the configuration file, shutdown and no shutdown are always indicated in system generated configuration files.

The no form of this command puts an entity into the administratively enabled state.

This command configures the router ID for OSPF.

The router ID configured in the base instance of OSPF overrides the router ID configured in the config>router context.

The default value for the base instance is inherited from the configuration in the config>router context. When that is not configured the following applies:

This is a required command when configuring multiple instances and the instance being configured is not the base instance. When configuring multiple instances of OSPF, there is a risk of loops because networks are advertised by multiple domains configured with multiple interconnections to one another. To avoid this from happening all routers in a domain should be configured with the same domain-id. Each domain (OSPF instance) should be assigned a specific bit value in the 32-bit tag mask.

The default value for non-base instances is 0.0.0.0 and is invalid, in this case the instance of OSPF will not start. When configuring a new router ID, the instance is not automatically restarted with the new router ID.

The next time the instance is initialized, the new router ID is used.

Issue the shutdown and no shutdown commands for the instance for the new router ID to be used, or reboot the entire router

The no form of this command reverts to the default value.

Note: The platforms as described in this document allow for the configuration of a single OSPF instance at any time. The instance ID can be any number other than 0. This enables these platforms to be used in a network where multi-instance OSPF is deployed, and the node must use an instance ID other than the default instance ID of 0. The number of OSPF instances supported on the 7210 SAS differs depending on the platform. Contact a Nokia representative for information about the supported scaling limits.

This command enables the context to configure OSPF to support IPv6.

Before OSPFv3 can be activated on the router, the router ID must be configured. The router ID is derived by one of the following methods:

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized, the new router ID is used. To force the new router ID, issue the shutdown and no shutdown commands for OSPFv3 or restart the entire router.

The no form of this command disables OSPF support for IPv6.

This command enables the advertisement of router capabilities to its neighbors for informational and troubleshooting purposes. A router information (RI) LSA as defined in RFC 4970 advertises the following capabilities:

The link, area, and as keywords control the scope of the capability advertisements.

The no form of this command disables this advertisement capability.

This command configures the router as an Autonomous System Boundary Router (ASBR) if the router is to be used to export routes from the Routing Table Manager (RTM) into this instance of OSPF. When a router is configured as an ASBR, the export policies into this OSPF domain take effect. If no policies are configured, no external routes are redistributed into the OSPF domain.

The no form of this command removes the ASBR status and withdraws the routes redistributed from the RTM into this OSPF instance from the link state database.

When configuring multiple instances of OSPF, there is a risk of loops because networks are advertised by multiple domains configured with multiple interconnections to one another. To avoid loops, all routers in a domain should be configured with the same domain ID. Each domain (OSPF instance) should be assigned a specific bit value in the 32-bit tag mask.

When an external route is originated by an ASBR using an internal OSPF route in a specific domain, the corresponding bit is set in the AS-external LSA. As the route gets redistributed from one domain to another, more bits are set in the tag mask, each corresponding to the OSPF domain the route visited. Route redistribution looping is prevented by checking the corresponding bit as part of the export policy; if the bit corresponding to the announcing OSPF process is already set, the route is not exported there. Figure 10 shows the checking of the corresponding bit.

Figure 10:  Checking Corresponding Bit 

Domain IDs are incompatible with any other use of normal tags. The domain ID should be configured with a value between 1 and 31 by each router in a specific OSPF domain (OSPF instance).

When an external route is originated by an ASBR using an internal OSPF route in a specific domain, the corresponding bit (1 to 31) is set in the AS-external LSA.

The no form of this command removes the ASBR status and withdraws the routes redistributed from the routing table into OSPF from the link-state database.

This command enables OSPF summary and external route calculations in compliance with RFC1583 and earlier RFCs.

RFC1583 and earlier RFCs use a different method to calculate summary and external route costs. To avoid routing loops, all routers in an OSPF domain should perform the same calculation method.

Although it would be favorable to require all routers to run a more current compliancy level, this command allows the router to use obsolete methods of calculation.

The no form of this command enables the post-RFC1583 method of summary and external route calculation.

This command disables the IGP-LDP synchronization feature on all interfaces participating in the OSPF routing protocol. When this command is executed, IGP immediately advertises the actual value of the link cost for all interfaces that have the IGP-LDP synchronization enabled if the currently advertised cost is different. It will disable IGP-LDP synchronization for all interfaces. This command does not delete the interface configuration.

For information about LDP synchronization, refer to “IGP-LDP and static route-LDP Synchronization on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C” and the ldp-sync and ldp-sync-timer commands in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

The no form of this command restores the default settings and re-enables IGP-LDP synchronization on all interfaces participating in the OSPF routing protocol and for which the ldp-sync-timer is configured.

This command associates export route policies to determine which routes are exported from the route table to OSPF or OSPFv3. Export polices are only in effect if OSPF or OSPFv3 is configured as an ASBR.

If no export policy is specified, non-OSPF or OSPFv3 routes are not exported from the routing table manager to OSPF or OSPFv3.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of this command removes all policies from the configuration.

This command configures the maximum number of routes (prefixes) that can be exported into OSPF or OSPFv3 from the route table.

The no form of this command removes the parameters from the configuration.

This command configures limits on the number of non-default AS-external LSA entries that can be stored in the link-state database (LSDB) and specifies a wait timer before processing these entries after the limit is exceeded.

The limit value specifies the maximum number of non-default AS-external LSA entries that can be stored in the LSDB. Placing a limit on the non-default AS-external LSAs in the LSDB protects the router from receiving an excessive number of external routes that consume excessive memory or CPU resources. If the number of routes reaches or exceeds the configured limit, the table is in an overflow state. When in an overflow state, the router will not originate any new AS-external LSAs and will withdraws all the self-originated non-default external LSAs.

The seconds value specifies the amount of time to wait after an overflow state before regenerating and processing non-default AS-external LSAs. The waiting period acts like a dampening period preventing the router from continuously running Shortest Path First (SPF) calculations caused by the excessive number of non-default AS-external LSAs.

The external-db-overflow command must be set identically on all routers attached to any regular OSPF or OSPFv3 area. OSPF or OSPFv3 stub areas and not-so-stubby areas (NSSAs) are excluded.

The no form of this command disables limiting the number of non-default AS-external LSA entries.

This command configures the preference for OSPF or OSPFv3 external routes.

A route can be learned by the router from different protocols, in which case, the costs are not comparable. When this occurs the preference is used to decide which route will be used.

Different protocols should not be configured with the same preference, if this occurs the tiebreaker is determined by the default preference as defined in the Table 28. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.

The no form of this command reverts to the default value.

This command enables graceful-restart for OSPF or OSPFv3. When the control plane of a GR-capable router fails, the neighboring routers (GR helpers) temporarily preserve adjacency information, so packets continue to be forwarded through the failed GR router using the last known routes. If the control plane of the GR router comes back up within the GR timer, the routing protocols reconverges to minimize service interruption.

The no form of this command disables graceful restart and removes all graceful restart configurations in the OSPF or OSPFv3 instance.

This command disables the helper support for graceful restart.

When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart) or be a restarting router or both. The router supports only helper mode. This facilitates the graceful restart of neighbors but will not act as a restarting router.

The no form of this command enables helper support and is the default when graceful-restart is enabled.

This command specifies the import route policy for an OSPF3 instance.

The no form of this command removes the policy association with the OSPF3 instance.

This command enables Loop-Free Alternate (LFA) computation by SPF for the OSPF routing protocol instance.

This command instructs the IGP SPF to precompute both a primary next hop and an LFA next hop for every learned prefix. When found, the LFA next hop is populated into the routing table along with the primary next-hop for the prefix.

The remote LFA next hop calculation by the IGP LFA SPF is enabled by using the remote-lfa option. When this option is enabled in an IGP instance, SPF performs the remote LFA additional computation following the regular LFA next-hop calculation when the latter results in no protection for one or more prefixes that are resolved to a specific interface.

Remote LFA extends the protection coverage of LFA-FRR to any topology by automatically computing and establishing or tearing down shortcut tunnels, also referred to as repair tunnels, to a remote LFA node. Doing this puts the packets back into the shortest path without looping them back to the node that forwarded them over the repair tunnel. The remote LFA node is referred to as a PQ node. A repair tunnel can, in theory, be an RSVP LSP, an LDP-in-LDP tunnel, or a segment routing tunnel. Using segment routing repair tunnels is restricted to the remote LFA node.

The remote LFA algorithm is a per-link LFA SPF calculation and is not per-prefix, like the regular LFA calculation. It provides protection to all destination prefixes that share the protected link by using the neighbor on the other side of the protected link as a proxy for those prefixes.

This command excludes from LFA SPF calculation prefixes that match a prefix entry or a tag entry in a prefix policy.

The implementation already allows the user to exclude an interface in IS-IS or OSPF, an OSPF area, or an IS-IS level from the LFA SPF.

If a prefix is excluded from LFA, then it will not be included in LFA calculation regardless of its priority. The prefix tag will, however, be used in the main SPF. Note that prefix tags are defined for the IS-IS protocol but not for the OSPF protocol.

The default action of the loopfree-alternate-exclude command, when not explicitly specified by the user in the prefix policy, is a “reject”. Therefore, regardless if the user did or did not explicitly add the statement “default-action reject” to the prefix policy, a prefix that did not match any entry in the policy will be accepted into LFA SPF.

The no form of this command deletes the exclude prefix policy.

This command changes the overload state of the local router so that it appears to be overloaded. When overload is enabled, the router can participate in OSPF or OSPFv3 routing, but is not used for transit traffic. Traffic destined to directly attached interfaces continues to reach the router.

To put the IGP in an overload state, enter a timeout value. The IGP will enter the overload state until the timeout timer expires or a no overload command is executed.

If the overload command is encountered during the execution of an overload-on-boot command, this command takes precedence. This could occur as a result of a saved configuration file where both parameters are saved. When the file is saved by the system the overload-on-boot command is saved after the overload command. However, if overload-on-boot is configured under OSPF or OSPFv3 with no timeout value configured, the router will remain in overload state indefinitely after a reboot.

The no form of this command reverts to the default. When the no overload command is executed, the overload state is terminated regardless of the reason the protocol entered overload state.

This command determines whether the OSPF or OSPFv3 stub networks should be advertised with a maximum metric value when the system goes into overload state for any reason. When enabled, the system uses the maximum metric value. When this command is enabled and the router is in overload, all stub interfaces, including loopback and system interfaces, will be advertised at the maximum metric.

This command configures the IGP upon bootup in the overload state until one of the following events occurs:

When the router is in an overload state, the router is used only if there is no other router to reach the destination. The no overload command does not affect the overload-on-boot function.

The no form of this command removes the overload-on-boot function from the configuration.

This command configures the preference for OSPF or OSPFv3 internal routes.

A route can be learned by the router from different protocols, in which case, the costs are not comparable. When this occurs, the preference is used to decide which route will be used.

Different protocols should not be configured with the same preference. If this occurs, the tiebreaker is based on the default preference as defined in Table 28. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.

The no form of this command reverts to the default value.

This command configures the reference bandwidth used to calculate the default costs of interfaces based on their underlying link speed.

The default interface cost is calculated as follows:

cost = reference-bandwidth ÷ bandwidth

The default reference-bandwidth is 100,000,000 Kb/s or 100 Gb/s, so the default auto-cost metrics for various link speeds are as follows:

The reference-bandwidth command assigns a default cost to the interface based on the interface speed. To override this default cost on a particular interface, use the metric metric command in the config>router>ospf>area>interface context.

The no form of this command reverts to the default value.

This command configures the router ID for the OSPF or OSPFv3 instance.

When configuring the router ID in the base instance of OSPF or OSPFv3, it overrides the router ID configured in the config>router context.

The default value for the base instance is inherited from the configuration in the config>router context. If the router ID in the config>router context is not configured, the following applies.

When configuring a new router ID, the instance is not automatically restarted with the new router ID. The next time the instance is initialized, the new router ID is used.

To force the new router ID to be used, issue the shutdown and no shutdown commands for the instance, or reboot the entire router.

The no form of this command reverts to the default value.

This command enables the context to configure OSPF or OSPFv3 timers. Timers control the delay between receipt of an LSA requiring a Dijkstra (Shortest Path First (SPF)) calculation and the minimum time between successive SPF calculations.

Changing the timers affects CPU utilization and network reconvergence times. Lower values reduce the convergence time but increase CPU utilization. Higher values reduce CPU utilization but increase the reconvergence time.

This command defines the minimum delay that must pass between receipt of the same LSAs arriving from neighbors.

Nokia recommends that the neighbor configured lsa-generate lsa-second-wait interval is equal or greater than the lsa-arrival timer configured here.

The no form of this command reverts to the default value.

This command customizes the throttling of OSPF or OSPFv3 LSA generation. Timers that determine when to generate the first, second, and subsequent LSAs can be controlled with this command. Subsequent LSAs are generated at increasing intervals of the lsa-second-wait timer until a maximum value is reached.

Configuring the lsa-arrival interval to equal or less than the lsa-second-wait interval configured in the lsa-generate command is recommended.

The no form of this command reverts to the default value.

This command defines the maximum interval between two consecutive SPF calculations in milliseconds. Timers that determine when to initiate the first, second, and subsequent SPF calculations after a topology change occurs can be controlled with this command. Subsequent SPF runs (if required) will occur at exponentially increasing intervals of the spf-second-wait interval. For example, if the spf-second-wait interval is 1000, the next SPF will run after 2000 milliseconds, and then next SPF will run after 4000 milliseconds, and so on, until it reaches the spf-wait value. The SPF interval will stay at the spf-wait value until there are no more SPF runs scheduled in that interval. After a full interval without any SPF runs, the SPF interval will drop back to the spf-initial-wait value.

The timer must be entered in increments of 100 milliseconds. Values entered that do not match this requirement will be rejected.

The no form of this command reverts to the default value.

This command enables the context to configure segment routing parameters within an IGP instance.

Segment routing adds to OSPF routing protocols the ability to perform shortest path routing and source routing using the concept of the abstract segment. A segment can represent a local prefix of a node, a specific adjacency of the node (interface or next-hop), a service context, or a specific explicit path over the network. For each segment, the IGP advertises an identifier referred to as a segment ID (SID).

When segment routing is used together with the MPLS data plane, the SID is a standard MPLS label. A router forwarding a packet using segment routing pushes one or more MPLS labels.

Segment routing using MPLS labels is used in both shortest path routing applications and traffic engineering applications. This command configures the shortest path forwarding application.

After segment routing is configured in the OSPF instance, the router performs the following operations.

When the user enables segment routing in an IGP instance, the main SPF and LFA SPF are computed, and the primary next-hop and LFA backup next-hop for a received prefix are added to the RTM without the label information advertised in the prefix SID sub-TLV.

The no form of this command reverts to the default value.

This command configures the prefix SID index range and offset label value for an IGP instance.

The user must configure the prefix SID index range and the offset label value that this IGP instance uses. Because each prefix SID represents a network global IP address, the SID index for a prefix must be unique in the network. Therefore, all routers in the network are expected to configure and advertise the same prefix SID index range for an IGP instance. However, the label value used by each router to represent this prefix, that is, the label programmed in the ILM, can be local to that router by the use of an offset label, referred to as a start label, as in the following:

Local Label (Prefix SID) = start-label + {SID index}

The label operation in the network becomes similar to LDP when operating in the independent label distribution mode (RFC 5036), with the difference that the label value used to forward a packet to each downstream router is computed by the upstream router based on the advertised prefix SID index using the preceding formula.

There are two mutually exclusive modes of operation for the prefix SID range on the router. In the global mode of operation, the user configures the global value and this IGP instance assumes the start label value is the lowest label value in the SRGB and the prefix SID index range size equal to the range size of the SRGB. When one IGP instance selects the global option for the prefix SID range, all IGP instances on the system are restricted to do the same. The user must shut down the segment routing context and delete the prefix-sid-range command in all IGP instances to change the SRGB. After the SRGB is changed, the user must re-enter the prefix-sid-range command. The SRGB range change fails if an already allocated SID index or label goes out of range.

In the per-instance mode of operation, the user partitions the SRGB into non-overlapping sub-ranges among the IGP instances. The user therefore configures a subset of the SRGB by specifying the start label value and the prefix SID index range size. All resulting net label values (start-label + index) must be within the SRGB or the configuration fails.

The code checks for overlaps of the resulting net label value range across IGP instances and strictly enforces that these ranges do not overlap. The user must shut down the segment routing context of an IGP instance to change the SID index or label range of that IGP instance using the prefix-sid-range command.

In addition, any range change will fail if an already allocated SID index or label goes out of range. The user can, however, change the SRGB on the fly as long as it does not reduce the current per-IGP instance SID index or label range defined in the prefix-sid-range command. Otherwise, the user must shut down the segment routing context of the IGP instance and delete and reconfigure the prefix-sid-range command.

The no form of this command reverts to the default value.

This command configures the maximum transmission unit (MTU) of all SR tunnels within each IGP instance.

The MTU of an SR tunnel populated into the TTM is determined like in the case of an IGP tunnel; for example, LDP LSP, based on the outgoing interface MTU minus the label stack size. Remote LFA can add at least two more labels to the tunnel for a total of three labels. There is no default value. If the user does not configure an SR tunnel MTU, the MTU is determined by IGP.

The MTU of the SR tunnel in bytes is determined as follows:

SR_Tunnel_MTU = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- (1+ frr-overhead)*4}

Where:

The SR tunnel MTU is dynamically updated whenever any of the preceding parameters used in its calculation changes. This includes when the set of tunnel next hops changes, or the user changes the configured SR MTU or interface MTU value.

The no form of this command reverts to the default value.

This command configures the TTM preference of shortest path SR tunnels created by the IGP instance. The TMM preference is used in the case of VPRN auto-bind or BGP transport tunnels when the new tunnel binding commands are configured to the any value, which parses the TTM for tunnels in the protocol preference order. The user can either use the global TTM preference or list the tunnel types they want to use. When they list the tunnel types explicitly, the TTM preference is used to select one type over the other. In both cases, a fallback to the next preferred tunnel type is performed if the selected one fails. Also, a reversion to a more preferred tunnel type is performed as soon as one is available.

The segment routing module adds an SR tunnel entry to the TTM for each resolved remote node SID prefix and programs the data path with the corresponding LTN with the push operation pointing to the primary and LFA backup NHLFEs.

The default preference for shortest path SR tunnels in the TTM is set lower than LDP tunnels but higher than BGP tunnels to allow controlled migration of customers without disrupting their current deployment when they enable segment routing. The following is the setting of the default preference for various tunnel types. This includes the preference of SR tunnels based on the shortest path (referred to as SR-OSPF).

The global default TTM preference for the tunnel types is as follows:

The default value for SR-OSPF is the same regardless of whether one or more OSPF instances programmed a tunnel for the same prefix. The selection of an SR tunnel in this case is based on the lowest IGP instance ID.

The no form of this command reverts to the default value.

This command enables traffic engineering route calculations constrained by nodes or links.

Traffic engineering enables the router to perform route calculations constrained by nodes or links. The traffic engineering capabilities of this router are limited to calculations based on link and nodal constraints.

The no form of this command disables traffic-engineered route calculations.

This command enables the context to configure an OSPF or OSPF3 area. An area is a collection of network segments within an AS that have been administratively grouped together. The area ID can be specified in dotted decimal notation or as a 32-bit decimal integer.

The no form of this command deletes the specified area from the configuration. Deleting the area also removes the OSPF or OSPF3 configuration of all the interfaces, virtual-links, and address-ranges that are currently assigned to this area.

This command creates ranges of addresses on an Area Border Router (ABR) for the purpose of route summarization or suppression. When a range is created, the range is configured to be advertised or not advertised into other areas. Multiple range commands may be used to summarize or hide different ranges. In the case of overlapping ranges, the most specific range command applies.

ABRs send summary link advertisements to describe routes to other areas. To minimize the number of advertisements that are flooded, you can summarize a range of IP addresses and send reachability information about these addresses in an LSA.

The no form of this command deletes the range advertisement or non-advertisement.

This command installs a low priority blackhole route for the entire aggregate. Exisiting routes that make up the aggregate will have a higher priority and only the components of the range for which no route exists are blackholed.

It is possible that when performing area aggregation, addresses may be included in the range for which no actual route exists. This can cause routing loops. To avoid this problem, configure the blackhole-aggregate option.

The no form of this command removes this option.

This command configures the metric used by the area border router (ABR) for the default route into a stub area.

The default metric should only be configured on an ABR of a stub area.

An ABR generates a default route if the area is a stub area.

The no form of this command reverts to the default value.

This command configures the key rollover interval.

The no form of this command resets the configured interval to the default setting.

This command enables the context to configure an OSPF or OSPFv3 NSSA and adds or removes the NSSA designation from the area.

NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF areas. The major difference between a stub area and an NSSA is that an NSSA has the capability to flood external routes that it learns throughout its area and via an ABR to the entire OSPF or OSPFv3 domain.

Existing virtual links of a non-stub area or NSSA area are removed when the designation is changed to NSSA or stub.

An area can be designated as stub or NSSA, but never both at the same time.

By default, an area is not configured as an NSSA area.

The no form of this command removes the NSSA designation and configuration context from the area.

This command enables the generation of a default route and its LSA type into an NSSA by an NSSA ABR or ASBR.

The functionality of the type-7 parameter and the type-nssa parameter is the same. The type-7 parameter is available in the ospf context; the type-nssa parameter is available in the ospf3 context. Include the type-7 or type-nssa parameter to inject a type 7 LSA default route instead of the type 3 LSA into the NSSA configured with no summaries.

To revert to a type 3 LSA, enter the originate-default-route command without the type-7 or type-nssa parameter.

When configuring an NSSA with no summaries, the ABR will inject a type 3 LSA default route into the NSSA area. Some older implementations expect a type 7 LSA default route.

The no form of this command disables origination of a default route.

This command enables the redistribution of external routes into the NSSA or an NSSA ABR that is exporting the routes into non-NSSA areas.

NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF or OSPFv3 areas. The major difference between a stub area and an NSSA is that the NSSA has the capability to flood external routes that it learns (provided it is an ASBR) throughout its area and via an Area Border Router to the entire OSPF or OSPFv3 domain.

The no form of this command disables the default behavior to automatically redistribute external routes into the NSSA area from the NSSA ABR.

This command enables the context to configure an OSPF or OSPF3 stub area and adds or removes the stub designation from the area.

External routing information is not flooded into stub areas. All routers in the stub area must be configured with the stub command. An OSPF or OSPF3 area cannot be both an NSSA and a stub area.

Existing virtual links of a non-stub or NSSA area will be removed when its designation is changed to NSSA or stub.

By default, an area is not a stub area.

The no form of this command removes the stub designation and configuration context from the area.

This command enables sending summary (type 3) advertisements into a stub area or NSSA on an ABR.

This parameter is particularly useful to reduce the size of the routing and link-state database (LSDB) tables within the stub or NSSA area.

By default, summary route advertisements are sent into the stub area or NSSA.

The no form of this command disables sending summary route advertisements and, for stub areas, only the default route is advertised by the ABR.

This command configures an interface with a static security association (SA) used to authenticate OSPFv3 packets.

The no form of this command removes the SA name from the configuration.

This command configures the password used by the OSPF or OSPFv3 interface or virtual-link to send and receive OSPF or OSPFv3 protocol packets on the interface when simple password authentication is configured.

All neighboring routers must use the same type of authentication and password for proper protocol communication. If the authentication-type is configured as password, his key must be configured.

By default, no authentication key is configured.

The no form of this command removes the authentication key.

This command enables authentication and specifies the type of authentication to be used on the OSPF or OSPFv3 interface.

Both password and message-digest authentication are supported.

By default, authentication is not enabled on an interface.

The no form of this command disables authentication on the interface.

This command enables the use of bidirectional forwarding (BFD) to control the state of the associated OSPF interface. By enabling BFD on an OSPF interface, the state of the interface is tied to the state of the BFD session between the local node and the remote node.

The optional remain-down-on-failure parameter can be specified on OSPF interfaces that are enabled for BFD to keep OSPF from reaching the full state if the BFD session to that neighbor cannot be established. This option is disabled by default and should be used only if there is a chance that unicast packets might be discarded while multicast packets are forwarded.

The no form of this command removes BFD from the associated OSPF adjacency.

This command configures the time, in seconds, that OSPF or OSPFv3 waits before declaring a neighbor router down. If no hello packets are received from a neighbor for the duration of the dead interval, the router is assumed to be down. The minimum interval must be two times the hello interval.

The no form of this command reverts to the default value.

This command configures export routing policies that determine the routes exported from the routing table to OSPF.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered overrides the previous command. A maximum of five policy names can be specified.

If an aggregate command is also configured in the config>router context, the aggregation is applied before the export policy is applied.

Routing policies are created in the config>router>policy-options context.

The no form of this command removes the specified policy-name or all policies from the configuration if no policy-name is specified.

This command configures the maximum number of routes (prefixes) that can be exported into OSPF from the route table.

The no form of this command removes the parameters from the configuration.

This command configures the interval between OSPF or OSPFv3 hellos issued on the interface or virtual link.

The hello-interval, in combination with the dead-interval, is used to establish and maintain the adjacency. Use this parameter to edit the frequency that hello packets are sent.

Reducing the interval, in combination with an appropriate reduction in the associated dead-interval, allows for faster detection of link or router failures at the cost of higher processing costs.

The no form of this command reverts to the default value.

This command enables the context to configure an OSPF or OSPFv3 interface.

By default, interfaces are not activated in any interior gateway protocol, such as OSPF or OSPFv3, unless explicitly configured.

The no form of this command deletes the OSPF interface configuration for this interface. The shutdown command in the config>router>ospf>interface context can be used to disable an interface without removing the configuration for the interface.

This command configures the interface type to be either broadcast or point-to-point.

Use this command to set the interface type of an Ethernet link to point-to-point to avoid having to carry the broadcast adjacency maintenance overhead of the Ethernet link provided the link is used as a point-to-point.

If the interface type is not known at the time the interface is added to OSPF or OSPFv3, and subsequently the IP interface is bound (or moved) to a different interface type, this command must be entered manually.

The no form of this command reverts to the default value.

This command instructs IGP to exclude a specific interface or all interfaces that are participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This reduces LFA SPF calculation where it is not needed.

When an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When it is excluded from the LFA SPF in OSPF, it is excluded in all areas. However, the loopfree-alternate-exclude command can only be executed under the area in which the specified interface is primary. If the command is enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.

The no form of this command reinstates the default value.

This command configures a message digest key when MD5 authentication is enabled on the interface. Multiple message digest keys can be configured.

The no form of this command removes the message digest key identified by the key-id.

This command configures an explicit route cost metric for the OSPF or OSPFv3 interface that overrides the metrics calculated based on the speed of the underlying link.

The no form of this command deletes the manually configured interface metric, so the interface uses the computed metric based on the reference-bandwidth command setting and the speed of the underlying link.

This command configures the OSPF or OSPFv3 interface MTU value used when negotiating an OSPF or OSPFv3 adjacency.

The operational OSPF or OSPFv3 MTU value is calculated as follows.

If this command is not configured:

If this command is configured:

for OSPF (not OSPFv3):

The port MTU must be set to 512 bytes or higher, since OSPF cannot support port MTU values lower than 512 bytes.

for OSPFv3:

To determine the actual packet size, add 14 bytes for an Ethernet packet and 18 bytes for a tagged Ethernet packet to the size of the OSPF or OSPFv3 (IP) packet MTU configured with this command.

If this command is configured to a value less than the interface or port MTU value, the OSPF or OSPFv3 MTU value will be used to transmit OSPF packets.

The no form of this command uses the value derived from the MTU configured in the config>port context.

This command assigns a node SID index or label value to the prefix representing the primary address of an IPv4 network interface of type loopback. Only a single node SID can be assigned to an interface. The secondary address of an IPv4 interface cannot be assigned a node SID index and does not inherit the SID of the primary IPv4 address.

This command fails if the network interface is not of type loopback or if the interface is defined in an IES or a VPRN context. Also, assigning the same SID index or label value to the same interface in two different IGP instances is not allowed within the same node.

The value of the label or index SID is taken from the range configured for this IGP instance. When using the global mode of operation, a new segment routing module checks that the same index or label value cannot be assigned to more than one loopback interface address. When using the per-instance mode of operation, this check is not required because the index and label ranges of the various IGP instance are not allowed to overlap.

The no form of this command reverts to the default value.

This command adds the passive property to the OSPF or OSPFv3 interface where passive interfaces are advertised as OSPF or OSPFv3 interfaces but do not run the OSPF or OSPFv3 protocol.

By default, only interface addresses that are configured for OSPF or OSPFv3 will be advertised as OSPF or OSPFv3 interfaces. The passive parameter allows an interface to be advertised as an OSPF or OSPFv3 interface without running the OSPF or OSPFv3 protocol.

While in passive mode, the interface will ignore ingress OSPF or OSPFv3 protocol packets and not transmit any OSPF or OSPFv3 protocol packets.

The no form of this command removes the passive property from the OSPF or OSPFv3 interface.

This command configures the priority of the OSPF or OSPFv3 interface that is used in an election of the designated router on the subnet.

This parameter is only used if the interface is of type broadcast. The router with the highest priority interface becomes the designated router. A router with priority 0 is not eligible to be the designated router or backup designated touter.

The no form of this command reverts the interface priority to the default value.

This command specifies the length of time that OSPF or OSPFv3 will wait before retransmitting an unacknowledged link state advertisement (LSA) to an OSPF neighbor.

The value should be longer than the expected round trip delay between any two routers on the attached network. When the retransmit-interval expires and no acknowledgement has been received, the LSA will be retransmitted.

The no form of this command reverts to the default interval.

This command configures the estimated time, in seconds, that it takes to transmit an LSA on the interface or virtual link.

The no form of this command reverts to the default delay time

This command configures a virtual link to connect area border routers to the backbone through a virtual link.

The backbone area (area 0.0.0.0) must be contiguous and all other areas must be connected to the backbone area. If it is not practical to connect an area to the backbone, the area border routers must be connected via a virtual link. The two area border routers will form a point-to-point like adjacency across the transit area. A virtual link can only be configured while in the area 0.0.0.0 context.

The router-id specified in this command must be associated with the virtual neighbor. The transit area cannot be a stub area or a NSSA.

The no form of this command deletes the virtual link.