OSPF - 3 - OSPF Configuration details

OSPF Costs and Clearing the OSPF Process

The following list summarizes how IOS chooses OSPF interface costs:
  1. Set the cost per neighbor using the neighbor neighbor cost value command.(This is valid only on OSPF point-to-multipoint nonbroadcast network types.)
  2. Set the cost per interface using the ip ospf cost value interface subcommand.
  3. Allow the cost to default based on interface bandwidth and the OSPF Reference Bandwidth(Ref-BW) (default 10 5 Kbps). The formula is Ref-BW/bandwidth (Kbps).
  4. Default based on bandwidth, but change Ref-BW using the  auto-cost reference-bandwidth value command within the OSPF process.  

Regardless of the network or ip ospf area command, OSPF will always establish adjacencies over an interface only using the primary IP address. OSPF will never use secondary addresses to establish an adjacency.

OSPF Filtering  

Link-state protocols do not advertise routes—they advertise topology information. Also, SPF loop prevention relies on each router in the same area having an identical copy of the LSDB for that area. 

Three major types of OSPF filtering are as follows:

  -Filtering routes, not LSAs: Using the distribute-list in command, a router can filter the routes that its SPF process is attempting to add to its routing table, without affecting the LSDB.   

  -ABR type 3 LSA filtering: A process of preventing an ABR from creating particular type 3 summary LSAs.   

  -Using the area range no-advertise option: Another process to prevent an ABR from creating specific type 3 summary LSAs.    

Filtering Routes Using the distribute-list Command  

For RIP and EIGRP, the distribute-list command can be used to filter incoming and outgoing routing updates. With OSPF, the distribute-list in command filters what ends up in the IP routing table, and only on the router on which the  distribute-list in command is configured.

The following rules govern the use of distribute lists for OSPF:
  -The distribute list in the inbound direction applies to results of SPF—the routes to be installed into the router’s routing table.
  -The distribute list in the outbound direction applies only to redistributed routes and only on an ASBR; it selects which redistributed routes shall be advertised.
  -The inbound logic does not filter inbound LSAs; it instead filters the routes that SPF chooses to add to that one router’s routing table.    -If the distribute list includes the incoming interface parameter, the incoming interface is checked as if it were the outgoing interface of the route. (If the router learn a route through that interface, outgoing interface of the route is that interface.)

The distribute-list route-map option allows a much greater variety of matching parameters, and much more detailed logic with route maps.

OSPF ABR LSA Type 3 Filtering 

Type 3 LSAs do not contain detailed information about the topology of the originating area; instead, each type 3 LSA represents a subnet, and a cost from the ABR to that subnet. The OSPF ABR type 3 LSA filtering feature allows an ABR to filter type 3 LSAs at the point where the LSAs would normally be created.

Use the area number filter-list prefix name in | out command under router ospf. The referenced prefix-list is used to match the subnets and masks to be filtered. The area number and the in | out option of the area filter-list command work together, as follows: When in is configured, IOS filters prefixes going into the configured area; when out is configured, IOS filters prefixes coming out of the configured area. E.g. area 3 filter-list prefix filter-type3-10-3-2-0 out command filters the route from going out of area 3; so this route is not received in any other area.

Filtering Type 3 LSAs with the area range Command  

The third method to filter OSPF routes is to filter type 3 LSAs at an ABR using the area range command. The area range command performs route summarization at ABRs, telling a router to cease advertising smaller subnets in a particular address range, instead creating a single type 3 LSA whose address and prefix encompass the smaller subnets. When the  area range  command includes the  not-advertise  keyword, not only are the smaller component subnets not advertised as type 3 LSAs, but the summary route is also not advertised as a type 3 LSA either. this command has the same effect as the area filter-list command with the out keyword.

Virtual Link Configuration

An OSPF virtual link allows a pair of possibly remote routers to create a targeted OSPF session across the IP network. The virtual link is internally represented as an unnumbered point-to-point link between the two endpoint routers and exists in the backbone area, regardless of the area through which it is created. The area through which the virtual link is created is called a transit area and it must be a regular area. Note that the virtual link cannot pass through a transit area that is a stubby area. The area virtual link commands point to the other router's RID, and the transit area over which the virtual link exists. 

Configuring Classic OSPF Authentication

The basic rules for configuring OSPF authentication are as follows:   

  -Three types are available: type 0(none), type 1(clear text), and type 2(MD5).   

  -Authentication is enabled per interface using the ip ospf authentication interface subcommand.   

  -The default authentication is type 0(no authentication).   

  -The default can be redefined using the area authentication subcommand under router ospf .   

  -The keys are always configured as interface subcommands.   

  -Multiple MD5 keys with different key IDs are allowed per interface. This allows for graceful key migration where a new key can be added without disrupting the adjacencies. 

Configuration examples

interface FastEthernet0/0 

 ip ospf authentication //enables type 1 auth

 ip ospf authentication-key key-t1  //defines the simple text key

interface FastEthernet0/0 

 ip ospf authentication message-digest //enables type 2 auth

 ip ospf message-digest-key 1 md5 key-t2 //defines the key

show ip ospf int fa 0/0 //show ospf auth type

The area authentication command simply tells the router to change that router’s default OSPF authentication type for all interfaces in that area.

Because virtual links have no underlying interface on which to configure authentication, authentication is configured on the area virtual-link command itself.

Configuring Extended Cryptographic OSPF Authentication 

To utilize the SHA-HMAC authentication, OSPF uses key chains similarly to EIGRP or RIPv2. Key facts:

  -Each key in the key chain must have a cryptographic algorithm configured using a per-key cryptographic-algorithm command.

  -Each key in a key chain can be configured with the send-lifetime and accept-life-time keywords to limit its usability to a particular timeframe. If multiple keys in the key chain are eligible to sign egress packets, the key with the highest key ID will be used. Be aware that this behavior differs from RIPv2 and EIGRP that select the key with  the lowest key ID. 

  -The key rollover procedure as used by classic OSPF is not used with key chains. To sign egress packets, OSPF will always use the valid key with the highest key ID in the key chain. To authenticate ingress packets, OSPF will try to use the key indicated in the received packet. There is no key migration phase of sending multiple OSPF packets signed with different valid keys.   

  -The extended cryptographic authentication is enabled per interface using the ip ospf authentication key-chain key-chain-name interface subcommand using its extended syntax, referring to a particular key chain.

  -Using the extended cryptographic authentication on virtual links is accomplished using the area area-id virtual-link router-id key-chain key-chain-name OSPF-level command.   

  -MD5 authentication is one of the supported cryptographic algorithms in key chains. An OSPF router configured for MD5 authentication using the classic commands will be able to interoperate with a router configured using the new key chain style.

OSPF authentication is a good place for tricky CCIE lab questions—ones that can be solved in a few minutes if you know all the intricacies.

Protecting OSPF Routers with TTL Security Check  

If all OSPF routers sent their packets with TTL set to 255, receiving an OSPF packet with its TTL less than 255 would be a clear indication that the packet originated outside the network segment over which it was received. TTL Security Check can be activated either on a per-interface basis using the ip ospf ttl-security interface level command, or globally for all interfaces in a particular OSPF process using the ttl-security all-interfaces command and ip ospf ttl-security disable command to exempt the interface. All OSPF packets sourced by that interface have their TTL set to 255, and only packets received with a TTL of 255 are accepted.

Both these commands have an optional hops hop-count argument that allows relaxing the TTL Security Check. Using the hops  hop-count command influences what OSPF packets will be accepted; it has no impact on the TTL of OSPF packets originated by the router, which will remain at 255.

The minimum hop-count value is 1 (meanin pakcets with TTL of 254 is accepted). Whenever an OSPF packet is received by a router, its TTL is first decremented by 1(this decrement is skipped if the packet’s TTL is equal to 1), and the packet is then passed to OSPF and to TTL Security Check, which will act based on this decremented TTL value. Neither the ttl-security all-interface nor the ip ospf ttl-security command has any impact on configured virtual or sham links.

Tuning OSPF Performance

Tuning the SPF Scheduling with SPF Throttling  

If a router continuously keeps receiving updated LSAs, the delay before the upcoming SPF run should progressively grow to dampen the negative impact of the flapping in network. By default, Cisco routers will schedule an SPF run 5 seconds after receiving an updated LSA, and if an updated LSA arrives after this SPF run, the subsequent delay will grow up to 10 seconds.

The scheduling of SPF runs can be controlled by a feature called SPF Throttling. This feature defines a variable-length wait interval between two consecutive SPF runs. There are three parameters controlling this feature called spf-start, spf-hold, and spf-max-wait.

The SPF Throttling feature is configured by a single timers throttle spf spf-start spf-hold spf-max-wait command in the  router ospf section. All arguments are indicated in milliseconds. Current values can be also verified in show ip ospf  output and, debug ip ospf spf statistic command can be used to verify the current and next wait intervals.

Tuning the LSA Origination with LSA Throttling 

To control the rate at which a particular LSA might be reoriginated by its originating router. The idea behind LSA Throttling is precisely the same as with SPF Throttling. The mechanism is again driven by three values: start interval, hold-interval, and max-interval.
By default, Cisco routers are configured to originate an updated LSA immediately and delay its subsequent origination by 5 seconds and not to progressively increase this interval. That is, start-interval is 0, and hold-interval and max-interval  are set to 5000 milliseconds. The LSA Throttling feature is configured using a single timers throttle lsa all start-interval hold-interval max-interval command in OSPF configuration. The parameters are again expressed in milliseconds. Use debug ip ospf database-timer rate-limit command to verify.

Apart from throttling the LSA origination, a router can also be configured to ignore the same LSA upon arrival if it appears to arrive too often. This throttling of arriving LSAs is configured using the  timers lsa arrival milliseconds OSPF command. If two or more same LSAs arrive less than  milliseconds  apart, only the first one is accepted and the remaining LSAs are dropped. In effect, the same LSA is accepted only if it arrives more than  milliseconds  after the previous accepted one. The default setting is 1000 milliseconds and can be seen in the show ip ospf output.

OSPFv2 Prefix Suppression  
In large and densely interconnected networks, a significant amount of space in LSDBs and resulting routing tables is occupied by transit link prefixes—that is, IP networks on inter-router links without end hosts.

OSPF Stub Router Configuration
OSPF stub router feature allows a router to either temporarily or permanently be prevented from becoming a transit router.

OSPF Graceful Restart
Graceful OSPF Restart(GR) allows a router to restart while its neighbors continue to forward packets to the restarting router as if it was up and running. This approach is sometimes called “routing through a failure". Cisco also implemented this feature earlier called Non Stop Forwarding(NSF). Two classes of devices are involved in GR/NSF. The router undergoing the graceful

restart is said to be in the graceful restart mode; Its directly connected neighbors are said to be in the  helper mode during the graceful restart. Helper neighbors assist in pretending that the router undergoing a graceful restart is up and running. Every router can act as a helper provided that the support is available in the IOS. However, only routers with specific hardware support can perform the graceful restart themselves. Cisco use terms- NSF-aware  devices, which can act only as helper devices, and NSF-capable devices,  which can act both as helpers and can also perform a graceful restart themselves.

It is possible to continue forwarding without loops while the routing process restarts, assuming that the following conditions are true:
  -The router’s hardware construction allows
  -The router whose OSPF process is restarting must notify its neighbors that the restart is going to take place by sending a “grace LSA,” which is a type 9 opaque LSA with link-local flooding scope, containing the estimated duration of restart (the grace period), the reason of the restart, and on multiaccess networks, the IP address of the restarting router.  
  -All the neighbors support, and are configured for, graceful restart helper mode.  
  -The restart takes place within a specific grace period.  

Both Cisco and IETF NSF awareness are enabled by default in Cisco IOS. Disabling it requires a routing process command for each NSF version, nsf [cisco | ietf] helper disable. 

OSPF Graceful Shutdown

The Graceful Shutdown feature allows an OSPF process to update the neighbors that the router is going down. Using a simple shutdown command in the router ospf mode, the router will immediately  

  -Drop all OSPF adjacencies   

  -Flush all LSAs it has originated (flood them with the age set to 3600 seconds)   

  -Send out Hello packets to its neighbors with the DR/BDR fields set to 0.0.0.0 and an empty neighbor list, prompting the neighbors’ adjacency states to fall back to the Init state   

  -Stop sending and receiving OSPF packets

The Graceful Shutdown feature can also be configured on a per-interface basis using the ip ospf shutdown command.

OSPFv3  

Mostly OSPFv2 and OSPFv3 protocols are simply different because of the differences in the underlying Layer 3 protocol. Key differences between OSPFv2 and OSPFv3 include the following:   

  -Configured using interface commands: To enable OSPFv3 process ID(PID) 1 and area 2 on a given interface, the basic command is simply ipv6 ospf 1 area 2. Issuing this command also creates the ipv6 router ospf 1  command in global configuration mode.   

  -Advertising multiple networks on an interface: If multiple IPv6 addresses are configured on an interface, OSPFv3 advertises all the corresponding networks.   

  -OSPFv3 RID must be set: OSPFv3 can automatically set its 32-bit RID based on the configured IPv4 addresses, using the same rules for OSPFv2. OSPFv3 cannot automatically choose its RID. You must manually configure the RID before OSPFv3 will start. 

  -Flooding scope: The scope for flooding LSAs is one of three specific types in OSPFv3:   

  -Link-local scope: Used by the new LSA type, Link LSA. 

  -Area scope: For LSAs flooded throughout a single OSPFv3 area. Used by Router, Network, Inter-Area Prefi x, Inter-Area Router, and Intra-Area Prefix LSA types.   

  -AS scope: LSAs of this type are flooded throughout the routing domain; this is used for AS External LSAs.

  -Multiple instances per link: The instance must match on all routers that are to become adjacent on a link.   

  -Terminology: OSPFv3 uses the term link  for what OSPFv2 calls a network.    

  -Sources packets from link-local addresses: With the exception of virtual links, OSPFv3 uses link-local addresses for all communications between neighbors and sources packets from link-local addresses. On virtual links, OSPFv3 sources packets from a globally scoped IPv6 address.   

  -Authentication: OSPFv2 natively supports three authentication types. OSPFv3, however, does not itself provide authentication because IPv6 covers this requirement with its internal support for AH and ESP protocols.

  -Networks in LSAs: Whereas OSPFv2 expresses networks in LSAs as [address, mask], OSPFv3 expresses networks in LSAs as [prefix, prefix length].

OSPFv3 LSA Types  

OSPFv3 LSA types are basically the same as OSPFv2 LSAs, except for their slightly different names and the additions of type 8 and 9 LSAs

In OSPFv3, the type 1 and 2 LSAs no longer carry any addressing information. They only carry a description of topology adjacencies—what other object is a router or a multiaccess network connected to, using router RIDs as an address-independent way of referring to a neighboring object. 

IPv6 prefixes on individual interfaces of a router are  carried in a type 9 LSA (Intra-Area-Prefix LSA) with the area flooding scope. Moreover, as IPv6 unicast routing uses link-local addresses as next-hop addresses, each router advertises its link-local address in a type 8 LSA (Link LSA) sent out the particular interface. Type 8 LSAs have the link flooding scope and are never flooded beyond the receiving neighbor on the link. 

With this separation of topology and addressing information, if an interface address changes, only an updated Link LSA and Intra-Area-Prefix LSA will be originated and flooded. Type 1 and 2 LSAs will not change. Therefore, routers do not need to schedule a new SPF run but merely update the prefixes located in an already computed shortest-path tree.

OSPFv3 in NBMA Networks  

OSPFv3 operates in NBMA networks almost exactly like OSPFv2. 

R1(config-if)#ipv6 ospf neighbor fe80::1 Note that the address in the command must be a link-local address of the neighbor; other addresses will be rejected. OSPFv3 neighbor relationships over NBMA networks take a relatively long time to form(a minute or two), even on high-speed media. Remember that NBMA OSPF peers require neighbor  statements is the saying, “nonbroadcast needs neighbors.”  

Configuring OSPFv3 over Frame Relay  

The configuration of frame-relay map statements is much the same in IPv6, but there are a couple of twists: First, there is no InverseARP for IPv6. All IPv6/DLCI mappings therefore have to be configured manually. Second, the mappings must be created both for the link-local and the global addresses of the neighbor’s interface. Only the link-local mapping statement requires the  broadcast keyword.

Enabling and Configuring OSPFv3 

After basic IPv6 addressing and reachability are configured and working, the OSPFv3 configuration process includes these steps:   

  Step 1. Identify the desired links connected to each OSPFv3 router.   

  Step 2. Determine the OSPF area design and the area to which each router link (interface) should belong.   

  Step 3. Identify any special OSPF routing requirements, such as stub areas, address summarization, LSA filtering, and virtual links.   

  Step 4. Configure OSPF on the interfaces.   

  Step 5. Configure routing process commands, including a router ID on IPv6-only routers.   

  Step 6. Verify OSPF configuration, routing tables, and reachability.    

Like IPv4, setting the network type of a loopback address to point-to-point makes the route to this loopback appear in router's routing table as a /64 network rather than as a /128 network(a host route). The show ipv6 interface brief command displays both the unicast and link-local addresses. The show ipv6 protocols command gives the best summary of OSPFv3 configuration by interface and OSPF area. 

OSPFv3 Authentication and Encryption   

One area in which OSPFv3 is arguably simpler than OSPFv2, at the protocol operation level, is that it uses IPv6’s native authentication support rather than implementing its own authentication mechanisms. To enable IPv6 OSPF authentication using AH, issue the ipv6 ospf authentication command. To enable encryption using ESP, issue the ipv6 ospf encryption command. These are interface configuration commands. With OSPFv3 on a single interface—if you configure ipv6 ospf authentication, you cannot add ipv6 ospf encryption and vice versa.

Configuring OSPFv3 authentication or encryption requires selecting cryptographic algorithms for hashing or encryption, and supplying keys of appropriate length that are used during hashing(IPsec uses keyed hashing) and encryption. Together, the selected mode of operation plus the cryptographic algorithms and keys form a so-called security association that defines how packets should be protected by IPsec. A security association is identified by a number called the Security Parameter Index (SPI). Each OSPFv3 packet protected by IPsec carries the SPI number of the security association used to protect it, and the receiving router uses the SPI to identify the security association to process the packet to decrypt and authenticate it.

Key things to know about OSPFv3 authentication and encryption: 

  -OSPFv3 can use AH for authentication.   

  -OSPFv3 can use ESP for authentication and encryption.   

  -OSPFv3 can use authentication trailer for authentication.   

  -OSPFv3 IPsec-based authentication and encryption can be applied per area or per link (interface); per-link configuration is more secure because it creates more layers of security.   

  -Routers that directly exchange IPsec-protected OSPFv3 packets must use the same SPI number, AH or ESP mode, cryptographic algorithms, and keys for the encryption/decryption and authentication to succeed.   

  -Routers that directly exchange authentication trailer–protected OSPFv3 packets must use the same cryptographic algorithms, key IDs, and key strings for the authentication to succeed.     

OSPFv3 Address Family Support 

OSPFv3 was augmented with an instance ID that allows multiple OSPFv3 processes to communicate over the same link while remaining separate. The entire range of instance IDs can be effectively split into several categories for different address families. 

    Multiple address family support in OSPFv3 works by OSPFv3 running a completely separate instance for each configured address family. If not specified explicitly, these in stances will choose their base instance IDs automatically(0 for IPv6, 64 for IPv4). There is no information shared between individual instances, even if they run under a single OSPFv3 process. 

    Routers supporting address families will nicely establish adjacencies for an IPv6 unicast address family with non-AF-compliant neighbors running instance IDs 0–31. Beyond this range, only neighbors that mutually support address families will be able to establish an adjacency.

    OSPFv3 packets are always encapsulated into IPv6 packets. To run OSPFv3, with or without address families, network interfaces must be configured for IPv6 operation. This is true even if running OSPFv3 in IPv4 address family mode only, advertising only IPv4 prefixes. Although LSAs will carry IPv4 prefixes, resulting OSPFv3 packets will still be encapsulated in IPv6. Also, because of the same reasons, a virtual link requires end-to-end IPv6 connectivity, which is by definition not available in non-IPv6 address families. Therefore, OSPFv3 with address families supports virtual  links only for IPv6 unicast address families.  

OSPFv3 Prefix Suppression  

In OSPFv3, the prefix suppression works simply by omitting the suppressed transit link prefixes from type 8 and 9 LSAs. For OSPFv3, the transit link prefix suppression is configured either on a per-process basis using the prefix-suppression command, or on per-interface basis using either the ipv6 ospf prefix-suppression or ospfv3 prefix-suppression command, depending on whether OSPFv3 is running in plain or in address family mode.

   Just like in OSPFv2, prefix suppression applies to all configured interfaces except for loopbacks, passive interfaces, and secondary IP addresses in  an IPv4 address family.   

OSPFv3 Graceful Shutdown  

As opposed to the Graceful Shutdown procedure in OSPFv2, where the shutdown is practically immediate, OSPFv3 will perform the shutdown over the Dead interval until all neighbors are declared down. The shutdown is carried out in a more gradual fashion, by dropping the DR/BDR roles, withdrawing all attached, inter-area and redistributed prefixes, declaring the router as a stub router (by setting the costs of all links to 65,535), and finally flushing the router’s own type 1 LSA entirely after all neighbors have gone down thanks to the Hello packets from neighbors being ignored as a part of the procedure.