When adding an object, you must click the Show Disabled link to see the line. Then, click the + for the command to enable it, and click configuration and select advanced . The commands that will be enabled by default are already enabled with their default values.

When editing an object, the line will already be enabled.

The remainder of this procedure assumes you have clicked Show Disabled. If you cannot see a command, make sure you expose the disabled commands.

Click + to enable the router-id command, then click the variable and enter the IPv4 address that should be used when sending any router updates from this device. No two routers in an OSPF system can have the same router ID, so ensure that it is unique in the area.

If you do not explicitly specify a router ID for the process, the system uses the highest IP address assigned to an active interface. Thus, the router ID can change if you disable the selected interface, or you change its addresses. By assigning a router ID explicitly, you ensure consistency for your process.

Click + to enable the configure summary-route-cost command, then click the variable and select either any , which turns off RFC 1583 compatibility, or rfc1583 , which turns it on.

Even though this command is not enabled by default in the OSPF object, in fact RFC 1583 compatibility is the default method used when calculating summary route costs. If you examine the configuration defined in the CLI, only the disabled setting is shown.

Routing loops can occur with RFC 1583 compatibility enabled. Disable it to prevent routing loops. Ensure that you set RFC 1583 compatibility the same on all OSPF routers in an OSPF routing domain.

Click + to enable the ignore lsa mospf command.

The system does not support LSA Type 6 MOSPF packets. You can enable this command so the system does not send syslog messages when it receives these packets, to reduce the noise in your syslog server.

The following distance commands are enabled by default. You can change OSPF route administrative distances based on route type. The distances are 1 to 255, with the higher numbers being less trusted than lower numbers. These metrics are used to judge the relative value of a learned route when comparing similar routes from different processes.

• distance ospf inter-area 110 . Click the number and set the distance for all routes from one area to another area.

• distance ospf intra-area 110 . Click the number and set the distance for all routes within an area.

• distance ospf external 110 . Click the number and set the distance for routes from other routing domains that are learned by redistribution.

The following timer commands are enabled with these default values.

• timers lsa arrival 1000 . Click the number and set the minimum interval at which the system accepts the same link-state advertisement (LSA) from OSPF neighbors, from 0 to 600000 milliseconds. Use this command to indicate the minimum interval that must pass between acceptance of the same LSA that is arriving from neighbors. LSAs arriving before this minimum time are ignored.

• timers pacing flood 33 . Click the number and set the time at which LSAs in the flooding queue are paced in-between updates, from 5 to 100 milliseconds.

• timers pacing lsp-group 240 . Click the number and set the interval at which OSPF link-state advertisements (LSAs) are collected into a group and refreshed, checksummed, or aged, from 10 to 1800 seconds.

• timers pacing retransmission 66 . Click the number and set the time interval at which LSAs in the retransmission queue are paced, 5 milliseconds to 200 milliseconds. We recommend that you do not change the packet retransmission pacing timer unless all other options to meet OSPF packet flooding requirements have been exhausted. Specifically, configure summarization, stub area usage, queue tuning, and buffer tuning before changing the default flooding timers.

• timers throttle lsa 0 5000 5000 . Click the numbers and set rate-limiting values for Open Shortest Path First (OSPF) link-state advertisement (LSA) generation. LSA and SPF throttling provide a dynamic mechanism to slow down LSA updates in OSPF during times of network instability and allow faster OSPF convergence. The values are:

  • Start Interval (first number)—The minimum delay to generate the first occurrence of an LSA, from 1 to 600000 milliseconds. The first instance of LSA is generated immediately after a local OSPF topology change. The next LSA is generated only after this start interval. Specify 0 to have LSAs generated without delay.

  • Hold Time (second number)—The minimum delay to generate the LSA again, from 1 to 600000 milliseconds. This value is used to calculate the subsequent rate limiting times for LSA generation.

  • Maximum Interval (third number)—The maximum delay to generate the LSA again, from 1 to 600000 milliseconds.

• timers throttle spf 5000 10000 10000 . Click the numbers and set rate-limiting values for the shortest path first (SPF) generation. The values are:

  • Start Interval (first number)—The delay to receive a change to the SPF calculation, from 1 to 600000 milliseconds.

  • Hold Time (second number)—The delay between the first and second SPF calculations, from 1 to 600000 milliseconds.

  • Maximum Interval (third number)—The maximum wait time for SPF calculations, from 1 to 600000 milliseconds.

Click + to enable the default-information originate command. You can optionally enable and configure the following commands to fine-tune the feature:

• default-information originate always . Always advertise a default route even if there is no default route.

• default-information originate metric 1 metric-type metric-type-value . The metric type and value for generating the default route.

  • Click the metric number and enter the OSPF default metric value, from 0 to 16777214. Unless you know you need a different value, enter 10.

  • Click the metric-type number and select 1 or 2 as the external link type associated with the default route advertised into the OSPF routing domain. The default is 2.

• default-information originate route-map route-map . Select a route map that specifies the routing process that generates the default route if the route map is satisfied.

The system can experience some known failure situations that should not affect packet forwarding across the switching platform. The Non-Stop Forwarding (NSF) capability allows data forwarding to continue along known routes, while the routing protocol information is being restored. This capability is useful when there is a component failure (for example, in HA, the active unit fails over to the standby unit, or in a cluster, the primary unit fails with a secondary unit being elected as new primary), or when there is a scheduled hitless software upgrade.

You can configure graceful restart on OSPFv2 by using either using NSF Cisco (RFC 4811 and RFC 4812) or NSF IETF (RFC 3623).

You can configure a device as NSF-capable or NSF-aware. A NSF-capable device can indicate its own restart activities to neighbors and a NSF-aware device can help a restarting neighbor.

• You can configure a device as NSF-aware irrespective of the mode in which it operates.

• A device has to be in either High Availability (failover) or Spanned Etherchannel (L2) cluster mode for you to configure it as NSF-capable.

To configure graceful restart:

This option is meaningful only if you configure the area to be a stub or NSSA, as explained below. Click + to enable to following command in the area properties:

area area-id default-cost 1

If necessary, enter the correct area ID. Then, click the number and enter the relative cost of the route, from 0 to 16777214. The default is 1. The higher the number, the less likely the route will be used over another route that applies for the destination.

You can filter prefixes advertised in Type 3 link-state advertisements (LSAs) between OSPFv2 areas of an area border router (ABR). Prefix filtering improves your control of route distribution between OSPF areas. With prefix filtering, you can allow only specified prefixes to be sent from one area to another area and restrict all other prefixes. You can apply this type of area filtering out of a specific OSPF area, into a specific OSPF area, or into and out of the same OSPF area at the same time.

Before configuring this command, you must create the prefix lists, which are Smart CLI objects, on the Device > Advanced Configuration page. You can configure separate prefix lists for inbound or outbound advertisements: select the direction for the filter-direction parameter.

area area-id filter-list prefix prefix-list filter-direction

Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the ABR into the stub area for destinations outside the autonomous system. You must use default routing in the stub area for it to work properly. To further reduce the number of LSAs sent into a stub area, you can use the no-summary keyword of the area stub command on the ABR to prevent it from sending a summary link advertisement (LSA Type 3) into the stub area.

To configure the area as a stub:

A not-so-stubby area (NSSA) is similar to a stub area. NSSA does not flood Type 5 external LSAs from the core into the area, but it can import autonomous system external routes in a limited way within the area.

NSSA imports Type 7 autonomous system external routes within an NSSA area by redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA area border routers (ABRs), which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation.

You can simplify administration if you are an ISP or a network administrator that must connect a central site using OSPFv2 to a remote site that is using a different routing protocol by running the connecting area as an NSSA. The connection between the corporate site border router and the remote router cannot be run as an OSPFv2 stub area because routes for the remote site cannot be redistributed into the stub area, which means that two routing protocols would have to be maintained. A simple protocol such as RIP would usually be run to handle the redistribution. With NSSA, you can extend OSPFv2 to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA.

Before you use this feature, consider these guidelines:

• You can set a Type 7 default route that can be used to reach external destinations. When configured, the router generates a Type 7 default into the NSSA or the NSSA area boundary router.

• Every router within the same area must agree that the area is NSSA; otherwise, the routers cannot communicate with each other.

To configure the area as an NSSA:

In OSPF, all areas must be connected to a backbone area. If the connection to the backbone is lost, it can be repaired by establishing a virtual link. You can configure virtual links to routers that are connected to the backbone area.

When you configure the area range command, the result is that a single summary route is advertised to other areas by the ABR. Routing information is condensed at area boundaries. External to the area, a single route is advertised for each address range. This behavior is called route summarization. You can configure multiple area range commands for an area. In this way, OSPF can summarize addresses for many different sets of address ranges.

To configure route summarization:

neighbor ip-address interface interface

• Click ip-address and enter the IP address of the neighbor router.

• Click interface and select the interface through which the system can reach the router.

If the IP address of the router is on the same network as the selected interface, a static route is not necessary. For example, if you select an interface whose IP address is 10.100.10.1/24, and the neighbor address is 10.100.10.2/24, you do not need a static route.

• advertising . Advertise routes that match the address.

• non-advertising . Suppress routes that match the address.

This value is not used by OSPF itself. It may be used to communicate information between autonomous system boundary routers (ASBR). If none is specified, then the remote autonomous system number is used for routes from BGP and EGP; for other protocols, zero (0) is used.

The primary reason to use tag values is for controlling redistribution based on the tag number. If you do not use it in your redistribution route maps, there is no need to configure it here.

There are two forms of the distribute-list out command, one with an identifier variable after the protocol variable, and one without the identifier. You can select the following protocols, but they are divided between these command versions based on whether you must provide the additional identifier information.

• connected . For routes established for networks that are directly connected to the system’s interfaces.

• static . For static routes you manually created.

• rip . For routes advertised to RIP.

• bgp automonous-system . For routes advertised to BGP. Click identifier and enter the autonomous system number for the BGP process defined on the system.

• eigrp automonous-system . For routes advertised to EIGRP. Click identifier and enter the autonomous system number for the EIGRP process defined on the system.

• ospf process-id . For routes advertised to OSPF. Click identifier and enter the process ID for the other OSPF process defined on the system.

• bgp , eigrp . Enter the autonomous system number.

• ospf . Enter the process ID number.

• connected , static , isis , rip . Enter none . Even if you enter a different value, it will be ignored.

For example, if you do not enable this command, a specific route for 10.100.10.0/24 would not be redistributed; instead, only a route for 10.0.0.0/8 would be redistributed.

If you do not apply a route map, all routes for the process (that fit the other commands configured for redistribution), are redistributed.

redistribute protocol metric metric-value metric-type metric-type-value

Click the variables and configure the following:

• metric . The metric value for the routes being distributed, from 0 to 16777214. When redistributing from one OSPF process to another OSPF process on the same device, the metric will be carried through from one process to the other if you do not specify a metric value. When redistributing other processes to an OSPF process, the default metric is 20.

• metric-type . The metric type is the external link type that is associated with the default route that is advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2 for a Type 2 external route. The default is 2.

These commands specify the criteria by which OSPF routes are redistributed into other routing domains.

• redistribute ospf match external 1 . Routes that are external to the autonomous system, but are imported into OSPF as Type 1 external routes.

• redistribute ospf match external 2 . Routes that are external to the autonomous system, but are imported into OSPF as Type 2 external routes.

• redistribute ospf match internal . Routes that are internal to a specific autonomous system.

• redistribute ospf match nssa-external 1 . Routes that are external to the autonomous system, but are imported into OSPF as Type 1 external routes and marked as Not-So-Stubby-Area (NSSA) only.

• redistribute ospf match nssa-external 2 . Routes that are external to the autonomous system, but are imported into OSPF as Type 2external routes and marked as Not-So-Stubby-Area (NSSA) only.