This section provides information to configure Open Shortest Path First (OSPF) using the command line interface.
Topics in this section include:
Configuration planning is essential to organize routers, backbone, non-backbone, stub, NSSA areas, and transit links. OSPF provides essential defaults for basic protocol operability. You can configure or modify commands and parameters. OSPF is not enabled by default.
The minimal OSPF parameters which should be configured to deploy OSPF are:
This section provides information to configure OSPF and OSPF3 as well as configuration examples of common configuration tasks.
The minimal OSPF parameters that need to be configured are:
The following is an example of a basic OSPF configuration:
The following is an example of a basic OPSF3 configuration:
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.
It is possible to configure an SR OS to operate with an IPv6 only BOF and no IPv4 system interface address. When configured in this manner, the operator must explicitly define IPv4 router IDs for protocols such as OSPF and BGP as there is no mechanism to derive the router ID from an IPv6 system interface address.
The following displays a router ID configuration example:
Use the CLI syntax displayed below for:
The following displays a basic OSPF configuration example:
Use the following CLI syntax to configure OSPF3 parameters:
The following displays an OSPF3 configuration example:
OSFP 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.
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 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 CLI syntax to configure an OSPF area:
Use the following CLI syntax to configure an OSPF3 area:
The following displays an OSPF area configuration example:
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 OSPF3 are configured the same as OSPF stub areas.
Use the following CLI syntax to configure virtual links:
Use the following CLI syntax to configure virtual links for OSPF3:
The following displays a stub configuration example:
The following displays a stub configuration example:
The following displays a stub configuration example for the OSPF3:
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 CLI syntax to configure stub areas:
Use the following CLI syntax to configure stub areas for the OSPF3:
The following displays an NSSA configuration example:
The following displays a OSPF3 NSSA configuration example:
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 CLI syntax to configure stub areas:
The following displays a virtual link configuration example:
The following displays an OSPF3 virtual link configuration example:
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 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 RFC 5185. To do this, add the keyword secondary when creating the interface.
Use the following CLI syntax to configure an OSPF interface:
The following displays an interface configuration example:
The following displays an interface configuration:
This section includes the following topics:
The use of protocol authentication is recommended to protect against malicious attack on the communications between routing protocol neighbors. These attacks could aim to either disrupt communications or to inject incorrect routing information into the systems routing table. The use of authentication keys can help to protect the routing protocols from these types of attacks.
Authentication must be explicitly configured and can be done so through two separate mechanisms. First is configuration of an explicit authentication key and algorithm through the use of the authentication and authentication-type commands. The second method is through the use of the authentication keychain mechanism. Both mechanisms are described in the following sections.
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. Once 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, 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 CLI syntax to configure authentication:
The following displays authentication configuration examples:
The use of authentication mechanism is recommended to protect against malicious attack on the communications between routing protocol neighbors. These attacks could aim to either disrupt communications or to inject incorrect routing information into the systems routing table. The use of authentication keys can help to protect the routing protocols from these types of attacks. In addition, the use of authentication keychains provides the ability to configure authentication keys and make changes to them without affecting the state of the routing protocol adjacencies.
To configure the use of an authentication keychain within OSFP, use the following steps:
For a key entry to be valid, it must include a valid key, the current system clock value must be within the begin and end time of the key entry, and the algorithm specified in the key entry must be supported by the OSPF protocol.
The OSPF protocol supports the following algorithms:
Keychain Error handling:
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 CLI syntax to configure the designated router:
The following displays a priority designation example:
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 a Stub Area and Configuring a Not-So-Stubby Area.
Use the following CLI syntax to configure a route summary:
The following displays a stub route summary configuration example:
The following displays a stub route summary configuration example:
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 defined in Table 13. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.
Route Type | Preference | Configurable |
Direct attached | 0 | No |
Static routes | 5 | Yes |
OSPF internal | 10 | Yes 1 |
IS-IS level 1 internal | 15 | Yes |
IS-IS level 2 internal | 18 | Yes |
OSPF external | 150 | Yes |
TMS | 167 | No |
IS-IS level 1 external | 160 | Yes |
IS-IS level 2 external | 165 | Yes |
BGP | 170 | Yes |
Note:
If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision of what route to use is determined by the configuration of the ecmp in the config>router context.
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.
Use the following CLI syntax to configure a route preference:
Use the following CLI syntax to configure a route preference for the OSPF3:
The following displays a route preference configuration example:
The following displays a route preference configuration example:
This section discusses the following OSPF configuration management tasks:
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 CLI syntax to change a router ID number:
The following displays a NSSA router ID modification example:
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.
You can change or remove existing OSPF parameters in the CLI or NMS. 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: