3.13. Configuring OSPF with CLI
This section provides information to configure Open Shortest Path First (OSPF) using the command line interface.
3.13.1. OSPF Configuration Guidelines
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:
- Router IDEach router running OSPF must be configured with a unique router ID. The router ID is used by both OSPF and BGP routing protocols in the routing table manager.When configuring a new router ID, protocols will not automatically be restarted with the new router ID. Shut down and restart the protocol to initialize the new router ID.
- OSPF instanceOSPF instances must be defined when configuring multiple instances and/or the instance being configured is not the base instance.
- An areaAt least one OSPF area must be created. An interface must be assigned to each OSPF area.
- InterfacesAn interface is the connection between a router and one of its attached networks. An interface has state information associated with it, which is obtained from the underlying lower level protocols and the routing protocol itself. An interface to a network has associated with it a single IP address and mask (unless the network is an unnumbered point-to-point network). An interface is sometimes also referred to as a link.
3.13.2. Basic OSPF Configurations
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:
- A router ID - If a router-id is not configured in the config>router context, the router’s system interface IP address is used.
- One or more areas.
- Interfaces (interface "system").
The following is an example of a basic OSPF configuration:
The following is an example of a basic OPSF3 configuration:
3.13.2.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:
- Defining the value in the config>router router-id context.
- Defining the system interface in the config>router>interface ip-int-name context (used if the router ID is not specified in the config>router router-id context).
- Inheriting the last four bytes of the MAC address.
- On the BGP protocol level, a BGP router ID can be defined in the config>router>bgp router-id context and is only used within BGP.
- Defining a router ID when creating an OSPF instance config>router>ospf [instance-id] [router-id]
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:
3.13.3. Configuring OSPF Components
Use the CLI syntax displayed in the following subsections to configure OSPF components.
3.13.3.1. Configuring OSPF Parameters
The following displays a basic OSPF configuration example:
3.13.3.2. Configuring OSPF3 Parameters
Use the following CLI syntax to configure OSPF3 parameters:
The following displays an OSPF3 configuration example:
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.13.3.3. Configuring an OSPF or OSPF3 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 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:
3.13.3.4. Configuring a 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 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:
3.13.3.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 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:
3.13.3.6. Configuring a Virtual Link
The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see Area 0.0.0.5 in Figure 13) then the area border routers (such as routers Y and Z) must be connected via a virtual link. The two area border routers form a point-to-point-like adjacency across the transit area (see Area 0.0.0.4). A virtual link can only be configured while in the area 0.0.0.0 context.
Figure 13: OSPF Areas
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:
3.13.3.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 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:
3.13.3.8. Configuring Authentication
3.13.3.8.1. Overview
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.
3.13.3.8.2. Configuring Authentication Keys and Algorithms
The following authentication commands can be configured on the interface level or the virtual link level:
- authentication-key — Configures the password used by the OSPF interface or virtual-link to send and receive OSPF protocol packets on the interface when simple password authentication is configured.
- authentication-type — Enables authentication and specifies the type of authentication to be used on the OSPF interface, either password or message digest.
- message-digest-key — Use this command when message-digest keyword is selected in the authentication-type command. The Message Digest 5 (MD5) hashing algorithm is used for authentication. MD5 is used to verify data integrity by creating a 128-bit message digest from the data input. It is unique to that specific data.
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. After 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:
3.13.3.8.3. Configuring Authentication using Keychains
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 OSPF, use the following steps:
- Configure an authentication keychain within the config>system>security context. The configured keychain must include at least on valid key entry, using a valid authentication algorithm for the OSPF protocol.
- Associate the configure authentication keychain within OSPF. Authentication keychains can be used to specify the authentication key and algorithm on a per interface basis within the configuration for the OSPF protocol.
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:
- clear text password
- MD5
- HMAC-SHA-1-96
- HMAC-SHA-1
- HMAC-SHA-256
Keychain Error handling:
- If a keychain exists but there are no active key entries with an authentication type that is valid for the associated protocol, then inbound protocol packets will not be authenticated and discarded and no outbound protocol packets will be sent.
- If keychain exists, but the last key entry has expired, a log entry will be raised indicating that all keychain entries have expired. The OSPF protocol requires that the protocol continue to authenticate inbound and outbound traffic using the last valid authentication key.
3.13.3.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 CLI syntax to configure the designated router:
The following displays a priority designation example:
3.13.3.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 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:
3.13.3.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 defined in Table 10. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.
Table 10: Route Preference Defaults by Route Type
Route Type | Preference | Configurable |
Direct attached | 0 | — |
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 |
IS-IS level 1 external | 160 | Yes |
IS-IS level 2 external | 165 | Yes |
BGP | 170 | Yes |
- Preference for OSPF internal routes is configured with the preference command.
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:
3.13.4. Configuration Example of LFA Policy use in Remote LFA and TI-LFA
Figure 14 shows a sample network topology that uses the OSPF routing protocol and in which the user assigns an SRLG ID to each group of OSPF links to represent fate-sharing among the links in the group. Assume the router ecmp value is set to 1.
Figure 14: Application of LFA Policy to RLFA and TI-LFA
The user wants to enforce that the LFA backup computed and programmed by each node for a given destination prefix avoids the SRLG ID of the primary next hop of that prefix. To that effect, the user applies an LFA policy to each link that is used as a primary next hop to reach destination prefixes.
For instance, node F uses the top interface to node C as the primary next hop for the SR-OSPF tunnel to the SID of node C. The LFA policy states that the LFA backup must exclude outgoing interfaces which are member of SRLG ID of the interface of the primary next hop. Therefore, node F must select an LFA backup that avoids SRLG ID=SrlgGroup_1.
Node F enabled base LFA, remote LFA with node-protect, and TI-LFA with node-protect on the OSPF routing instance. The LFA SPF yields the following candidate LFA backup paths for the tunnel to the SID of node C:
- Base LFA returns two backup paths: next hop over the second interface to C (cost 10) and next hop over the interface to node E (cost 20).After applying the LFA policy, only next hop over the interface to node E (cost 20) remains. The second interface to node C is also a member of SRLG ID=SrlgGroup_1 and therefore the LFA next hop using it is excluded.
- TI-LFA returns a single backup path: the next hop over the second interface to C (cost 10).After applying the LFA policy, no LFA backup path remains.
- Remote LFA returns two backup paths: one backup path by PQ node C over the second interface to C (cost 10) and one by PQ node E over the interface to node E (cost 20).After applying the LFA policy, only the backup path by PQ node E over the interface to node E (cost 20) remains.
- The LFA backup paths found by all three LFA methods are only link-protecting because node C is a neighbor of node F.
- The final outcome is the selection among the LFA methods and base LFA is preferred to RLFA; therefore, next hop over the interface to node E (cost 20) is selected and programmed by node F as the backup path for the SR-OSPF tunnel to the SID of node C.
- The adjacency from node F to node C over first interface to node C also inherits the same LFA backup path as the node SID of C since the same LFA policy applies.
The following are excerpts of the CLI configuration of node F in this specific example. The commands relevant to the LFA policy applied to link F-C as identified by arrows.
In addition, the output of show commands in node F highlights both the primary and the link-protect base LFA backup for both the node SID tunnel to C and the adjacency SID tunnel over the first interface to node C.
Because C is the termination for both its node SID and the adjacency SID tunnels from node F, only link protection can be provided as shown by the output of show command tools>dump>router>ospf sr-database (field L(R)). However, the output of the same show command for the tunnel to the SID of node D indicates the base LFA backup over the direct interface to node D is node-protecting (field Tn(R)).
3.14. OSPF Configuration Management Tasks
This section discusses OSPF configuration management tasks.
3.14.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 CLI syntax to change a router ID number:
The following displays a NSSA router ID modification example:
3.14.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.14.3. Modifying OSPF Parameters
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: