IP, TCP, UDP Header

IP Header

Version identifies the IP version to which the packet belongs. This four-bit field is set to binary 0100 to indicate version 4 (IPv4) or binary 0110 to indicate version 6(IPv6).

Header Length is a four-bit field that tells the length of the IP header in 32-bit words. This field is included because the Options field(described later in this section) can vary in size. The minimum length of the IP header is 20 octets, and the options might increase this size up to a maximum of 60 octets the maximum length in 32-bit words that can be described by this field.

Type of Service(TOS) is an eight-bit field that can be used for specifying special handling of the packet. This field actually can be broken down into two subfields: Precedence and TOS.

Total Length is a 16-bit field specifying the total length of the packet, including the header, in
octets. By subtracting the header length, a receiver might determine the size of the packet's data
payload. Because the largest decimal number that can be described with 16 bits is 65,535, the
maximum possible size of an IP packet is 65,535 octets.

Identifier is a 16-bit field used in conjunction with the Flags and Fragment Offset fields forfragmentation of a packet. Packets must be fragmented into smaller packets if the original length exceeds the Maximum Transmission Unit (MTU) of a data link through which they pass. For example, consider a 5000-byte packet traveling through a network. It encounters a data link with a 1500 byte MTU. That is, the frame can contain a maximum packet size of 1500 bytes. The router that places the packet onto this data link must first fragment the packet into chunks of no
more than 1500 octets each. The router then marks each fragment with the same number in the Identifier field so that a receiving device can identify the fragments that go together. A fragmented packet is not reassembled at the other end of the data link; the packet stays fragmented until it reaches its final destination.

Flags is a three-bit field in which the first bit is unused. The second is the Don't Fragment (DF) bit. When the DF bit is set to one, a router cannot fragment the packet. If the packet cannot be forwarded without fragmenting, the router drops the packet and sends an error message to the source. This function enables the testing of MTUs in a network. The DF bit can be set using the Extended Ping utility in IOS. The third bit is the More Fragments (MF) bit. When a router fragments a packet, it sets the MF bit to one in all but the last fragment so that the receiver knows to keep expecting fragments until it encounters a fragment with MF = 0.

Fragment Offset is a 13-bit field that specifies the offset, in units of eight octets, from the beginning of the header to the beginning of the fragment.[6] Because fragments might not always arrive in sequence, the Fragment Offset field allows the pieces to be reassembled in the correct order.

Note that if a single fragment is lost during a transmission, the entire packet must be resent and refragmented at the same point in the network. Therefore, error-prone data links could cause a disproportionate delay. And if a fragment is lost because of congestion, the retransmission of the entire series of fragments might increase the congestion.

Time to Live(TTL) is an eight-bit field that will be set with a certain number when the packet is first generated.

Protocol is an eight-bit field that gives the "address," or protocol number, of the host-to-host or transport layer protocol for which the information in the packet is destined.

Header Checksum is the error detection field for the IP header. The checksum is not calculated forthe encapsulated data; UDP, TCP, and ICMP have their own checksums for doing this.

Source and Destination Addresses are the 32-bit IP addresses of the originator of the packet and the destination of the packet.

Options is a variable-length field and, as the name says, is optional. Space is added to the packet header to contain either source-generated information or for other routers to enter information;the options are used primarily for testing. The most frequently used options are
  -Loose source routing, in which a series of IP addresses for router interfaces is listed. The packet must pass through each of these addresses, although multiple hops might be taken between the addresses.
  -Strict source routing, where again a series of router addresses is listed. Unlike loose source routing, the packet must follow the route exactly. If the next hop is not the next address on the list, an error occurs.
  -Record route provides room for each router to enter the address of its outgoing interface as the packet transits so that a record is kept of all routers the packet encounters. Record route provides a function similar to trace except that the outgoing interfaces, both on the path to the destination and on the return path, are recorded.
  -Timestamp is an option similar to record route except each router also enters a timestamp: the packet not only keeps track of where it has been but also records when it was there.
All these options might be invoked by using the Extended Ping on Cisco routers.

-------------------------------------------------------------------------------------------

TCP Header

TCP attaches a header to the application layer data; the header contains fields for the sequence numbers and other information such as port nubmer. The applicationdata with its attached TCP header is then encapsulated within an IP packet for delivery.

Source and Destination Port are 16-bit fields that specify the source and destination applications for the encapsulated data. A port number for an application, when coupled with the IP address of the host the application resides on, is called a socket. A socket uniquely identifies every application in a network.

Sequence Number is a 32-bit number that identifies where the encapsulated data fits within a data stream from the sender. For example, if the sequence number of a segment is 1343 and the segment contains 512 octets of data, the next segment should have a sequence number of 1343 + 512 + 1 = 1856.

Acknowledgment Number is a 32-bit field that identifies the sequence number the source next expects to receive from the destination. If a host receives an acknowledgment number that does not match the next sequence number it intends to send (or has sent), it knows that packets have been lost.

Header Length, sometimes called Data Offset, is a four-bit field indicating the length of the header in 32-bit words. This field is necessary to identify the beginning of the data because the length of the Options field is variable.

The Reserved field is four bits, which are always set to zero.

Flags are eight 1-bit flags that are used for data flow and connection control. The flags, from left to right, are Congestion Window Reduced (CWR), ECN-Echo (ECE), Urgent (URG), Acknowledgment (ACK), Push (PSH), Reset (RST), Synchronize (SYN), and Final (FIN).

Window Size is a 16-bit field used for flow control.
Checksum is 16 bits, covering both the header and the encapsulated data, allowing error detection.
Urgent Pointer is used only when the URG flag is set. The 16-bit number is added to the Sequence Number to indicate the end of the urgent data.

Options, as the name implies, specifies options required by the sender's TCP process. The most commonly used option is Maximum Segment Size, which informs the receiver of the largest segment the sender is willing to accept. The remainder of the field is padded with zeros to ensure that the header length is a multiple of 32 octets.

-----------------------------------------------------------------------------

UDP Header

A UDP packet is much smaller header than TCP. The Source and Destination Port fields are the same as they are in the TCP header; the UDP length indicates the length of the entire segment in octets. The checksum covers the entire segment, but unlike TCP, the checksum here is optional; when no checksum is used, the field is set to all zeros.

IP Services

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. 

OSPF - 2 - OSPF Design and LSAs

OSPF Design Terms 

A router that is actively  attached to multiple areas (that is, has at least one active interface in these areas), including the backbone area, considers itself an ABR. Autonomous System Boundary Routers(ASBR) inject routes external to OSPF into the OSPF domain.

Conceptually, an OSPF router keeps an independent and separate LSDB for each area to which it is connected. An internal router to an area has a single LSDB; an ABR has multiple separate LSDBs, one for each connected area. When computing a routing table, SPF is run in each LSDB separately, and the results are combined in a single routing table subject to OSPF path preference rules.

It is important to keep in mind that in multiarea OSPF, ABRs maintain separate per-area LSDBs and run SPF in each of them independently, and then combine the results and use them to populate per-area LSDBs with condensed information about other areas.

Using areas provides the following benefits:
  -Generally smaller per-area LSDBs, requiring less memory.
  -Faster SPF computation thanks to the sparser LSDB.
  -A link failure in one area only requires a partial SPF computation in other areas.
  -Routes can be summarized and filtered only at ABRs (and ASBRs). Having areas permits summarization, again shrinking the LSDB and improving SPF calculation performance.

The size of the LSDB on most routers should shrink. The LSDB shrinks because an ABR does not pass denser and more detailed type 1 and 2 LSAs from one area to another; instead, it passes type 3 summary LSAs.

OSPF Path Selection Process  

  -OSPF always chooses an intra-area route over an inter-area route for the same prefix, regardless of metric.
  -ABRs ignore type 3 LSAs learned in a nonbackbone area during SPF calculation, which prevents an ABR from choosing a route that goes into a nonbackbone area and then back into the backbone. (to prevent routing loops)

LSA Types  

An important fact concerning all LSA types is that only a router that has originated a particular LSA is allowed to modify it or withdraw it. Other routers must  process and flood this LSA within its defined flooding scope if they recognize the LSA’s type and contents, but they must not ever change its contents, block it or drop it before its maximum lifetime has expired. This requirement makes sure that all routers in an area have the same LSDB contents and have a consistent view of the network.
As a result, summarization and route filtering can be done in a very limited fashion, unlike in distance vector protocols, where summarization and route filtering can be performed at any point in the network.

Transit network: A network over which two or more OSPF routers have become neighbors and elected a DR so that traffic can transit from one to the other. An exception to this rule is a point-to-point interconnection between two routers.
Stub network: A subnet on which a router has not formed any neighbor relationships.  

LSA Types 1 and 2  

Each router creates and floods a type 1 LSA for itself. These LSAs describe the router, its interfaces (in that area), and a list of neighboring routers (in that area) on each interface. The LSA itself is identified by a link-state ID(LSID) equal to that router’s RID.
Type 2 LSAs represent a transit subnet for which a DR has been elected. The LSID is the DR’s interface IP address on that subnet. Note that type 2 LSAs are not created for subnets on which no DR has been elected.

With all the type 1 and 2 LSAs inside an area, a router’s SPF algorithm is able to create a topological graph of the network, calculate the possible routes and finally choose the best routes. For subnets without a DR, the type 1 LSAs hold enough information for the SPF algorithm to create the math model of the topology.

In the show ip ospf database output: The Link ID column should say as Link State ID. While Link State ID is a unique identifier of an entire LSA, a Link ID is a particular entry specifically in a type 1 LSA body that describes an adjacency to a neighboring object of a router. A single type 1 LSA identified by a single Link State ID can describe several adjacencies represented by several Link ID entries. These two terms are not interchangeable.  

The show ip ospf database  command lists the LSAs in that router’s LSDB, with LSA type 1 LSAs (router LSAs) first, then type 2(network link states), continuing sequentially through the LSA types. 

LSA Type 3 and Inter-Area Costs

ABRs do not forward type 1 and 2 LSAs from one area to another. Instead, ABRs advertise type 3 LSAs into one area to represent subnets described in both the type 1 and 2 LSAs in another area. Each type 3 summary LSA describes a simple inter-area destination—the subnet, the mask, and the ABR’s cost to reach that subnet.

Routers calculate the cost for a route to a subnet defined in a type 3 LSA by adding the calculated cost to reach the ABR that created and advertised the type 3 LSA and the cost as listed in the type 3 LSA. You can see the cost of the type 3 LSA with the show ip ospf database summary link-id command, and the cost to reach the advertising ABR with the show ip ospf border-routers command, and show ip ospf statistics to list the number of SPF calculations.

Withdrawal of type 3 LSAs does not require a full SPF run. Instead, routers in these areas simply check whether there is another type 3 LSA concerning the same networks providing a backup path, and when they find there is none, they simply remove the affected networks from their routing tables.  

Type 3 summary LSAs are flooded only within the area into which they were originated by ABRs. They do not cross area boundaries. Instead, ABRs compute an internal OSPF routing table for the backbone area using all types of LSAs received in the backbone area, and for each intra-area and inter-area route, they originate a new type 3 LSA to be flooded to their attached nonbackbone areas. Two important rules about originating and processing type 3 LSAs:

  -An ABR uses only those type 3 LSAs that are received over a backbone area in its SPF calculation. Type 3 LSAs received over nonbackbone areas will be skipped during the ABR’s SPF computation, though they are stored in the ABR’s LSDB and flooded within that nonbackbone area as usual.   

  -When an ABR creates and floods type 3 LSAs to advertise networks from one area to another, only intra-area routes from nonbackbone areas are advertised into the backbone; both intra-area and inter-area routes are advertised from the backbone into nonbackbone areas.    

LSA Types 4 and 5, and External Route Types 1 and 2 

OSPF allows for two types of external routes- type 1 and 2. The type determines whether only the external metric is considered by SPF when picking the best routes (external type 2, or E2), or whether both the external and internal metrics are added together to compute the metric (external type 1, or E1). By default, Cisco routers use the E2 metric type in redistribution.  

When an ASBR injects an external route, it creates a type 5 LSA for the subnet. The LSA lists the metric and the metric type. The ASBR then floods the type 5 LSA throughout all regular areas. Other routers process the LSA depending on the metric type.

the total cost of E1 external routes is computed as the cost of reaching the ASBR advertising the network, plus the E1 cost of the external network. The path with the least total cost is used; if there are multiple such paths, use them all. The total cost of E2 external routes is immediately the E2 cost of the external network. The path with the least E2 cost is used, and in case of a tie, the path having the least cost to an advertising ASBR is used; if there are still multiple paths, use them all. If there are both E1 and E2 routes to the same external network available, the E1 is always preferred to E2.  

when an ABR then floods the type 5 LSA into another area, the ABR creates a type 4 LSA, containing the ASBR’s RID and the ABR’s metric to reach the ASBR that created the type 5 LSA. Routers in other areas use the type 4 LSA to know what ASBRs in other areas exist, what ABRs can be used to reach them, and what is the distance of each ABR to a particular ASBR. If the ASBR is in the same area as the computing router, it is computed using the type 1 and 2 LSAs in that area. If the ASBR is in a different area, the cost of reaching it is computed using the type 1 and 2 LSAs in  the computing router’s area toward an ABR, plus the cost from the ABR’s type 4 LSA toward the ASBR. Note that a type 4 LSA concerning a particular ASBR is not required in the area where the ASBR reside and hence never flooded into it.

show ip ospf database external 192.168.2.0, show ip ospf database asbr-summary, show ip ospf border-routers are useful commands.

OSPF Design in Light of LSA Types  

Stubby Areas  

Not all areas need to have knowledge about individual external networks. Stubby area is an area that does not contain an ASBR and thus does not mediate an external connectivity to the entire OSPF domain. Such an area does not really benefit from knowing about individual external networks.
If an area is configured as a stubby area, ABRs will stop advertising type 4 and 5 LSAs into this area. In addition, every internal router in a stubby area will ignore any received type 5 LSAs, and will not originate any such LSAs itself. As a result, no external networks or ASBRs will be known by any internal router in a stubby area. In addition, ABRs in a stubby area will automatically inject a default route into the area as a type 3 LSA. Stubby area mainly limits the external routes(type 4 and 5); replacing those routes with a default rotue generted by ABR. The visibility of intra-area and inter-area networks in a stubby area is not affected in any way. A stubby area can contain one or more ABRs.

All four stub area types stop type 4 and 5 LSAs from entering the area. When the name includes “totally,” type 3 LSAs are also not passed into the area by ABRs except a type 3 LSA carrying the default route, significantly reducing the size of the LSDB. If the name includes “NSSA,” it means that external routes can be redistributed into OSPF by routers inside the stubby area;

In areas that are totally stubby, non-ABRs should omit the  no-summary  keyword because the additional type 3 LSA filtering is performed only on ABRs. 

NSSA can hold an ASBR and perform external route injection. This external information is carried in type 7 LSAs to distinguish it from normal external routes in type 5 LSAs, which are still prohibited even in NSSAs. In addition, the ABR with the highest RID will perform a translation from type 7 LSA to type 5 LSA and thereby inject the external route to other areas.

The NSSA is also the only nonregular type of area into which a default route is not advertised automatically. To advertise a default route into an NSSA, ABRs must be configured with the area area-id nssa default-information-originate command. All other nonregular area types will inject a default route automatically, including totally NSSA(NSSA-TS). show ip ospf database nssa-external, show ip ospf database | begin Type-5

OSPF Path Choices That Do Not Use Cost 

Under most circumstances, when an OSPF router runs the SPF algorithm and finds more than one possible route to reach a particular subnet, the router chooses the route with the least cost.

Choosing the Best Type of Path

If there are multiple routes with different route types to reach a given subnet,the router ignores the costs and instead choose the best route based on this preference - Intra-area routes, Inter-area routes, E1/N1 routes, E2/N2 routes.

Best-Path Side Effects of ABR Loop Prevention

The other item that affects OSPF best-path selection relates to some OSPF loop-avoidance features. Inside an area, OSPF uses Link State logic, but between areas, OSPF acts as a Distance Vector (DV) protocol. OSPF uses some of the same underlying concepts of DV loop-avoidance features, including Split Horizon. From a nonbackbone area, only internal routes can be advertised into the backbone.

OSPF Path Choices That Do Not Use Cost

Under most circumstances, when an OSPF router runs the SPF algorithm and finds more than one possible route to reach a particular subnet, the router chooses the route with the least cost.

Choosing the Best Type of Path

If there are multiple routes with different route types to reach a given subnet,the router ignores the costs and instead choose the best route based on this preference - Intra-area routes, Inter-area routes, E1/N1 routes, E2/N2 routes.


Best-Path Side Effects of ABR Loop Prevention

The other item that affects OSPF best-path selection relates to some OSPF loop-avoidance features. Inside an area, OSPF uses Link State logic, but between areas, OSPF acts as a Distance Vector (DV) protocol. OSPF uses some of the same underlying concepts of DV loop-avoidance features, including Split Horizon. From a nonbackbone area, only internal routes can be advertised into the backbone. ABR - genereate Type 3 LSAs for all inter/intra area routes from backbone and install them in non-backbone; generate Type 3 LSAs only for intra area routes from non-backbone to backbone. An ABR ignores type 3 LSAs from another ABR over nonbackbone area. These routing decisions can result in arguably suboptimal routes, and even asymmetric routes. 

OSPF - 1 - OSPF Database Exchange

OSPF defines five different messages that routers can use to establish adjacencies and exchange routing information.

OSPF Router IDs 

Before an OSPF router can send any OSPF messages, it must choose a unique 32-bit identifier called the OSPF router identifier(RID). Cisco routers use following sequence to choose RID
  -Use router-id id subcommand under router ospf.
  -Use the highest numeric IP address on any currently nonshutdown loopback interface that has not yet been allocated as a RID by any other OSPF process.
   -Use the highest numeric IP address on any currently nonshutdown, nonloopback interface that has not yet been allocated as a RID by any other OSPF process.

Multiple OSPF processes running on a single router try to choose unique RIDs. Each of the OSPF processes performs the same three steps to choose a RID, skipping IP addresses that have already been used as RIDs by other OSPF processes running on the router.
It is sufficient for the interface to be in the down/down state to be considered by OSPF as a prospective interface for RID selection.
OSPF does not have to advertise a route to reach the RID’s subnet.
The RID does not have to be reachable per the IP routing table.
Routers consider changing the OSPF RID when the OSPF process is restarted, or when the RID is changed through configuration. If a router’s RID changes, the rest of the routers in the same area will have to perform a new SPF calculation, even if the network topology has not changed. The reason is that a RID change is indistinguishable from a process of replacing one router with another.

Becoming Neighbors, Exchanging Databases, and Becoming Adjacent 

The LSAs themselves are not OSPF messages. An LSA is a data structure, held inside a router’s LSDB and exchanged inside LSU messages. 

OSPF Neighbor States

Down: Initial state for a neighbor. Mostly seen when a working adjacency to a neighbor is torn down or when a manually configured neighbor does not respond to our initial Hello packets. Note that having a neighbor in the Down state implies that the router already knows about this neighbor’s IP address.   

Attempt: This state is valid only on nonbroadcast multiaccess (NBMA) and point-to-multipoint nonbroadcast networks. On these networks, a neighbor is immediately placed into the Attempt state and contacted by Hello packets sent at usual intervals. 

  

Init: This router can hear the other router but it is not certain whether the other router can hear this router. 

2-Way: This state confirms a bidirectional visibility between the two routers. The 2-Way is a stable state between routers on multiaccess networks that do not intend to become fully adjacent.

ExStart: The purpose of the ExStart state is to establish the Master/Slave relationship. In the ExStart state, routers exchange empty Database Description packets to compare their Router IDs, determine the Master and Slave roles for each 

router, and agree on a common starting sequence number used to acknowledge subsequent Database Description packets used in the Exchange state. 

Exchange: During this state, Database Description packets are exchanged between the routers carrying the list of link-state database elements(list of LSAs; not the LSA data itself.) known by each router. Each router builds a list of LSAs to be subsequently downloaded from the other router.   

Loading: A neighbor is moved from the Exchange to Loading state after it has advertised the complete list of LSAs and this router needs to download some of the LSAs from the neighbor. The neighbor is kept in the Loading state during the LSA download.   

Full: A neighbor is moved from the Exchange or Loading state to the Full state when all required LSAs have been downloaded from the neighbor, so all missing or outdated LSAs have been acquired. The Full state is a stable state between routers that have become fully adjacent. 

Becoming Neighbors: The Hello Process 

To discover neighbors, Cisco OSPF routers listen for multicast Hello messages sent to 224.0.0.5—the All OSPF Routers  multicast address—on any interfaces that have been enabled for OSPF. The Hellos are sourced from that router’s primary IP address on the interface. After two routers discover each other by receiving Hellos from the other router, the routers perform the following parameter checks based on the receive Hellos:   

  -Must pass the authentication process   

  -Must be in the same primary subnet, including the same subnet mask   

  -Must be in the same OSPF area   

  -Must be of the same area type (regular, stub, not-so-stubby area[NSSA])   

  -Must not have duplicate RIDs   

  -OSPF Hello and Dead timers must be equal    

If any of these items do not match, the two routers simply do not form a neighbor relationship. OSPF process ID doesn't have to match. The maximum transmission unit (MTU) must be equal for the DD packets to be successfully processed between neighbors, but this parameter check is technically not part of the Hello process. The MTU mismatch would negatively affect the database synchronization process in the ExStart and Exchange phases.

The third function of Hello packets is to verify bidirectional visibility between routers on the same segment. Each Hello packet contains a list of neighbors from whom the sending router received valid and acceptable Hellos. If a router finds its own RID in the list of seen routers in a Hello received from a neighbor, it can be sure that they can hear each other. 

 Finally, the fourth important function for a Hello is to maintain a heartbeat function between neighbors. The neighbors send Hellos every hello interval; failure to receive a Hello within the longer dead interval causes a router to believe that its neighbor has failed. The hello interval defaults to 10 seconds on interfaces with an OSPF broadcast or point-to-point network type, and 30 seconds on interfaces with an OSPF nonbroadcast or point-to-multipoint network type; the dead interval defaults to four times the hello interval. Use debug ip ospf hello for debugging.

Transmitting LSA Headers to Neighbors 

 When two routers hear Hellos, and the parameter check passes, each router creates and sends Database Description(DD, or sometimes called DBD)packets, which contain the headers of each LSA. The routers exchange an index list of all the LSAs they each know about; the next step in the process is letting a router request a new copy of only those LSAs it does not have or which are less recent. Each DD packet, which can contain several LSA headers, has a sequence number assigned. The receiver acknowledges a received DD packet by sending a DD packet with the identical sequence number back to the sender.

Database Description Exchange: Master/Slave Relationship 

the neighbors determine which router is to be the master and which is to be the slave during the database exchange between them. The roles of master and slave define the responsibilities of routers during the exchange of DD packets. Only the master is allowed to send DD packets on its own accord as well as to set and increase their sequence numbers. A slave is allowed to send a DD packet only as a response to a DD packet received from master router,  and must use the same sequence number.

    

Among other fields, a DD packet header contains three flags:Master(MS) flag, More(M) flag, Init(I) flag. There are two rules to sending DD packets that must be observed at all times: 1. Each DD packet sent from the master must be replied to by the slave and 2.A slave can send a DD packet only as a response to receiving a master’s DD packet.

In situation where slave holds more LSAs in its database than master's, the slave set the M flag in its DD packet sent in response to the master’s DD packet. If the master receives a DD packet from the slave with the M flag set, it knows that the slave has at least one more DD packet to send, so it must poll it again. A  master will stop send sending DD packets to a slave when it has no more LSA headers to advertise, and the slave’s last received DD packet has the M flag cleared.

In the beginning of the exchange, each router places the other into the ExStart state. Each of them considers itself to be the master, and sends an empty DD packet to the other router, containing a randomly chosen sequence number, and MS(Master), M(More), and I(Init) flags set to 1. After receiving the neighbor’s DD packet, however, the router with the lower RID will change its role to slave, and it will respond with a DD packet with MS and I flags cleared and the sequence number set to the sequence number of master’s DD packet. This accomplishes the master/slave selection, and both routers move to the Exchange state. The master will then send a DD packet with the sequence number incremented by 1, optionally containing one or more LSA headers, and the slave will respond with a DD packet reusing the same sequence number from the received packet, optionally advertising its own LSA headers. The exchange continues in the same fashion, with the master incrementing the sequence number of each subsequent DD packet, until both routers have advertised all known all LSA headers.

Requesting, Getting, and Acknowledging LSAs  

After all LSA headers have been exchanged using DD packets, each neighboring router has a list of LSAs known by the neighbor. Using that knowledge, a router needs to request a full copy of each LSA that is missing from its own LSDB. To know whether a neighbor has a more recent copy of a particular LSA, a router looks at the sequence number of the LSA in its LSDB and compares it to the sequence number of that same LSA learned from the DD packet. Routers use Link-State Request(LSR) packets to request one or more LSAs from a neighbor. The neighboring router replies with Link-State Update (LSU) packets, which hold one or more full LSAs. Both routers sit in a Loading state while the LSR/LSA process continues. After the process is complete, they settle into a Full state.

Designated Routers on LANs

OSPF optimizes the LSA flooding process on multiaccess data links by using the concept of a designated router(DR). They create a type 2 LSA that represents the multiaccess network segment.

Designated Router Optimization on LANs 

If the DR or BDR needs to send an update, it simply does it directly by sending an LSU packet containing the updated LSA to the multicast IP address 224.0.0.5, the All OSPF Routers group. A router on a multiaccess segment that is neither DR nor BDR is in the Full state only with the DR and BDR. If it needs to send an update, it sends an LSU packet to the multicast IP address 224.0.0.6, the All OSPF DR Routers group. Neither the DR nor BDR acknowledge the original LSU with an LSAck. Instead, the LSU flooded by the DR serves as an implicit acknowledgment to the original router that sent the update. Other routers on the segment including the BDR, except the original router, will acknowledge the DR’s LSU with a unicast LSAck sent to the DR. When a DR is used on a link, a router that is neither a DR or a BDR is called a DROther router. Two neighbors that are both DROthers do not become fully adjacent; they stop at the 2-Way state.

To describe the fact that some neighbors do not directly exchange DD and LSU packets, OSPF makes a distinction between the terms neighbors and adjacent, as follows:  

  -Neighbors: Two routers that share a common data link and that exchange Hello messages, and the Hellos must match for certain parameters.   

  -Adjacent(fully adjacent): Two neighbors that have completed the process of fully exchanging DD and LSU packets directly between each other.    

DR Election on LANs  

The election occurs after the routers have become neighbors, but before they send DD packets and reach the ExStart neighbor state. When an OSPF router reaches the 2-Way state with the first neighbor on an interface, it has already received at least one Hello from that neighbor. If the Hello messages state a DR of 0.0.0.0—meaning that none have been elected—the router waits before attempting to elect a DR wait with the goal of giving all the routers on that subnet a chance to finish initializing after a failure so that all the routers can participate in the DR election. The wait time period is called the OSPF wait time, which is set to the same value as the Dead timer. However, if the received Hellos already list the DR’s RID, the router does not have to wait before beginning the election process. The router does not attempt to elect a new DR, assuming that the DR listed in the received Hello is indeed the current DR. Generally speaking, the following rules govern the DR/BDR election process:   

  -Any router with its OSPF priority set to 1–255 inclusive is eligible to become a DR or BDR. A router with its OSPF priority set to 0 is ignored in DR/BDR elections.   

  -Each router performs the elections locally based on the collected data from other neighbors on the segment;

  -During the wait interval, whose length is automatically set to the Dead interval on the interface, each router collects the priorities and RIDs of other neighbors on the segment by listening to received Hellos, adding its own RID and priority to the list as well. However, a router does not assert itself as the DR or BDR during the wait interval, and all Hellos it sends indicate that the DR and BDR are not yet elected. 

  -If, during the wait interval, a Hello packet arrives from a neighbor that claims itself to be the BDR or if a neighbor that claims to be the DR and no BDR address is indicated in the Hello, the router immediately proceeds to the DR/BDR election process. Otherwise, the full wait interval period on the interface needs to expire.   

  -The election is performed only for those roles that are not yet claimed in neighbor Hellos(either both DR and BDR, or just BDR). A router examines the list of priorities and RIDs it has collected over the wait interval, choosing the router with the highest priority as the DR. If multiple routers advertise the same highest or second-highest priority, still competing for the role of DR or BDR, the higher RID is used to break  the tie.

  -After the election has completed, if a new router arrives or an existing router improves its priority, it cannot preempt the existing DR and take over as DR (or as BDR).   

  -When a DR is elected and the DR fails, the BDR becomes the DR, and a new election is held for a new BDR only.  

Designated Routers on WANs and OSPF Network Types  

Not using a DR on a point-to-point WAN link makes sense. 

 Cisco router interfaces can be configured to use, or not use, a DR, plus a couple of other key behaviors, based on the  OSPF network type for each interface. The OSPF network type determines that router’s behavior regarding the following:   

  -Whether the router tries to elect a DR on that interface   

  -Whether the router must statically configure a neighbor(with the neighbor command), or find neighbors using the typical multicast Hello packets 

  -Whether more than two neighbors should be allowed on the same subnet.

The interface type values can be set with the ip ospf network type interface subcommand.

Caveats Regarding OSPF Network Types over NBMA Networks  

The key items you should check when looking at an OSPF configuration over Frame Relay, when the OSPF network types used on the various routers do not match:

  -Make sure that the default Hello/Dead timers do not cause the Hello parameter check to fail.

  -If one router expects a DR to be elected, and the other does not, the neighbors might come up and full LSAs be communicated. However, show command output might show odd information, and next-hop routers might not be reachable. So, make sure that all routers in the same NBMA subnet use an OSPF network type that either uses a DR or does not.   

  -If a DR is used, the DR and BDR must have a permanent virtual circuit (PVC) to every other router in the subnet. If not, routers will not be able to learn routes. Routers that do not have a PVC to every other router must not be permitted to become a DR/BDR.   

 -If neighbors need to be configured statically, configuring the neighbor command on a single router is sufficient to bring up the OSPF adjacency with the configured neighbor. For clarity and stability, however, it is better to configure  neighbor  commands on both routers.    

Two simple options exist for making OSPF work over Frame Relay—both of which do not require a DR and do not require  neighbor commands. If the design allows for the use of point-to-point subinterfaces, use those and take the default OSPF network type of point-to-point, and no additional work is required. If multipoint subinterfaces are needed, or if the configuration must not use subinterfaces, adding the ip ospf network point-to-multipoint command on all the routers works.

Example of OSPF Network Types and NBMA  

On NBMA networks with an OSPF network type that requires that a DR be elected, make sure that the correct DR is elected. The DR and BDR must each have a PVC connecting them to all the DROther routers and to each other. With partial meshes, the election should be influenced by configuring the routers’ priority and RIDs such that the hub site of a hub-and-spoke partial mesh becomes the DR.

The priority specified in the neighbor command is never used in DR/BDR elections. For that purpose, exclusively the interface priority configured by the ip ospf priority interface command is taken into account. However, if there are multiple neighbor statements configured and at least one of them has a nonzero priority specified in the statement (the default neighbor  priority setting is 0 when  unspecified), the router will first send Hello packets only to those neighbors with a nonzero priority. Only  after DR/BDR elections have completed between these routers, the router will start sending Hello packets to all remaining neighbors.

The priorities specified in the  neighbor commands do not need to match the real priorities of these neighbors, but if they differ, the router can engage in DR/BDR elections with neighbors not entitled to become a DR/BDR. In any case, though, real priorities of these neighbors as seen in their Hello packets will be used to complete the DR/BDR elections.

Also, if the neighbors are reachable over an interface whose priority has been set to 0 using the ip ospf priority command, the router will automatically remove all corresponding neighbor statements from the configuration. This behavior prevents the router from participating in any way in the DR/BDR elections. This forces the router to wait for its neighbors to contact it. The router knows about no neighbors on its own, and is dependent on the DR and BDR contacting it thanks to their own neighbor statements.  

SPF Calculation  

After a router has new or different information in its LSDB, it uses the Dijkstra SPF algorithm to examine the LSAs in the LSDB and derive the new tree of shortest paths to available destinations.

Steady-State Operation

  -Each router sends Hellos, based on per-interface hello intervals.   

  -Each router expects to receive Hellos from neighbors within the dead interval on each interface; if not, the neighbor is considered to have failed.   

  -Each router originally advertising an LSA refloods each LSA (after incrementing its sequence number by 1) based on a per-LSA Link-State Refresh (LSRefresh) interval(default 30 min).   

  -Each router expects to have its LSA refreshed within each LSA’s MaxAge timer(default 60 min)

EIGRP - Named Mode, Additional and Advanced EIGRP Features

Starting with IOS Release 15.0(1)M, an EIGRP process on a router can be configured using a so-called named mode. It is the preferred mode and all commands for new features in EIGRP will be made available in the named mode only. It is very important to stress that the classic and named mode are just two different ways of how EIGRP is configured. They do not  constitute two different versions of EIGRP. There is no difference to EIGRP packet format or operation, except(of course) the new configurable features for which the commands are available only in the named mode.

Address Family (AF) section: Created using the  address-family  command, this is a mandatory section directly inside  router eigrp   name  configuration that specifies the particular address family for which an EIGRP instance shall be started.

Per-AF-interface section: Optional. It holds EIGRP settings pertaining to the specified interface and AF. One per-AF-interface section can be created for each routed interface or subinterface.

Per-AF-topology section: This is a section present inside a particular AF, related to the support of Multi Topology Routing (MTR) in EIGRP.

Multiple-name EIGRP processes can be started on a single router as long as their names are unique. The process name is not sent in EIGRP messages; it is a locally significant value and is never compared to process names on other routers.
Each named EIGRP process can hold only a single instance for an address family. It cannot have 2 IPv4 address family in the same process. 1 IPv4 and 1 IPv6 is ok. Also, two or more distinct named EIGRP processes cannot run the same address family instance with the same AS number.

In the classic mode configuration of IPv6 EIGRP, an IPv6 EIGRP process was shut down by default after configuring it, and a no shutdown command was necessary to actually start it. In the named configuration mode, as soon as you configure an IPv6 address family, it automatically adopts all interfaces on which IPv6 has been enabled (even a link-local address is sufficient) and starts running on them.

Note the difference between deactivating an EIGRP address family instance on an interface using the shutdown command and declaring an interface as passive using the passive-interface  command (both used in an  af-interface  section): No EIGRP adjacencies will be formed over a passive interface, but its global prefixes will still be advertised over other interfaces. Deactivating an EIGRP address family instance makes the EIGRP completely ignore the interface, not forming any adjacencies over it and also not advertising any of its prefixes.

Address Family Section: This section is where any configurations specific to the EIGRP process itself are applied. Commonly used commands include  network and neighbor statements.

Per-AF-Interface Configuration Section: This configuration section is where all EIGRP interface-specific commands are applied. Except non-EIGRP-specific commands such as bandwidth and delay, every other EIGRP-related command can now be configured in this section.

Per-AF-Topology Configuration Section: This configuration mode relates to the support of multiple routing topologies in EIGRP. Multiple topologies can be used to segregate different classes of traffic, such as data, voice, and video, and carry them over different links in the same physical network, or to keep separate and independent topologies for IPv4 and IPv6 routing.

Together with the named mode, related  show  commands have also been updated. Instead of show ip eigrp, the new show eigrp address-family ipv4; instead of show ipv6 eigrp, show eigrp address-family ipv6 .

Additional and Advanced EIGRP Features 

Router ID

As with many protocols, EIGRP also uses a concept of a Router ID(RID), a single 4-byte number representing a particular router instance. The primary use of the EIGRP RID has been to reduce the possibility of routing loops in networks where route redistribution is being performed on more than one router. A router will discard every received route carrying the router’s own RID. 

The rules of RID value selection are the same as with OSPF. First, the eigrp router-id command in EIGRP configuration is preferred. If not configured, the highest IP address among nonshutdown loopback interfaces is chosen. If not, the highest IP address among all other nonshutdown interfaces. If a router’s RID changes, it drops and reestablishes its adjacencies; a brief connectivity outage might therefore ensue.  

When you are changing interface addresses of a running router without restarting it, the EIGRP RID will remain unchanged. This can cause unpleasant issues when a new router is introduced into the network, retaking other routers’ addresses and tasks, while the old router is renumbered without restarting it. They will not learn route injected by each other becuase of the same RID. show eigrp address-family ipv4 events can be used to view such event.

Router ID can be viewed via show ip eigrp topology, show ipv6 eigrp topology, show eigrp protocols and show ip protocols commands. 

Unequal-Cost Load Balancing

Unlike most internal routing protocols, EIGRP has a feature that allows you to distribute the load of your traffic across multiple unequal-cost paths and not just over paths providing the least distance to a destination. The key to unequal-cost load balancing is the presence of Feasible Successors. 

Unequal-cost load balancing is enabled through the variance multiplier command which essentially defines how many times worse than the best path a route through a Feasible Successor can be to be still used by EIGRP for unequal-cost load balancing.  A multiplier of 1, which is the default, implies that no unequal-cost load balancing is being performed.The current variance valued is viewed va show ip protocols command. If multiple unequal-cost paths to a destination are installed into the routing table, the router will forward proportionally less traffic over the worse paths, and vice versa. 

The key to performing unequal-cost load balancing is first to have Feasible Successors toward a destination. Routers that do not meet the Feasibility Condition and thus are not considered Feasible Successors are not considered in the unequal-cost load balancing. 

Add-Path Support  

Starting with IOS Release 15.3(2)T, EIGRP was extended with a so-called Add-Path support, allowing a hub to advertise multiple equal-cost routes to the same destination. The prerequisite is to first have them installed in its routing table. This might require tuning the metrics and the  maximum-paths command value first. Also, the hub router must have the Split Horizon deactivated on the multipoint tunnel interface toward individual spokes.  

The Add-Path feature can be configured only in the named mode, and is controlled on a per-interface basis.

Spoke routers do not need to be specifically configured for the Add-Path feature, apart from possible tuning of the  maximum-paths command to be allowed to insert multiple equal-cost paths into their routing tables. The Variance (Unequal Cost Load Balancing) and Add-Path features are not compatible with each other.

Stub Routing

The stub routing feature is most commonly used in hub-and-spoke networks and is configured only on spoke routers. The results of configuring a router as a stub are multifold: 

  -A stub router does not propagate routes learned through EIGRP to its neighbors, with the exception of EIGRP-learned routes that are explicitly selected using leak-map construct. This prevents a stub router from ever being considered a Feasible Successor for remote networks by its neighbors.

  -A stub router advertises only a subset of its own EIGRP-enabled networks to its neighbors. 

  -Neighbors of a stub router aware of its stub status (thanks to the specific TLV in the stub router’s Hello packets) will never send a Query packet to a stub router.

The following rules summarize the stub router behavior with respect to handling Query packets:

  -Originating Query packets is not modified in any way. Rules for entering the Active state and sending Queries are precisely the same.   

  -Processing received Query packets depends on what network was queried for. If the network in the received Query is a network the stub router is allowed to advertise, meaning that it falls under the configured category of summary ,  connected, static, or redistributed, the router will process the Query normally (even possibly causing the stub router to become Active itself) and send back an appropriate Reply. The same is valid for an EIGRP-learned network that is allowed to be further advertised using a leak-map. If the Query contains a network that the stub router knows about but  is not allowed to advertise, it will be processed in the usual way but the Reply will always indicate infinite distance, regardless of what the stub router truly knows about the network.

There are two primary reasons why even a stub router might receive a Query. First, a stub router’s neighbor might be running an old IOS that does not recognize the stub TLV yet. Second, if there are multiple routers on a  common segment and all of them are configured as stub routers, if any of these stub routers need to send a Query, it will also send it to all its stub neighbors. 

In case of multiaccess segments with mixed neighbors (stub and nonstub), EIGRP solves the problem of sending Queries only to nonstub neighbors in two ways: Either it sends the Queries as unicasts to the nonstub neighbors or it uses the Conditional Receive mode in RTP to send multicast Queries. Although mixing stud/nonstub router on a common subnet is not a recommended practice, it is used in cases where the hubs and spokes are interconnected by a DMVPN or a VPLS service.

The EIGRP stub routing feature provides important advantages when implemented in hub-and-spoke networks:  

  -It prevents suboptimal routing from occurring within hub-and-spoke networks.   

  -It prevents stub routers with low-speed links from being used as transit routers.   

  -It significantly limits the number of Query packets and the depth of their propagation, allowing the EIGRP network to convergence faster and avoid the SIA states.    

In named mode, the eigrp stub command is used in the particular address family section.
When using receive-only keyword, the stub router does not advertise any prefixes. It only receives prefixes advertised to it by its neighbors. This keyword cannot be used with any other keywords when configuring stub routing.
The leak-map name keyword configures the stub router to advertise selected EIGRP-learned routes that would not be ordinarily advertised. The  name references a route-map. The leak-map is crucial in scenarios where a branch office uses a pair of interconnected routers configured as stub routers. If these routers are to provide backup connectivity to each other, they must be allowed to readvertise EIGRP-learned routes to each other, even in stub mode.
The connected keyword configures the stub router to advertise connected subnets. Note that the directly connected interfaces will not be advertised automatically; it is still necessary to add them to EIGRP using the usual network command.
The static keyword configures the stub router to advertise static routes. The static routes need to be redistributed into EIGRP to be advertised.
The summary keyword configures the stub router to advertise summary routes if configured on interfaces.
By default, when eigrp stub is enabled without additional keywords, both connected and summary are assumed. In a hub-and-spoke network, the hub router can be configured to advertise only the default route to the spoke router(s), filtering out all other more specific route entries, effectively reducing the routing table on the spoke to a single EIGRP-learned default route entry.

Use show ip protocols - to check current router stub setting. show ip eigrp neighbors detail - to check neighbor's stub settings.

Route Summarization 

Route summarization reduces the amount of routing information that routers must exchange, process, and maintain, which allows for faster convergence and less router load within the network. With particular respect to EIGRP, summarization is also a powerful tool to create a boundary for Query propagation.

Neighbors of a router performing route summarization do not know the individual component routes. Queries originated inside the summarized part of network, including those for component routes, will be propagated according to the usual rules; a router performing route summarization does not modify the Query contents nor influence its flooding scope. However, when a Query asking for a particular component route is forwarded to the summarizing router’s neighbor, this neighbor has no knowledge of the component, so it immediately responds with a Reply containing infinite distance. As a result, summarization causes the propagation of Queries to be bounded by directly connected neighbors of routers that perform route summarization.  

EIGRP supports automatic and manual route summarization. In automatic summarization, a subnet of a particular major network is advertised as the major network itself if the subnet is to be advertised out an interface that lies in a different major network. In EIGRP, automatic summarization does not apply to external routes unless there is also an internal network that belongs to the same major network as the external routes. The no auto-summary command should be used in the EIGRP configuration to deactivate it.  

Manual summarization allows summarizing routes at any chosen router and its interface in the network. EIGRP poses no limitations on the particular manual summary address/netmask combination. If it suits you, you can summarize even into a default route. Furthermore, configuring multiple overlapping summary addresses on an interface is also supported. Manual summarization is configured on a per-interface basis using the ip summary-address eigrp autonomous-system address netmask [distance] [leak-map name] command in classic config mode. In named mode in the corresponding af-interface section, use the summary-address address netmask [leak-map name] command.

Whenever a summary route is advertised, the router performing the summarization automatically installs a so-called discard route for this summary route into its routing table. The network and netmask in this discard route are identical to the network and netmask of the advertised summary, and the outgoing interface is set to Null0. The discard route prevents suboptimal routing or routing loops in situations when a router advertises a summary route but has no knowledge of a more specific matching subnet for incoming traffic. A discard route’s administrative distance is 5 by default. To raise the discard route’s administrative distance, use the admin-distance optional argument in the ip summary-address eigrp per-interface command and use the summary-metric address netmask distance admin-distance command in topology base section of named mode.

Be careful about setting the discard route’s administrative distance to 255. In earlier IOS releases, this prevented the discard route from being installed into the routing table, but the summary address was nonetheless advertised. 

By default, when an EIGRP router originates a summary route, it looks up the lowest metric from among all known component routes that are covered by this summary, and uses this metric as the metric of the summary route itself. The summary-metric command in topology base section can be used to set a static metric.

Using a leak-map leak-map optional keyword allows the prefixes permitted by the route-map(EIGRPLeak) to be advertised unsummarized along with the summary route.

R2(config-router-af-interface)#  summary-address  172.20.32.0/19 leak-map EIGRPLeak 

The show ip protocols command will list all configured summaries and interfaces they are placed on, including the advertised computed metric. In  show ip route the corresponding discard route will be shown if the summary is being advertised,

Passive Interfaces  

Can enabled on logical interfaces such as loopback interfaces and on interfaces connected to networks with end hosts.

A passive interface does not send or process received EIGRP packets, but the network configured on the interface is still advertised. In the classic configuration mode, the passive-interface command accepts an interface name or the default keyword, causing all interfaces to be considered passive; in that case, the no passive-interface command can subsequently be used to make selected interfaces active again. 

Graceful Shutdown  

The Graceful Shutdown allows a router to advertise that it is being deactivated, either on an interface, for a particular address family, or as the entire process, thereby allowing its neighbors to react immediately, rather than wait for the Hold timer to expire.

Classic config mode allows only IPv6 EIGRP to use the shutdown command. IPv4 EIGRP has no direct shutdown command. In the classic mode, the Goodbye message was usually sent when shutting down interfaces, configuring them as passive, removing the related network or ipv6 eigrp  

commands, or removing the entire EIGRP process or restarting the router. In the named mode, the shutdown command can be used in various places:  

  -Directly in the router eigrp mode, causing all configured address family instances under that process name to be deactivated   

  -In the particular address family mode, causing the entire particular address family instance to be deactivated   

  -In the particular af-interface section in the address family mode

Securing EIGRP with Authentication  

Since its inception, EIGRP supports Message Digest 5(MD5) hashing to ensure the integrity of EIGRP messages and to prevent the injection of false routing information into the EIGRP domain. In addition, starting with IOS Releases 15.1(2)S and 15.2(1)T, EIGRP authentication support has been extended with the second-generation Secure Hash Algorithm, also known as SHA-2.

MD5 authentication can be configured both in classic and named mode; SHA authentication can only be configured in the named mode. 

As with all key chain–based authentication schemes, for the authentication between two neighbors to succeed, they must match on the key ID and key string used to authenticate exchanged packets. 

In the classic mode, ip authentication mode eigrp and ip authentication key-chain eigrp interface commands to activate MD5 authentication. There is no way to configure EIGRP authentication for all interfaces at once. In named mode, confgiure in af-interface section using the authentication mode and authentication key-chain commands. 

If multiple keys in the key chain are eligible to sign egress packets, the key with the lowest key ID will be used. To authenticate received packets, EIGRP will try to use the key indicated by its ID in the received packet if the key is still valid.

Default Routing Using EIGRP

EIGRP has no dedicated command to inject a default route into an EIGRP domain. Well-known techniques to advertise default route are

 -Redistributing the default route from other routing source into EIGRP,

 -Using manual summarization to summarize all advertised routes into a default route. Often used in hub-and-spoke scenarios, this requires a suitable topology.    

Configuring network 0.0.0.0 is almost never a good idea. Take note that if the default route on the router is not configured specifically as a directly connected static route, the network 0.0.0.0 command has no effect on it and will not cause it to be advertised.

Split Horizon

A route must not be advertised over an interface used to reach it. This prevents the “re-advertising” of routing information back to the next hop from which it is learned in the first place. 

While Split Horizon with Poisoned Reverse is a powerful loop-prevention mechanism, it is sometimes necessary to deactivate it. This is particularly important in hub-and-spoke networks, where multiple spoke routers are reachable over a single interface on a hub using (Frame Relay or ATM multipoint interfaces, multipoint GRE tunnels in DMVPN deployments). If the topology and requirements permit it, the most scalable solution to this issue is to advertise a default route to all spokes.

EIGRP can be configured to deactivate the Split Horizon with Poisoned Reverse on a per-interface basis.

EIGRP Over the ToP  

Over the ToP, or OTP. This feature allows creating overlay multipoint VPNs between customer edge routers running EIGRP without any special cooperation with the service provider that operates the network interconnecting the edge routers. The key to the OTP functionality is the Locator/Identifier Separation Protocol, or LISP. 

The Locator/Identifier Separation Protocol (LISP) aims at decoupling the location of a host from its identity, allowing the host to retain its identity regardless of its location in a network. The general idea in LISP is to separate the identity and location into two independent entities, each of them represented by a complete address, and provide a mapping service.

In LISP, a host has an Endpoint ID, or EID, that identifies its identity that never needs to change. This EID can be an IPv4 address, an IPv6 address, or any other address format as needed. The outside address of the router effectively represents the location of the EID and is denoted as Routing Locator, or RLOC. 

In OTP, EIGRP serves as the replacement for LISP control plane protocols. Instead of doing dynamic EID-to-RLOC mappings in native LISP-mapping services, EIGRP routers running OTP over a service provider cloud create targeted sessions, use the IP addresses provided by the service provider as RLOCs, and exchange routes as EIDs. 

With just a few OTP routers, configuring a full mesh of static neighbors is relatively easy. However, if the OTP network grows, this would not be a scalable approach. Therefore, OTP also introduces a special router role, a so-called route reflector that allows collapsing the full mesh of OTP neighbors to a hub-and-spoke model of neighbor configuration, with the route reflector collecting learned networks from its clients and readvertising them back to individual clients, optionally maintaining the original next-hop value.

EIGRP Logging and Reporting

The eigrp event-logging enables the router to store a log of EIGRP events. The contents of the EIGRP log can be viewed by issuing the show eigrp address-family {ipv4 | ipv6} events command. By default, the EIGRP event log stores up to 500 lines of events. 

The eigrp log-neighbor-changes router configuration command allows the router to log EIGRP neighbor relationship changes. This command is enabled by default.

EIGRP Route Filtering 

Outbound and inbound EIGRP updates can be filtered at any interface, or for the entire EIGRP address family instance, in either direction. EIGRP allows ACLs, prefix lists, and route-maps to be used for route filtering in a distribute-list command.

  -ACLs: distribute-list acl-number | acl-name {in | out} [interface]   

  -Prefix lists: distribute-list prefix prefix-list-name {in | out} [interface]   

  -Route maps: distribute-list route-map route-map-name {in | out} [interface]    

Prefix lists is recommended. Distribute lists do not directly limit the propagation of Queries. Instead, what they do is more involved:  

  -For distribute lists in the out direction: All outgoing Updates, Queries, Replies, SIA-Queries, and SIA-Replies will indicate the correct metric for permitted prefixes and infinite metric for denied prefixes.   

  -For distribute lists in the in direction: In all incoming Updates, Replies, and SIA-Replies, permitted prefixes are processed normally while denied prefixes are ignored. Received Queries and SIA-Queries are not influenced by the distribute list and are processed without modification.  

EIGRP Offset Lists  

EIGRP offset lists allow EIGRP to add to a route’s metric, either before sending an update or for routes received in an update. The offset list also specifies which routing updates to examine by specifying a direction(in or out) and, optionally, an interface. If the interface is omitted from the command, all updates for the defined direction will be examined.

Clearing the IP Routing Table  

Because EIGRP keeps all possible routes in its topology table, a clear ip route * command does NOT cause EIGRP to send any messages or learn any new topology information; the router simply refills the IP routing table with the best routes from the existing topology table. The clear eigrp address-family {ipv4 | ipv6} neighbors command can be used to clear all neighbor relationships and have the router reestablish them from scratch. An optional soft keyword allows for a graceful restart, in which the topology databases between the router and its neighbors are resynchronized but the adjacencies are not torn down.