From: Geoff Zinderdine (geoffz@xxxxxxx)
Date: Sat Aug 31 2002 - 11:49:20 GMT-3
>That should do you, if you want to test it, get 2 windoze boxes on each
>Ethernet and try to browse one computer name from the other, this will
>generate some netbios name requests and responses etc and subsequently
(providing you have everything right) will create a circuit.
For those who see no reason to infect an otherwise perfectly good computer
with Windows and have a few spare routers kicking around, you
can use the following dspu config (from Skyline Computers User Guide)
to test DLSw with actual SNA traffic. This has the added benefit of being
accessible remotely without having to do anything on Windows boxes to
initialize the circuits. I use a couple of old 3000 series routers that
aren't good for much else in their present state but a couple of IGS or 16xx
would do just as well. The advice to put them initially in the same VLAN
and
then move them into position is best heeeded. Once you have a working
config then
you can just add them to whatever vlan you need to at the time to test. I
think it
is totally worth the 30 or 40 bucks each to have instant dlsw verification
at any time!
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 2s. 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 2s are concerned.
For instance, instead
of 20 PUs at a remote site, with 20 LLC2 connections and its overhead, the
host thinks its 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 PU2
s.
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.
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:43 GMT-3