Cisco Cram or: How I Learned to Stop Lolling and Love the Book: CCIE OCG: OSPF (Chapter 9), Part III

OSPF Configuration

The example configuration has the following design goals in mind:

The OSPF process IDs do not have to match on separate routers, but best practice recommends using the same process IDs across the network.
Using the network command to match interfaces.
Configuring S1's RID as 1.1.1.1.
Setting priorities on the backbone LAN to favor S1 and S2 to become the DR/BDR.
Configuring a minimal dead interval of 1 second, with Hello multiplier of 4, yielding a 250-ms Hello interval on the backbone LAN.

R1#
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ip ospf dead-interval minimal hello-multiplier 4
!
router ospf 1
area 3 nssa no-summary
area 4 stub no-summary
area 5 stub
network 10.1.0.0 0.0.255.255 area 0
network 10.3.0.0 0.0.255.255 area 3
network 10.4.0.0 0.0.255.255 area 4
network 10.5.0.0 0.0.255.255 area 5

R2#
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.0
ip ospf dead-interval minimal hello-multiplier 4
ip ospf 2 area 0
!
router ospf 2
area 5 stub

R3#
router ospf 1
! R3 should omit the no-summary keyword, because R3 is not an ABR.
area 3 nssa
network 10.0.0.0 0.255.255.255 area 3

R4#
router ospf 1
area 4 stub
network 10.0.0.0 0.255.255.255 area 4

S1#
interface Vlan1
ip address 10.1.1.3 255.255.255.0
ip ospf dead-interval minimal hello-multiplier 4
ip ospf priority 255
!
router ospf 1
router-id 7.7.7.7
network 10.1.0.0 0.0.255.255 area 0

S2#
interface Vlan1
ip address 10.1.1.4 255.255.255.0
ip ospf dead-interval minimal hello-multiplier 4
ip ospf priority 254
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0

OSPF Costs and Clearing the OSPF Process

How OSPF chooses OSPF interface costs:

Set the cost per neighbor using the neighbor <ip-add> cost <value> command. This is only valid on OSPF point-to-multipoint non-broadcast network types.
Set the cost per interface using the ip ospf cost <value> under the interface.
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).
Default based on bandwidth, but change Ref-BW using the auto-cost reference-bandwidth <value> command within the OSPF process.
The IOS interface bandwidth is kept in Kbps and the auto-cost reference-bandwidth units are Mbps.
When choosing the best routes to reach a subnet, OSPF also considers whether a route is intra-area route, inter-area route, E1/N1 route, or E2/N2 route.

Alternatives to the OSPF network Command

As of Cisco IOS Software Release 12.3(11)T, OSPF configuration can completely omit the network command, instead relying on the ip ospf <pid> area <area-id> interface subcommand.
With the network command, OSPF advertises stub networks for any secondary IP subnets that are matched by the command.
The ip ospf area interface subcommand causes any and all secondary subnets on the interface to be advertised as stub networks - unless the optional secondaries none parameter is included.
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

Intra-area route filtering presents some special challenges with link-state routing.
Link-state protocols do not advertise routes - they advertise topology information.
SPF loop prevention relies on each router in the same area having an identical copy of the LSDB for that area.
Only the router that has originated an LSA is ever allowed to modify its contents.
Three major types of OSPF filtering:

Filtering routes, not LSAs: Using the distribute-list 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 command is configured.
Note that the redistribute command does control what enters and leaves the LSDB.
The following rules govern the use of distribute-lists for OSPF:

The inbound direction applies to the results of SPF - the routes to be installed into the routing table.
The outbound direction applies only to redistributed routes and only on an ASBR; it selected 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 the 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.

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

OSPF ABR LSA Type 3 Filtering

ABRs do not forward Type 1 and 2 LSAs from one area into another, but instead create Type 3 LSAs for each subnet defined in Type 1 and 2 LSAs.
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.
Type 3 LSAs can be filtered where they would normally be created.
By filtering at the ABR, before the Type 3 LSA is injected into another area, the requirement for identical LSDBs inside the area can be met, while still filtering LSAs.
Configured using the area <area-id> filter-list prefix <name> in|out command.
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.

Filtering Type 3 LSAs with 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.
As a result, this command has the same effect as the area filter-list command with the out keyword, filtering the LSA from going out to any other areas.

Virtual Link Configuration

OSPF requires that each non-backbone area be connected to the backbone area (area 0).
OSPF virtual links overcome the limitation of needing a physical connection to the backbone.
A virtual link allows a pair of possibly remote routers to create a targeted OSPF session across the IP network.
A virtual link endpoint becomes an ABR, with a full copy of area 0's LSDB entries.
A virtual link is not a tunnel for data packets; rather, it is a targeted session that allows two remote routers within a single area to become fully adjacent and synchronize their LSDBs.
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.
As no tunneling is involved, packets routed through this transit area are forwarded based on their true destination addresses, requiring the transit area to know all networks in the OSPF domain, intra-area, inter-area, and external.
The area virtual link commands point to the other router's RID, and the transit area over which the virtual link exists.
Timers and authentication can be set on the area virtual-link command.
It is important to remember that the virtual links themselves are in area 0.

R1#
router ospf 1
router-id 1.1.1.1
area 3 virtual-link 3.3.3.3

R3#
router ospf 1
router-id 3.3.3.3
area 3 virtual-link 1.1.1.1

Configuring Classic OSPF Authentication

Classically three authentication types: none, clear-text, and MD5.
SHA-1 recently added (new configuration).
Classic OSPF authentication differs significantly from RIPv2 and EIGRP.
The basic rules for configuring OSPF authentication are as follows:

Three types available: type 0 (none), type 1 (clear text), and type 2 (MD5).
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 under the OSPF process.
The keys are always configured as interface subcommands.
Multiple MD5 keys with different key IDs are allowed per interface, which allows for graceful key migration where a new key can be added without disrupting the adjacencies. The method is simple: To sign sent packets, OSPF always uses the key that was added as the last one on the interface (regardless of the key number). To authenticate the received packets, it uses the key ID that is indicated in the packet.

The keys are stored in clear text in the configuration, unless the service password-encryption command is added.

Configuring Extended Cryptographic OSPF Authentication

Starting with IOS Release 15.4(1)T, OSPF also supports SHA-HMAC authentication.
SHA-HMAC uses key chains similarly to EIGRP or RIPv2.
In addition, the key chain definition has been enhanced to select a particular cryptographic algorithm for a particular key.
Each key in the key chain must have a cryptographic algorithm configured using a per-key cryptogprahic-algorithm command. Failure to do so will result in OSPF not using that key.
Each key in a key chain can be configured with the send-lifetime and accept-lifetime 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. This is different 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 pahse 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 <name>. Configuring the extended cryptographic authentication using the area OSPF process level command is not supported.
Using the extended cryptographic authentication on virtual links is accomplished using the area <area-id> virtual-link <router-id> key-chain <name>.
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, provided the cryptographic algorithm for the keys in the key chain is MD5. When the new key chain style configuration is used, passwords configured with the ip ospf message-digest-key commands will be ignored.

key chain OSPF
key 1
cryptographic-algorithm hmac-sha-256
key-string CC1E
!
interface GigabitEthernet0/0
ip ospf authentication key-chain OSPF

R1# show ip ospf interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
! Lines omitted for brevity.
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.0.12.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Cryptographic authentication enabled
Sending SA: Key 1, Algorithm HMAC-SHA-256 - key chain OSPF

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

Protection against DoS attacks on the control plane.
Receiving an OSPF packet outside a virtual link or sham link with its TTL less than 255 is a possible indication of a malicious activity. Such packets can be dropped.
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.
If activated globally, individual interfaces can be exempted using the ip ospf ttl-security disable interface level command.
When active, 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 commands have an optional hops <1-254> argument that allows relaxing the TTL Security Check.
Setting the hop-count to a particular value makes the TTL Security Check accept OSPF packets with their TTL in the range from 255 down to 255 - hop-count.
If ttl-security all-interface hops 100, OSPF accepts all packets with their TTL in the range from 255 down to 155, inclusive.
Setting the hop-count to 254 effectively disables the TTL Security check.
If the hop-count is not specified, the value of 1 is automatically assumed.
The hop-count 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 of 1 might be surprising, considering that OSPF packets sourced by directly connected neighbors will have their TTL set to 255, and there is no reason to allow OSPF packets with a TTL of 254.
However, IOS-based Cisco routers exhibit a peculiar behavior in that they appear to decrement the TTL received OSPF packets before handling them over to the OSPF process.
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 have any impact on configured virtual or sham links.
The protection is activated with the area virtual-link ttl-security hops or the area sham-link ttl-security hops command. The hop-count argument is mandatory.
The hop-count value should be based on the longest possible intra-area path (in terms of number of routers) between the link endpoints.
Interfaces toward routers that do not support TTL Security Check shall be configured with the ip ospf ttl-security disable command.

Tuning OSPF Performance

Apart from Hello and Dead timers, OSPF can be significantly tuned in many other ways.

Tuning the SPF Scheduling with SPF Throttling

After a router receives an updated LSA, it needs to schedule its SPF to process the update.
It is ideal to wait some time for more updated LSAs to arrive, and process multiple updates in a single run.
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.
SPF Throttling defines a variable-length wait interval between two consecutive SPF runs.
Three parameters: spf-start, spf-hold, and spf-max-wait.
spf-start defines the initial wait interval before an SPF computation.
spf-hold defines a wait time between subsequent SPF runs, and its value doubles for each consecutive SPF run.
spf-max-wait is the maximum time between two SPF runs (doubling the spf-hold value is capped at spf-max-wait), and also defines a period during which the network must be stable for the wait interval to be set back to spf-start and the spf-hold to its preconfigured value.
If the network has been stable for the last spf-hold period but not for the entire spf-max-wait since the last SPF run, the wait interval returns to the spf-start value but the subsequent wait will still be set to twice the previous spf-hold value.
Example (spf-start = 10 sec, spf-hold = 15 sec, and spf-max-wait = 100 sec):

An updated LSA arrives at time T. The router schedules the nearest SPF run at T+10.
Another updated LSA arrives at time T+2. The router stores it in its LSDB and continues waiting.
At T+10, the router runs the SPF and sets the next wait interval to 15 secs (spf-hold). If another updated LSA arrives within 15 seconds since this SPF runs, the nearest SPF will be run at T+25.
One or more updated LSAs indeed arrive between T+10 and T+25. At T+25, the router runs the SPF and sets the next wait interval to twice the previous spf-hold value, that is, 30 sec. If another updated were to arrive within 30 seconds since this SPF run, the nearest SPF will be run at T+55. The network is considered stable if no topology change is detected within 100 seconds since this SPF run, that is, until T+125.
During the next 30 seconds, no updated LSAs arrive. The wait interval is reset back to spf-start, that is, 10 seconds. The nework is not considered stable, though, because 100 seconds since the last SPF has not elapsed yet; therefore, spf-hold remains at 30 seconds.
At T+80, an updated LSA arrives. The router schedules the nearest SPF run at T+90 and waits until this period expires.
At T+90, the router runs SPF and sets the next wait interval to twice the previous spf-hold value, that is, 60 seconds. If another updated LSA arrives within 60 seconds since thi SPF run, the nearest SPF will be run at T+150. The network wil be considered if no topology change is detected within 100 seconds since this SPF run, that is, until T+190.
During the next 60 secs, no updated LSAs arrive. The wait interval is reset back to spf-start, that is, 10 sec. The nework is not considered stable, though, because 100 seconds since the last SPF has not elapsed yet; therefore, spf-hold remains at 60 secs.
No updated LSA arrives till T+190. As a result, the network is considered stable and the spf-hold is set to its initial value of 15 secs. Any topology change detected after this moment will be handled like the beginning of this scenario.

Configuration: timers throttle spf <spf-start> <spf-hold> <spf-max-wait>.
All arguments are indicated in milliseconds.

Tuning the LSA Origination with LSA Throttling

Control the rate at which a particular LSA might be reoriginated by its originating router.
The same idea as with SPF Throttling.
Three parameters: start-interval, hold-interval, and max-interval.
The hold-time will be reset to its configured value only if the LSA was not required to be updated for the entire max-interval since its last update.
By defaul, 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.
start-interval = 0, hold-interval and max-interval = 5000 milliseconds.
Configuration: timers throttle lsa all <start-interval> <hold-interval> <max-interval>.
The values are again expressed in milliseconds.
A router can also be configured to ignore the same LSA upon arrival if it appears to arrive too often.
Configuration: timers lsa arrival <msec>.
If two or more same LSAs arrive less than <msec> apart, only the first one is accepted an the remaining LSAs are dropped.
The default setting is 1000 milliseconds.
Obviously, the value of the minimum LSA arrival interval should be smaller than the neighbor's initial hold interval in LSA throttling.
Otherwise, a neighbor would be allowed to send an updated LSA sooner than this router would be willing to accept it.

Incremental SPF

The SPF calculation can be augmented so that after a topology change only the affected part of the shortest-path tree is recalculated.
Activated using the simple ispf command (no additional arguments or parameters).

router ospf 1
ispf

OSPFv2 Prefix Suppression

Maintaining transit link prefixes in LSDBs and routing table is, at least from the connectivity standpoint, largely useless.
Not advertising these prefixes can possibly save a significant amount of memory and CPU cycles without impairing the network connectivity.
Suppressing transit link prefixes is different for Type 1 and Type 2 LSAs.
Keep in mind that the goal of this mechanism is to suppress transit link prefixes, that is, the IP network addresses used on these links, not the transit links themselves.
Transit links describe the connections between routers and must continue to be advertised; otherwise, SPF would be unable to construct the shortest-path tree.
Type 1 LSA describes a router and its adjacencies (links) to its neighboring objects.
There are four possible link types that can be described by a Type 1 LSA:

Point-to-point link to another router: This is a transit link pointing toward the other router's RID. It contains no addressing information and will not be influenced by the prefix suppression mechanism.
Link to a transit network: This is a transit link pointing toward the transit network's DR IP address. While it refers to an IP address of the DR, it contains no further addressing information such as network mask, and will not be influenced by the prefix suppression mechanism.
Stub network: This entry describes the IP prefix used either in a true stub network or a prefix used on a point-to-point link to another router. A router can suppress all stub network entries in a Type 1 LSA that correspond to IP prefixes used on point-to-point links.
Virtual router: This is a virtual transit point-to-point link pointing toward a virtually adjacent router's RID. It contains no addressing information and will not be influed by the prefix suppression mechanism.

Therefore, in Type 1 LSAs, suppressing the transit link prefixes is accomplished by omitting stub network entries that contain prefixes on point-to-point interfaces to other routers.
The IP prefix of the network can be computed by bitwise ANDing the Link State ID of the LSA and the netmask carried in its payload. Neither of these two fields can be removed from the type 2 LSA without making its format incompatible.
To routers that implement RFC 6860, a Type 2 LSA advertising the netmask of 255.255.255.255 is a signal that the LSA contains no IP prefix information. Routers not implementing this RFC will install a host route toward that network’s DR. While the advantage of saving routing table space is lost on such routers, no interoperability issues will be introduced.
Configuration: prefix-suppression under the OSPF process.
This command will cause the router to suppress all prefixes on all its OSPF-enabled interfaces except loopbacks, secondary IP addresses, and prefixes on passive interfaces.
Also possible to active on a per-interface basis: ip ospf prefix-suppression.
If the prefix suppression is activated globally, the interface is exempted by using the ip ospf prefix-suppression disable command.

OSPF Graceful 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.
"routing through a failure" vs. "routing around a failure"
Cisco implemented its own version of graceful restart before RFC 3623 that is called Non-Stop Forwarding (NSF).
Cisco supports both NSF and GR; both area configured using nfs commands.
Two classes of devices involved in GR/NSF.
restart mode = the router undergoing the graceful restart.
helper mode = its directly connected neighbors.
The neighbors must ignore the lack of Hellos for an indicated grace period, continue to consider the router fully adjacent and report it as fully adjacent in their Type 1 and 2 LSAs, and continue to consider the router a DR for the segment if it was elected as the DR before the graceful restart.
Neighbors pretend that the router undergoing a graceful restart is up and running.
Only routers with specific hardware can perform the graceful restart themselves because of the obvious need to have forwarding hardware autonomous and independent from the main CPU.
NSF-aware device can act only as a helper device.
NSF-capable device can act as a helper device and also perform a graceful restart themselves.
The following conditions must be true:

The router's hardware construction allows the control plane to restart while the line cards continue to forward packets based on the last version of their forwarding database.
The router whose OSPF process is restarting must notify its neighbors that the restart is happening 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.
The LSA database remains stable during the restart.
All the neighbors support, and are configured for, graceful restart helper mode.
The restart takes place within a specific grace period.
During restart, the neighboring fully adjacent routers must operate in helper mode.

Both Cisco and IETF NSF awareness are enabled by default in Cisco IOS.
Disable: nsf [cisco | ietf] helper disable under the routing process.

OSPF Graceful Shutdown

Allows the OSPF process to update the neighbors that the router is going down.
Using a simple shutdown command under the OSPF process, the router will immediately:

Drop all OSPF adjacencies.
Flush all LSAs it has originated (flood them with the MaxAge 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.

Also on a per-interface basis: ip ospf shutdown.
In that case, the router will immediately:

Drop all OSPF adjacencies over that particular interface.
Flood updated LSAs that no longer include that particular interface and adjacencies through other interfaces if any.
Send the neighbors' adjacencies to the Init state.
Stop sending and receiving OSPF packets over that particular interface.

Revert back by removing the shutdown or ip ospf shutdown command.

Cisco Cram or: How I Learned to Stop Lolling and Love the Book

Friday, March 20, 2015

CCIE OCG: OSPF (Chapter 9), Part III