Category: OSPF

OSPFv3: Differences between OSPFv2 and OSPFv3

OSPFv2 and OSPFv3 share many concepts however here are the major differences between the two protocols:

  • OSPFv3 is configured using interface commands, to enable an interface for a particular area and begin sending/receiving OSPF packets all you configure is ipv6 ospf 1 area 2 under the interface and that turns on the protocol and advertises the network on that port.   This also creates the ipv6 router ospf 1 in global configuration mode.
  • OSPFv3 can advertise multiple networks on an interface, if multiple secondary addresses are configured on the same interface all those networks are advertised as well.
  • OSPFv3 RID must be set, it will not dynamically learn or assign a RID if there are no IPv4 addresses, if there are some present it can still dynamically assign one based on the IPv4 address.
  • OSPFv3 has 3 flooding scopes:
    • Link local scope – new LSA type link LSA
    • Area scope – this is for LSAs flooded throughout a single OSPFv3 area.  Used by router, network, inter-area prefix, intra-area prefix, and inter-area router LSA type
    • AS scope – LSAs are flooded throughout the routing domain this is used for AS external LSAs
  • Multiple Instances per link – OSPFv3 supports multiple instances on a single interface where there are multiple routers connected to the same multi access segment, and you don’t want all routers to form neighborships but instead only specific routers, you can do this by instancing the OSPF configration under the interface.
  • Terminology – OSPFv3 uses the term link as represented in OSPFv2 as a network
  • Link local addresses are used on the interface to source all OSPF packets from with the exception of virtual links, virtual links used a globally scoped IPv6 address to source packets from
  • Authentication – OSPF does not support any method of authentication as AH and ESP are built into IPv6 natively
  • Networks in LSAs – OSPFv2 expresses prefixes as address/mask in its LSAs, OSPFv3 expresses prefixes as prefix/prefix length, where the default routes prefix length is 0.
Advertisements

OSPF: Graceful Shutdown

In some situations its necessary to take a router down with as little disruption as possible.  This can be accomplished using the graceful shutdown feature of OSPF.  This allows OSPF to update its neighbors that the router is going down, simply by using the shutdown command on the OSPF configuration.  The router will immediately perform the following functions when shutdown is configured:

  • Drops all OSPF neighborships
  • Flushes all LSA it originated (floods all LSAs 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 with an empty neighbor prompting the neighbors adjacency states to fall back to the init state
  • Stops sending and receiving OSPF packets

Graceful restart can also be configured per interface using the ip ospf shutdown command.  Which basically does the same functions as above but does it for any neighbors or OSPF functions off of that particular interface.

 

OSPF: Graceful Restart

OSPF Graceful Restart allows a router to restart while it’s neighbors continue to forward packets to the restarting router as if it was up and running.  This is referred to as routing through a failure, instead of routing around a failure which would be OSPFs usual response to a router going down.

This was introduced in IOS when Non Stop Forwarding (NSF) was introduced.  NSF and GR are both configured using nsf commands.

The router restarting is said to be in restart mode while its neighbors are in helper mode during the graceful restart.

helper neighbors have to ignore the fact that there is a lack of hellos keeping the ospf neighborship up during the restart, it ignores them during a predefined grace period and considers the restarting router to be fully adjacent during this time.

Any router can act as a helper if its supported in the IOS, however only routers with specific hardware support can perform restart functions, since there is a need to have autonomous forwarding hardware in the event of a failure.  To differentiate between the two types of devices cisco refers to helper devices as NSF-aware and restart devices as NSF-capable.

 

OSPF: Prefix Suppression

Maintaining transit network routes between two endpoints can clutter LSDBs and cause unnecessary overhead in maintaining LSDBs.  These prefix’s are merely used for transport between two sites and knowledge of them is largely not needed as most traffic will be generated by end hosts on non-transit networks.

OSPF combines topology and addressing information in type 1 and type 2 LSAs, meaning that the addressing of these transit links would be maintained in these LSAs.  The goal is to suppress the prefix only, not necessarily the link state information.  Type 1 LSAs describe a router and its adjacencies to its neighboring objects, there are four possible link types described by the type 1 LSA:

Point to point link – This is a transit link pointing to another routers RID, it contains no addressing information and will not be influenced by prefix suppression.

Link to a transit network – This is a transit link pointing toward the transit networks DR IP address, it contains no further IP information outside of the DR IP and will not be influenced by prefix suppression.

Stub network – This is the IP prefix used 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 type 1 LSAs that correspond to IP prefixes used on point to point links.

Virtual link – This is a virtual transit point to point link pointing to a virtually adjacent router RID, it contains no addressing information and will not be influenced by prefix suppression.

So for type 1 LSAs only stub network entries that contain prefixes for point to point interfaces will be suppressed.

Type 2 LSAs describe  transit multiaccess networks and all connected routers, and they include information from which the IP prefix used in the network can be calculated.

Specifically the link state ID ofa type 2 LSA is set to the IP of the DR in the multiaccess network, and the LSa body contains the network  and subnet mask, among other things.

The IP prefix of a network can be computed by bitwise ANDing the Link State ID of the LSA and the netmask carried in its payload.  Therefore these can’t be removed without making the format of the LSA incompatible. So RFC 6860 uses a different approach, it sets the netmask field to the value of 255.255.255.255, which is an invalid mask for a multiaccess network.

routers implementing RFC 6860 will recognize the netmask as a signal that the LSA contains no IP prefix information.  This will allow routers not implementing RFC to install a host route toward that networks DR, while the advantage of saving routing table space is lost on these routers no interoperability issues are introduced.

Prefix suppression can be activated by entering in the prefix-suppression command in router ospf mode.  This will suppress the router from advertising any prefixes except loopbacks, secondary IP addresses and prefixes on passive interfaces, these are considered nontransit prefixes.

It can also be configured per interfaces using the ip ospf prefix-suppression command.

You can exempt an interface from being suppressed by using the ip ospf prefix-suppression disable command.

OSPF: Incremental SPF

Every time a topology change occurs the SPF algorithm is run to always produce the best path to a destination, however depending on the location of the topology change SPF will recompute parts of the topology that didn’t change.  Causing unnecessary computations to be performed on parts of the network that have nothing to do with the topology change.

To assist with this the SPF calculation can be changed so that after a topology change, only the affected part of the SPF tree is recalculated.  This is referred to as incremental SPF and can be activated using the ispf command under the OSPF configuration.

OSPF: LSA Throttling

OSPF uses the same idea behind LSA throttling as it does for SPF throttling.  Its intended purpose is to rate limit the amount of times a specific LSA is re-advertised to a network.  The functionality behind LSA throttling also relies on three timers:

start-interval
hold-interval
max-interval

Once an LSA has not been updated for more than max-interval and it needs to be updated it will be created and flooded after the start-interval, when the next wait interval is set to the value of the hold-interval.

If the same LSA needs to be updated within the wait interval since it was last originated, the true origination and flooding will be postponed until the current wait interval expires and after creating and flooding the updated LSA.

The hold interval is doubled and used as the next wait interval, and will do so each time the LSA has to be updated within the hold interval until it’s capped by the max interval. Making the LSA throttling behavior exactly the same as the SPF throttling behavior.

By default Cisco routers update the LSA immediately and does not progressively increase the interface for subsequent origination’s which is set to 5 seconds by default.

OSPF: SPF Throttling

In networks where  there are links that can bounce often, this could cause the SPF algorithm to recalculate the best path often causing unnecessary strain on the processor of the router.  To make this calculation more efficient in scenarios such as this, you can tune OSPF to run the SPF algorithm in intervals as opposed to immediate link state changes.

The scheduling of SPF runs is controlled by a feature called SPF throttling, there are three parameters of this feature that define the length of time between SPF runs.

spf-start
spf-hold
spf-max-wait

spf-start defines the wait interval before SPF computation.

spf-hold parameter defines the wait time between subsequent SPF runs and its value doubles for each consecutive SPF run

spf-max-wait defines the maximum time between two SPF runs and also defines how long the network must be stable before the interval is reset back to the spf-start and spf-hold pre-configured values.

 

OSPF: TTL Security Check

Control plane attacks can occur when a compromised device sends unicast OSPF messages to a participating OSPF router, to combat these types of attacks, OSPF can use the TTL security check.

The idea is that if an IP packet is routed its TTL is reduced by one for each subsequent hop towards its destination.  If all OSPF routers sent their packets with a TTL of 255 it would be easy to differentiate packets originating from off net.  Since OSPF communication is always based on direct router to router communication (except for virtual and sham links) packets received with TTL less than 255 can be considered malicious traffic and can be dropped.

TTL security check can be activated per interface or globally, where interfaces can be turned off to participate in the security check as needed.

The TTL check can also be tuned to accept TTL values less than 255 by configuring an offset that subtracts its value from 255.  This may be useful as some Cisco platforms will sometimes decrements the TTL value of the packet before its handed off to the OSPF process and would otherwise cause a packet to be dropped when it shouldn’t be.

 

OSPF: Extended Cryptographic Authentication

Beginning with IOS release 15.4(1)T OSPF supports Secure Hash Algorithm Hash Message Authentication Code (SHA-HMAC) as described in RFC 5709.

To utilize SHA-HMAC authentication OSPF uses key chains similar to EIGRP or RIPv2.  Also the key chains have been enhanced to select a particular cryptographic algorithm for each key.

Thins to watch out for:

  • each key must have a cryptographic algorithm configured, failure to do so will result in OSPF ignoring that key.
  • each key can be configured to only be usable at certain times, using the lifetime commands.  If multiple keys are available at a given time the highest key ID will be used…this is different from RIP or EIGRP in that they use the lowest key ID
  • there is no key rollover mechanism the highest key id is used to sign egress packets, the key specified in the received packet is used to process ingress packets.
  • extended cryptographic authenication is enabled per interface.
  • extended cryptographic authentication on virtual links is configured under the area area-id virtual-link router-id key-chain key-chain-name command
  • MD5 authentication is one of the supported cryptographic algorithms in key chains.  An OSPF router configured for Md5 using classic commands will interoperate with a neighbor using the new key chain style, provided the cryptographic algorithm for the keys in the key chain is MD5.  When the new style is used, passwords configured with the ip ospf message-digest-key command are ignored.

OSPF: Authentication

OSPF supports authentication using non, clear text, and MD5.  SHA-1 was recently added to the list of supported authentication methods but is configured differently than the other authentication types.

Classic method:

  • three types are available, type 0 (none) type 1 (clear text) type 2 (MD5)
  • authentication is enabled per interface
  • default authentication type is 0
  • the default can be redefined in the OSPF configuration
  • keys are always configured under the interface
  • multiple Md5 keys with different IDs are allowed per interface

OSPF uses the key that was added last to the interface to sign sent packets (regardless of key number)

To authenticate a received packet, it uses the key ID that is indicated in the packet.

If a neighbor comes up that does not have the same key number as the neighbor the router begins a process called OSPF key rollover, and the neighbors begin sending packets as many times as they have keys for the interface, the rollover ends when both sides have the same key selected.

Key rollover is only used for MD5 authentication, since there are no keys for cleartext, this process is not used when that authentication type is selected.

Virtual links do not have specific interfaces under which you would configure authentication commands, instead virtual links are configured under the area virtual-link command itself.