4.11.1. Configuring the Router ID

The router ID uniquely identifies the router within an AS. In OSPF, routing information is exchanged between autonomous systems, which are groups of networks that share routing information. The router ID can be set to be the same as the system interface address (loopback address). This is the default setting.

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 OSPF or restart the entire router.

Use the following CLI syntax to configure a router ID (in the config>router context):

The following displays a router ID configuration example:

4.11.2. Configuring an OSPF 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 your network consists of multiple areas, you must also configure a backbone area (0.0.0.0) on at least one router. The backbone contains the area border routers and other routers not included in other areas. The backbone distributes routing information between areas. To maintain backbone connectivity, there must be at least one interface in the backbone area or a virtual link must be configured to another router in the backbone area.

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

Use the following CLI syntax to configure an OSPF area (in the config>router context):

The following displays an OSPF area configuration example:

4.11.3. 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 itself. An interface to a network is associated with a single IP address and mask (unless the network is an unnumbered point-to-point network). If the address is removed from an interface, all OSPF data for the interface is also removed. If the address is merely changed, 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 associated with more than one area, as specified in RFC 5185. To enable an interface to be associated with multiple areas, include the secondary keyword when creating the interface.

Use the following CLI syntax to configure an OSPF interface in the config>router context:

The following displays an interface configuration example:

4.12.1. Configuring a Stub Area

Configure stub areas to control external advertisement 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. The area ID cannot be 0.0.0.0 – this address is reserved for the backbone area.

By default, summary route advertisements (type 3 LSAs) 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.

Stub areas cannot be used as transit areas. If the area was originally configured as a transit area for a virtual link, existing virtual links are removed when its designation is changed to NSSA or stub.

Use the following CLI syntax to configure a stub area:

The following displays a stub configuration example:

4.12.2. Configuring a Not-So-Stubby 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 can flood external routes that it learns throughout its area and from an area border router to the entire OSPF domain. An area cannot be both a stub area and an NSSA. The area ID cannot be 0.0.0.0 – this address is reserved for the backbone area.

NSSAs cannot be used as transit areas. If the area was originally configured as a transit area for a virtual link, existing virtual links are removed when its designation is changed to NSSA or stub.

Use the following CLI syntax to configure NSSAs:

The following displays an NSSA configuration example:

4.12.3. 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 possible or practical to connect an area to the backbone, the area border routers must be connected via a virtual link. 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 context of area 0.0.0.0. The transit area cannot be a stub area or an NSSA.

The router-id parameter specified in the virtual-link command must be associated with the virtual neighbor; that is, the router ID of the far-end router must be specified, not the local router ID.

Use the following CLI syntax to configure a virtual link:

The following displays a virtual link configuration example:

4.12.4. Configuring Authentication

Authentication must be explicitly configured and can be done using two separate mechanisms:

Either the authentication-key command or the auth-keychain command can be used by OSPF, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

Use the following CLI syntax to configure authentication:

The following displays authentication configuration examples:

Use the following CLI syntax to associate an interface or virtual link with an authentication keychain. The keychain must already be defined in the system>security>keychain context.

4.12.5. Assigning a Designated Router

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. If routers have the same priority, the designated router is elected based on the highest router ID. 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.

When a router starts up, it checks for a current designated router. If a designated router is present, the router accepts that designated router, regardless of its own priority designation. If the designated and backup designated routers fail, new designated and backup routers are elected according to their priority numbers or router IDs (in case of a priority tie).

Designated routers are used only in multi-access (broadcast) networks.

Use the following CLI syntax to configure the designated router:

The following displays a priority designation example:

4.12.6. Configuring Route Summaries

ABRs send summary advertisements (type 3 LSAs) into a stub area or NSSA to describe the routes to other areas. This command is particularly useful in order to reduce the size of the link-state database 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.

Use the following CLI syntax to configure a route summary:

The following displays a stub route summary configuration example:

4.12.7. Configuring Route Preferences

A router can learn routes from different protocols and distribute them into OSPF, 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 and used as the path to the destination. The route with the lowest preference value is selected.

The 7705 SAR supports the redistribution of static routes and routes from directly attached and aggregated networks into OSPF.

Different protocols should not be configured with the same preference. If this occurs, the tiebreaker is based on the default preferences as defined in Table 35.

If multiple routes are learned with an identical preference using the same protocol, the lowest-cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, the decision of what route to use is determined by the configuration of ECMP in the config>router context. Refer to the 7705 SAR Router Configuration Guide for information on ECMP.

Note: To configure a preference for static routes, use the config>router>static-route-entry context. Refer to the 7705 SAR Router Configuration Guide, “IP Router Command Reference”, for information.

Use the following CLI syntax to configure a route preference for OSPF internal and external routes:

The following displays a route preference configuration example:

4.13.1. Modifying a Router ID

Because the router ID is defined in the config>router context, not in the OSPF configuration context, the protocol instance is not aware of changes to the ID value. 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 CLI syntax to change a router ID number:

The following displays an NSSA router ID modification example:

4.13.2. Deleting a Router ID

You can modify a router ID, but you cannot delete the parameter. If 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, the last 4 bytes of the chassis MAC address are used as the router ID.

4.13.3. Modifying OSPF Parameters

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

The following example displays an OSPF modification in which an interface is removed and another interface added.

The following example displays the OSPF configuration with the modifications entered in the previous example: