Modeling WAN Networks in Integrated IS-IS
This section discusses how to configure Integrated IS-IS over a WAN.
Categories of WANs for Integrated IS-IS
WANs typically are implemented as either point-to-point or point-to-multipoint, and most support multiple connections. These WANs typically do not support broadcasting, though, and thus are classified as NBMA.
Integrated IS-IS considers three categories of WANs, as follows:
Point-to-point leased circuits—There are few issues for configuring Integrated IS-IS on these circuits.
Dialup connections—Configuring IS-IS over dialup should be avoided if possible, except to use as a backup.
Switched WANs—Various design options exist for NBMA networks.
These three categories are discussed in further detail in the following sections.
Point-to-Point
Point-to-point WANs are typically leased circuits between two routers. A point-to-point WAN has two devices attached, one at each end of the circuit. Usually such links will run Cisco HDLC or Point-to-Point Protocol (PPP). This corresponds exactly to the Integrated IS-IS classification of a point-to-point network.
NOTE
A point-to-point circuit still is regarded as an NBMA network, just as a back-to-back Ethernet connection is still a LAN. Both are examples of multiple-access networks that have only two devices attached.
On a point-to-point link a single IIH PDU is sent. This specifies whether the adjacency is at Level 1, Level 2 or both.
When the adjacency is established, each neighbor sends a CSNP describing the contents of its link-state database. Each router then requests any missing LSPs from the neighbor using PSNPs and acknowledges the receipt of the LSPs with PSNPs.
This activity reduces the amount of routing traffic across the point-to-point link—each router exchanges only the information missing from its link-state database rather than the entire link-state database of its neighbor router.
Dialup
Dialup networks using dial-on-demand routing (DDR) can be configured as either point-to-point or point-to-multipoint WAN implementations, as follows:
Legacy DDR dialup connections (that is, using dialer map commands) are NBMA (even though they might use PPP as their line protocol) because a single interface can support multiple destinations.
Dialer profiles and dialer virtual profiles are point-to-point connections (because one dialer profile represents one remote profile), but these can suffer from loss-of-neighbor delays similar to those for NBMA networks.
Dialer virtual profiles are point-to-point connections in which the interface drops immediately if the remote end disconnects. This leads to faster neighbor-loss detection and faster convergence.
NOTE
Dialup interfaces are not dealt with further in this book. As a general rule, you should avoid using IS-IS over dialup, except to provide dial-backup functionality.
For further information on dialup networks and configuring them, see the Cisco Press Book Building Cisco Remote Access Networks.
Switched WANs
IS-IS can work over an NBMA multipoint network only if the network is configured with a full mesh. Anything less than a full mesh could cause serious connectivity and routing issues. However, even if a full mesh is configured, this is no guarantee that a full mesh will exist at all times. A failure in the underlying switched WAN network or a misconfiguration on one or more routers could break the full mesh either temporarily or permanently. Therefore, you should avoid NBMA multipoint configurations for IS-IS networks. Use point-to-point subinterfaces instead.
Point-to-point subinterfaces usually should be configured with their own IP subnet (typically with a 30-bit, or /30, subnet mask). In modern IP networks using private addressing or variable-length subnetting, usually plenty of spare IP addresses can be applied to point-to-point subinterfaces.
Alternatively, because Integrated IS-IS uses CLNS packets for its route propagation, the ip unnumbered interface configuration command can be used on point-to-point interfaces. However, this works only on more recent Cisco IOS Software releases (Version 12.0 and later); earlier releases fail to establish an IS-IS adjacency because the IP subnets do not match at either end of the link.
Configuring Integrated IS-IS in an NBMA WAN
This section describes how to configure Integrated IS-IS in an NBMA environment and shows some example configurations.
Configuration Steps
To enable Integrated IS-IS over switched WAN media, do the following:
|
Step 1 |
Start the Integrated IS-IS process and assign NETs as usual. |
|
Step 2 |
On each NBMA, interface do the following: |
|
|
Design a mesh between the NBMA peers (full or partial). |
|
|
Configure point-to-point subinterfaces for each NBMA virtual circuit (VC), and assign IP addresses. |
|
|
Define the mapping of Level 3 protocols/addresses to the VC. If manual mappings are used (for example, x25 map or frame-relay map commands), the CLNS mapping must specify the keyword broadcast to support routing packets. However, the IP mapping does not require this (it is used only for next-hop resolution, not for routing packets). |
|
|
Start IS-IS processing on the subinterface using the ip router isis command. This command must not be used on the main interface of the router, or that (multipoint) interface will generate a pseudonode LSP for itself. |
Further tuning can be done to control the flooding of link-state information using timer and blocking commands.
NOTE
You can reduce LSP flooding in two ways:
Blocking flooding on specific interfaces—The advantage of full blocking over mesh groups is that it is easier to configure and understand, and fewer LSPs are flooded. Blocking flooding on all links permits the best scaling performance but results in a less robust network structure. Permitting flooding on all links results in poor scaling performance.
Configuring mesh groups—The advantage of mesh groups over full blocking is that mesh groups allow LSPs to be flooded over one hop to all routers on the mesh, while full blocking allows some routers to receive LSPs over multiple hops. This relatively small delay in flooding can have an impact on convergence times, but the delay is negligible compared to overall convergence times.
Running IS-IS in NBMA using Point-to-Point Subinterfaces
Figure 5-22 is an example of a router network connected over Frame Relay and using point-to-point subinterfaces. In this network, Frame Relay is modeled as a collection of subnets, with each Frame Relay permanent virtual circuit (PVC) treated as its own point-to-point network with its own subnet.
)
Figure
5-22 Frame Relay Network Using Point-to-Point Subinterfaces
The network in Figure 5-22 is an example of a star network topology. It is important to note that the routers at the points of the star (R1, R2, and R3) are also configured with point-to-point subinterfaces, even though (unlike the central router, R4) they connect to only one VC. This is the best practice for all routing protocols (because it allows further VCs to be added without affecting the existing VC), but it is imperative to IS-IS. A main interface (for example, interface Serial 0) is a multipoint interface, even if it happens to have only one VC configured. If the single VC were configured under a main interface, IS-IS would treat this as a broadcast network and attempt to elect a DIS. Also, the adjacency would not establish because the multipoint end would send broadcast, network-style hellos, but the central router would send point-to-point hello PDUs.
Example 5-22 shows the configuration of the central router, router R4, in Figure 5-22.
Example 5-22 Configuration of Router R4 in Figure 5-22
interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.252 ip router isis frame-relay interface-dlci 100 ! interface Serial0/0.2 point-to-point ip address 10.1.1.5 255.255.255.252 ip router isis frame-relay interface-dlci 200 ! interface Serial0/0.3 point-to-point ip address 10.1.1.9 255.255.255.252 ip router isis frame-relay interface-dlci 300 |
Example 5-22 shows the following:
The encapsulation type (frame-relay) is set under the main interface (Serial0/0). No IP or IS-IS configuration is included under the main interface.
Three subinterfaces are defined, one for each VC. Each subinterface specifies the following:
The IP address for that point-to-point link. There is a different subnet for each subinterface.
Integrated IS-IS as the routing protocol over that subinterface (this is done using the ip router isis command).
The VC to use for that point-to-point subinterface, using the frame-relay interface-dlci command. This is the only command needed to enable both IP and CLNS across this VC. The router automatically enables across this VC all the protocols that are enabled on the point-to-point subinterface, and it specifies broadcast for all those protocols.
Example 5-23 shows the output of the show frame-relay map EXEC command for router R4 in the example network shown in Figure 5-22.
Example 5-23 show frame-relay map Command Output from Router R4 in Figure 5-22
R4#show frame-relay map Serial0/0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast status defined, active Serial0/0.2 (up): point-to-point dlci, dlci 200(0xC8,0x3080), broadcast status defined, active Serial0/0.3 (up): point-to-point dlci, dlci 300(0xA4,0x4580), broadcast status defined, active |
As shown in Example 5-23, the show frame-relay map command displays the status of each Frame Relay VC, providing information as follows:
Its assigned subinterface—for example, Serial0/0.1.
Its type—in this case, point-to-point, meaning that it has been assigned to a point-to-point subinterface.
The VC identification—for example, dlci 100.
Whether it supports broadcast (for example, routing) packets.
Its status. A status of defined means it has been configured on the Frame-Relay switch, and a status of active indicates that this VC is operational. A status of inactive means that the router on the other end is not available. A status of deleted means that the DLCI was not advertised in the last LMI full status update.
Example 5-24 shows the output of the debug isis adj-packets EXEC command on router R4 in the example network shown in Figure 5-22.
Example 5-24 debug isis adj-packets Command Output from Router R4 in Figure 5-22
R4#debug isis adj-packets
ISIS-Adj: Sending serial IIH on Serial0/0.1, length 1499
ISIS-Adj: Rec serial IIH from DLCI 100 (Serial0/0.1), cir type L1L2,
cir id 00, length 1499
ISIS-Adj: rcvd state UP, old state UP, new state UP
ISIS-Adj: Action = ACCEPT
<output omitted>
ISIS-Adj: Sending serial IIH on Serial0/0.2, length 1499
ISIS-Adj: Rec serial IIH from DLCI 200 (Serial0/0.2), cir type L1L2,
cir id 01,
length 1499
ISIS-Adj: Sending serial IIH on Serial0/0.3, length 1499
ISIS-Adj: Rec serial IIH from DLCI 300 (Serial0/0.3), cir type L1L2,
cir id 02,
length 1499
|
Example 5-24 shows the neighborship establishment across the Serial0/0.1 subinterface, sending and receiving serial (that is, point-to-point) IIH PDUs and declaring the adjacency to be up. Ongoing hello conversations for the other subinterfaces also are shown.
Running IS-IS in NBMA Using Multipoint Interfaces
Figure 5-23 shows an alternative NBMA version of the network shown in Figure 5-22. In this case, all the Frame Relay ports are configured as multipoint interfaces, either as a multipoint subinterface (on the central router, router R4) or possibly as the main interfaces on the other routers. All interfaces share the same IP subnet.
)
Figure
5-23 Frame Relay Network Using Multipoint Interfaces
In Figure 5-23, the network is still a star topology, as in the previous example. In a multipoint environment it is important that a full mesh be implemented; therefore, all routers in this network must have VCs interconnecting them, although these are not shown in the figure.
If this were a true hub-and-spoke environment and the spoke sites had no need to communicate with each other, this topology could work with only the indicated DLCIs rather than having a full mesh. In this case, the central router (R4) must become the DIS for the NBMA network (because it is the only router visible to all others), so a suitable IS-IS priority should be set on the Frame Relay interface. Routes would be installed in each spoke router toward the other spoke routers through their local IP addresses. However, packets to these destinations would be dropped because there are no direct VCs between the spokes.
Example 5-25 shows the configuration of the multipoint interface on the central router, R4.
Example 5-25 Configuration of Router R4 in Figure 5-23
interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.2 multipoint ip address 10.0.0.4 255.0.0.0 ip router isis frame-relay map clns 100 broadcast frame-relay map clns 200 broadcast frame-relay map clns 300 broadcast frame-relay interface-dlci 100 frame-relay interface-dlci 200 frame-relay interface-dlci 300 ! router isis net 00.0001.0000.0000.0004.00 |
As can be seen in Example 5-25, IP and CLNS maps must be configured separately in a multipoint environment:
The frame-relay interface-dlci command is used to enable IP across the Frame Relay PVCs. Inverse ARP resolves the remote end IP addresses. On a point-to-point subinterface, this command enables all traffic, but in a multipoint environment, this enables only IP.
Alternatively, the IP maps could be entered explicitly using the frame-relay map ip ip address dlci command. In this case, the broadcast keyword might not be necessary for IP because only directed IP packets will use this VC. (Remember that the Integrated IS-IS routing protocol is not sending IP packets.)
To enable CLNS, which must be done separately from IP in a multipoint environment, the frame-relay map clns command is used. CLNS is used for the IS-IS routing packets, so the broadcast keyword must be specified.
Examples 5-26 and 5-27 show how the same monitoring commands as used in the previous example produce a slightly different output for the multipoint environment.
Example 5-26 is the show frame-relay map command output from router R4 in Figure 5-23.
Example 5-26 show frame-relay map Command Output from Router R4 in Figure 5-23
R4#show frame-relay map Serial0/0.4 (up): CLNS dlci 400(0x190,0x6400), static, broadcast, CISCO, status defined, active Serial0/0.4 (up): ip 10.1.4.3 dlci 400(0x190,0x6400), dynamic, broadcast,, status defined, active |
In Example 5-26, the show frame-relay map command again displays the status of each Frame Relay VC. This time however, separate entries are created for the IP and CLNS mappings (even though they use the same VC). The CLNS map shows that it is created as a static map and that broadcast was specified. The IP map is dynamic because the IP address was resolved by Inverse ARP.
Example 5-27 is the debug isis adj-packets command output from router R4 in Figure 5-23.
Example 5-27 debug isis adj-packets Command Output from Router R4 in Figure 5-23
R4#debug isis adj-packets ISIS-Adj: Sending L2 LAN IIH on Serial0/0.2, length 1500 ISIS-Adj: Rec L2 IIH from DLCI 400 (Serial0/0.2), cir type L1L2, cir id 0000.0000.0004.03, length 1500 ISIS-Adj: Sending L1 LAN IIH on Serial0/0.2, length 1500 ISIS-Adj: Rec L1 IIH from DLCI 400 (Serial0/0.2), cir type L1L2, cir id 0000.0000.0004.03, length 1500 |
In Example 5-27, the debug isis adj-packets command again shows the neighborship establishment. This time, the adjacency uses LAN IIH PDUs because this is a multipoint environment.
Detecting Mismatched Interfaces
When interfaces are misconfigured in an NBMA environment, the network will not function as desired.
An example of a misconfiguration is when one end of a link is specified as a point-to-point subinterface but the other end is using a point-to-multipoint interface. Issuing the show clns neighbors command on each router indicates the mismatch. An example is shown in Example 5-28. Here router R2 is specified as a point-to-point subinterface, while router R4 is using a point-to-multipoint interface configuration.
Example 5-28 show clns neighbors Command Output from Misconfigured Routers
R2#show clns neighbors System Id Interface SNPA State Holdtime Type Protocol 0000.0000.0004 Se0/0.2 DLCI 300 Up 8 L1 IS-IS R5 Et0/0 0050.3ef1.5960 Up 8 L2 IS-IS R1 Se0/0.1 DLCI 100 Up 23 L1 IS-IS R4#show clns neighbors System Id Interface SNPA State Holdtime Type Protocol R6 Et0/0 0010.117e.74a8 Up 26 L2 IS-IS R3 Se0/0.3 DLCI 400 Up 28 L2 IS-IS 0000.0000.0002 Se0/0.2 DLCI 300 Init 29 L1 IS-S 0000.0000.0001 Se0/0.1 DLCI 200 Up 290 IS ES-IS |
The shaded lines in Example 5-28 indicate the routers' view of each other. Router R2 (the point-to-point end) shows the adjacency as up. However, the adjacency is stuck in the init state on router R4 (the multipoint end).
The misconfiguration results from the fact that the two ends of the VC are set to different types, which is an illegal configuration. The point-to-point end sends serial IIH PDUs. The multipoint end sends LAN IIH PDUs.
The ISO standard (ISO 10589) defines a three-way handshake 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 neighbor's SNPA in the hello packet. The neighbor does the same thing with this router's SNPA.
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, this process is omitted for a point-to-point adjacency. However, Cisco IOS Software 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 mismatch configuration described in this example depends on the Cisco IOS Software release level. If using a release earlier than Release 12.1(1)T, the following happens (this is the case shown in Example 5-28):
Router R4 (configured for multipoint) receives the point-to-point hello from router R2 but treats it as a LAN hello and puts the adjacency in the init state. It looks for its own SNPA in the received hello PDUs (in a LAN hello PDU, this would be identified in TLV 6, IS Neighbors, but this TLV is not present in a serial hello) but never finds them. Therefore, the adjacency remains in the init state.
Router R2 (configured for point-to-point) receives a LAN hello PDU and treats it as a point-to-point hello. It checks the hello 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 that this is an ISO-specified point-to-point link, ignores the Cisco three-way handshake, and allows the adjacency to establish, setting it to up.
If using a release of Cisco IOS Software since Release 12.1(1)T, the following happens:
Router R4 (configured for multipoint) receives the point-to-point hello, realizes that it is the wrong hello type, and installs the neighbor as an ES. Router R2 would show up in the show clns neighbors command output on router R4 with a protocol of ES-IS.
Router R2 (configured for point-to-point) receives the LAN hello, recognizes the mismatch, and ignores the neighbor. Router R4 would not appear at all in router R2's show clns neighbors command output. Using the debug isis adj-packets command would show the incoming LAN IIH PDU and router R2 declaring the mismatch.