IS-IS Routing Protocol - Part 2

IS-IS Operation over Different Network Types

IS-IS natively supports only broadcast and point-to-point network types. IS-IS has no special provisions to correctly operate over partially meshed data link layer technologies such as hub-and-spoke Frame Relay. Recommended practice dictates that you configure such networks using point-to-point subinterfaces and run IS-IS over these point-to-point links.  It is noteworthy to mention that what IS-IS calls broadcast links should much better be
called multiaccess links.

In IS-IS, there are only three possible adjacency states:
  -Down: The initial state. No IIHs have been received from the neighbor.
  -Initializing: IIHs have been received from the neighbor, but it is not certain that the neighbor is properly receiving this router’s IIHs.
  -Up: IIHs have been received from the neighbor, and it is certain that the neighbor is properly receiving this router’s IIHs.

IS-IS Operation over Point-to-Point Links  

In OSI addressing, each router assigns a locally significant single octet number to each interface, and this number is called the Local Circuit ID.
The three-way-handshake method is based on each router on a point-to-point link advertising an adjacency state TLV in its IIH packets that contains the following fields:
  -Adjacency Three Way State: This is the state of adjacency as seen by the sending router.
  -Extended Local Circuit ID: This is the ID of the sending router’s interface.
  -Neighbor System ID: This value is set to the ID of the neighboring router whose IIHs have been successfully received.
  -Neighbor Extended Local Circuit ID: This value is set to the Extended Local Circuit ID field value from the neighbor’s IIH packets.  

The logic of the three-way handshake (Early Cisco Implementation)
  1. If Router A receives an IIH from Router B with the Adjacency Three Way State set to Down, it is clear that Router A can hear Router B. It is not certain, though, whether Router B can hear Router A. Router A will start sending its IIH with the Adjacency Three Way State set to Initializing to tell Router B it can hear it.
  2. When Router B receives an IIH from Router A with the Adjacency Three Way State set to Initializing, it knows that these IIHs are effectively sent in response to its own IIH, and that Router A is in fact telling Router B it can hear it. Router B is now certain that bidirectional communication is possible. Therefore, it starts sending its IIH with the Adjacency Three Way State set to Up.
  3. When Router A receives an IIH from Router B with the Adjacency Three Way State set to Up, it knows Router B can hear it. Router A is now also certain that bidirectional communication is possible and starts sending its IIH with the Adjacency Three Way State set to Up, concluding the three-way handshake.  

(IETF Implementation) The adjacency state TLV was augmented with the Extended Local Circuit ID, neighbor System ID, and Neighbor Extended Local Circuit ID fields to carry additional information about the neighbor’s identity and interface.
With these fields in place, an IIH that carries a three-way adjacency state TLV is accepted only if one of the following conditions is met:
  -The Neighbor System ID and Neighbor Extended Local Circuit ID are not present (typical at the beginning of the adjacency buildup, or the neighbor implements only the early version of the three-way handshake).
  -The Neighbor System ID matches the receiving router’s System ID and the Neighbor Extended Local Circuit ID matches the receiving interface’s ID.
If these conditions are not met, the incoming IIH is silently dropped. Hence, these rules form an IIH acceptance check.
Therefore, the three-way handshake logic as described in the three previous steps changes simply by replacing all occurrences of “ receives IIH ” with “ receives and accepts IIH .”

After the adjacency is declared as Up, routers will attempt to synchronize their link-state databases. Both routers will mark all their LSPs for flooding over the point-to-point link; plus they send CSNP(Complete Sequence Number Packet) packets to each other. If a router learns from the received CSNP that its neighbor already has an LSP that is scheduled to be sent, the router will  unmark  the LSP, removing it from the set of LSPs to be flooded. This way, only the LSPs missing from the neighbor’s database will be sent to it. In addition, if a router learns from the received CSNP that the neighbor has LSPs that are newer or unknown, it will request them using a PSNP packet. Note that neither of these is necessary, as both routers nonetheless initially set up all their LSPs to be flooded across the link, without the aid of CSNP or PSNP packets. The  initial  sending of CSNPs to compare the link-state databases and PSNPs  to request missing or updated entries increases the resiliency of the synchronization process but is not strictly necessary.  Importantly, though, every LSP sent over a point-to-point link, whether during the initial database synchronization or anytime later when it is updated or purged, must be acknowledged, and this is done using PSNP or CSNP packets.

IS-IS Operation over Broadcast Links  

Detecting neighbors is again performed by IIH packets. In a fashion similar to OSPF, an IS-IS router lists the MAC addresses (or better said, SNPAs) of all neighboring routers it hears on a broadcast interface in its IIH packet sent through that interface. If a router receives an IIH from a neighbor and finds its own SNPA indicated in the IIH, it knows that the routers can see each other, and can move the adjacency to the Up state. If not, the adjacency is kept in the Initializing state. OSPF performs a similar operation, but it lists Router IDs of heard routers in its Hello packets.

IS-IS also elects one Designated IS for each broadcast network but it has no concept of a backup DIS. A DIS is elected based on these criteria:   

  -The router with the highest interface priority.  

  -In case of a tie, the router with the highest SNPA.   

  -In case the SNPAs are not comparable, the router with the highest System ID. This rule is used on Frame Relay and ATM physical interfaces and multipoint subinterfaces, which are treated as broadcast interfaces by IS-IS.

The interface priority is configurable using a perinterface isis priority priority [level] command. DIS elections in IS-IS are preemptive: Whenever a router is connected that has a higher priority than the current DIS, the same priority and higher SNPA, it will take over the DIS role.

In IS-IS, all routers on a common broadcast segment become fully adjacent, regardless of which is the DIS. This is different from OSPF. In IS-IS, 

every router can send  an LSP on the broadcast link and all others are allowed to accept it.A DIS is responsible for two important operations: 1) Helping routers on a broadcast segment to synchronize; 2) Representing the broadcast segment in the link-state database as a standalone object—the Pseudonode. 

Synchronization of IS-IS routers on a broadcast network is surprisingly simple. The DIS creates and sends a CSNP packet in regular intervals (10 seconds by default) on the segment. This CSNP packet lists all LSPs present in the DIS’s link-state database. Other routers on the segment receive this CSNP and compare it to the index of their own link-state database.

The DIS is not a relay of LSPs; rather, it is a reference point of comparison. If a router misses an LSP known by the DIS, or if the LSP is older than the one known by the DIS, the router will request the newer LSP through PSNP and the DIS will flood it. If the PSNP or the LSP gets lost during transmission, the process will simply repeat itself. Conversely, if a router knows about a newer LSP than the one known by the DIS, or if the DIS seems to miss it  completely, the router will simply flood the LSP onto the network. No explicit acknowledgment by the DIS is sent. If the LSP has arrived, the DIS will advertise it in its next periodic CSNP, and this CSNP serves as an implicit acknowledgment.. PSNPs are used on broadcast networks only to request LSPs, not to acknowledge them.  Another responsibility of the DIS is to represent the broadcast network in the link-state database so that the topological model of the network is simpler.

With a pseudonode, the broadcast network itself is represented as a node—more specifically, a pseudo node—in the topology. To exist as a pseudonode in a link-state database, a broadcast network must have its own LSP. It is the responsibility of the DIS to originate and flood the Pseudonode LSP on behalf of the broadcast network. Recall that each LSP is identified by a triplet of System 

ID, Pseudonode ID, and LSP Fragment Number. ID. In case of router LSPs, the System ID carries the ID of the router and the Pseudonode ID is set to 0. In case of network LSPs (that is, Pseudonode LSPs), the System ID is the ID of the DIS, and the Pseudonode ID is set to the Local Circuit ID of the DIS’s interface in the network. 

The show isis hostname  is used to check the mapping of hostnames to System IDs. To verify IS-IS neighbor adjacencies, show isis neighbors is useful. show isis neighbors detail would also show information about each router's SNPA and configured priority. The show isis database lists Pseudonode LSP that is recognizable by its Pseudonode ID being non-zero. To see the contents of LSPs, show isis database detail can be used. 

The router acting as a DIS shortens its own Hello and Hold time to just one-third of the configured values. This is done to allow other routers to detect its failure more rapidly. If a DIS fails, another router will be elected in its place, but because there is no additional adjacency buildup necessary (all routers on the segment are already fully adjacent), a DIS switchover is merely related to replacing the old Pseudonode LSP originated by the previous DIS with a new LSP from the newly elected DIS and remaining routers updating their LSPs to point toward the new Pseudonode LSP.

Areas in IS-IS

Because only a single NSAP address is assigned to a node, and the NSAP address contains the domain and area identifier, the entire node with all its interfaces belongs only to a single area. Because routers are also usually assigned a single NSAP address, they also belong to a single area only. It is in fact possible to configure up to three different NSAP addresses on an IS-IS router in a single IS-IS instance, provided that the System ID in all NSAP addresses is identical and the NSAP addresses differ only in their Area ID.
Multiple NSAP addresses on an IS-IS instance are nonetheless used only during network changes, and in stable operation, there should be only a single NSAP address configured per IS-IS process. IS-IS uses the entire high-order part of the NSAP address up to the start of System ID as the area identifier. Nodes in a single area must obviously be addressed using the same NSAP format, the same initial domain identifier, and the same internal area number(high-order domain specific part). Any difference in these octets would signify that the addressing format is different (and hence incomparable to any other), or the domain(that is, the autonomous system) is different, or the internal area numbering differs.

L1 routing is a process of intra-area routing. If OSI protocols such as CLNP were in use, routers would collect NSAP addresses of their directly attached end hosts and advertise them in their routing updates simply as other adjacencies. With IP protocols, each L1 router advertises its directly connected IP networks in its L1 LSP. A very important fact is that two interconnected neighboring L1 routers configured with different areas will never establish an adjacency.

L2 routing is a process of inter-area routing, that is, delivering packets between stations located in different areas. If OSI protocols were in use, routers would not collect nor advertise end host NSAP addresses. Instead, routers would only advertise their area IDs in their L2 LSPs. L2 routers therefore form a backbone of a multiarea domain, and for this backbone to operate correctly, it must be contiguous and  pervade all areas within the domain. Sometimes, the backbone as the set of L2 routers is also called an L2 subdomain. With IP protocols, IP addresses do not carry embedded area information like NSAP addresses. Each L2 router advertises its  directly connected IP networks  to achieve contiguous IP connectivity in the backbone,  plus all other L1 routes from its own area with appropriate metrics , to advertise IP networks present in particular areas. Thus, while LSPs are never leaked between L1 and L2 link-state databases, on L2 routers, IP  routing information computed from the router’s L1 link-state database is injected into its L2 LSP.  No IP networks are injected from L2 into L1 unless specifically configured.

L1 routers in an area have no L2 link-state database and therefore have no information about other areas that is carried by L2 routers. From this viewpoint, L1 routers in an area have a visibility identical to routers in an OSPF Totally Stubby Area—they see their own area but nothing more. Yet, a L1 router can still perform redistribution from external sources, and these redistributed networks will be visible both in that area and uptaken by L2 routers into the backbone. Therefore, L1 routers in an area behave more as if they were in an OSPF Not So Stubby-Totally Stubby (NSSA-TS) area.

L2 routers disrespect area boundaries when it comes to creating adjacencies and flooding link-state database contents. They create adjacencies with other L2 routers regardless of the area ID, and share all information present in their L2 link-state databases. Therefore, the entire L2 subdomain across all areas in the entire domain can be likened to a single OSPF backbone area.

IS-IS on Cisco routers defaults to L1L2 operation. Note the default administrative distance of 115 for all IS-IS-learned routes.

In show isis database  output, where three flags, ATT, P, and OL, are called ATTached, Partition repair, and Overload flags. The ATT flag is especially relevant to inter-area routing. When an L1L2 router performs its L2 SPF calculation and determines that it can reach other areas besides its own (note that LSPs also carry the area ID of their originating routers), it sets the ATT flag in its L1 LSP. L1-only routers in the area can use any router whose ATT bit is set in its L1 LSP to reach other areas. Because no IP addressing information flows down from L2 into L1, L1-only routers have no knowledge about prefixes in other areas. They automatically install a default route toward their nearest L1L2 router whose ATT bit is set into their routing table. The Partition repair bit indicates whether the router is capable of an optional feature that allows healing a partitioned area over the L2 subdomain—functionality similar to an OSPF virtual link. The Partition repair function was never widely implemented, and Cisco routers do not support it; hence they always set the P bit to 0.

Finally, the Overload bit was originally intended to signal that the router is, for whatever reason, unable to store all LSPs in its memory, and that its link-state database is overloaded. Therefore, if a router’s LSP has the O bit set, the SPF computation on other routers will ignore this router when computing shortest paths to other routers and their networks. However, the SPF will still take the directly attached  networks of this router into account because these continue to be reachable.

The O bit can also be used when a router needs to be taken out of service for maintenance without causing major disruption to the network. Instead of simply shutting the router down, setting the O bit first will make other routers immediately recalculate their routing tables, computing alternate paths (if such paths exist) that do not traverse this router. The network converges on alternate paths much sooner than it would take if the  router was simply taken offline and other routers needed to wait for its Hold timer to expire. Also, the O bit is very useful if a new router is to be attached to a network. Yet another important application of the O bit is to allow the router to settle its adjacencies  after reboot and wait for some time to stabilize while already running IS-IS and populating its routing table, before becoming a transit router. This feature is especially important with BGP that can converge significantly slower than IS-IS.

To see the contents of L2 database, the show isis database l2 detail command is used. Each the L2 LSP of each router contains both its directly connected networks along with all L1 networks in that router's area.
Identical L2 link-state database contents would be displayed on any L2-enabled router in this network. Looking at any L2 LSP in isolation, you do not even know which prefix is directly connected to the router and which one is an L1 prefix “uptaken” into L2—they are both advertised in the same manner.

Regarding redistribution, external networks are  by default injected into L2 but can be configured to be injected into L1 or both L1 and L2 on a router. If an external route is redistributed to L1, all other routers in the same area will see the route as an L1 IS-IS route. When “uptaking” L1 routes into L2 on backbone routers, they do not discriminate between internal L1 networks and external networks in the area that have been redistributed as L1 routes. Multiple areas in a domain are nowadays created primarily for the purpose of address summarization. In IS-IS, area summarization should be configured on each L1L2 router in the area using summary-address command inside the router isis section,

Authentication in IS-IS

IIH packets are authenticated independently of LSP, CSNP, and PSNP packets. In particular with LSPs, for L1 LSPs, all routers within the area must use the same  area password —the  level-1 authentication password , while for L2 LSPs, all  L2-enabled routers within the L2 subdomain must use the same  domain password —the  level-2 authentication password , to authenticate LSPs. If a single area or domain password was used to authenticate all packets, however, all routers in the area or in the backbone would be using the same password, which can be considered a security drawback. Therefore, to authenticate adjacencies themselves, IS-IS allows you to separately authenticate IIH packets.

Authentication in IS-IS can be activated independently for IIH and independently for non-IIH (LSP, CSNP, PSNP) packets. IIH authentication is configured on interfaces and applies only to IIH packets exchanged with directly connected neighbors. Therefore, different interfaces of a router can use different IIH passwords. The same type of authentication and the same password must be configured on all routers in an area if L1 non-IIH authentication is used, or on all L2 routers in the domain if L2 non-IIH authentication is used.

If IIH packets fail authentication, the routers will be completely prevented from communicating in IS-IS even if the non-IIH packets themselves passed the authentication or did not require the authentication. If IIH packets pass the authentication but the non-IIH packets fail it, the routers will be in the Up adjacency state but they will not be able to synchronize their link-state databases.

IPv6 Support in IS-IS  

IS-IS is a true multiprotocol routing protocol in the sense that it does not require any particular Layer 3 protocol to carry its packets, and in a single instance, it can carry information about destinations described by different address families. It is not necessary to start an additional IS-IS process to carry IPv6 routes along with IPv4. Instead, the existing IS-IS process is simply instructed to advertise IPv6 routes along with other information it is already advertising.

Configuring IS-IS    

Interfaces are added to IS-IS directly by configuring them with the ip router isis command. IS-IS has no network command. There is no network command in IS-IS.

If the network from the interface shall be advertised but the interface should remain passive, simply referring to it by the passive-interface  command is signal enough to IS-IS to know that the interface’s network should be advertised even though the interface itself should disallow creating any adjacencies over it. And finally, if the interface is intended to operate as an active interface, it shall be configured with the ip router isis  command.

If a router is configured for L1L2 operation, it will by default try to establish both L1 and L2 adjacencies over all active IS-IS interfaces. If it is known that an interface should be used to establish only L1 or only L2 adjacencies, it is possible to limit its operation only to the selected  level. That will prevent the router from sending and processing packets of a different routing level over that interface.

The per-interface isis authentication and per-process authentication commands support optional level-1 and  level-2 keywords to specify the desired level for which the authentication should be activated. If not specified, both levels are authenticated.

Note that unlike other IGP protocols, IS-IS does not use a separate process configuration section for its IPv6 operation. The  router isis  section is universal for all address families supported by IS-IS.

The show clns command shows a brief but useful information about this router's NET and mode of Integrated IS-IS operation

IS-IS Routing Protocol - Part 1

IS-IS is a link-state routing protocol. IS-IS does not run over any network layer protocol; instead, it encapsulates its messages directly into data-link frames. Adjacency and addressing information in IS-IS messages is encoded as Type-Length-Value (TLV) records, thereby providing excellent flexibility and extendability.

OSI Network Layer and Addressing 

The term  End System (ES) is used for a host, and the term  Intermediate System (IS) is used for a router. An end-to-end communication between two End Systems(hosts) in a Domain (autonomous system) involves zero or more Intermediate Systems (routers) interconnected by Circuits(interfaces).

Two basic services: connection-less-mode and connection-mode network layer communication. The connectionless mode of operation is identical to the way that IP operates, as a pure datagram service without any prior session establishments. In OSI networks, the Layer 3 network protocol that provides a connectionless communication between ES entities is called ConnectionLess-mode Network Protocol(CLNP). The CLNP protocol is to OSI networks what IPv4/IPv6  are to TCP/IP networks. The set of services provided by CLNP is called ConnectionLess Network Services, or simply CLNS. For connection-oriented mode in OSI networks, an adaptation of the X.25 protocol is used. There is no analogous connection-oriented network layer protocol in TCP/IP networks.

The addressing used in OSI networks, both in connectionless and connection-oriented mode, is called NSAP addressing , with the acronym standing for Network Service Access Point representing an address of a particular network service on a particular network node in the network.

NSAP addressing bears many differences to addressing in TCP/IP networks. An NSAP address is assigned to the  entire network node , not to its individual interfaces. A single node requires only one NSAP address in a common setup, regardless of how many network interfaces it uses. As a result, NSAP addressing does not have the notion of per-interface subnets similar to IP subnets.

An NSAP address consists of two parts: The Initial Domain Part(IDP) and the Domain Specific Part(DSP). The internal format and length of these two parts are variable to a large extent and depend on the actual application in which the NSAP addressing is used.  The IDP itself consists of two fields: the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI). The AFI value  indicates the format of the remaining address fields.The IDI field has a variable length depending on the address format indicated by AFI and might even be omitted. Together, the AFI and IDI indicate the routing domain (the autonomous system) in which the node is located.  

The DSP consists of a variable-length High-Order Domain Specific Part (HO-DSP) that identifies the part (or an  area) of the domain in which the node is located. The System ID is the unique identifier of the node itself. SEL field, also called an NSAP  Selector or NSEL, is a 1-octet-long field that identifies the particular service in or above the network layer on the destination node that should process the datagram. A rough analogy in the IP world would be the particular protocol above IP, or the transport port. 

In typical IS-IS deployments, the addressing uses the AFI of 49 in which the length and meaning of the HO-DSP field are entirely up to the administrator. If the value of the SEL octet is 0, no particular service is being addressed, and the entire NSAP address simply identifies the destination node itself without referring to any particular service on that node. An NSAP address in which  the SEL octet is set to 0 is called a Network Entity Title (NET), and this is the address that is configured on the node. Configuration of NETs will be a mandatory part of IS-IS configuration. To summarize, NSAP addresses can be thought to contain, in a single instance, information about the destination’s autonomous system, area, unique identifier, and even the requested upper-layer service. 

The written format of NSAP addresses uses hexadecimal digits separated into groups of one or more octets by a dot. 

For example, in 49.0001.1234.5678.3333.00, the AFI is 49, signifying a local address; the 0001 is the area number; the 1234.5678.3333 is the System ID of the node; and the trailing 00 is the SEL value, making this NSAP address also a NET. An NSAP address is often easier to read from right to left. In the NSAP address

49.0001.1234.5678.3333.00, the rightmost octet is the SEL value(00), the following six octets are the System ID (1234.5678.3333), followed by other HO-DSP octets(0001), IDI(not present in this NSAP) and ending with the leftmost octet, the AFI(49).  

As there is no concept of a subnet, routing between the two networks is accomplished by each IS assembling a list of all attached ES nodes and advertising it to its neighbors.  

Individual interfaces are not assigned their own addresses at the network layer. However, their Layer 2 addresses are used in the same way as TCP/IP networks use them. In OSI networks, a Layer 2 address of an interface is called a Sub Network Point of Attachment(SNPA). For purposes of distinguishing between interfaces of the same node, an IS enumerates its interfaces by a locally significant 1-octet number called the Local Circuit ID, which increments by 1 with every interface added to the IS-IS instance beginning with 0 on Cisco routers.   

Levels of Routing in OSI Networks 

Four levels of routing

  -Level 0 routing:  Routing between two ES nodes on the same link, or between an ES node and its nearest IS   

  -Level 1 routing:  Routing between ES nodes in a single area of a domain   

  -Level 2 routing:  Routing between ES nodes in different areas of a domain   

  -Level 3 routing:  Routing between ES nodes in different domains    

Level 0 routing is concerned with the way that an ES (end node) discovers its nearest IS(gateway), and conversely, how an IS knows which ES nodes are connected to it. This is accomplished by both ES and IS sending a periodic Hello message advertising their existence. Hellos sent by ES nodes are called ES Hello(ESH), while Hellos sent by IS nodes are called IS Hello(ISH). Level 0 routing is also referred to as ES-IS routing.

Level 1 routing is concerned with intra-area routing, that is, routing between ES nodes that are members of the same area. IS nodes in an area will have a detailed and complete visibility of the entire area’s topology. On Level 1, IS nodes collect lists of all ES nodes directly attached to them, and advertise these lists to each other to learn the placement of all ES nodes. Level 2 routing is concerned with inter-area routing within the same domain, that is, routing between ES nodes that reside in different areas of the same domain. On Level 2, IS nodes exchange area prefixes to learn how to reach particular areas. Hence, Level 1 routing can be described as routing by System ID, while Level 2 routing can be described as routing by area prefix. Level 2 routing constitutes the backbone of a domain, providing communication between individual areas of the domain. Level 3 routing is concerned with interdomain routing. In a TCP/IP world, this is a fairly direct analogy of inter-autonomous system routing provided by BGP.

IS-IS Metrics, Levels, and Adjacencies  

IS-IS metrics are assigned to individual interfaces (links). Four types of metrics:   

  -Default: Required to be supported by all IS-IS implementations; usually relates to the bandwidth of the link(higher value represents a slower link)   

  -Delay: Relates to the transit delay on the link   

  -Expense: Relates to the monetary cost of carrying data through the link   

  -Error: Relates to the residual bit error rate of the link    

Most IS-IS implementations today support only the default metric. Cisco IS-IS implementation assigns all interfaces the default metric of 10, regardless of their bandwidth. 

The original IS-IS specification and RFC 1195 define any single interface (link) and attached network metric to be 6 bits wide, resulting in the range of 1–63, and the complete path metric as 10 bits wide in the range of 1–1023. Today’s requirements, however, call for a much wider range of metrics. Wide metrics  were introduced, allowing for a 24-bit width for the interface metric and a 32-bit width for the entire path metric. It is ecommended to use wide metrics whenever available and supported; however, all routers in an area must use the same type of metrics.

IS-IS routers operate on each routing level independently. For each routing level, be it Level 1 or Level 2, an IS-IS router establishes separate adjacencies with its neighbors running on the same level, and maintains a separate link-state database. Two neighboring routers configured for both Level  1 and Level 2 routing will create two independent adjacencies, one for each level.

For each enabled level, a router originates and floods a Link State PDU(LSP). An LSP is similar to an OSPF Link State Update packet with one or more Link State Advertisements. IS-IS routers use Level 1 and Level 2 LSPs to describe their adjacencies on that particular level. Contents of a Level 1 link-state database are exchanged only over Level 1 adjacencies, and Level 2 link-state database contents are exchanged over Level 2 adjacencies only. 

IS-IS Packet Types  

Four types - Hello packet, Link State PDU, Complete Sequence Numbers PDU, Partial Sequence Numbers PDU.

Hello packets, also denoted as IIH (IS-IS Hello), are used to perform the usual task of detecting neighboring routers (and also their loss), verifying bidirectional visibility, establishing and maintaining adjacencies, and electing a Designated IS(DIS—similar to a Designated Router in OSPF). 10 seconds by default. The Hold time is 3 times hello time(30 sec by default). As opposed to OSPF, timers do not need to match on neighboring routers. On a DIS, the individual timers are  always  one-third of the configured timers (with default settings)—a DIS sends Hellos every 10/3=3.333 seconds, and the Hold interval is 30/3=10 seconds. This is done to detect a DIS or its outage more readily. There are three types of Hello: Level 1 Hello, Level 2 Hello (both used on broadcast networks), and L1L2 Hello (used on point-to-point interfaces).

Link State PDUs  

A Link State Protocol Data Unit (LSP) is used to advertise the routing information. An LSP is vaguely similar to an OSPF Link State Update packet containing one or more Link State Advertisements. There are, however, notable differences between OSPF LSU/LSA and IS-IS LSP. In OSPF, the smallest standalone element of the link-state database is an LSA (note that LSA is not a packet itself). In IS-IS, the smallest standalone element of the link-state database is an entire LSP. There are no different types of LSPs to describe different network objects; instead, these are described by distinct Type-Length-Value(TLV) records inside an LSP’s variably sized payload.

Similar to OSPF LSAs that are uniquely identified by their type and Link-State ID, IS-IS LSPs are also uniquely identified by a number that consists of three parts:  

  -System ID  of the router that originated this LSP (6 octets; taken from the router’s NET address)   

  -Pseudonode ID  that differentiates between the LSP describing the router itself and the LSPs for multiaccess networks in which the router is a Designated IS (1 octet) 

  -LSP Number  denoting the fragment number of this LSP (1 octet). The LSP Number is also called simply the Fragment Number or Fragment for short.  

We will denote this triplet of System ID + Pseudonode ID + LSP Number as LSPID. For LSPs that describe routers themselves, the Pseudonode ID is always set to 0. Separate LSPs are originated for Level 1 and for Level 2, depending on what levels the router operates at. To distinguish between various versions of the same LSP, each LSP has a sequence number—a 32-bit unsigned integer starting at 0x00000001 and ending at 0xFFFFFFFF. Each modification to an LSP is accompanied by incrementing its sequence number.

Each LSP has a Remaining Lifetime value associated with it. When originated, the Remaining Lifetime is set to 1200 seconds (20 minutes), and is decreased. IS-IS routers refresh their self-originated LSPs every 15 minutes. If the LSP’s Remaining Lifetime decreases to 0, the router will delete the LSP’s body from the link-state database, keep only its header, and advertise the empty LSP with the Remaining Lifetime set to 0. Flooding an empty LSP with the Remaining Lifetime set to 0 is called an  LSP purge . The expired LSP can be purged from the link-state database after an additional time called ZeroAgeLifetime set to 60 seconds. This is done to ensure that the LSP’s header is retained until the purged LSP has been safely propagated to all neighbors. 

Because IS-IS messages are encapsulated directly into Layer 2 frames whose maximum payload size—the Maximum Transmission Unit (MTU)—is limited, IS-IS must implement its own fragmentation functions for LSPs whose size exceeds the MTU. Each LSP consists of a fixed-size header and a variable-size body that contains one or more TLV records that carry the actual addressing and topological information. If putting all TLV records into a single LSP would cause it to exceed the MTU, the router will simply create multiple LSPs.  These LSPs are identified with the same System and Pseudonode ID, and with an increasing LSP Number as the fragment number, starting from 0. An important fact is that this fragmentation is performed only by the router that originates the LSP. After the LSP is flooded, it must not be modified by any other router, and also not be defragmented and/or refragmented. A consequence of this rule is that across the entire flooding scope of the LSP (an area for a Level 1 LSP, or all Level 2 routers and their interconnections for a Level 2 LSP), the MTU on interfaces must be identical. If this requirement cannot be met, IS-IS routers must be manually configured to keep each LSP not bigger than the smallest MTU.  

The show isis hostname on R1 displays the numerical System ID and the related hostname of the router with that ID. The show isis database shows the contents of the link-state database. 

In IS-IS, a router on a particular routing level generates only a single (although possibly fragmented) LSP containing all relevant information related to that router in one place:  

  -Adjacencies to neighboring routers or networks (similar to type 1 LSAs)   

  -Intra-area and inter-area prefixes(similar to prefix information collected from type 1, 2, and 3 LSAs)   

  -External prefixes(similar to type 5/7 LSAs)    

Type 2 LSA in OSPF carries two vital pieces of information: the address and netmask of a multiaccess network (address information) and a list of connected routers to this network(topological information). In IS-IS, the address information about all networks, both point-to-point and multiaccess, is contained in the LSP of each router connected to that network. The topological information about the network itself and the list of connected routers are contained in a so-called Pseudonode LSP generated by the DIS on the multiaccess network. 

An LSP has a unique identifier as a whole, and can only be flooded, requested, acknowledged, refreshed, aged, and flushed as a whole. Therefore, with any topological or addressing change, affected routers regenerate their entire LSPs and flood them. each IS-IS router originates only a single LSP (plus Pseudonode  LSPs if it is a DIS), and has therefore only a single or a few self-originated LSPs to age and refresh. 

Another difference between LSUs/LSAs and LSPs concerns their internal format with particular regard to extensibility. IS-IS encodes all topological and addressing information in Type-Length-Value records. While slightly less efficient in terms of memory and processing, this approach allows extensibility from day zero: A router will process those TLV  records it recognizes and ignore the records it does not support.

Note: LSP packets are used to carry topological and addressing information in IS-IS. An LSP describes its originator, its adjacencies to neighboring network objects, and related addressing. Each LSP is uniquely identified by the SystemID.PseudonodeID-LSPNumber. Each LSP has a sequence number, starting at 0x00000001 and ending at 0xFFFFFFFF. The lifespan of an LSP is limited by its Remaining Lifetime timer set to 1200 seconds and decreasing. After this timer expires, a router is required to wait at least another ZeroAgeLifetime (60 seconds) before flushing the LSP. LSPs are refreshed by default every 900 seconds. Separate LSPs are originated for Level 1 and Level 2.

Complete and Partial Sequence Numbers PDUs 

Complete Sequence Numbers PDU (CSNP) and Partial Sequence Numbers PDU(PSNP) packets are used to synchronize link-state databases. CSNP packets are very similar in their function to OSPF Database Description Packets. The purpose of CSNP packets is to advertise a complete list of LSPs in the sender’s link-state database. Receivers of CSNP packets can compare their link-state database contents to the list of LSPs in the CSNP and perform appropriate action. Note that CSNPs list only LSPIDs, but they do not contain LSP bodies.

On point-to-point links, CSNP packets are exchanged usually only during initial adjacency buildup; on broadcast networks, CSNP packets are originated periodically by the DIS. PSNP packets are functionally similar to OSPF Link State Request and Link State Acknowledgment packets. Using PSNP, a router can either request a particular LSP or acknowledge its arrival. A single PSNP can request or acknowledge multiple LSPs.

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.