The Logical Link Control layer, IEEE 802.2, defines Service Access Points (SAP) and Link Service Access Points (LSAP). These are conceptually similar to TCP port numbers in many ways, although it is important to remember that they operate at the Logical Link Layer (Layer 2), not the Transport Layer (Layer 4), as TCP does. They are simply numbers that a device uses when it wants to establish a connection to another device to run a particular application. The number specifies a particular application protocol. The packets establishing a connection specify both a Source SAP number (SSAP) and a Destination SAP number (DSAP). These are, obviously enough, the SAP numbers of the source and destination applications. Table 15-1 lists several of the most common SAP numbers.

Cisco routers include the ability to filter based on LSAP numbers using access lists in the range from 200 to 299. Here is an example of the syntax of an LSAP access list:

access-list 201 permit 0x0000 0x0D0D

The first hexadecimal number after the permit keyword represents both SSAP and DSAP. The first two hex digits are the SSAP, and the second two are the DSAP. The next field is a wildcard bit pattern. When the wildcard has a 0 bit, the corresponding bit in the SAP numbers must be exactly as it is in the given pattern, and any place where the wildcard has a 1 bit can have either a zero or a one.

The mask in this particular example is 0x0D0D. The hex number D has a bit pattern of 1101. So, the access list as written will allow any packets with either SSAP or DSAP values shown in Table 15-2.

Such access lists are usually used to block unwanted local ring traffic such as Net-BIOS or Netware, while permitting the SNA traffic. If, on the other hand, you wanted to permit only NetBIOS traffic and block all other protocols, you could use an access list like this:

access-list 202 permit 0xF0F0 0x0000

When a device wants to send a packet using Logical Link Control (LLC) protocols through a bridged network, it has the capability of source-routing this packet. This means that the end device is able to specify a particular network path. To do this, however, it first has to find an appropriate path. It does this by sending a packet called an explorer through the network. As this explorer packet passes through the network, each bridge adds information about itself to the packet and forwards it along. So when it finally arrives, it has a complete path description that the end device can use to build a RIF.

There are, in fact, two different kinds of explorers, called spanning tree explorers and all routes explorers. They both perform the same basic function of trying to map the best path to the required destination. The difference, however, is that a spanning tree explorer follows only one path, and the all routes explorer attempts all paths. When a bridge receives a spanning tree explorer, it forwards the packet along a single path defined by the Spanning Tree Protocol (STP).

STP eliminates loops from a bridged network. It is important to remember that running STP is optional, and not every bridge is configured to run it. It is not frequently used in DLSw+ networks because the protocol has the ability to do useful things such as load sharing between links. STP inherently prevents load sharing among the many different possible paths through a network by shutting down all paths except for one.

Note that STP is required on transparently bridged networks, however, because there is no RIF to control path selection. If you have multiple connections between transparent bridges, such as Ethernet switches, you must use STP.

STP ensures that there is one and only one active path between any two points by first electing a root bridge. This device is the logical center of the bridged network. When a bridge receives a packet destined for a device that is not on one of its ports, it simply forwards that packet toward the center. The packet may take several hops to reach the root bridge, which has an exhaustive table of MAC addresses and knows how to forward every packet that it receives. If it doesn’t know the destination, it will duplicate the packet and send it out every path except the one it was received on, in the hopes of finding the destination.

A spanning tree explorer packet simply follows the STP path through the network to reach the required destination. An all routes explorer works similarly, but it follows all possible paths to reach the ultimate destination. At each bridge where there is a choice to be made between two or more possible paths, the bridge duplicates the packet and forwards it along all of them. So the destination device will probably receive several possible solutions. In general, it will pick the first one it receives on the assumption that this must represent the fastest path.

When the destination device receives an explorer packet, it turns it around and sends it back to the original source, retaining the routing information. Now both devices know how to request a path to one another through the network when they need to exchange information. When they send packets of application data, they will include a Routing Information Field (RIF) that specifies the desired path.

This process can obviously get messy if there are a lot of devices all trying to find one another at the same time. So DLSw+ includes some optimizations that allow routers to improve on the RIF discovery process. Every router contains a RIF cache of all of the remote devices that it knows how to reach. When a device on the local Token Ring sends an explorer looking for something the router already knows how to reach, DLSw doesn’t need to bother forwarding this explorer through the network. Instead, it responds directly without having to consume network resources forwarding the explorer.

One common misunderstanding that people have about DLSw+ is that to implement Cisco routers in a network using IBM’s Advanced Peer-to-Peer Networking (APPN) functionality, you have to use one of Cisco’s APPN code sets. This is not the case. The core DLSw+ functionality is included in the default minimal IP-Only IOS code set for all 12.x and most 11.x IOS levels. You need to use the APPN code set only if you intend for the router to take an active part in the higher layer protocols.

APPN is effectively the next generation version of SNA. Among many improvements, it makes the protocol routable for improved scalability. However, APPN still runs over the same lower layer protocols such as LLC2 on Token Rings and SDLC on serial interfaces. So, in most cases the router doesn’t need to know whether APPN or SNA is used at higher layers.

The APPN code set is required only if the router needs to provide native APPN routing. In most cases, even networks using APPN within the mainframe and its Front End Processor (FEP), the bridging functions of DLSw+ are sufficient to provide all of the required connectivity.

The most recent generations of mainframe computers from IBM are capable of supporting TCP/IP and Gigabit Ethernet directly, so we expect that the future of mainframe networking will use IP rather than APPN. In this case, SNA and DLSw will be necessary only to support legacy SNA equipment.

You want to set up DLSw to allow Token Ring bridging through an IP network.

There are many different ways to configure two routers to allow Token Ring-to-Token Ring bridging through DLSw. The most common reason for doing this is to allow Token Ring SNA LLC2 devices to communicate with a mainframe FEP attached to another Token Ring. It is relatively common to have many remote rings connecting to a single central ring. In cases like this, it is often best to use one or more dedicated DLSw routers at the central location. The CPU overhead required for supporting a large number of DLSw connections can be relatively high, so it is useful to restrict this functionality to special-purpose DLSw routers and keep it off of routers that also need to handle core routing functions.

Here is the DLSw configuration for a central router, which is the one that connects directly to the ring that holds the FEP:

dlsw-central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-central(config)#interface Loopback0
dlsw-central(config-if)#ip address 10.1.1.5 255.255.255.252
dlsw-central(config-if)#exit
dlsw-central(config)#access-list 701 permit 4000.3745.AAAA 8000.0000.0000
dlsw-central(config)#source-bridge ring-group 101
dlsw-central(config)#dlsw local-peer peer-id 10.1.1.5 promiscuous
dlsw-central(config)#dlsw timer explorer-wait-time 5
dlsw-central(config)#dlsw icanreach mac-exclusive
dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff
dlsw-central(config)#dlsw cache-ignore-netbios-datagram
dlsw-central(config)#dlsw allroute-sna
dlsw-central(config)#interface TokenRing0
dlsw-central(config-if)#description Ring number 0x00A (10)
dlsw-central(config-if)#source-bridge 10 5 101
dlsw-central(config-if)#source-bridge spanning
dlsw-central(config-if)#source-bridge input-address-list 701
dlsw-central(config-if)#end
dlsw-central#

And the remote routers are configured like this:

dlsw-branch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-branch(config)#interface Loopback0
dlsw-branch(config-if)#ip address 10.1.2.5 255.255.255.252
dlsw-branch(config-if)#exit
dlsw-branch(config)#access-list 200 permit 0x0000 0x0D0D
dlsw-branch(config)#source-bridge ring-group 101
dlsw-branch(config)#dlsw local-peer peer-id 10.1.2.5
dlsw-branch(config)#dlsw timer explorer-wait-time 5
dlsw-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200
dlsw-branch(config)#dlsw allroute-sna
dlsw-branch(config)#interface TokenRing0
dlsw-branch(config-if)#description branch Token Ring 0x047 (71)
dlsw-branch(config-if)#multiring all
dlsw-branch(config-if)#source-bridge 71 5 101
dlsw-branch(config-if)#source-bridge spanning
dlsw-branch(config-if)#end
dlsw-branch#

These configurations will work well for situations in which a large number of remote routers need to make DLSw connections to a central router. However, if you only need to connect two routers, you can still use the same pair of configurations. In that case, you simply need to decide which router will initiate the session. The initiating router will use the dlsw-branch configuration, and the receiving router will be dlsw-central. The initiating router will start trying to establish the connection as soon as it boots, and will continue periodically until it succeeds. This is true whether or not there is any traffic ready to be sent through this connection.

The first things to notice about these two configurations are the dlsw local-peer and dlsw remote-peer statements. These statements must match. In this case the branch router uses the address 10.1.1.5 to specify the remote peer. This address corresponds to the Loopback0 interface on the central router. So, on the central router, it is critically important that the local-peer statement points to this same IP address.

The central router does not have a dlsw remote-peer statement. This is because the central router will not establish DLSw connections. The promiscuous keyword in the local-peer statement allows this router to simply accept incoming connections from other routers. In this example we expect to have many remote branch routers connecting to the same central router. Configuring a separate remote peer on the central router for every branch would be an onerous task, particularly if branch routers are frequently added and deleted. When building a many-to-one type bridge, it is generally preferable to configure the central router to simply accept all remote peers.

This means that the central router will accept a DLSw connection from anybody. Naturally it doesn’t make sense to configure promiscuous on both routers because one of them has to initiate the connection. So the branch router is configured with normal point-to-point local-peer and remote-peer commands.

When configuring the local and remote DLSw peers, you can specify the IP address for any interface on the router, as long as both routers agree on which address is to be used. In these configuration files both local peers point to the respective Loopback0 interfaces on each router. This is because the Loopback0 interface is a purely internal software port that can never become unavailable due to an external failure. If the router is reachable at all through any path, then the Loopback0 interface is reachable, and consequently the DLSw peer relationship will be kept alive. In the case of Token Ring to Token Ring bridging, it may make sense to bring down the peer relationship when one of the rings fails. In this case, you can configure the local peers to point to an IP address on the Token Ring interface itself. However, if either router supports more than one SNA interface, such as a second Token Ring or an SDLC serial port, then you will probably not want your SDLC traffic to fail just because of a Token Ring failure.

There are only two routers in this example, but it is relatively common to have a backup router on the central ring. Each router can have many remote peers, each configured with a separate dlsw remote-peer statement.

There are two other pieces of information in the dlsw remote-peer command on the branch router:

dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200

The number 0 in the third field is a list number. The value of 0 is the default, and is sufficient for most applications. If any other value is specified, it tells DLSw that you want to set up ring lists or port lists. You would do this if you wanted to bridge traffic from one ring to one remote DLSw peer and traffic from another ring to a different peer. For example, if your router has four different rings, and you only want rings 1, 2, and 4 (but not 3) to use this particular DLSw peer, then you would configure a port list as follows, arbitrarily calling this port list number 5:

Router(config)#dlsw port-list 5 tokenring 1 tokenring 2 tokenring 4
Router(config)#dlsw remote-peer 5 tcp 10.1.1.5

An alternative way of doing this would be to use the ring numbers. If, for example, the ring number associated with these Token Ring interfaces were 70, 95, and 142 (all of these ring numbers are in decimal rather than the more conventional hexadecimal notation, which would be 46, 5F, and 8E, respectively), you could accomplish the same thing with a dlsw ring-list command:

Router(config)#dlsw ring-list 5 rings 70 95 142
Router(config)#dlsw remote-peer 5 tcp 10.1.1.5

Note that, in general, if you are working with physical rings, there is usually less danger of confusion when using the port-list version of this command. It is easy to become confused by virtual ring numbers and bridge numbers and so forth when constructing a ring list, particularly because most devices will represent these values in hexadecimal notation, while the router uses decimal.

In both versions, if there are other Token Ring interfaces that do not appear in any ring list, then they will not take part in any DLSw bridging. Alternatively, you could create more port lists or ring lists representing these other rings, and create more dlsw remote-peer statements for them, as follows:

Router(config)#dlsw port-list 5 tokenring 1 tokenring 2 tokenring 4
Router(config)#dlsw port-list 6 tokenring 3
Router(config)#dlsw remote-peer 5 tcp 10.1.1.5
Router(config)#dlsw remote-peer 6 tcp 10.1.1.9

These list numbers only have local significance to the router they are set on. So, if you are sending port list 5 to 10.1.1.5 and 6 to 10.1.1.9 (as in this example), there is nothing special required to complete that relationship on the remote peer routers. The other router doesn’t know or care that it isn’t getting all of this router’s DLSw traffic.

The last parts of the remote-peer command on the branch router define an lsap-output-list, and associate it with access list 200. This is optional, but useful. To understand what it does, please refer to the discussion of SAPs in the introduction to this chapter.

Router(config)#source-bridge ring-group 101

Router(config)#source-bridge ring-group 101
Router(config)#source-bridge ring-group 557
Router(config)#source-bridge ring-group 4031

dlsw-branch(config)#interface TokenRing0
dlsw-branch(config-if)#source-bridge 71 5 101

Router(config)#interface Tokenring0
Router(config-if)#source-bridge 70 5 71
Router(config-if)#interface Tokenring1
Router(config-if)#source-bridge 71 5 70
Router(config-if)#interface Tokenring2
Router(config-if)#source-bridge 72 6 73
Router(config-if)#interface Tokenring3
Router(config-if)#source-bridge 73 6 72

dlsw-central(config)#access-list 701 permit 4000.3745.AAAA 8000.0000.0000
dlsw-central(config)#interface TokenRing0
dlsw-central(config-if)#source-bridge input-address-list 701

dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff

dlsw-central(config)#dlsw allroute-sna

dlsw-central(config)#dlsw timer explorer-wait-time 5

dlsw-central(config)#dlsw icanreach mac-exclusive
dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff

You want to set up DLSw to allow Token Ring-to-Ethernet bridging.

DLSw includes the capability to bridge different kinds of media. One common example of this is bridging an Ethernet segment to a Token Ring. In this example, we connect an Ethernet branch to the same central Token Ring DLSw router used in Recipe 15.1:

dlsw-ether-branch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-ether-branch(config)#interface Loopback0
dlsw-ether-branch(config-if)#ip address 10.1.3.5 255.255.255.252
dlsw-ether-branch(config-if)#exit
dlsw-ether-branch(config)#access-list 200 permit 0x0000 0x0D0D
dlsw-ether-branch(config)#source-bridge ring-group 101
dlsw-ether-branch(config)#dlsw local-peer peer-id 10.1.3.5
dlsw-ether-branch(config)#dlsw timer explorer-wait-time 5
dlsw-ether-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lf 1470 lsap-output-list 200
dlsw-ether-branch(config)#dlsw bridge-group 1
dlsw-ether-branch(config)#dlsw transparent switch-support
dlsw-ether-branch(config)#dlsw allroute-sna
dlsw-ether-branch(config)#interface Ethernet0
dlsw-ether-branch(config-if)#description branch Ethernet
dlsw-ether-branch(config-if)#bridge-group 1
dlsw-ether-branch(config-if)#bridge 1 protocol ieee
dlsw-ether-branch(config-if)#end
dlsw-ether-branch#

Before looking at this in detail, we need to stress that routable protocols such as TCP/IP always behave better when they are routed. So you should only use bridging between different media as in this example when there are unroutable protocols that must communicate between them. Perhaps the most common example is when LLC2 SNA devices must be accessed from an Ethernet segment.

The first difference between this example and the one shown in Recipe 15.1 is in the remote-peer command, where we have added the flag lf 1470. This restricts the MTU of the bridged network to 1470 bytes so that the larger Token Ring frames cannot use the bridge. Token Ring supports much larger frames than Ethernet does. In a bridged network, there is no packet fragmentation facility (as there is in routed networks). If large Token Ring packets cross the bridge to an Ethernet segment, they must be dropped.

Ideally, this MTU restriction should be made on the remote-peer commands at both ends. If your central router must support both Ethernet and Token Ring branches, then it makes sense to configure two remote-peer commands on the central router, one for each type of remote medium. The command that the central router uses for bridging to Ethernet segments should then have the MTU restricted in the same way with the lf 1470 flag. If you like, you could also have a separate statement on the central router for remote Token Ring peers that can use the default value.

The next important difference between this Ethernet branch and the previous Token Ring branch is the presence of the command dlsw transparent switch-support. This is used in cases where the Ethernet segment that the router is connecting to the bridge is itself bridged. This would be the case if the local Ethernet segment contains an Ethernet switch. Remember from the introduction of this chapter that all Ethernet switches are transparent bridges. This command is particularly important when there are two redundant DLSw routers on an Ethernet segment. In such a case, the switch will become confused by the fact that the same downstream MAC addresses appear from both routers. If you are using Ethernet hubs, this command is unnecessary.

The interface configuration for Ethernet is completely different from the Token Ring example. There are three commands in this example that define the bridging characteristics of the Ethernet interface. The first is the bridge-group command found in the Ethernet interface configuration block. This command tells the router to associate this interface with the first logical bridge group in the router. This number is purely local to the router. You could build a bridge between two Ethernet interfaces on the same router as follows:

Router(config)#interface Ethernet0
Router(config-if)#bridge-group 1
Router(config-if)#exit
Router(config-if)#interface Ethernet1
Router(config-if)#bridge-group 1

But, in this example, we want to connect the Ethernet port to a Token Ring on another router. To do so, we associate this bridge group instead with DLSw using the dlsw bridge-group global configuration command:

dlsw-ether-branch(config)#dlsw bridge-group 1
dlsw-ether-branch(config)#interface Ethernet0
dlsw-ether-branch(config-if)#bridge-group 1

The bridging behavior is defined with the following command:

dlsw-ether-branch(config-if)#bridge 1 protocol ieee

This command tells the router to use the IEEE 802.1d STP for avoiding loops when creating the bridge instead of the older and incompatible Digital Equipment Corporation (DEC) standard. Unless you are connecting to extremely old equipment that doesn’t support the IEEE standard, you should always use this command.

dlsw-ether-branch(config)#source-bridge enable-80d5

Recipe 15.1

You want to convert the bit ordering of MAC addresses to see how they will look after passing through an Ethernet-to-Token Ring bridge.

The Perl script in Example 15-1 converts Ethernet addresses to the way they will appear when connected through a bridge to a Token Ring. It also performs the reverse translation of Token Ring addresses to Ethernet, which is identical.

#!/usr/local/bin/perl
#
# eth-tok-mac.pl -- a script to convert Ethernet to Token Ring MAC
#                   addresses when bridging with RSRB or DLSw
#
$convert[0] = "0";     $convert[1] = "8";
$convert[2] = "4";     $convert[3] = "C";
$convert[4] = "2";     $convert[5] = "A";
$convert[6] = "6";     $convert[7] = "E";
$convert[8] = "1";     $convert[9] = "9";
$convert[10] = "5";    $convert[11] = "D";
$convert[12] = "3";    $convert[13] = "B";
$convert[14] = "7";    $convert[15] = "F";

if($#ARGV != 0) {usage( );}

$input_MAC = $ARGV[0];

# first split the incoming MAC into bytes
$_ = $input_MAC;
s/[.:-]//g;

for ($i=0; $i*2 < length($_); $i++) {
   @input_bytes[$i] = substr($_, $i*2, 2);
}

for ($i=0; $i <= $#input_bytes; $i++) {
   $_ = @input_bytes[$i];

   # first check that there aren't any illegal characters in this address
   if(/[^0-9a-fA-F]/) {
      usage( );
  }

  if (length( ) = = 2 ) {
     @output_bytes[$i] = $convert[hex(substr($_, 1, 1))]
                       . $convert[hex(substr($_, 0, 1))];
  } else {
     usage( );
  }
}

print "the resulting MAC is: ";
for ($i=0; $i < $#input_bytes; $i++) {
   print "@output_bytes[$i]-";
}
print "@output_bytes[$#input_bytes]
";

sub usage( ) {
  print "usage: eth-tok-mac.pl <MAC>
";
  print "     where <MAC> is in the form HH:HH:HH:HH:HH:HH
";
  print "     or HH-HH-HH-HH-HH-HH or HHHH.HHHH.HHHH
  print "     (H is a hex number 0-F)
";
  print "The output is the converted MAC address.
";
  print "Note that this conversion is exactly the same whether converting
";
  print "from Ethernet to Token Ring or Token Ring to Ethernet.
";

  exit;
}

$ eth-tok-mac.pl 00-00-0c-f0-84-60
the resulting MAC is: 00-00-30-0f-21-06

Token Ring uses a convention of most significant bit first when writing a byte. Ethernet, on the other hand, puts the least significant bit first. So, when a bridge connects these two media, the MAC addresses of devices on the Ethernet side will look unfamiliar when viewed from the Token Ring side, and vice versa. The rule for converting from one to the other is relatively simple, however, because it just reflects this reversing of the bit ordering.

Table 15-3 shows how the conversion algorithm works.

This table converts each individual hex character in a MAC address, but there is more to it than this because a byte is 8 bits long, not 4 bits like a hex character.

Suppose the Ethernet address is 0000.0cf0.8460. The third byte of this address is 0c. To figure out how this byte will look on the Token Ring side of the bridge, switch the two hex characters to get c0. Then convert each of these characters using Table 15-3. The c becomes 3 and the 0 stays the same, giving a final value of 30. Converting the entire address similarly gives 00-00-30-0f-21-06.

The script provides an automated way to do these translations. If the 8 bits in a byte are numbered from 1–8, this algorithm simply flips the order so that they appear from 8–1. This is clearly identical to the inverse translation where the bit order is converted from 8–1 to 1–8. So both the script and the above manual technique work identically when converting Ethernet addresses to Token Ring or Token Ring addresses to Ethernet.

Recipe 15.2

You want to configure a serial port to connect to an SDLC device so that it can use DLSw to talk to a central mainframe.

The global configuration commands in this example are identical to those shown in Recipe 15.1 for using DLSw+ to connect two Token Rings. The central router’s configuration is identical to what was used in 15.1, so the following shows only the remote branch configuration:

dlsw-branch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-branch(config)#interface Loopback0
dlsw-branch(config-if)#ip address 10.1.2.5 255.255.255.252
dlsw-branch(config-if)#exit
dlsw-branch(config)#access-list 200 permit 0x0000 0x0D0D
dlsw-branch(config)#source-bridge ring-group 101
dlsw-branch(config)#dlsw local-peer peer-id 10.1.2.5
dlsw-branch(config)#dlsw timer explorer-wait-time 5
dlsw-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200
dlsw-branch(config)#dlsw allroute-sna
dlsw-branch(config)#interface Serial1
dlsw-branch(config-if)#description Connection to one remote SDLC device
dlsw-branch(config-if)#encapsulation sdlc
dlsw-branch(config-if)#no keepalive
dlsw-branch(config-if)#nrzi-encoding
dlsw-branch(config-if)#clock rate 4800
dlsw-branch(config-if)#sdlc role primary
dlsw-branch(config-if)#sdlc vmac 4000.CCCC.0000
dlsw-branch(config-if)#sdlc poll-pause-timer 200
dlsw-branch(config-if)#sdlc address 20
dlsw-branch(config-if)#sdlc xid 20 017A0006
dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 20
dlsw-branch(config-if)#sdlc dlsw 20
dlsw-branch(config-if)#end
dlsw-branch#

SDLC is a serial protocol that is commonly used for SNA devices. It is extremely popular in financial environments for devices such as banking machines, card readers, and account printers. Using SDLC in conjunction with DLSw is becoming increasingly common in these sorts of situations. This allows the remote SDLC devices to communicate with the Token Ring Interface Coupler (TIC) on a mainframe computer through an IP network. There is a huge advantage to this because it means that you don’t have to have a separate serial port on your mainframe’s Front End Processor (FEP) for every remote SDLC connection. Instead, you can have a single Token Ring interface supporting hundreds of remote devices that are connected through a reliable routed TCP/IP network.

Although it is essentially a synchronous serial protocol, there are several ways of constructing SDLC links. The simplest is a point-to-point connection from the router to an SDLC device, perhaps even another router. The SDLC link can also connect several devices in a long serial bus connection called a multidrop, and it can even be set up in a ring topology. To accomplish this, SDLC requires that each device have a unique 8-bit address between 0x01 and 0xFF in hexadecimal (1–255 in decimal notation). Each device is configured to respond to one of these SDLC addresses. A primary SDLC device polls every known address in turn to ask the devices if they have data to send. So, despite having many physical devices sharing a serial connection, there is no danger of collisions from two devices sending simultaneously. One of the advantages to DLSw is that it takes care of local acknowledgement of these SDLC polls. So if you connect two SDLC circuits together using DLSw, the polling traffic doesn’t cross the WAN, which saves bandwidth.

The example sets up the SDLC encapsulation on the port, provides the Data Communications Equipment (DCE) clock, and acts as the master device to a downstream SDLC device. The example also defines an artificial Token Ring MAC address for this device so that the FEP will be able to communicate with it through its Token Ring port. Let’s look at these functions separately:

dlsw-branch(config)#interface Serial1
dlsw-branch(config-if)#encapsulation sdlc
dlsw-branch(config-if)#nrzi-encoding
dlsw-branch(config-if)#clock rate 4800

First, the command encapsulation sdlc sets up the interface to use SDLC framing. This is accompanied by the nrzi-encoding command that specifies the electrical characteristics of the signaling. Non-Return to Zero Inverted (NRZI) is often required with IBM equipment. The default behavior for SDLC connections on Cisco routers is the similarly named but very different Non-Return to Zero (NRZ) encoding. You can configure the router to use NRZ by just turning off NRZI encoding with the command no nrzi-encoding.

Next, this example assumes that the router is the DCE for this SDLC line, so it must supply the clock, with the clock rate command. In the example, the clock rate is set to 4800bps. In general, you want the clock rate to be as high as the downstream devices can support, to facilitate better data transfer rates. However, it is relatively common to see SDLC devices that work only intermittently at higher rates such as 19,200bps. So a good practice when having problems with SDLC equipment is to turn the clock rate down somewhat and see if the problems go away.

Note that any time that you configure a router serial interface to be the DCE device, you must use a DCE cable. The router will not even accept the clock rate command if you have a DTE cable connected to the interface.

The command sdlc role primary is used with multidrop SDLC connections to define the router’s function in the multidrop network:

dlsw-branch(config-if)#sdlc role primary

A multidrop connection simply means that several devices are connected in series to the same serial port. You lose nothing by using this command with a single downstream device connected directly to the router, however. The different options for the sdlc role command are primary, secondary, and prim-xid-poll. Configuring the router to be the SDLC primary all downstream devices to be either PU 2.0, PU 2.1, or a mixture. The router will be the master. You should specify prim-xid-poll only if all downstream devices use PU 2.1 and you want the router to be the master device of the group.

In this example, there is only one SDLC device connected to the router, and its SDLC address is specified as 0x20 in hex. This is specified by the sdlc address command. Recipe 15.5 shows how to configure the router for several downstream SDLC devices.

The SDLC address is purely local to this SDLC connection. So, to uniquely identify a particular remote device anywhere in the network, the mainframe needs more information. Each device is identified in VTAM in a switched major node definition using two parameters called IDBLK and IDNUM. Cisco concatenates these two identifiers together to form the Exchange of Identification (XID). The example shows how to associate a particular IDBLK/IDNUM with a particular SDLC address using the following command:

dlsw-branch(config-if)#sdlc xid 20 017A0006

The IDBLK is contained in the first three digits of the XID field, 017 in this case, and the IDNUM appears in the remaining five digits, A0006. Typographical errors in the XID string are some of the most common SDLC problems. Make sure that this 8-digit hexadecimal number precisely matches the IDBLK/IDNUM configured for this device in VTAM.

Next, look at the commands that work with DLSw to allow this particular device to communicate with the mainframe. First, there must be a virtual Token Ring MAC address, which is defined using the sdlc vmac command:

dlsw-branch(config-if)#sdlc vmac 4000.CCCC.0000

Recall that the mainframe thinks that this SDLC device is actually a Token Ring device. This command defines the fake Token Ring address that the mainframe will use to communicate with it. However, there could be several devices on this port, all of which must have unique MAC addresses. To solve this problem, the last two digits of this address are replaced by the SDLC address. So the last two hex characters in this configuration statement must be zero. In this particular case, the sdlc vmac command defines a MAC address of 4000.CCCC.0000 for the serial interface. The one configured downstream device has an SDLC address of 20 (in hex), so it will appear on the mainframe’s ring with the MAC address 4000.CCCC.0020.

Just as the SDLC device must appear to be a Token Ring device to the mainframe, the mainframe must appear to be an SDLC device on this serial port. So your router must insert the FEP’s MAC address into the LLC packet. This is configured with the sdlc partner command:

dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 20

Note that the SDLC address is specifically included in this command to allow the different devices on a multidrop SDLC circuit to communicate with different FEPs.

DLSw has to know to pick up this particular SDLC address and share it with its DLSw peer routers. You set this with the sdlc dlsw command:

dlsw-branch(config-if)#sdlc address 20
dlsw-branch(config-if)#sdlc dlsw 20

The router will reject this command if you have not previously defined this address with the sdlc address command.

In this example, we have modified one of the important SDLC timing parameters with the sdlc poll-pause-timer command:

dlsw-branch(config-if)#sdlc poll-pause-timer 200

In SDLC, the primary device must poll the downstream devices to see if they have something to send. The example uses this command with an argument of 200, which instructs the router to wait for a period of 200 milliseconds between these polls. The default value is 100 milliseconds. The reason for using a longer interval between polls is simply to allow the downstream devices more time to respond. In some cases—particularly if the SDLC line is long or involves modems or line drivers to reach a physically remote device—the default value is not sufficient to account for the natural latency of the line. Note, however, that this polling does not cross the DLSw bridge, only the SDLC side of the network. This ability to terminate the local polling saves bandwidth and makes the network more tolerant of WAN latency.

There is one important final note on SDLC-to-Token Ring bridging. In Recipe 15.2, when bridging Ethernet to Token Ring, we had to make a restriction on the MTU in the dlsw remote-peer command. This is not necessary for SDLC. The SDLC frame size is normally either 265 or 521 bytes, much smaller than even the Ethernet frame size. But the difference here is that DLSw can fragment the larger Token Ring packets when sending them out of the SDLC port. However, it cannot combine several smaller SDLC frames into a larger Token Ring frame.

Recipe 15.2

You want to configure a serial port for an SDLC multidrop line supporting several devices.

SDLC supports multidrop connections. These are serial links that connect to several downstream devices in series. Each device has its own SDLC address, which must be configured in the router. The global DLSw configuration for this example is omitted here because it is identical to the previous recipe:

dlsw-branch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-branch(config)#interface Serial1
dlsw-branch(config-if)#description Connection to three remote SDLC devices
dlsw-branch(config-if)#encapsulation sdlc
dlsw-branch(config-if)#no keepalive
dlsw-branch(config-if)#nrzi-encoding
dlsw-branch(config-if)#clock rate 4800
dlsw-branch(config-if)#sdlc role primary
dlsw-branch(config-if)#sdlc vmac 4000.CCCC.0000
dlsw-branch(config-if)#sdlc poll-pause-timer 200
dlsw-branch(config-if)#sdlc address 20
dlsw-branch(config-if)#sdlc xid 20 017A0006
dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 20
dlsw-branch(config-if)#sdlc address 21
dlsw-branch(config-if)#sdlc xid 21 017A0007
dlsw-branch(config-if)#sdlc partner 4000.3745.AAAA 21
dlsw-branch(config-if)#sdlc address 22
dlsw-branch(config-if)#sdlc xid 22 017A0008
dlsw-branch(config-if)#sdlc partner 4000.3745.AAAB 22
dlsw-branch(config-if)#sdlc slow-poll 30
dlsw-branch(config-if)#sdlc dlsw 20 21 22
dlsw-branch(config-if)#end
dlsw-branch#

The basic router configuration is nearly the same here as it is for the single device shown in Recipe 15.4, but there are a few differences. The first difference is that all three of the SDLC addresses are configured, where the previous recipe had only one. Each SDLC address appears in four places, and you must ensure that all four are configured for all SDLC devices.

There must be an sdlc address command for each address, and the XID for each device must be defined with an sdlc xid command. You must associate each SDLC address with an FEP Token Ring MAC address using the sdlc partner command. In this example, the sdlc partner command for the third SDLC address, 22, is associated with a different FEP MAC address than the other two, just to show how this can be done. In most cases you would probably want to use the same FEP for all of the devices on a port, though.

Finally, you must associate each of these SDLC addresses with a DLSw bridge:

dlsw-branch(config-if)#sdlc dlsw 20 21 22

This tells the router to share these three specific SDLC addresses with DLSw. The router will not accept this command unless there is a matching sdlc address command defining each of these addresses.

Besides defining the additional SDLC addresses for the multidrop operation, this example also includes the command sdlc slow-poll with an argument of 30. This tells the router to ask each device for its data every 30 seconds, rather than the default 10 seconds. This is useful in multidrop configurations because it is often difficult to service all of the devices within the required time interval.

Recipe 15.4

You want to connect two serial devices through an IP network.

Serial Tunnel (STUN) provides the ability to emulate an SDLC circuit through an IP network. To simply connect two SDLC or two HDLC ports on different routers together, you can use the following:

Stun-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Stun-A(config)#interface Loopback
Stun-A(config-if)#ip address 10.1.15.5 255.255.255.252
Stun-A(config-if)#exit
Stun-A(config)#stun peer-name 10.1.15.5
Stun-A(config)#stun protocol-group 1 basic
Stun-A(config)#interface Serial1
Stun-A(config-if)#encapsulation stun
Stun-A(config-if)#nrzi-encoding
Stun-A(config-if)#clock rate 19200
Stun-A(config-if)#stun group 1
Stun-A(config-if)#stun route all tcp 10.1.15.9
Stun-A(config-if)#end
Stun-A#

This router could then connect its serial port to a port on a second router, configured as follows:

Stun-B#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Stun-B(config)#interface Loopback
Stun-B(config-if)#ip address 10.1.15.9 255.255.255.252
Stun-B(config-if)#exit
Stun-B(config)#stun peer-name 10.1.15.9
Stun-B(config)#stun protocol-group 1 basic
Stun-B(config)#interface Serial1
Stun-B(config-if)#encapsulation stun
Stun-B(config-if)#nrzi-encoding
Stun-B(config-if)#clock rate 19200
Stun-B(config-if)#stun group 1
Stun-B(config-if)#stun route all tcp 10.1.15.5
Stun-B(config-if)#end
Stun-B#

You can also do more interesting things with STUN. For example, if you wanted to create a virtual multidrop SDLC circuit, you could do something like this. The first router connects to the controller, while the other two hold the SDLC devices:

Stun-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Stun-A(config)#interface Loopback
Stun-A(config-if)#ip address 10.1.15.5 255.255.255.252
Stun-A(config-if)#exit
Stun-A(config)#stun peer-name 10.1.15.5
Stun-A(config)#stun protocol-group 1 sdlc
Stun-A(config)#interface Serial1
Stun-A(config-if)#encapsulation stun
Stun-A(config-if)#nrzi-encoding
Stun-A(config-if)#clock rate 19200
Stun-A(config-if)#stun group 1
Stun-A(config-if)#stun sdlc role secondary
Stun-A(config-if)#sdlc address 20
Stun-A(config-if)#sdlc address 21
Stun-A(config-if)#stun route address 20 tcp 10.1.15.9 local-ack
Stun-A(config-if)#stun route address 21 tcp 10.1.15.13 local-ack
Stun-A(config-if)#end
Stun-A#

Configure the second router like this:

Stun-B#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Stun-B(config)#interface Loopback
Stun-B(config-if)#ip address 10.1.15.9 255.255.255.252
Stun-B(config-if)#exit
Stun-B(config)#stun peer-name 10.1.15.9
Stun-B(config)#stun protocol-group 1 sdlc
Stun-B(config)#interface Serial1
Stun-B(config-if)#encapsulation stun
Stun-B(config-if)#nrzi-encoding
Stun-B(config-if)#clock rate 19200
Stun-B(config-if)#stun group 1
Stun-B(config-if)#stun sdlc role primary
Stun-B(config-if)#sdlc address 20
Stun-B(config-if)#stun route address 20 tcp 10.1.15.5 local-ack
Stun-B(config-if)#end
Stun-B#

Set up the third peer as follows:

Stun-C#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Stun-C(config)#interface Loopback
Stun-C(config-if)#ip address 10.1.15.13 255.255.255.252
Stun-C(config-if)#exit
Stun-C(config)#stun peer-name 10.1.15.13
Stun-C(config)#stun protocol-group 1 sdlc
Stun-C(config)#interface Serial1
Stun-C(config-if)#encapsulation stun
Stun-C(config-if)#nrzi-encoding
Stun-C(config-if)#clock rate 19200
Stun-C(config-if)#stun group 1
Stun-C(config-if)#stun sdlc role primary
Stun-C(config-if)#sdlc address 21
Stun-C(config-if)#stun route address 21 tcp 10.1.15.5 local-ack
Stun-C(config-if)#end
Stun-C#

In principle, you could configure DLSw to connect two SDLC ports together across an IP network using a slight variation of Recipe 15.5. But there is a simpler way to accomplish this. Cisco IOS includes two features, STUN and Block Serial Tunnel (BSTUN). STUN is useful for connecting things such as SDLC ports, even to the extent of building virtual SDLC multidrop links. BSTUN, on the other hand, is most useful when connecting ports running the IBM Bisync protocol. BSTUN is discussed in Recipe 15.7.

The first example in this recipe shows how to simply connect two serial ports together through an IP network using an emulated serial line. This type of configuration can be useful when dealing with applications that use the serial data link protocols in a nonstandard way. It can also be useful if you have to provide a serial connection between two locations that are already in your IP network.

This example first defines a single STUN protocol group as number 1 on each router. Then, in the interface configuration blocks, this number tells STUN how to interpret the data it receives on this interface. You could define several different protocol groups supporting different protocols if required. Note that the protocol group number is purely local to the router. So what appears as protocol group number 1 on the first router could be group number 5 on the second router.

The second example shows a somewhat more complicated configuration. In this case, STUN is used to emulate not a single circuit through an IP cloud, but a multi-drop circuit for use with SDLC devices. In more complex situations like this it is often better to use DLSw, but sometimes the SDLC devices need to see one another directly for one reason or another.

The only tricky part to this type of configuration is understanding which routers are primary and which are secondary for SDLC. It’s a little bit easier to understand if you envision the primary as the top of the network. Everything feeds into the primary. So if a router interface connects to downstream SDLC devices, as in routers Stun-B and Stun-C, the serial port is configured as primary, because it is controlling everything downstream. On Stun-A, however, the router is acting as the network for the real controller device, so this router’s serial interface is configured as secondary.

This example also includes local acknowledgement to prevent SDLC polling from crossing the IP network:

Stun-C(config-if)#stun route address 21 tcp 10.1.15.5 local-ack

This means that the router will respond to polls on behalf of devices that are on the other end of the tunnel to save bandwidth and improve performance. Allowing acknowledgement frames to cross the IP network sometimes introduces large latencies to the SDLC network because the devices must wait longer before sending the next data frame.

Recipe 15.7

You want to connect two Bisync (BSC) devices through an IP network.

This pair of router configurations shows how to define a tunnel connecting two serial ports that support BSC devices:

BSTUN-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
BSTUN-A(config)#interface Loopback
BSTUN-A(config-if)#ip address 10.1.16.5 255.255.255.252
BSTUN-A(config-if)#exit
BSTUN-A(config)#bstun peer-name 10.1.16.5
BSTUN-A(config)#bstun protocol-group 1 bsc
BSTUN-A(config)#interface Serial1
BSTUN-A(config-if)#encapsulation bstun
BSTUN-A(config-if)#clock rate 19200
BSTUN-A(config-if)#bstun group 1
BSTUN-A(config-if)#bsc char-set ebcdic
BSTUN-A(config-if)#bsc secondary
BSTUN-A(config-if)#bstun route all tcp 10.1.16.9
BSTUN-A(config-if)#end
BSTUN-A#

The configuration of the second router is similar:

BSTUN-B#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
BSTUN-B(config)#interface Loopback
BSTUN-B(config-if)#ip address 10.1.16.9 255.255.255.252
BSTUN-B(config-if)#exit
BSTUN-B(config)#bstun peer-name 10.1.16.9
BSTUN-B(config)#bstun protocol-group 1 bsc
BSTUN-B(config)#interface Serial1
BSTUN-B(config-if)#encapsulation bstun
BSTUN-B(config-if)#clock rate 19200
BSTUN-B(config-if)#bstun group 1
BSTUN-B(config-if)#bsc char-set ebcdic
BSTUN-B(config-if)#bsc primary
BSTUN-B(config-if)#bstun route all tcp 10.1.16.5
BSTUN-B(config-if)#end
BSTUN-B#

The configuration here is similar to Recipe 15.6. The main differences are in the protocols supported. The bstun protocol-group command in this case tells the router that BSTUN group number 1 will be passing BSC protocol data. There are several other options, including for Diebold and MDI alarm systems, as well as a generic async option.

In this recipe, the bsc char-set command is set to IBM’s EBCDIC character set, but you can also use ASCII. The choice depends on the type of traffic you are dealing with. Mainframe Bisync applications will usually use EBCDIC. At one time, Bisync was as a popular way to connect terminals and printers to a mainframe. But (thankfully) this ancient protocol inches closer to extinction with each passing year.

The only other important point to note is that the bstun route command can be used to route different stations attached to the same Bisync line depending on their addresses. Bisync allows many devices to be connected to the same controller, similar to an SDLC multidrop line. For example, if you wanted station C1 going to one destination and C2 to another, you could route them separately:

BSTUN-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
BSTUN-A(config)#interface Serial1
BSTUN-A(config-if)#bstun route address C1 tcp 10.1.16.9
BSTUN-A(config-if)#bstun route address C2 tcp 10.1.16.13
BSTUN-A(config-if)#end
BSTUN-A#

Recipe 15.6

You want to control packet fragmentation in DLSw to improve throughput.

There are two methods for controlling packet fragmentation when using DLSw. The first is to set an MTU for the bridge, as mentioned in Recipe 15.2:

Router-A(config)#dlsw remote-peer 0 tcp 10.1.1.5 lf 1470 lsap-output-list 200

This method is used primarily when connecting media with different MTU values. However, it is also common to connect two high-MTU media such as Token Rings via an intervening network that has low-MTU links. In this situation, you should take advantage of DLSw’s TCP transport by using the following command:

Router-A(config)#ip tcp path-mtu-discovery

These two different commands work at different levels and accomplish different goals. The first one sets the MTU of packets that pass through the bridge. However, the DLSw packets themselves need not have the same MTU. In fact, DLSw+ is able to break up a large Token Ring packet and carry it in a series of several DLSw packets, then reassemble the large packet at the other end. The first command instructs DLSw not to accept any packets for bridging if they are larger than the specified size.

The most serious performance problems happen when the DLSw packets themselves must be fragmented in the network. In general, the DLSw routers will use the largest MTU that they can. This will usually wind up being the MTU of the first link into the IP network heading towards the router at the other end of the bridge. There could be a link along the path that can’t transmit a packet this large, so a router in the middle of the network will fragment the packet according to standard TCP packet fragmentation rules. The receiving DLSw router reassembles the packet before de-encapsulating the payload packet.

This tends to be relatively inefficient, and it can cause serious throughput issues in some networks. So, to avoid the problem, you can configure both DLSw peer routers to use a clever feature of TCP called Path MTU Discovery, which is described in RFC 1191. When the TCP connection is first made, in this case by forming a DLSw peer relationship between two routers, the routers start by figuring out the largest MTU that they can pass between them without fragmentation.

They do this by setting the Don’t Fragment (DF) bit in the IP header and sending the largest packet that the interface can support. If a router somewhere in the network finds that it must fragment the packet to forward it, it will drop it instead and send back an informational ICMP “Datagram Too Big” packet to report the problem. The ICMP message includes the maximum size that it could have passed along. This allows the two end points to quickly deduce the largest packet size they can use.

TCP Path MTU Discovery is not enabled by default on Cisco routers. This command will affect all TCP sessions with this router, not just DLSw. In general, it is most effective if all of the DLSw routers have this feature enabled.

Recipe 15.2; RFC 1191

You want to set the Type of Service (TOS) field in DLSw packets to ensure that they get preferential treatment in the network.

In many organizations, the SNA traffic that is encapsulated in DLSw is considered both mission critical and time sensitive. Lower priority traffic should not be allowed to interfere with it. The simplest way to accomplish this is to tag these high priority packets using the standard IP Precedence field:

Router-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-A(config)#ip local policy route-map dlswroutemap
Router-A(config)#ip route-cache policy
Router-A(config)#access-list 101 permit tcp any any eq 2065
Router-A(config)#access-list 101 permit tcp any eq 2065 any
Router-A(config)#access-list 101 permit tcp any any eq 2067
Router-A(config)#access-list 101 permit tcp any eq 2067 any
Router-A(config)#route-map dlswroutemap permit 10
Router-A(config-route-map)#match ip address 101
Router-A(config-route-map)#set ip precedence flash-override
Router-A(config-route-map)#end
Router-A#

The most important concept here is the idea that you should set the priority of a packet at the point where it enters the network. In this case, the DLSw packet is actually created by the router, so this is the perfect place to tag it. Then every other router in the network can simply react appropriately to this priority tag without having to look deeply into the packet to figure out how important it is.

This example just shows how to set the IP Precedence field; it doesn’t actually affect the forwarding behavior. You have to ensure that the interfaces on routers that need to forward this packet are configured to deal with IP Precedence properly by using Weighted Fair Queueing (WFQ) or some other appropriate queueing mechanism. Techniques for doing this are shown in Chapter 11. The actual tagging of the packet is done using policy-based routing, which is described in more detail in Chapter 5.

The IP Precedence value is set for every TCP packet with a source or destination port of 2065 or 2067. These are the two ports commonly used for DLSw traffic: 2065 is used by DLSw Version 1, and Version 2 uses 2067. Cisco’s DLSw+ primarily uses 2065, although Recipe 15.10 shows an exception to this convention.

Chapter 11 demonstrates some more sophisticated options for setting QoS tag values.

Chapter 5; Chapter 11

You want DLSw to preserve and support the SNA or APPN class of service definitions for forwarding packets through your IP network.

To configure DLSw to follow the SNA or APPN priorities defined in the traffic flow, you must configure the peer relationship to allow multiple distinct data streams:

Router-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-A(config)#dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200 priority
Router-A(config)#end
Router-A#

You can then go further and map the individual priority streams to specific IP Precedence values. You can define new values as follows:

Router-A#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-A(config)#dlsw tos map low 0 normal 1 medium 2 high 3
Router-A(config)#end
Router-A#

You can also use any of the default values shown in Table 15-4.

The TOS map does not need to match at both ends of a DLSw connection. But, if you use the priority option on the dlsw remote-peer command on one router, you must also use it on the other:

Recipe 15.9 showed how to configure the router to tag the IP Precedence field in all DLSw packets for preferential treatment through the network. This example allows for the creation of four separate DLSw priority levels that follow the SNA priorities. This is useful, for example, if the SNA traffic stream includes both bulk data transfers and interactive traffic.

As soon as you enable SNA prioritization in the dlsw remote-peer command, DLSw forms four TCP connections instead of just one. So it is critical that you enable this option on both ends if it is required, or the remote router will simply reject the DLSw peer connection. DLSw will then start using the TCP port numbers shown in Table 15-4.

Note that the highest priority SNA traffic has an IP TOS value of 5 (Critical) by default when SNA Priority is enabled. This is not a good choice in many networks. The routers need to reserve the top two Precedence values, Internetwork Control (6) and Network Control (7), for vital functions like routing protocols. Giving high-priority SNA traffic a Precedence value of 5 means that there is no room for other high-priority traffic such as voice. This is why we have included the dlsw tos map command in the recipe example. This command allows you to select more appropriate TOS values for the four SNA priorities.

Whether you use this method or the one in Recipe 15.9 to set up QoS for DLSw is mostly a matter of whether you need to preserve the native SNA priority scheme. Opening four TCP connections, as in this recipe, causes the router to use more memory and CPU resources. This might become an issue on heavily loaded routers, particularly when many routers use a common central DLSw peer.

Recipe 15.9; Chapter 11

You want to improve the fault tolerance of your DLSw network.

There are several things you can do to improve the reliability and fault tolerance of your network. Many of these solutions have the added benefit of improving performance. The first important thing to consider is having more than one DLSw peer router connected to the mainframe’s Token Ring. In this case, you will want to make sure that you balance the load between the two peers as much as possible:

dlsw-branch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dlsw-branch(config)#source-bridge ring-group 101
dlsw-branch(config)#dlsw local-peer peer-id 10.1.2.5
dlsw-branch(config)#dlsw timer explorer-wait-time 5
dlsw-branch(config)#dlsw load-balance circuit-count
dlsw-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200
dlsw-branch(config)#dlsw remote-peer 0 tcp 10.1.1.9 lsap-output-list 200
dlsw-branch(config)#dlsw allroute-sna
dlsw-branch(config)#end
dlsw-branch#

This example is extremely similar to the one shown in Recipe 15.1, so we’ve left out the interface parts of the configuration. The main difference is the presence of a second dlsw remote-peer command. This points to the IP address of a second router that is on the same central Token Ring as the mainframe. So the same mainframe MAC address is visible on this branch router coming from both DLSw peers.

The dlsw load-balance circuit-count command tells the router to balance circuits between these two peers. For example, if several PCs are connected to the branch Token Ring and they all have SNA sessions to the mainframe, this feature will ensure that half of these sessions will follow one path, and half will follow the other. If one of these peers fails, the circuits will be reestablished through the remaining path.

The routers will not tear down circuits to balance the load, but rather will look at the current number of circuits on each peer each time a new circuit is established. They will then use this information to decide where to put the new circuit.

The other option here is the default round-robin circuit balancing. Round robin has the disadvantage that it takes a very long time to rebalance the load after a failure. So we recommend using the circuit-count option for load balancing between two or more remote DLSw peers.

Recipe 15.1

You want to check on DLSw status on your router.

This command shows the status of a DLSw peer relationship:

Router>show dlsw peers
Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 10.1.1.5        CONNECT        350       350  conf      0    0   0 02:55:03
 TCP 10.1.1.9        CONNECT        124       124  conf      0    0   0 01:17:28
 Total number of connected peers: 2
 Total number of connections:     2

This command looks at the status of the SNA circuits carried within these peer connections:

Router>show dlsw circuits
Index           local addr(lsap)    remote addr(dsap)  state          uptime
1459617889      4000.5555.a820(04)  4000.3745.aaaa(04) CONNECTED         3d05h
2097152104      4000.5555.ac21(04)  4000.3745.aaaa(04) CONNECTED         2d18h
738197600       000c.2950.aa40(14)  4000.3745.aaaa(04) CONNECTED         3d06h
2214592610      4000.aaaa.3826(04)  4000.3745.aaaa(04) CONNECTED         3d05h
2785017948      4001.bbbb.6797(04)  4000.3745.aaaa(04) CONNECTED         3d06h
Total number of circuits connected: 5

It is important to remember the difference between a peer and a circuit. A peer relationship exists between two DLSw routers. You can bring up a peer relationship between two routers and have no application information flowing between them. A circuit, on the other hand, is an SNA connection between a device connected to one of these routers and a device connected to the other.

The show dlsw peers command shows only information about the peer relationship. It indicates the state of each peer connection, how many packets have been sent and received along each path, how many circuits are active, and how long the peers have been up. The example shows two peer routers, as is the case in Recipe 15.11. In this example, both peers are in a connected state, and neither has any active circuits passing through it (as shown in the ckts column).

The show dlsw circuits command looks at the status of the circuits. In this case, there are five active circuits. The output shows how long each of the circuits has been connected, and the MAC addresses involved. It also shows the SSAP and DSAP associated with each session, which can help you determine what circuits apply to what applications.

The index number associated with each circuit is just an identifying number that you can use to manually disconnect a particular circuit. You can clear all of the circuits at once as follows:

Router#clear dlsw circuits

Or, to clear only the second circuit listed in the example output, use the following:

Router#clear dlsw circuits 2097152104

Recipe 15.11

You want to check the status of an SDLC device on your router.

You can get a lot of useful SDLC information by simply looking at the interface:

Router>show interface serial1
Serial1 is up, line protocol is up
  Hardware is HD64570
  Description: Connection to three remote SDLC devices
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation SDLC, loopback not set
    Router link station role: PRIMARY (DCE)
    Router link station metrics:
      slow-poll 30 seconds
      T1 (reply time out) 3000 milliseconds
      N1 (max frame size) 12016 bits
      N2 (retry count) 20
      poll-pause-timer 200 milliseconds
      poll-limit-value 1
      k (windowsize) 7
      modulo 8
      sdlc vmac: 4000.CCCC.00--
  sdlc addr 20 state is CONNECT
      cls_state is CLS_IN_SESSION
      VS 0, VR 0, Remote VR 0, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 5025/618
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 15/2 SNRMs 0/0 DISC/RDs 0/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 22/21
  sdlc addr 21 state is CONNECT
      cls_state is CLS_IN_SESSION
      VS 0, VR 0, Remote VR 0, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 127/15
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 1/0 SNRMs 0/0 DISC/RDs 0/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 20/22
  sdlc addr 22 state is SNRMSENT
      cls_state is CLS_CONNECT_RSP_PEND
      VS 0, VR 0, Remote VR 0, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 25/0
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 0/0 SNRMs 0/0 DISC/RDs 0/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 21/20
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:05:31
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 6 bits/sec, 2 packets/sec
  5 minute output rate 3 bits/sec, 1 packets/sec
     157210 packets input, 315708 bytes, 0 no buffer
     Received 287021 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     156918 packets output, 307682 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up   RTS=down  CTS=up

This recipe shows the output of a show interface command for the multidrop configuration shown in Recipe 15.5. The first line reports that the interface is “up” and line protocol is also “up.” In general, these values are affected by physical issues such as whether the cabling is correctly connected, clocking, and the choice of NRZ or NRZI line coding. The other thing to look at if you have trouble bringing the line up is the duplex setting of the interface. On Cisco routers, SDLC uses full duplex by default. To change this to half-duplex, use the sdlc hdx command:

Router-A#(config)#interface Serial1
Router-A#(config-if)#sdlc hdx

In the output of the show interface command, you can immediately see that there are three SDLC addresses configured, with hexadecimal addresses 20, 21, and 22. In this particular case, only the first two stations are shown in a connected state, and the third is not responding. The router is trying to contact it, so it is listed in a “SNRMSENT” state. This means that the router has sent a Set Normal Response Mode (SNRM) request to initialize the Physical Unit (PU). Table 15-5 shows all of the possible states for SDLC devices.

In normal conditions, all of your devices should be in the “CONNECT” state, so this is a good thing to check when debugging an SDLC problem. If a device is connected but you suspect that there is a problem with it, there is a useful EXEC command that is effectively an SDLC version of ping:

Router#sdlc test serial 1 20
SDLC Test for address C1 completed
Frames sent=10 Frames received=10

This command sends short SDLC frames out the specified interface (in this case, Serial1) addressed to the desired destination address (in this case, 20). If the device is online and the circuit is configured correctly, then you should see the same number of frames received as sent. By default, it sends 10 frames. You can change the number and content of these frames, but this simple form is usually sufficient.

The most common problems with an SDLC connection are mismatched XID or SDLC addresses. Sometimes you will encounter physical problems caused by either a bad cable or electrical noise. And the other most common issues are caused by clock rate problems (either too fast or too slow for the attached devices), or an incorrect choice of NRZ or NRZI line coding. It is usually best to start with the physical layer and see if the interface is coming up at all. If the interface won’t come up, or comes up but won’t stay up, then look for physical problems such as these. If the interface comes up, but you can’t communicate with the devices, look for problems with XID values and SDLC addresses.

Recipe 15.5

You want to debug and isolate DLSw problems.

The first thing to do with any DLSw issue is to verify that the peers are working correctly, as in Recipe 15.12. If the peers are not established, then test IP connectivity with ping packets. If you can ping but the peers won’t come up, then verify your configuration as in Recipe 15.1. In particular, ensure that the remote peer of each router precisely matches the local peer on the other end.

If the DLSw peers are active, check the circuits, as in Recipe 15.12.

For failed circuits involving SDLC devices, check the serial interface, as in Recipe 15.13.

For Token Ring or Ethernet devices, verify that the interface is functioning properly as in Chapter 16.

If the peers are active and the interfaces look good, then there are three main things that could still be wrong. There could be a loop problem within the DLSw network. There could be a MAC address problem, or a MAC or LSAP filtering issue. Or there could be a network congestion or performance problem.

There are several useful debug commands for use with DLSw. For looking at the router-to-router DLSw transport, you can use the debug dlsw command:

dlsw-branch#debug dlsw

You can get other useful information about SNA and LLC2 connection problems with these debug commands:

dlsw-branch#debug sna state
dlsw-branch#debug llc2 state

If your routers will not establish a DLSw peer relationship, the most common problem is simple IP connectivity. Verify that you can ping the address in the remote-peer statement. Note also that at most one end can use the promiscuous keyword to avoid configuring a remote-peer statement. This feature allows the router to sit and quietly wait for other routers to initiate connections. Somebody has to start the conversation.

Another common reason for failing to connect is simply a configuration mismatch between the local peer and remote peer definitions. Make sure that if you have a remote-peer statement, then the IP address exactly matches the address in the local-peer statement of the other router. It is not enough just to target any address on the remote peer router: it must be exactly the same address.

If this is correct and you can ping but still cannot connect, then there are two remaining possibilities. One is that there are port-specific filters or routing rules that permit ping, but handle DLSw packets differently. This is particularly possible when using policy-based routing in an attempt to give DLSw packets a preferred path through the network. The preferred path may have serious congestion problems, for example.

The other possibility is that there is a complete incompatibility between the versions of DLSw running at the two ends. If both are Cisco routers, then this is not going to happen. But there are still some pre-RFC 1795 DLSw implementations out there, and Cisco’s DLSw+ cannot negotiate a connection with noncompliant versions.

If you are trying to debug a DLSw problem, make sure that the peers are connected:

dlsw-branch#show dlsw peers
Peers:            state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 10.1.1.5    CONNECT    1348082    547505  conf      0    3   0     4w6d
 TCP 10.1.1.9    CONNECT     167013    200235  conf      0    3   0     4w5d
 TCP 10.2.1.5    DISCONN          0         0  conf      0    0   -        -
 TCP 10.2.1.9    DISCONN          0         0  conf      0    0   -        -
Total number of connected peers: 2
Total number of connections:     2

In this example, four peers have been configured, but only two of them are connected. A simple ping test would reveal in this case that the two disconnected peers are currently unreachable because of a network problem.

This command output also shows that there are currently three circuits connected to each of the active peers, for a total of six active circuits. You can look at information on the individual circuits with the show dlsw circuits command:

dlsw-branch#show dlsw circuits
Index           local addr(lsap)    remote addr(dsap)  state          uptime
2164260933      4000.53aa.2440(04)  4000.3745.aaaa(04) CONNECTED         5d00h
1627390033      4000.53aa.8420(04)  4000.3745.aaaa(04) CONNECTED         2d01h
2684354644      4000.53aa.7023(04)  4000.3745.aaaa(04) CONNECTED      09:41:36
2013265928      000c.29d0.bb41(14)  4000.3745.aaab(04) CONNECTED          4w5d
654311497       4001.001b.a1f3(04)  4000.3745.aaab(04) CONNECTED         3d18h
1342177367      4000.53aa.e3a1(04)  4000.3745.aaab(04) CONNECTED      06:09:14
Total number of circuits connected: 6

Here you can see that these six circuits connect to two different FEP MAC addresses. All of the DSAP values are 0x04, and one of the circuits has an LSAP value of 0x14. This is useful in making sure that you have appropriate SAP filters in place.

The following shows the output of a debug trace on this same router:

dlsw-branch#debug dlsw
DLSw reachability debugging is on at event level for all protocol traffic
DLSw peer debugging is on
DLSw local circuit debugging is on
DLSw core message debugging is on
DLSw core state debugging is on
DLSw core flow control debugging is on
DLSw core xid debugging is on
dlsw-branch#
May 15 22:18:35.320:  DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 40
May 15 22:18:35.320: CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 40 from
TokenRing0/0
May 15 22:18:35.320: CSM:   smac c001.001b.21aa, dmac 0020.353f.ab4a, ssap 4 , dsap 0
May 15 22:18:35.320: broadcast filter failed mac check
May 15 22:18:35.320: broadcast filter failed mac check
May 15 22:18:35.320: CSM: Write to all peers not ok - PEER_NO_CONNECTIONS
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:35.556:  DISP Sent : CLSI Msg : TEST_STN.Req   dlen: 46
May 15 22:18:36.240:  DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 40
May 15 22:18:36.244: CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 40 from
TokenRing0/0
May 15 22:18:36.244: CSM:   smac c001.001b.21aa, dmac 0060.9442.7cf3, ssap 4 , dsap 0
May 15 22:18:36.244: broadcast filter failed mac check
May 15 22:18:36.244: broadcast filter failed mac check
May 15 22:18:36.244: CSM: Write to all peers not ok - PEER_NO_CONNECTIONS

Note that one device with a Token Ring MAC address of c001.001b.21aa is attempting to make a connection to two different destination MAC addresses. These connections are being rejected with the message “broadcast filter failed mac check.” This message appears because of the dlsw icanreach mac-exclusive command that filters out all MAC addresses from crossing the network unless they are explicitly configured on the router.

Watching this same debug trace for a little while longer reveals more interesting entries:

May 15 22:18:46.852: DLSw: 654311497 decr s - s:58 so:0 r:89 ro:0
May 15 22:18:46.852: DLSW Received-disp : CLSI Msg : DATA.Ind   dlen: 336
May 15 22:18:46.852: DLSw: START-FSM (654311497): event:DLC-Data.Ind state:CONNECTED
May 15 22:18:46.852: DLSw: core: dlsw_action_l( )
May 15 22:18:46: %DLSWC-3-SENDSSP: SSP OP = 10( INFO ) to peer 10.1.1.5(2065) success
May 15 22:18:46.852: DLSw: END-FSM (654311497): state:CONNECTED->CONNECTED
May 15 22:18:46: %DLSWC-3-RECVSSP: SSP OP = 10( INFO )  from peer 10.1.1.5(2065)
May 15 22:18:46.920: DLSw: 654311497 decr r - s:58 so:0 r:88 ro:0
May 15 22:18:46.920: DLSw: START-FSM (654311497): event:WAN-INFO state:CONNECTED
May 15 22:18:46.924: DLSw: core: dlsw_action_m( )
May 15 22:18:46.924:  DISP Sent : CLSI Msg : DATA.Req   dlen: 308
May 15 22:18:46.924: DLSw: END-FSM (654311497): state:CONNECTED->CONNECTED
May 15 22:18:48.612: DLSw: Keepalive Request sent to peer 10.1.1.9(2065))
May 15 22:18:48.628: DLSw: Keepalive Response from peer 10.1.1.9(2065)

In this section of the trace, you can see one of the circuits (654311497) actually sends and receives a piece of information. You can see that it uses the first of the active peers, 10.1.1.5, and that the conversation happens on TCP port 2065. A short time later, you can see the router exchange keepalive messages with the other peer to ensure that the peer relationship remains active.

The following shows what happens when a particular circuit suddenly disconnects. In this case, we have deliberately cleared one of the circuits:

dlsw-branch# clear dlsw circuit 2013265928
May 15 22:18:55.412: DLSw: START-FSM (2013265928): event:ADMIN-STOP state:CONNECTED
May 15 22:18:55.412: DLSw: core: dlsw_action_r( )
May 15 22:18:55: %DLSWC-3-SENDSSP: SSP OP = 25( HLTN )  to peer 10.1.1.5(2065)
success
May 15 22:18:55.412:  DISP Sent : CLSI Msg : DISCONNECT.Req   dlen: 4
May 15 22:18:55.412: DLSw: END-FSM (2013265928): state:CONNECTED->HALT_NOACK_PEND
May 15 22:18:55.424: SNA: Connection to Focal Point SSCP lost
May 15 22:18:55.424:  DLSW Received-ctlQ : CLSI Msg : DISCONNECT.Cfm CLS_OK dlen: 8
May 15 22:18:55.424: DLSw: START-FSM (2013265928): event:DLC-Disc.Cnf  state:HALT_
NOACK_PEND
May 15 22:18:55.424: DLSw: core: dlsw_action_z( )
May 15 22:18:55.424:  DISP Sent : CLSI Msg : CLOSE_STN.Req   dlen: 4
May 15 22:18:55.424: DLSw: END-FSM (2013265928): state:HALT_NOACK_PEND->CLOSE_PEND
May 15 22:18:55.424:  DLSW Received-ctlQ : CLSI Msg : DISCONNECT.Ind   dlen: 8
May 15 22:18:55.424: DLSw: START-FSM (2013265928): event:DLC-Disc.Ind state:CLOSE_
PEND
May 15 22:18:55.424: DLSw: END-FSM (2013265928): state:CLOSE_PEND->CLOSE_PEND
May 15 22:18:55.424:  DLSW Received-ctlQ : CLSI Msg : CLOSE_STN.Cfm CLS_OK dlen: 8
May 15 22:18:55.424: DLSw: START-FSM (2013265928): event:DLC-CloseStn.Cnf state:
CLOSE_PEND
May 15 22:18:55.428: DLSw: core: dlsw_action_y( )
May 15 22:18:55.428: DLSw: 2013265928 to dead queue
May 15 22:18:55.428: DLSw: START-TPFSM (peer 10.1.1.5(2065)): event:CORE-DELETE
CIRCUIT state:CONNECT
May 15 22:18:55.428: DLSw: dtp_action_v( ), peer delete circuit for peer 10.1.1.
5(2065)
May 15 22:18:55.428: DLSw: END-TPFSM (peer 10.1.1.5(2065)): state:CONNECT->CONNECT
May 15 22:18:55.428: DLSw: END-FSM (2013265928): state:CLOSE_PEND->DISCONNECTED

As you can see, there are several stages that the connection must go through to complete the disconnection request. First it goes into a “HALT_NOACK_PEND” state, meaning that both ends have not yet acknowledged the halt order. From there it goes into a “CLOSE_PEND” state, and finally “DISCONNECTED,” as the two DLSw peer routers finally agree that the connection has been terminated.

For one final example, here is what the debug sna state trace looks like for a similar disconnection and reconnection:

dlsw-branch#debug sna state
  SNA state change debugging is on for all PUs

dlsw-branch#clear dlsw circuit 2130706520
dlsw-branch#
May 15 22:22:57.399: SNA: LS VDLCTEST: input=Disc.Ind, Connected -> PendClose
May 15 22:22:57.403: SNA: PU VDLCTEST: input=T2ResetPu, Active -> Reset
May 15 22:22:57.403: SNA: LS VDLCTEST: input=Close.Cnf, PendClose -> Reset
May 15 22:22:57.403: SNA: Connection to Focal Point SSCP lost
May 15 22:23:27.035: SNA: LS VDLCTEST: input=StartLs, Reset -> PendConOut
May 15 22:23:33.035: SNA: LS VDLCTEST: input=ReqOpn.Cnf, PendConOut -> Xid
May 15 22:23:33.303: SNA: LS VDLCTEST: input=Connect.Ind, Xid -> ConnIn
May 15 22:23:33.303: SNA: LS VDLCTEST: input=Connected.Ind, ConnIn -> Connected
May 15 22:23:33.427: SNA: PU VDLCTEST: input=Actpu, Reset -> Active
May 15 22:23:33.427: SNA: Connection to Focal Point SSCP established

In this trace, you can see the exchange of XID information and the final activation of the circuit takes less than a second here. The main time lag occurs as the end devices wait a few seconds after disconnection before trying to reconnect their SNA sessions.

Recipe 15.1; Recipe 15.12; Recipe 15.13; Chapter 16