3.9.1. Configuring the Router ID

The router ID uniquely identifies the router within an AS. In OSPF, routing information is exchanged between autonomous systems, groups of networks that share routing information. It can be set to be the same as the loopback (system interface) address. Subscriber services also use this address as far-end router identifiers when service distribution paths (SDPs) are created. The router ID is used by both OSPF and BGP routing protocols. A router ID can be derived by:

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is (re) initialized the new router ID is used. An interim period of time can occur when different protocols use different router IDs. To force the new router ID, issue the shutdown and no shutdown commands for each protocol that uses the router ID or restart the entire router.

The following is a sample router ID configuration output.

3.10.1. Configuring OSPF Parameters

The following is a sample basic OSPF configuration output.

3.10.2. Configuring OSPFv3 Parameters

Use the following syntax to configure OSPF3 parameters.

The following is a sample OSPF3 configuration output.

OSPF also supports the concept of multi-instance OSPFv2 and OSPFv3 which allows separate instances of the OSPF protocols to run independently within SR OSs.

Separate instances are created by adding a different instance ID as the optional parameter to the config>router>ospf and config>router>ospf3 commands. When this is done a separate OSPF instance is created which maintains separate link state databases for each instance.

3.10.3. Configuring an OSPF and OSPFv3 Area

An OSPF area consists of routers configured with the same area ID. To include a router in a specific area, the common area ID must be assigned and an interface identified.

If a network consists of multiple areas you must also configure a backbone area (0.0.0.0) on at least one router. The backbone is comprised of the area border routers and other routers not included in other areas. The backbone distributes routing information between areas. The backbone is considered to be a participating area within the autonomous system. To maintain backbone connectivity, there must be at least one interface in the backbone area or have a virtual link configured to another router in the backbone area.

The minimal configuration must include an area ID and an interface. Modifying other command parameters are optional.

Use the following syntax to configure an OSPF area.

Use the following syntax to configure an OSPFv3 area.

The following is a sample OSPF area configuration output.

3.10.4. Configuring an OSPF and OSPFv3 Stub Area

Configure stub areas to control external advertisements flooding and to minimize the size of the topological databases on an area's routers. A stub area cannot also be configured as an NSSA.

By default, summary route advertisements are sent into stub areas. The no form of the summary command disables sending summary route advertisements and only the default route is advertised by the ABR. This example retains the default so the command is not entered.

If this area is configured as a transit area for a virtual link, then existing virtual links of a non-stub or NSSA area are removed when its designation is changed to NSSA or stub.

Stub areas for OSPFv3 are configured the same as for OSPF.

Use the following syntax to configure an OSPF stub area.

The following is a sample stub configuration output.

3.10.5. Configuring a Not-So-Stubby Area

You must explicitly configure an area to be a Not-So-Stubby Area (NSSA) 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 an NSSA has the capability to flood external routes it learns throughout its area and by an area border router to the entire OSPF domain. An area cannot be both a stub area and an NSSA.

If this area is configured as a transit area for a virtual link, then existing virtual links of a non-stub or NSSA area are removed when its designation is changed to NSSA or stub.

Use the following syntax to configure an NSSA for OSPF.

Use the following syntax to configure stub areas for the OSPFv3.

The following is a sample NSSA configuration output.

The following is a sample OSPFv3 NSSA configuration output.

3.10.6. Configuring 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 then 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 parameter specified in the virtual-link command must be associated with the virtual neighbor, that is, enter the virtual neighbor’s router ID, not the local router ID. The transit area cannot be a stub area or an NSSA.

Use the following syntax to configure a virtual link.

The following is a sample virtual link configuration output.

3.10.7. Configuring an Interface

In OSPF, an interface can be configured to act as a connection between a router and one of its attached networks. An interface includes state information that was obtained from underlying lower level protocols and from the routing protocol. An interface to a network is associated with a single IP address and mask. If the address is merely changed, then the OSPF configuration is preserved.

The passive command enables the passive property to and from the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol. By default, only interface addresses that are configured for OSPF are advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol. When enabled, the interface will ignore ingress OSPF protocol packets and not transmit any OSPF protocol packets.

An interface can be part of more than one area, as specified in RFC5185. To do this, add the keyword secondary when creating the interface.

Use the following syntax to configure an OSPF interface.

The following is a sample interface configuration output.

3.10.8. Configuring Authentication

Authentication must be explicitly configured. The following authentication commands can be configured on the interface level or the virtual link level:

An special checksum is included in transmitted packets and are used by the far-end router to verify the packet by using an authentication key (a password). Routers on both ends must use the same MD5 key.

MD5 can be configured on each interface and each virtual link. If MD5 is enabled on an interface, then that interface accepts routing updates only if the MD5 authentication is accepted. Updates that are not authenticated are rejected. A router accepts only OSPF packets sent with the same key-id value defined for the interface.

When the hash parameter is not used, non-encrypted characters can be entered. When configured using the message-digest-key command, then all keys specified in the command are stored in encrypted format in the configuration file using the hash keyword. When using the hash keyword the password must be entered in encrypted form. Hashing cannot be reversed. Issue the no message-digest-key key-id command and then re-enter the command without the hash parameter to configure an unhashed key.

The following CLI commands are displayed to illustrate the key authentication features. These command parameters can be defined at the same time interfaces and virtual-links are being configured. See Configuring an Interface and Configuring a Virtual Link.

Use the following syntax to configure authentication.

The following is a sample authentication configuration output.

3.10.9. Assigning a Designated Router

A designated router is elected according to the priority number advertised by the routers. When a router starts up, it checks for a current designated router. If a designated router is present, then the router accepts that designated router, regardless of its own priority designation. When a router fails, then new designated and backup routers are elected according their priority numbers.

The priority command is only used if the interface is a broadcast type. The designated router is responsible for flooding network link advertisements on a broadcast network to describe the routers attached to the network. A router uses hello packets to advertise its priority. The router with the highest priority interface becomes the designated router. A router with priority 0 is not eligible to be a designated router or a backup designated router. At least one router on each logical IP network or subnet must be eligible to be the designated router. By default, routers have a priority value of 1.

Use the following syntax to configure the designated router.

The following is a sample priority designation output.

3.10.10. Configuring Route Summaries

Area border routers send summary (type 3) advertisements into a stub area or NSSA to describe the routes to other areas. This command is particularly useful to reduce the size of the routing and Link State Database (LSDB) tables within the stub or NSSA.

By default, summary route advertisements are sent into the stub area or NSSA. The no form of the summaries command disables sending summary route advertisements and, in stub areas, the default route is advertised by the area border router.

The following CLI commands are displayed to illustrate route summary features. These command parameters can be defined at the same time stub areas and NSSAs are being configured. See Configuring an OSPF and OSPFv3 Stub Area and Configuring a Not-So-Stubby Area.

Route summaries for OSPF3 are configured the same as for OSPF.

Use the following syntax to configure a route summary.

The following is a sample stub route summary configuration output.

The following is a sample stub route summary OSPv3 configuration output.

3.10.11. Configuring Route Preferences

A route can be learned by the router from different protocols, in which case, the costs are not comparable. When this occurs the preference value is used to decide which route is installed in the forwarding table if several protocols calculate routes to the same destination. The route with the lowest preference value is selected

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

Note: Preference for OSPF and OSPFv3 internal routes is configured with the preference command.

The following CLI commands are displayed to illustrate route preference features. The command parameters can be defined at the same time you are configuring OSPF. See Configuring OSPF Components.

Route parameters for OSPFv3 are configured the same as for OSPF.

Use the following syntax to configure a route preference.

The following is a sample route preference configuration output.

3.11.1. Modifying a Router ID

Since the router ID is defined in the config>router context, not in the OSPF configuration context, the protocol instance is not aware of the change. Re-examine the plan detailing the router ID. Changing the router ID on a device could cause configuration inconsistencies if associated values are not also modified.

After you have changed a router ID, manually shut down and restart the protocol using the shutdown and no shutdown commands in order for the changes to be incorporated.

Use the following syntax to change a router ID number.

The following is a sample NSSA router ID modification output.

3.11.2. Deleting a Router ID

You can modify a router ID, but you cannot delete the parameter. When the no router router-id command is issued, the router ID reverts to the default value, the system interface address (which is also the loopback address). If a system interface address is not configured, then the last 32 bits of the chassis MAC address is used as the router ID.

3.11.3. Modifying OSPF Parameters

You can change or remove existing OSPF parameters in the CLI or NMS. The changes are applied immediately.

The following is a sample OSPF modification in which an interface is removed and another interface added.

The following is a sample OSPF configuration output with the modifications entered in the previous sample.