CertificationISISNetworking

IS-IS Flooding

IS-IS Flooding:

A source of confusion for people trying to learn IS-IS is in trying to correlate IS-IS LSPs to an OSPF entity. Does the LSP serve an equivalent function to an OPSF Update message? Like Updates, it is the “package” by which information is sent from one router to another. But unlike Updates, LSPs are not limited in scope to a single link. They are flooded intact throughout an area. And also unlike Updates, the information contained in a single LSP pertains only to the router that originated it.

Perhaps we can say, then, that an LSP is more like an OSPF LSA. Just as LSAs are the basic data structures that the OSPF link state database is built from, LSPs are the basic data structures of the IS-IS link state database. But you saw in the previous section, and will see in greater detail later in this chapter, that there are a number of different LSA types providing a number of different kinds of information. There is, in contrast, only a single LSP for each adjacency type (L1 or L2). The kinds of information carried in different LSAs are carried in a single LSP, by different TLVs.

So, then, can we say that the real parallel is between IS-IS TLVs and OSPF LSAs? We cannot, because LSAs are more self-contained than TLVs. They have their own ages, checksums, and sequence numbers, whereas TLVs do not. LSAs also provide a complete set of functional information (about, for instance, a router, a pseudonode, or an external destination), whereas the information in a TLV (such as a list of addresses or neighbors, or authentication information) is intended to be used in conjunction with information in other TLVs.

The bottom line is that you cannot always draw a direct correlation between OSPF and IS-IS. The most you can say here is that LSPs, like OSPF LSAs, are the basic data units produced and flooded by individual routers for building link state databases. Because IS-IS runs over the data link level rather than the network level, LSPs are themselves packets and do not require a separate means of transport the way LSAs require Update packets.

Any of the following events causes an IS-IS router to generate and flood a new LSP:

  • Router startup.
  • The periodic refresh timer expires.
  • A new adjacency is established.
  • An adjacency or link changes state.
  • The metric associated with a link or reachable address changes.
  • The router’s SysID changes.
  • The router is elected or superseded as DIS.
  • An area address associated with the router is added or removed.
  • The overload status of the database changes.

 

The LSP Format:

 

A router generates separate LSPs for L1 and L2 adjacencies. On broadcast networks, L1 LSPs are sent to the multicast address AllL1IS (0180.c200.0014), and L2 LSPs are sent to multicast address AllL2IS (0180.c200.0015). Figure 5.6 shows the format of the IS-IS LSP.

Figure 5.6. The IS-IS Link State PDU.

 

  • A Type value of 18 (0x12) in the header indicates an L1 LSP, and a value of 20 (0x14) indicates and L2 LSP.
  • PDU Length specifies the length of the entire LSP, including the header. This value helps in determining how many TLVs are included in the LSP.
  • Remaining Lifetime is a 16-bit unsigned integer representing the number of seconds remaining before the LSP is “aged out.” As such it serves the same purpose as the Age field in OSPF LSAs, but with one very significant difference: As the two names imply, age increasesstarts at 0 and increments upwardwhereas remaining lifetime decreasesstarts at some value and decrements downward. The reason this is significant is that OSPF defines an architectural constant of MaxAge, which is 3,600 seconds, and a starting value of 1, which means the age of its LSAs is always constrained between these two constants. The IS-IS age has only one constant: 0, indicating an expired LSP. IS-IS also defines a MaxAge, which is the starting value of the Remaining Lifetime field, but the IS-IS MaxAge is configurable up to the 16-bit maximum of 65,535 seconds (18.2 hours), providing much more flexibility in managing the reflooding of LSPs and controlling the aging of its LSPs in the databases of other routers.

    The typical default MaxAge is 1,200 seconds (20 minutes). As the LSP is flooded, the remaining lifetime is decremented at each router’s outgoing interface, and it is also decremented once each second as the LSP resides in the link state database. So, like OSPF LSAs, the LSP must be refreshed by the originating router at some interval reliably less than the configured or default MaxAge. The refresh interval might be configurable, as it is with Cisco’s IS-IS implementation, or it might be automatically determined from the MaxAge. Juniper Networks’ IS-IS implementation, for example, automatically sets the refresh timer 317 seconds less than the MaxAge. IS-IS can flush an LSP from all link state databases, just as OSPF can, by prematurely aging out the LSP and reflooding it. The difference, of course, is that setting the Remaining Lifetime to 0 ages out the LSP.

  • Checksum is a 16-bit Fletcher checksum for detecting corruption of the LSP when it is received. The checksum is also rechecked as the LSP resides in the database, typically every 30 seconds. The checksum is calculated over all of the LSP after the Remaining Lifetime field. That field is not included in the calculation because it does not remain constant.

 

  • Sequence Number is a 32-bit integer. Unlike the OSPF sequence number, it is unsigned, meaning it starts at 1 and is incremented up to a maximum of SequenceModulus 1(232 1). Although this maximum sequence number should never be reached in normal networks, it is important to understand what happens if and when it is. An IS-IS router that must refresh an LSP whose existing sequence number is SequenceModulus 1 must wait MaxAge + 60 seconds, to ensure that the existing LSP is aged out of all databases. A new copy of the LSP can then be flooded with a sequence number of 1. This means that for the interval between the time MaxAge is reached and the time the flooding of the new LSP is completed, the originating router is considered unreachable.

 

Given the rule that sequence numbers must start at 1, the value of 0 becomes handy. Because it is always less than any normally incremented sequence number, a router that wants to receive the latest copy of a known LSP from a neighbor can set the sequence number of the LSP to 0 and flood it. The neighbor, having a copy of the LSP with a higher (and therefore newer) sequence number will send this LSP to the originator.

 

As with OSPF, IS-IS can increase an LSP’s sequence number more than 1 in some situations. The most common case is a restarted router that discovers that an LSP it generated before the restart still exists in other routers’ databases. The router will increment the LSP’s sequence number one beyond the existing sequence number and reflood the LSP.

 

There is the remote possibility that a restarted router can flood an LSP while a previously generated LSP still exists in other routers’ databases, and that the two LSPs contain different information but the same sequence numbers. In such a case, the routers receiving the flooded LSP and noting the differing checksums will install the new LSP in their databases but with a remaining lifetime value of 0 (expired) and reflood the LSP.

 

IS-IS uses the following procedure when comparing two copies of the same LSP to determine which is more recent:

 

1.
If one of the LSPs has a remaining lifetime of 0, it is the most recent.

2.
If the remaining lifetimes of both LSPs are non-zero, the PDU with the larger sequence number is the most recent.

3.
If the remaining lifetimes of both LSPs are non-zero and the sequence numbers are equal, and no checksum error has occurred, the LSPs are considered identical.

 

The LSP ID consists of three fields which together identify a particular LSP:

 

  • Source ID is the SysID of the originating router. ISO 10589 allows for much flexibility in the kind of address that can be included in this and other address-based fields, based on the value of the ID Length field of the header. An ID Length value of between 1 and 8 specifies the Source ID Length in octets. An ID Length value of 255 specifies that there is no Source ID field (zero length). And an ID Length of 0 specifies a Source ID Length of 6 octets. For IP routing the LSP always uses a 6-byte SysID as the Source ID, so the ID Length value is always 0, as you can see in Figure 5.6.
  • The Pseudonode ID is non-zero only when the LSP is originated by a DIS to represent a pseudonode. When this is the case, the LSP corresponds loosely to an OSPF Network LSA. This 1-byte field is the same value as the Local Circuit ID assigned to the broadcast link by the DIS originating the LSP.
  • The LSP Number is non-zero when a router must break its LSP into multiple parts. The maximum size of a single LSP, as specified by ISO 10589, is 1,492 bytes. So if a router cannot fit all of its TLVs into this maximum length, it produces a multipart LSP: The first part will have an LSP number of 0x00, the second 0x01, the third 0x02, and so on. It is important to understand that even though each of these parts has its own sequence number, remaining lifetime, and checksum (as it must, because there is no guarantee that the parts will all follow the same paths during flooding), and is marked separately in LS database displays, the information the parts contain makes up a single LSP for the purpose of the SPF calculation. If parts of an LSP are in the database but there is no LSP number 0x00 for the LSP, the other parts are ignored by the SPF calculation.

 

Acknowledgment of LSPs

 

The receipt of an LSP is acknowledged between adjacent neighbors to ensure reliable flooding. But there is no distinct acknowledgment message as there is with OSPF. Instead, IS-IS uses two PDUs called the Partial Sequence Number PDU (PSNP) and Complete Sequence Number PDU (CSNP). These PDUs, which are normally used for LS database synchronization, But for the purposes of discussing LSP acknowledgment, suffice it to say that both PDUs (collectively called Sequence Number PDUs) carry descriptions of one or more LSPs by listing their Remaining Lifetime, LSP ID, Sequence Number, and Checksum fields. The difference between the two is that CSNPs describe all LSPs in the originator’s LS database, whereas PSNPs carry only a subset of the LSPs in the originator’s LS database.

 

Explicit and implicit acknowledgments are used by IS-IS, but differently than the way they are used by OSPF. The receipt of an LSP on a point-to-point link is always explicitly acknowledged by sending a PSNP to the sender identifying the LSP. More than one LSP can be acknowledged in a single PSNP. If the receiver has a newer instance of the LSP in its LS database than the one it received, it sends a copy of the newer LSP back to the neighbor rather than sending a PSNP acknowledgment.

 

When an LSP is sent on a point-to-point link, the LSP’s SRM for that link is not cleared until an acknowledgment is received, either in the form of a PSNP or a newer or same-aged LSP. This creates a behavior similar to the OSPF retransmission list. If the LSP is not acknowledged, it is sent again at the next minimum LSP transmission interval.

Receipt of an LSP on a broadcast link is always implicitly acknowledged. The mechanism for acknowledging LSPs is a part of the LS database synchronization and maintenance procedures,But in brief, the mechanism works as follows: The DIS periodically (every 10 seconds) multicasts a CSNP on the broadcast link, which describes the LSPs in its LS database. When a router sends an LSP on the broadcast link, the LSP should be included in subsequent CSNPs. If it is not, the originating router will resend the LSP.

Unlike point-to-point links, an LSP’s SRM for a broadcast link is cleared as soon as the LSP is sent. This is because of the implicit acknowledgment via the CSNP. If the new instance of the LSP is not indicated in subsequent CSNPs, the sending router resets the SRM and retransmits the LSP at the appropriate time.

 

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

4cXG

Please type the text above:

Check Also

Close
Close
Close