Geoff Zinderdine
Aegis Network Consulting

Reproduced under Fair Use guidelines (http://www.copyright.gov/title17/92chap1.html#107)

Testing SNA using DSPU configurations
The Down Stream Physical Unit (DSPU) IOS feature typically sits between a mainframe host and several SNA PU type 2's. The DSPU feature appears to be a single PU as far as the host is concerned, and appears to be the host as far as the PU 2's are concerned.

For instance, instead of 20 PUs at a remote site, with 20 LLC2 connections and its overhead, the host thinks it's talking to 1 PU2, with 1 LLC2 connection. Between the router and the 20 real PU2s, there are 20 LLC connections, but since the DSPU router is typically near the remote PUs, those LLC2 sessions' overhead does not pose a problem.

To accomplish its goal, DSPU acts like a PU2 when talking to the mainframe, and acts like a PU5 (mainframe) when talking to the PU2s. So, when talking to a mainframe, DSPU can send Test frames as explorers, responds to an LLC SABME, and responds to ACTPU messages. Similarly, to talk to the PU2s, DSPU responds to Test frames, issues a SABME to each PU2 to start an LLC2 connection, and generates and sends ACTPU and ACTLU messages to the PU2s.

To test Skylabs, you can use sample DSPU configurations to generate SNA traffic. Although the configs make no sense for the real world, they do generate test requests and responses, SABME and UA, and real ACTPU and ACTPU response messages. The way to do this is configure some DSPU config on each of two different routers. In other words, configure one router to *act* as the PU5 (Mainframe), and configure the other router to act as a PU2. A *normal* DSPU config on one router does both but you can partially config DSPU on two different routers, and actually cause them to create LLC2 connections between each other.

For instance, R5 is configured to act like a PU2, and R6 is configured to act like a PU5 in the following configurations. (These configurations can be used with lab 26.)

 hostname r5-dsputest
 !
 dspu host Hoover xid-snd 05d11111 rmac 0200.6666.6666 rsap 4 lsap 4
 !
 int e 0
   mac-address 0200.5555.5555
   dspu enable-host lsap 4
   dspu start hoover
 
 
 hostname R6-dsputest
 !
 dspu pu PU-ETH rmac 0200.5555.5555 rsap 4 lsap 4
 !
 int e 0/0
   mac-address 0200.6666.6666
   dspu enable-pu lsap 4

The DSPU Host command can be interpreted as meaning I am talking to the host, so I act like PU2. Conversely, the DSPU PU command means "I am talking to a PU2, so I act like a PU5". So, R5 acts like a PU2, and R6 acts like a PU5. If you are testing with DSPU for the first time, you might want to put both R5 and R6 (in this example) on the same Ethernet VLAN, configure DSPU, and use the show dspu command to see the PU in an active state. Then, you can configure R5 and R6 to be in the correct VLANs. For instance, in lab26, and put R5 on the same Ethernet as Lone Rhino, and R6 off the same Ethernet as Wolf, to act as the Hoover mainframe in the book. DSPU will try to start the connection periodically, but for the inpatient, you can repeat the DSPU start config command.

When the PU is active, you have proven your RSRB or DSLw configuration is working.