DLSw circuit question

Hello forum,
there is a strange behaviour of a dlsw connection that I wish to discuss here.
We had (long time ago) established a dlsw connection between two mainfrmes, one had an OSA T/R adapter and the other a 3745 in front. This circuit was up and running and soon we "forgot" about it. No problems were ever reported.
Some months ago, we changed the T/R OSA to Ethernet OSA. Again, doing all necessary changes, the sessions were established ok. But we notice a strange behaviour. Every morning, the PU is in a strange state, either pending or conct and we have to vary inact/act the PU so that the sessions can be established. After about 1 to 2 minutes everyhing is ok.
We do not have taken any traces or displays, but I wanted to ask, is it something to do with the dlsw circuit between the two MAC addresses (ETH OSA and 3745) dropping through the night?
Is there any time limit that an established circuit is active?
Can we change this time?
During night, of course there is no activity between the two mainframes, so we guess a timer expires and the PU needs reactivation.
HAPPY NEW YEAR!!!!

I am trying to connect the following config:
IBM Host A <-OSA-> Ethernet <--> router <-- Serial --> IP Cloud (FR / ??) <--> FEP (with FR support) <--> IBM Host B.
IBM Host A runs CICS App, Terminals connected to the FEP on the IBM Host B side logon to CICS App on IBM Host A.
The person before me designed the connection using FRAS. After a few weeks of trying, I found out it won't work.
Based on the scanning throught this forum it seems that I can do this by using dlsw such as:
IBM Host A <-OSA-> Ethernet <--> router (DLsw) <-- Serial --> IP Cloud (FR / ??) <--> router (DLsw) <--> FEP (with FR support) <--> IBM Host B.
Since I am new to the network, I need a bit more help on the config on the IBM HOST A (VTAM XCA), both dlsw routers and the FEP on IBM Host B.
Also at the moment the link is Frame-relay (direct). Can the IBM Host A with OSA card and the 2 dlsw routers able to utilise the same frame-relay link or we have to get another type of wan link?

Similar Messages

Dlsw circuits random disconnect

Hello!!
Could somebody help me with this?
We have a dlsw network of almost 1600 remote dlsw peers.
We have six central peer routers.
Sometimes we saw some SNA PU´s down, and after 1 to 3 min return to "CONNECTED" (dlsw circuit). We dont´n see any dlsw peer down, only dlsw circuit falls.
On branch office router we saw by the command "show dlsw ciscuits history detail", that the event before disconnect is
Event
WAN halt-dl
What does this mean?
It is possibly a problem with the Central Peer Router?
The Carrier confirm us no problem with the WAN Network.
The Central Routers are Cisco7200VXR NPE400 512DRAM and IOS 12.4(4)T1
The branch office routers are Cisco1760 IOS 12.3(9).
Thanks for help!!
Pedro.

I'd look into monitoring the CPU usage (as well as the amount of memory used by DLSw Process) of the 1700 series branch routers. It may be that these TCP based connections from the 6 central routers are overwhelming them.
(i.e., http://www.cisco.com/warp/public/63/highcpu_processes.html#tcp_timer)
Especially if the remote routers are pushing a fair amount of traffic with process switching turned on the intfs (i.e., ACLs with the 'log' option on) or if you have stuff like SNMP polls from network mgmt software going.
Also...................
"Disconnectphase. When an LLC end station wishes
to terminate one of its existing connections, it sends
a disconnect (DISC) frame to the other end station,
which responds with UA. The same frame types are
defined for SDLC. With DLSW, these frames are reflected
between partners using the SSP messages
halt-dl (halt data link) and dl-halted (data link halted)
and the circuit is then disconnected. Another DLSW
disconnect scenario is the loss of a transport connection
due to intermediate router failure. When
a DLSw node detects such a failure, it performs a
local disconnect of all connected data links that
were using the failed transport connection."
from: http://www.research.ibm.com/journal/sj/343/gayek.pdf
**Hope this helps**
Based on your earlier statement...
"On branch office router we saw by the command "show dlsw ciscuits history detail", that the event before disconnect is
Event
WAN halt-dl
What does this mean? "
I'd look into the process utilization on the Branch routers

Dlsw - circuit problem

Hi. all
I have several routers with dlsw feature.
Routers works properly yesterday but not today.
Someone complained to me why sna communication be delayed today?
So i tried to check such as dlsw peer, circuit.
i found instatble of the Circuit.
circuit's uptime be reset...
How can i check this symtom..?
Regard.
John

Thank you for replying.
The Topology is below.
HOST HOST
| |
|
4006 Switch
|
| |
Router1 Router2
| |
ATM ATM
| |
Router3
|
L2 Switch
|
SNA G/W
There are dlsw peer between Router1 and Router 3 and
Router 2 and Router3.
The Router 3 was configured loadbalancing(circuit-count) for sna traffic.
Acually, i found some abnormal history by using "show dlsw circuit history detail".
469762913 0060.9436.d70a(04) 4848.2424.1212(04) 172.20.52.231
Created at : 10:59:11.230 KST Mon Dec 13 2004
Connected at : 10:59:11.314 KST Mon Dec 13 2004
Destroyed at : 11:46:50.699 KST Mon Dec 13 2004
Local Corr : 469762913 Remote Corr: 704643190
Bytes: 86335174/88147104 Info-frames: 106541/108372
XID-frames: 5/4 UInfo-frames: 0/0
Flags: Local created, Remote connected
Last events:
Current State Event Add. Info Next State
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN ifcm 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN halt-dl 0x0 HALT_PENDING
HALT_PENDING DLC DiscCnf 0x0 CLOSE_PEND
CLOSE_PEND DLC CloseStnCnf 0x0 DISCONNECTED

Flapping circuit question and loopback question...

Two questions)
1) If someone reset a pc or cable modem will that cause the circuit to flap (as shown below)?
054396: Oct 21 19:51:24.288 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/25, changed state to down
054397: Oct 21 19:51:25.289 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/25, changed state to down
054398: Oct 22 04:11:50.740 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/25, changed state to up
054399: Oct 22 04:11:51.776 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/25, changed state to up
054400: Oct 22 04:12:29.280 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/25, changed state to down
054401: Oct 22 04:12:30.308 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/25, changed state to down
2) Does this mean someone plugged a loopback adaptor into a switch port?
020561: Oct 20 02:21:12.212 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/12, changed state to up
020562: Oct 20 02:21:14.004 PDT: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on FastEthernet0/12.
020563: Oct 20 02:21:14.004 PDT: %PM-4-ERR_DISABLE: loopback error detected on Fa0/12, putting Fa0/12 in err-disable state
020564: Oct 20 02:21:16.048 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/12, changed state to down
020565: Oct 20 02:21:43.196 PDT: %PM-4-ERR_RECOVER: Attempting to recover from loopback err-disable state on Fa0/12
Thank you,

Thanks for your reply....why would a fe connection go up/down just suddenly then never again (as of yet)....could it be a slightly loose cable that got bumped or due to vibrations?
098422: Oct 24 00:50:15.227 PDT: %RTD-1-LINK_FLAP: FastEthernet0/1 link down/up 5 times per min
098424: Oct 24 00:50:25.225 PDT: %RTD-1-LINK_FLAP: FastEthernet0/1 link down/up 5 times per min
098425: Oct 24 00:50:30.303 PDT: %RTD-1-LINK_FLAP: FastEthernet0/1 link down/up 5 times per min
098426: Oct 24 00:52:37.483 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
098427: Oct 24 00:52:37.821 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
098428: Oct 24 00:52:41.693 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
098429: Oct 24 00:52:42.535 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
098430: Oct 24 00:52:44.640 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

=SNA/DLSw+ & Impact Question=

Hi all,
this is related to discussion:
http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dd82da4
I opened this new one since my question was answered.
Our Topology:
Server---L2 switch---L3 Dist switch---Firewall---L3 switch(Core)--Firewall--CLOUD--IBM host
The server would generate both IP and SNA traffic (port LU6.2). All media are ethernet. The L3 switches are DLSw+ capable. I don't know much about the firewalls and I don't have control in the cloud because its under a different administrator.
Questions:
1. if I would use DLSw+, I need to bridge the ethernet port of the L3 Dist switch connecting the Server side. But, the server's connection is part of a VLAN, so, in the config of L3 Dist Switch, I would need to bridge the VLAN to DLSw. Would this setup impact the original behaviour of my VLAN? The VLAN is a Switched VLAN interface routed to another VLANs also.
2. Is it possible to control the port that would be used where the DLSW+ would pass through? I think I would have problems w/ our Firewall which requires source-destination ports and IPs to pass traffic.
Any suggestions/opinions are very much welcome... thanks!!!
rodney

Hi,
if you are using vlan interfaces already than your configuration would look similar to this:
dlsw local-peer peer-id 10.10.10.1
dlsw remote-peer tcp 0 20.20.20.1
dlsw bridge-group 10
interface loopback 0
ip address 10.10.10.1 255.255.255.0
interface vlan 234
ip address ...
bridge-group 10
bridge 10 protocol vlan-bridge
that would allow you to bridge sna traffic into dlsw.
It assumes that 20.20.20.1 is the local peer configured on the partner router in front of the host.
The local peer tied to the loopback interface is just an example.
If you have i.e. more than one vlan you want to bridge than you can create multiple bridge-groups and you can configure multiple dlsw bridge-group statements. This way you bridge multiple vlans into dlsw but you dont bridge them together.
If you know the sap's you are using for sna, default is 4 as far as i know. Most commonly known are 4,8,12 than you can create an access list like this:
access-list 200 permit 0x0000 0x0d0d
and apply it to the bridge-group command on the interface.
interface vlan 234
bridge-group 10
bridge-group 10 input-sap-list 200
that allows only sap's 0,4,8,12 with and without the response bit set into the bridge group and effectively blocks all other traffic.
In respect to the tcp ports that dlsw is using over the WAN. Dlsw version 1, RFC1795, that is what cisco is using, opens always two tcp sessions at startup.
This router starts the connection, it opens a tcp connection on the destination port 2065, source port is a random port above 11000.
Now the receiving end is also opening a tcp session back to the first router. Destination port 2065, local, source port is a random port above 11000.
Next the dlsw capabilities exchange happens and the two peers exchange their information. Once they detected that they both are cisco devices and that they both support the usage of only one tcp session in both directions the one with the "numerically higher ip address" will drop its connection on the local tcp port 2065.
The remaining tcp connection is used for dlsw traffic in both directions.
this is described in detail in RFC1795, section 7.6.7.
thanks...
Matthias

SDLC - DLSW - EE(SNASW) question

I have very little background knowledge of DLSW or SNASwitching, but here goes...
I am currently trying to migrate an existing connection from SDLC -> DLSW ->token ring mainframe connection to SDLC -> DLSW -> SNASW EE. My EE connection from the cisco router to hte mainframe is up and active, but I am unable to get the DLSW connection to work. I have been able to get the Peers to CONNECT, but I do not have any DLSW circuits.
Remote Router
dlsw local-peer peer-id 192.168.105.84
dlsw remote-peer 0 tcp 10.248.3.36
dlsw remote-peer 0 tcp 192.168.105.46
dlsw remote-peer 0 tcp 192.168.105.47
interface Ethernet0/0
ip address 192.168.105.84 255.255.255.0
interface Serial0/0
no ip address
shutdown
interface BRI0/0
no ip address
shutdown
interface Serial1/0
description MPSM - MPS SDLC connection to MPS9 gateway
bandwidth 19200
no ip address
encapsulation sdlc
no keepalive
sdlc role primary
sdlc vmac 4534.0000.0900
sdlc address C1
sdlc xid C1 05310170
sdlc partner 4800.0000.0000 C1
sdlc dlsw C1
interface Serial1/1
description MPSM MT80MPS7 - IP80GG73
bandwidth 19200
no ip address
encapsulation sdlc
no keepalive
sdlc role primary
sdlc vmac 4534.0000.0700
sdlc address C1
sdlc xid C1 05310172
sdlc partner 4800.0000.0000 C1
sdlc dlsw C1
interface Serial1/2
description MPSM MT80MPS5 - IP80GG53
bandwidth 19200
no ip address
encapsulation sdlc
no keepalive
sdlc role primary
sdlc vmac 4534.0000.0500
sdlc address C1
sdlc xid C1 05310174
sdlc partner 4800.0000.0000 C1
sdlc dlsw C1
RTGRAMIHQMPSM01#sho dlsw peer
Peers:                state     pkts_rx   pkts_tx type drops ckts TCP   uptime
TCP 10.248.3.36     CONNECT      58648     59193 conf      0    0   0     2w6d
TCP 192.168.105.46 CONNECT    1085642   1212360 conf      0    2   0     2w6d
TCP 192.168.105.47 CONNECT      58492     58492 conf      0    0   0     2w6d
Total number of connected peers: 3
Total number of connections:     3
RTGRAMIHQMPSM01#sho dlsw circ
Index           local addr(lsap)    remote addr(dsap) state          uptime
1929380244      4534.0000.05c1(04) 4800.0000.0000(04) CONNECTED          2w6d
2969567635      4534.0000.07c1(04) 4800.0000.0000(04) CONNECTED          2w6d
Total number of circuits connected: 2
Data Center Router
source-bridge ring-group 336
dlsw local-peer peer-id 10.248.3.36
dlsw remote-peer 0 tcp 192.168.105.84
dlsw remote-peer 0 tcp 192.168.105.85
interface Loopback0
ip address 10.210.136.65 255.255.255.255
interface GigabitEthernet0/1
description VLAN526 to XWGRAMIDCFPIP01
ip address 10.248.3.36 255.255.255.248
duplex full
speed 100
media-type rj45
negotiation auto
interface FastEthernet0/2
no ip address
shutdown
duplex auto
speed auto
interface GigabitEthernet0/2
description VLAN529 to XWGRAMIDCFPIP02
ip address 10.248.3.44 255.255.255.248
duplex full
speed 100
media-type rj45
negotiation auto
interface GigabitEthernet0/3
no ip address
shutdown
duplex auto
speed auto
media-type rj45
negotiation auto
snasw pdlog information
snasw dlctrace buffer-size 10000
snasw cpname NETMPS.GRSNAS01
snasw dlus NETMPS.XD81
snasw port SNSWPORT hpr-ip GigabitEthernet0/1
snasw port DLSWPORT vdlc 336 mac 4800.0000.0000 conntype nohpr
snasw link SW01XD81 port SNSWPORT ip-dest 204.90.2.14
RTGRAMIDCSNAS01#sho dlsw peer
Peers:                state     pkts_rx   pkts_tx type drops ckts TCP   uptime
TCP 192.168.105.84 CONNECT      58652     58649 conf      0    0   0     2w6d
TCP 192.168.105.85 CONNECT      58578     58578 conf      0    0   0     2w6d
Total number of connected peers: 2
Total number of connections:     2
RTGRAMIDCSNAS01#sho dlsw circ
RTGRAMIDCSNAS01#
Like I said, I have little background knowledge about this connectivity. If there is additional information that I could provide, please let me know. Any help would be greatly appreciated.
Thanks,
Dave

To answer one of your questions, as far as I know, SNASw performance might not be same as that of HPR/IP

Dlsw+ problem with SNI connection

We have a cisco 1603 router using dlsw+ to peer with a Nortel ASN.
at the cisco end it is x21 connection from the FEP
at the Nortel end it is token ring to an OSA
when we try and start a JES node we get an IBM sense code 800A0000 and the session drops.
The sense code states the transmission was truncated by the receiving node
because the PIU (path information unit) was to large or there was no buffer space available
has anyone seen a similar problem ?
This link was working I am told there have been no changes to the routers, only thing I can think of is that the network reconverged and it is now taking a different path between the two sites. I am asking for trace routes and trying to check if that is right.
Am I going in the right direction ?

Apparently this is strictly a configuraiton problem on the host. There is nothing wrong with the Cisco or Nortel routers.
Please me explain to you the data flow. Assume that the FEP sends a packet to the 1603. (The following applies to a packet from the OSA to the FEP) If the packet is too large for the 1603 to handle, the 1603 will drop the packet. As a result, the SDLC link will go down. Otherwise, the 1603 adds a DLSw header (16 bytes I think), a TCP header (normally 20 bytes), and an IP header (20 bytes). The 1603 uses TCP to tranport the packet with TCP/IP header. Depending upon your TCP setting, TCP may segment the packets into a number of different segments. Then, TCP uses IP to deliver the segment(s) to the Nortel router. If the TCP segments are too big for any routers between the DLSw peer, the router may either fragment the TCP segments or send an ICMP message, according to RFC 1191, to the 1603. The ICMP causes the 1603 to lower the TCP segment size. If any routers between the DLSw peers do not support RFC1191, the routers will drop the TCP segment. This will cause TCP detecting a gap in TCP sequence number. Eventually, TCP will disconnect the virtual circuit, which cause the peer go down.
Once all the TCP segments for the orignal SNA packet arrive at the Nortel router, the TCP stack on the Nortel router assemble the original SNA packet and put in on the token ring interface.
From the description, it looks like that the SNA packet reaches destination VTAM. VTAM finds out that the PIU is too large. If there is any problem on the IP path, I expect to see either:
1. a disconnect on the LLC2 or SDLC circuit. In other words, a DLSw circuit disconnect
or
2. a DLSw peer disconnect
Please check the modtab and find out the max RU size inside the bind. Make sure both VTAMs can handle the RU size.

Dlsw using port channel

I have 2 dlsw router at head quater office, named dlswA and dlswB.
From branches router, dlswA is a primary peer and dlswB is a backup peer.
Both dlswA and B have 2 fast ethernet interfaces.
The current configuration of dlswA and dlswB are 1 port as IP port and other port as sna/bridge port.
With this configuration the problem is when SNA port at dlswA problem, then dlsw circuit will have the problem, because dlsw peer from branches still connected to dlswA.
if I configure 2 fast ethernet port become a port channel. And configure IP and bridge group at port channel interface (IP and SNA at the same interfaces), so when the port channel is down, then branches will connect to dlswB as a backup peer
Are the port channel configuration will solve the problem ? How about the stability of this configuration?

Thank Matthias for your reply.
Both of head end routers are on the same vlan and the host is using same mac address.
As far as i know if from branch have 2 active peer with cost setup, there will loops posibility because both head end routers are using ethernet with same vlan and same host mac address.
I test the port channel within my LAB using netbios, seem works as expected. when single port at port channel down, branch circuit still remain at dlswA router, when all port channel member down, the branch peering move to dlswB.
Here are the config:
hostname dlswA
dlsw local-peer peer-id 192.168.255.1 promiscuous
dlsw bridge-group 1
interface Port-channel10
ip address 192.168.255.1 255.255.255.248
bridge-group 1
interface FastEthernet0/0
no ip address
duplex auto
speed auto
channel-group 10
interface FastEthernet0/1
no ip address
duplex auto
speed auto
channel-group 10
end
hostname dlswB
dlsw local-peer peer-id 192.168.255.10 promiscuous
dlsw bridge-group 1
interface Port-channel11
ip address 192.168.255.10 255.255.255.248
bridge-group 1
interface FastEthernet0/0
no ip address
duplex auto
speed auto
channel-group 11
interface FastEthernet0/1
no ip address
duplex auto
speed auto
channel-group 11
end
Hostname Branch
dlsw local-peer peer-id 172.16.0.1
dlsw remote-peer 0 tcp 192.168.255.1
dlsw remote-peer 0 tcp 192.168.255.10 backup-peer 192.168.255.1 linger 0
dlsw bridge-group 1
interface Loopback0
ip address 172.16.0.1 255.255.255.255
interface FastEthernet0/1
no ip address
duplex auto
speed auto
bridge-group 1
But I'm not sure this scenario will work for sna application like ATM machine, and SNA SAA gateway.
Please kindly advised, Is there any alternatif ?

DLSW drop sporadically

Setup
6509 (IOS 12.1(13)E6) running standard DLSW ( i.e. non ethernet redundancy)over FastEthernet to 7513 (12.1(14)) connected to Mainframe over CIP2/IBM Channel.
1.
Our PC running LU6.2 over ethernet connected to the 6509 spordic loose thier connection due to the DLSW peer drops. (on the DLSW peer there is max 100 circuits)
2.
The 6509 have orther DSLW peers that run to other routers that are unaffected by the dropping peer.
3.
Likewise the 7513 that is the peer for the dropping DLSW connection has other peers that are unaffected.
4.
On a DLSW debug I see that the drop is caused due to failed DLSW keepalives.
5. As I found the CSCdw58350 I would appreciate some details how to determine if its the CSCdw58350 thats causing my problems ?? Or any other suggestions for the cause - thanks.
Regards
Gert Schaarup

Thanks
1. I will go for the IOS upgrade, but do I need to upgrade both ends of the dlsw peer ? (i.e. the 7513 with the CIP and the 6500 with the LU6.2 workstations)
2. After we moved some of the LU6.2 client to Token Ring (i.e. direct SNA to the host) the dlsw peer seems to stay up but we still see that dlsw circuits gets disconnected and shortly after reconnect without direct loss of LU6.2 data.
3. I do see some few half flow op and reset (like Half: 6/2 Reset 1/0) but could you please comment following output (taken 4 and 9 July when the peer is up, as the peer hasnt gone done since we moved some of the load) to see if these confirm that it is the bug that is the problem. - Thanks
07:54:01.231 PDT Fri Jul 4 2003
At the 7513 end:
CIP-Slot4#llc stat all
Maximum connections = 1200
Highest connections = 169
Current connections = 59
Connections rejected = 0
Connect requests = 5615
Connect responses = 0
Connect confirms = 5615
Connect indications = 0
Disconnect confirms = 207
Disconnect indications = 5128
Flow off terminated conn = 0
Session timeouts = 99
FRMRs sent = 1
FRMRs received = 1
SABMEs sent = 5632
SABMEs received = 0
DISCs sent = 542
DISCs received = 5027
UAs sent = 5027
UAs received = 5811
DMs sent = 0
DMs received = 10
IDLE connections = 0
Connection thresheld = 1200
Frames transmitted = 130903182
Transmit completes = 130903182
Frames received = 124105764
Flow offs sent = 43844
Flow ons sent = 43810
Flows (on/off) cancel = 180
Flow offs received = 0
Flow ons received = 0
CCB indications sent = 92883
CCB indications freed = 92883
Unexpected events = 36
Ack Timer Missed = 0
Frames ignored = 4
Data requests = 101195500
Data requests freed = 101193980
Aggregate data req qlen = 0
Maximum data req qlen = 0
Data indications = 87183015
Data indications freed = 87183015
Aggregate data ind qlen = -1457917659
Maximum data ind qlen = 87183015
Polls sent = 152722
Finals sent = 18591962
Polls rcvd = 18625036
Finals rcvd = 158403
RR polls sent = 152722
RNR polls sent = 0
REJ_polls sent = 0
RRs sent = 29607348
RRs received = 36878480
RNRs sent = 80011
RNR received = 27452
REJs sent = 1487
REJs received = 4178
Bad PDUs received = 0
Bad N(r)s received = 5
Bad N(s)s received = 1747
Out-of-seq N(s)s received = 38
Acknowledgements delayed = 81673676
Iframes transmitted = 101203134
Iframes retransmitted = 9115
Retries = 7507
Local busy entered = 96226
Local busy exited = 96226
Remote busy entered = 9737
Remote busy exited = 9429
Unexpec Ack = 0
Adapter registered = 4
SAPs registered = 1
CEPs registered = 59
Msgs to entity mgr = 31
Msgs to PSAP = 58712
Msgs to PCEP = 101206483
Msgs to DLU = 87346909
Invalid handles = 0
SAPs activated = 8
Deactivate SAP requests = 5
Deactivate SAP confirms = 5
SAPs reset by user = 2
SAPs reset by network = 0
SAP deact/reset completed = 7
SAPs deact/reset w/ CCBs = 2
SAPs frame drops = 0
Hash buckets used = 3439
Hash table collisions = 2181
Hash table lookups = 124174704
Hash table caparisons = 198849566
Hash table lookups failed = 58305
Longest collistion chain = 19
Receive erroneous frame = 0
DMA write operations = 130999946
DMA write completions = 130999946
DMA write errors = 0
DMA write waits = 0
DMA read notifications = 124534436
DMA read operations = 124534436
DMA read completions = 124534435
DMA read errors = 0
DMA reads discarded = 0
DMA reads discarded small = 0
DMA read chains freed = 0
Frames exceed MAX frameSZ = 0
Timer ticks (100ms) = 222075154
Timeouts = 6502680
Timers started = 275098246
Timers stopped = 268595506
T1 timers expired = 7607
Idle timers expired = 91521
T2 timers expired = 6403552
Longest timeout chain = 58
P/F timer started = 163700
P/F timer stopped = 158403
Ack timer started = 66234646
Ack timer stopped = 58411329
Busy timer started = 13354
Idle timer started = 145383718
T2 timer started = 63301341
T2 timer stopped = 63301340
Reject timer started = 1487
Reject timer stopped = 1589
LLC Stack locked = 363336715
LLC Stack delayed events = 101
LLC stack pending events = 0
LLC stack most pndng evnts= 1
LLC stack not locked.
15:17:44.199 PDT Wed Jul 9 2003
At the 7513 end:
CIP-Slot4#llc stat all
Maximum connections = 1200
Highest connections = 169
Current connections = 69
Connections rejected = 0
Connect requests = 10778
Connect responses = 0
Connect confirms = 10778
Connect indications = 0
Disconnect confirms = 301
Disconnect indications = 10216
Flow off terminated conn = 0
Session timeouts = 118
FRMRs sent = 1
FRMRs received = 1
SABMEs sent = 10815
SABMEs received = 0
DISCs sent = 628
DISCs received = 10096
UAs sent = 10096
UAs received = 11037
DMs sent = 0
DMs received = 12
IDLE connections = 0
Connection thresheld = 1200
Frames transmitted = 153147701
Transmit completes = 153147701
Frames received = 146574711
Flow offs sent = 52506
Flow ons sent = 52472
Flows (on/off) cancel = 198
Flow offs received = 0
Flow ons received = 0
CCB indications sent = 115314
CCB indications freed = 115314
Unexpected events = 103
Ack Timer Missed = 0
Frames ignored = 4
Data requests = 119159228
Data requests freed = 119157594
Aggregate data req qlen = 0
Maximum data req qlen = 0
Data indications = 102290655
Data indications freed = 102290655
Aggregate data ind qlen = -2074303823
Maximum data ind qlen = 102290655
Polls sent = 182235
Finals sent = 21206449
Polls rcvd = 21242583
Finals rcvd = 193195
RR polls sent = 182235
RNR polls sent = 0
REJ_polls sent = 0
RRs sent = 33862716
RRs received = 44225534
RNRs sent = 93378
RNR received = 30175
REJs sent = 2075
REJs received = 4686
Bad PDUs received = 0
Bad N(r)s received = 5
Bad N(s)s received = 2441
Out-of-seq N(s)s received = 69
Acknowledgements delayed = 95797452
Iframes transmitted = 119167992
Iframes retransmitted = 10275
Retries = 7696
Local busy entered = 108966
Local busy exited = 108966
Remote busy entered = 11023
Remote busy exited = 10715
Unexpec Ack = 0
Adapter registered = 4
SAPs registered = 1
CEPs registered = 69
Msgs to entity mgr = 35
Msgs to PSAP = 85729
Msgs to PCEP = 119180620
Msgs to DLU = 102514497
Invalid handles = 0
SAPs activated = 9
Deactivate SAP requests = 6
Deactivate SAP confirms = 6
SAPs reset by user = 2
SAPs reset by network = 0
SAP deact/reset completed = 8
SAPs deact/reset w/ CCBs = 2
SAPs frame drops = 0
Hash buckets used = 8529
Hash table collisions = 2283
Hash table lookups = 146676148
Hash table caparisons = 224807587
Hash table lookups failed = 80517
Longest collistion chain = 19
Receive erroneous frame = 0
DMA write operations = 153281642
DMA write completions = 153281642
DMA write errors = 0
DMA write waits = 0
DMA read notifications = 147050284
DMA read operations = 147050284
DMA read completions = 147050284
DMA read errors = 0
DMA reads discarded = 0
DMA reads discarded small = 0
DMA read chains freed = 0
Frames exceed MAX frameSZ = 0
Timer ticks (100ms) = 226558498
Timeouts = 7361429
Timers started = 324359028
Timers stopped = 316997530
T1 timers expired = 7815
Idle timers expired = 109334
T2 timers expired = 7244280
Longest timeout chain = 58
P/F timer started = 203551
P/F timer stopped = 193195
Ack timer started = 78970086
Ack timer stopped = 68892536
Busy timer started = 14376
Idle timer started = 170688653
T2 timer started = 74480287
T2 timer stopped = 74480287
Reject timer started = 2075
Reject timer stopped = 2229
LLC Stack locked = 426985053
LLC Stack delayed events = 120
LLC stack pending events = 0
LLC stack most pndng evnts= 1
LLC stack not locked.

Problem establishing SNA session over DLSw link

We are experiencing sporadic problems establishing an SNA session over a DLSw tunnel. The session is between a Tandem host and a CICS region on OS/390. A Cisco 7500 router performs one end of the DLSw link; that same router is channel-attached to the OS/390 mainframe using CIP and uses CSNA for SNA traffic.
The connection is initiated by the SNA software on the Tandem box, but it rarely works on the first attempt. The session goes into a pending state and has to be cancelled and re-tried. This has to be repeated until such time it is successful. Once the session is started it works without problem.
At the point of attempting to start the session all the components are in the 'correct' state, i.e.
-DLSw tunnel is connected
-Host PU is in 'connectable' (CONCT) state
-Host XCA defining CIP SNA and virtual lines are active
No action needs to be taken on the OS/390 end of the link (or anywhere else for that matter) between start attempts on Tandem.
From device traces on OS/390 my suspicion is that the session requests are not actually getting to VTAM on OS/390 for some reason. DLSw traces on 7500 appear the same in both case of success or fail of session start.
Has anyone experienced this, or know of problems in this area that may explain what we are seeing?
Thanks.
Keith

Mary,
thanks for the extra information.
I would advice at this point the following:
Open a case with the Tac. Provide the information you have at that point and agree on a action plan, i.e. what to look at what trace to take, when you are able to recreate the problem.
What i can see from the documents you attaches is the following:
I only see sna circuits in the dlsw circuit history.
In you show dlsw reach there are quite some netbios names aswell and a large number of mac addresses learned from the remote peer.
You may want to discuss some filter options with the tac to make sure we cut down on the size of the reach cache and to make sure we advertise only those mac addresses which are really needed.
From the show version, 12.1(17) should be fine for dlsw in the way you described it.
From the show dlsw circuit history detail we have a couple of times that circuits are disconnecting.
Most of the time these circuits are up for a long time and they get the following sequence before terminating:
Index local addr(lsap) remote addr(dsap) remote peer
1157627904 4000.0410.0001(08) 0800.8e00.9708(08) 10.19.2.124
Created at : 12:02:55.115 GMT Mon Nov 29 2004
Connected at : 12:02:55.447 GMT Mon Nov 29 2004
Destroyed at : 22:04:01.158 GMT Wed Dec 1 2004
Local Corr : 1157627904 Remote Corr: 3321888773
Bytes: 140092/145133 Info-frames: 1748/2327
XID-frames: 1/2 UInfo-frames: 0/0
Flags: Remote created, Local connected
Last events:
Current State Event Add. Info Next State
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED DLC DataInd 0x0 CONNECTED
CONNECTED ADM WanFailure 0x0 HALT_NOACK_PEND
HALT_NOACK_PEND DLC DiscCnf 0x0 CLOSE_PEND
CLOSE_PEND DLC CloseStnCnf 0x0 DISCONNECTED
this circuit was up for more than a month and the reason for disconnection was ADM WAN failure which means the dlsw peer went away at some point.
Some other circuits get these sequence:
CONNECTED WAN infoframe 0x0 CONNECTED
CONNECTED WAN halt-dl 0x0 HALT_PENDING
WAN halt-dl means the other end tells us to disconnect. No information on this end why. Most of the time it is a legitimate disconnect. but you would need to look at the dlsw peer to get information who terminated the session.
I dont see anything specific in a sense that a circuit did not go to connect at all. In the information you supplied.
Again my advice open a case with the tac and then you can work the issue to completion.
thanks...
Matthias

DLSw over WAN to Ethernet to Token Ring

Currently, a 3745 in Portland is token ring attached and SNA traffic travels that ring to an IBM 2210 router.
That IBM router connects to a second token ring, which a Cisco 2613 is also connected to. From there
the traffic travels DLSw over the WAN (3 T1s, Multilink PPP bundle) to a 7507 in Cincinnati where a 3745
is connected via serial.
3745-TIC<->TR<->2210<->TR<->2613(DLSw)<->WAN<->(DLSw)7507<->LIC-3745
The 7507 serial port is configured as follows:
interface Serial4/3
description 3745 LIC connection for Fred Meyer DLSW
mtu 4400
no ip address
encapsulation sdlc
no ip mroute-cache
no keepalive
serial restart-delay 0
clockrate 125000
sdlc vmac 4000.3745.0000
sdlc N1 35200
sdlc address 29 seconly
sdlc partner 4000.0910.0008 29
sdlc dlsw 29
The 2613 has an ethernet. The folks in Portland want to move off of the TR and on to Ethernet.
They will replace the IBM router with one that has both TR and ENET.
If we move to the ethernet, the result will be:
3745-TIC<->TR<->2210<->ENET<->2613(DLSw)<->WAN<->(DLSw)7507<->LIC-3745
Should I change the MTU size on the serial port to 1500 (Ethernet)?
Are there any changes that should occur on the 3745/Mainframe side?
Do you see any other issues?

You cannot increase the MTU for ethernet larger than 1500 bytes because 802.3 (the standard for ethernet) does not allow that.
You may see issues. The problem is that both 3745 does not know the existance of the ethernet. If either 3745 sends a packet larger than 1500 bytes, the 2613 will drop the packet. (I am not an expert on 2210, I do not know if the 2210 is smart enough to segment the SNA packet into 2. I doubt it does, but please confirm it with IBM.) This causes the remote FEP detects a gap in SDLC, LLC2, or TH sequence number. No matter which layer detects the problem. The end result is still the same. The DLSw circuit will be disconnected.
There are several suggestions to your problem:
1. Make sure the both FEP will not send any PIU larger than 1500 bytes. This can be done either on the NCP gen or modtab. Checking the modtab is tough because your system programmers have to know all application running over the link. Then, they have to check the corresponding modtab entry for the applications.
2. run DLSw between 7507 to IBM 2210
3. directly connect the 2613 to the TIC (3745)

Capacity Planning Question

I need to design a solution to replace some FEPs by Cisco routers with CIP interfaces. The main aspect of this job is choose the appropriate number of routers and the capabilities to support SNA sessions provided by FEPs. I know that the one of the key aspect is the rate and size of transactions.
I would like to know how I can get this informations from mainframe. There is any design guide explain how to define the number and configuration of routers ?
Best Regards

Only the transaction rate is revelant and important.
DLSw only keeps track of the number of PU (i.e. number of LLC2 connection and DLSw circuit). It does not keep track of the number of LU. In other words, DLSw uses the same router RP/CPU resource in the following cases:
1. 100 PUs with 2500 LUs and no transaction
2. 100 PUs with 100 LUs and no transaction
The only process that is PU related and consumes router RP/CPU resource is LLC2 keepalive. The router has to Receiver Readys (RRs), which is more or less LLC2 keepalive, when the PU is idle for the period of LLC2 idle-time. The default value for LLC2 idle-time is 10 second. If the router has a lot of PUs on it and consumes a lot of CPU/RP cycle on the process "LLC2 timer", just increase the LLC2 timer to 60 second.
There is no rule/formula between transaction rate and CPU cycle. The TME (Techincal Marketing Engineer) just pump traffic into different routers and record the CPU utilization. As the router uses the same amount of CPU/RP resource on packets with 40 bytes and packets with 1000 bytes, the DLSw white paper below only shows transaction rate vs different router platforms:
http://www.cisco.com/en/US/partner/products/sw/iworksw/ps2474/products_white_paper09186a008007ce75.shtml

Sh dlsw reachability searching

Hello,
I am trying to configure dlsw between two remote networks and it is very very slow. I wonder why the router is not founding some local macs. Could you please give me some advices? This is the show commands output
sh dlsw reach
DLSw Local MAC address reachability cache list
Mac Addr         status     Loc.    port                 rif
0006.299c.1cb9   SEARCHING LOCAL
0040.cd53.c834   SEARCHING LOCAL
0040.cd53.c8e4   SEARCHING LOCAL
0064.99c6.5903   FOUND      LOCAL   TBridge-001    --no rif--
1000.5a58.05f3   SEARCHING LOCAL
1000.d000.1244   SEARCHING LOCAL
1000.d000.1261   SEARCHING LOCAL
1000.d000.6800   SEARCHING LOCAL
1000.d000.a809   SEARCHING LOCAL
1000.d07f.04aa   SEARCHING LOCAL
1000.d07f.90bc   SEARCHING LOCAL
1000.d07f.b5b9   SEARCHING LOCAL
4200.0099.8984   SEARCHING LOCAL
4200.24ff.66c3   FOUND      LOCAL   TBridge-001    --no rif--
sh dlsw circuits
Index           local addr(lsap)    remote addr(dsap) state          uptime
2617245708      0090.d6a6.6933(04) 4200.0099.8980(04) CONNECTED      03:16:46
Total number of circuits connected: 1
sh dlsw peer
Peers:                state     pkts_rx   pkts_tx type drops ckts TCP   uptime
TCP 10.10.218.241   CONNECT     327135     59912 conf      0    1   0 03:19:36
Total number of connected peers: 1
Total number of connections:     1
interface Vlan229
description LINEA ADMINISTRATIVA
ip address 10.60.229.240 255.255.255.0 secondary
ip address 10.60.2.240 255.255.255.0
no ip redirects
bridge-group 1
llc2 ack-max 255
llc2 local-window 2
llc2 t1-time 10000
interface Vlan232
description LINEA SISTEMA ESPEJO AS/400 CONTINGENCIA
ip address 10.60.232.240 255.255.255.0
ip policy route-map FRAGMENT
bridge-group 1
end
Thanks!!

No, limit of 4 is a software structure limitation.

Load Balance & Fault Tolerance

I need do design a solution for load balance the DLSw traffic between 4 central routers and, if this 4 routers fail (oe wan fail) all peers and circuits need to be restablished on other site with other 4 routers.
To balance the traffic I will use the DLSw circuit count. To provide fault tolerance between sites I thinking to use backup peer.
My question is, "circuit count" will work togheter with "backup peer" ?
Thank´s in advance.

Only one backup dlsw peer is allowed. I cut and paste the following when I try to define more than one backup peer:
c3-2500(config)#dlsw remote-peer 0 tcp 2.2.2.2
c3-2500(config)#dlsw remote-peer 0 tcp 3.3.3.3 backup-peer 2.2.2.2
c3-2500(config)#dlsw remote-peer 0 tcp 4.4.4.4 backup-peer 2.2.2.2
%Primary peer already has backup defined
There are a number of approaches:
1. Remote routers have 8 peer connections. The cost for A, B, C, and D are lower than that of E, F, G, and H. Normally, the circuits are distributed among A, B, C, and D. Even one or more than one of A, B, C, and D goes down, the rest will take the load. If all A, B, C, and D goes down, E, F, G, and H will take all the circuits.
2. Slightly different than 1. Instead of making E, F, G, and H are permanent DLSw peer connection, make E is a backup peer for A, F is a backup peer for B, and so on.
3. Just another idea. Have you considered SNASw using HPR/IP? It may take you a while to set up on the host. However, this is the way to go because IBM has stopped selling 3746/3745. All SNI link will eventually go to HPR/IP.

Source bridge error

I have a simple DLSw config that doesn't seem to be working. The peers are up, but when the "debug source bridge" command is issued the following appears on the screen...
Error only happens on R2
Oct 18 09:58:22 EDT: SRB0: explorer enqueued (srn 116 bn 2 trn 400)
Oct 18 09:58:22 EDT: DLSW: explorer duplicate ring violation C630.1902.0740
Oct 18 09:58:22 EDT: SRB0: duplicate ring violation, s: 8020.00d7.91b3 d: ffff.ffff.ffff rif: C630.1902.0740
Oct 18 09:58:22 EDT: SRB0: explorer enqueued (srn 116 bn 2 trn 400)
Oct 18 09:58:22 EDT: DLSW: explorer duplicate ring violation C630.1902.0740
Oct 18 09:58:22 EDT: SRB0: duplicate ring violation, s: 8020.00d7.91b3 d: ffff.ffff.ffff rif: C630.1902.0740
My config is very straight forwared
R1
source-bridge ring-group 400
dlsw local-peer peer-id x.x.x.1 promiscuous
interface Loopback0
ip address x.x.x.1
interface TokenRing0/0
source-bridge 1 1 400
source-bridge spanning
R2
source-bridge ring-group 400
dlsw local-peer peer-id y.y.y.1
dlsw remote-peer 0 tcp x.x.x.1
dlsw bridge-group 5
interface Loopback0
ip address y.y.y.1
interface Ethernet0/0
bridge-group 5
interface TokenRing0/0
source-bridge 116 2 400
source-bridge spanning
bridge 5 protocol ieee
The error only happens once the source-bridge spanning command is issued on the Token-Ring interface (on R2). From what I understand you need it in a DLSw setup to forward the single route explorer frames.
The client cannot seem to bring up a circuit so I am not sure if there is a configuration problem or not. The debug looks like a broadcast to me...so perhaps there is something wrong with their local config. I guess I just want an answer to what the debug really means...because I cannot find anything on it...Cisco or the Net.
Thanks...
Brett

Brett,
the error message is making you aware of the fact that a certain frame is due to be forwarded onto a ring number it already has an entry for in its rif.
However in certain situations this is also seen in working environments due to the inner working of the cisco source bridging code.
Are you sure that there is no duplicate source-bridge path? If yes, ignore the message.
If the error message is only seen when you use source-bridge spanning to forward single route explorers on the tokenring than you can do the following. Assuming we are talking about sna in this example:
dlsw allroute-sna
in this case dlsw will forward explorers outbound towards the tokenring as allroute explorers for sna on a tokenring interface. The default is as single-route explorer.
However inbound into the router it is purely dependend on what the end system does. If the end system, the client, starts with a single route explorer you still need source-bridge spanning on the interface, otherwise dlsw will not see the frame.
How does the setup physcially look like?
Is your client on the tokenring or on the ethernet interface attached to dlsw?
I understand from your description that the client is behind R2, so when you issue a show dlsw reachability
can you see the client?
debug dlsw reach verbose
should give you an idea if the client tries to start a session and with what dmac.
Is dlsw trying to start a circuit? I.e. in what state is the circuit if there is one?
show dlsw circuit history detail can give you some more ideas what happened, if the router tries to start a circuit and it is not successfull. However you need to know a great deal of dlsw to fully understand that output.
A sniffer on the tokenring will certainly show if the client tries to start a session and with what dmac.
There are lots of possibilities why this might not work, so it is most likely the best to open a case with the tac and work the issue till conclusion.
thanks...
Matthias

DLSw circuit question

Similar Messages

Maybe you are looking for