Content

| 7.6 |  | Integrated IS-IS Operation in a WAN Environment |
| 7.6.5 |  | Detecting mismatched interfaces with Integrated IS-IS |

One important skill to develop with Integrated IS-IS configuration and troubleshooting is to be able to identify a problem resulting from mismatched interfaces in an NBMA environment.

An example of a misconfiguration would be configuring one end of a link, on router R2, to be specified as a point-to-point subinterface.The other end, router R4, is to be used as a point-to-multipoint interface. Issuing the show clns neighbors on each router shows a mismatch. R2, the point-to-point end router, shows the adjacency as "up". R4, the multipoint end, shows the adjacency as stuck in the "init" state. The misconfiguration results from the fact that the two ends of the VC are set to different network types. The point-to-point end sends serial IIH PDUs and the multipoint end sends LAN IIH PDUs, so an adjacency cannot form.

The ISO standard defines a three-way handshake, an agreement, for initiating LAN adjacencies as follows:

- The adjacency starts in the "down" state. The IS sends out LAN IIH PDUs, identifying itself.
- If a LAN IIH PDU is received, the adjacency is installed in the init state. This router then sends out an IIH PDU to the neighbor, including the SNPA of the neighbor in the Hello packet. The neighbor does the same thing with the SNPA on this router.
- The IS receives a second IIH from the neighbor router with its own SNPA identified in the packet. On receipt of this, the IS understands that the new neighbor knows of its presence and therefore declares the adjacency "up".

According to the ISO standard, ISO 10589, this process is omitted for a point-to-point adjacency. However, Cisco IOS implements the same three-way handshake by adding a point-to-point adjacency state TLV, TLV 240, in the serial Hello PDUs. In a similar manner to the LAN adjacency, the router checks for its own SNPA in the neighbor's Hello PDU before declaring the adjacency "up".

The result of the example mismatch depends on the IOS release. Prior to release 12.1(1)T the results were as follows:

- R4, the multipoint router, receives the point-to-point Hello PDU from R2 but treats it as a LAN Hello PDU and puts the adjacency in the init state. R4 looks for its own SNPA in the received Hello PDUs but never finds it. In a LAN Hello PDU this would be identified in TLV 6 as IS Neighbors, but this TLV is not present in a serial Hello PDU. Therefore, the adjacency remains in the init state.
- R2, the point-to-point router, receives a LAN Hello PDU and treats it as a point-to-point Hello PDU. It checks the Hello PDU for a TLV 240, point-to-point adjacency state, and fails to find one. For backward compatibility, or perhaps to allow the link to be made to a non-Cisco IS-IS device, the router assumes this is an ISO-specified point-to-point link. R2 ignores the Cisco three-way handshake and allows the adjacency to establish, setting it to "up".

Since Release 12.1(1)T the results are as follows:

- R4, the multipoint router, receives the point-to-point Hello PDU, realizes it is the wrong Hello type, and installs the neighbor as an ES. R4 would show R2 in the show clns neighbors with protocol “ES-IS".
- R2, the point-to-point router, receives the LAN Hello PDU, recognizes the mismatch, and ignores the neighbor. R4 would not appear at all in the show clns neighbors output of R2. A debug isis adj-packets output shows the incoming LAN IIH PDU and R2 declaring the mismatch.