Guest

IBM Networking

Troubleshooting DLSw IP Connectivity Issues

Cisco - Troubleshooting DLSw IP Connectivity Issues

Document ID: 17562

Updated: Jan 28, 2008

   Print

Introduction

This document enables you to troubleshoot IP connectivity issues between data-link switching (DLSw) peers.

Prerequisites

Requirements

Readers of this document should have knowledge of basic concepts of IP and TCP.

Components Used

This document is not restricted to specific software or hardware versions, but Cisco IOS?? software with the IBM Feature Set is required to run DLSw in Cisco Routers.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

IP Connectivity

One of the ways to determine if you have IP connectivity is to issue an extended ping (refer to IP Commands, and scroll down to the ping (privileged) section. With extended ping, you specify the target IP address as the remote DLSw peer address and specify the source as the local peer IP address. If this fails, you probably have an IP routing problem; either the local peer does not have a route to the remote peer, or the remote peer does not have a route to the local peer. To troubleshoot IP routing, refer to the IP Routing section of the Technology Support page.

After you verify that IP connectivity is good and that extended ping works, your next step is to issue the debug dlsw peer command.

caution Caution: The debug dlsw peer command can cause severe performance degradation, especially when performed on a router that is configured such that multiple peers come up simultaneously. Before you attempt to issue this debug command, refer to Important Information on Debug Commands.

Issue the??debug dlsw peer command to activate the peers between two Cisco routers:

DLSw: passive open 5.5.5.1(11010) -> 2065
DLSw: action_b(): opening write pipe for peer 5.5.5.1(2065)
DLSw: peer 5.5.5.1(2065), old state DISCONN, new state CAP_EXG
DLSw: CapExId Msg sent to peer 5.5.5.1(2065)
DLSw: Recv CapExId Msg from peer 5.5.5.1(2065)
DLSw: Pos CapExResp sent to peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
DLSw: Recv CapExPosRsp Msg from peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
shSw: peer 5.5.5.1(2065), old state CAP_EXG, new state CONNECT
DLSw: peer_act_on_capabilities() for peer 5.5.5.1(2065)
DLSw: action_f(): for peer 5.5.5.1(2065)
DLSw: closing read pipe tcp connection for peer 5.5.5.1(2065)

The router starts the peer, opens a TCP session with the other router, and starts to exchange capabilities. After a positive exchange of capabilities, the peer connects. In contrast to remote source-route bridging (RSRB), DLSw does not move the peer to a closed state if there is no traffic; the peers always stay connected. If the peers remain disconnected, you can issue the debug dlsw?? peer??and debug ip tcp transactions commands to determine why a connection was not opened.

If the peers connect intermittently, determine if there is a firewall between the peers. If so, refer to Configuring Data-Link Switching and Network Address Translation. If you have a Frame Relay connection, ensure that you are not exceeding the Committed Information Rate (CIR) and dropping TCP packets as a result.

These output examples illustrate some of the methods discussed in this document:

dlswts2.gif

Router Configurations

source-bridge ring-group 2
dlsw local-peer peer-id 172.17.240.35
dlsw remote-peer 0 tcp 172.17.140.17
!
interface Loopback0
ip address 172.17.240.35 255.255.255.0
source-bridge ring-group 2
dlsw local-peer peer-id 172.17.140.17
dlsw remote-peer 0 tcp 172.17.240.35
!
interface Loopback0
ip address 172.17.140.17 255.255.255.0

Before the DLSw peers will exchange their capabilities and establish a session, TCP/IP must establish a route between the TCP/IP peer addresses.

This TCP/IP route can be verified if you issue the show ip route ip-address and if you do an extended ping between the DLSw peer addresses.

If you suspect a problem with the IP route, then let the extended ping run for a few minutes and check that it remains constant.

router2# show ip route 172.17.140.17

Routing entry for 172.17.140.0/24
 Known via "connected", distance 0,
 metric 0 (connected, via interface)
 Routing Descriptor Blocks
 * directly connected, via Ethernet1/0
   Route metric is 0,
   traffic share count is 1
router1# show ip route 172.17.240.35

Routing entry for 172.17.240.0/24
 Known via "connected", distance 0,
 metric 0 (connected, via interface)
 Routing Descriptor Blocks
 * directly connected, via Ethernet1/0
   Route metric is 0,
   traffic share count is 1
router2# ping

Protocol [ip]:
Target IP address: 172.17.140.17
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.17.240.35
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record,
 Timestamp, Verbose [none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
 to 172.17.140.17, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 1/3/4 ms
router1# ping

Protocol [ip]:
Target IP address: 172.17.240.35
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.17.140.17
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record,
 Timestamp, Verbose [none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
 to 172.17.240.35, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 1/3/4 ms

Issue the debug ip tcp transactions command to check how TCP/IP knows the route between the DLSw peer addresses.

router2# debug ip tcp transactions

TCP special debugging is on
c1603r
Mar 9 12:02:03.472: TCB02132106 created
Mar 9 12:02:03.472: TCP0: state was LISTEN -> SYNRCVD
                    [1998 -> 172.17.140.17(11001)]
Mar 9 12:02:03.476: TCP0: Connection to 172.17.140.17:11011,
                    received MSS 1460, MSS is 516
Mar 9 12:02:03.476: TCP: sending SYN, seq 1358476218, ack 117857339
Mar 9 12:02:03.480: TCP0: Connection to 172.17.140.17:11001,
                    advertising MSS 1460
Mar 9 12:02:09.436: TCP0: state was SYNRCVD -> CLOSED
                    [1998 -> 172.17.140.17(11001)]
Mar 9 12:02:09.440: TCB 0x2132106 destroyed
Mar 9 12:02:15.471: TCB0214088C created

If a valid route exists and extended pings are successful, but the DLSw peer fails to reach the CONNECT state, then check that a firewall (such as an access list on DLSw port number 2065) is not the cause of the problem.

router2# show access-lists

Extended IP access list 101
  deny ip any any log-input
  deny tcp host 172.17.240.35 172.17.140.0 0.0.0.255 eq 2065 established
  permit ip any any

Check that Network Address Translation (NAT) is not preventing the connection of the DLSw peer.

router2# show ip nat tran

Pro  Inside global   Inside local   Outside local   Outside global
---  172.17.240.200  10.1.1.1       ---             ---
---  172.17.240.201  10.2.1.201     ---             ---
---  172.17.240.202  10.2.1.202     ---             ---

After TCP/IP has established a route between the DLSw peer addresses, they will exchange capabilities (via capabilities exchange packets), and they will establish a peer connection (they go into CONNECT state).

router1# show dls capabilities

  DLSw: Capabilities for peer 172.17.140.17(2065)
   vendor id (OUI)         :'00C' (cisco)
   version number          : 1
   release number          : 0
   init pacing window      : 20
   unsupported saps        : none
   num of tcp sessions     : 1
   loop prevent support    : no
   icanreach mac-exclusive : no
   icanreach netbios-excl  : no
   reachable mac addresses : none
   reachable netbios names : none
   cisco version number    : 1
   peer group number       : 0
   border peer capable     : no
   peer cost               : 3
   biu-segment configured  : no
   local-ack configured    : yes
   priority configured     : no
   version string          :
Cisco Internetwork Operating System Software
IOS (tm) RSP Software (RSP-JSV-M), Version 12.1(1),
RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Tue 14-Mar-00 23:16 by cmong

Issue the show dlsw peer command to check the number of drops on the DLSw peer. If you see a count that either initially or rapidly increases, then this could indicate that you have congestion on the TCP queue depth of the DLSw peer.

For DLSw circuits, there is an internal flow control algorithm that will start to close the windows on various priority traffic, based on how congested the TCP queue depth becomes. If you start to experience congestion problems, then issue the show dlsw peer command to check the queue depth.

Note: Remember that the default queue depth value is 200. Any value in this field above 50 (25 percent) will start to cause flow control window sizes to be reduced.

router2# show dlsw peers

Peers:             state    pkts rx  pkts tx  type  drops  ckts  TCP  uptime
TCP 172.17.140.17  CONNECT  11       11             0      0     51   0:00:04:42

The CONNECT state is what you want to see. The DLSw peer in CONNECT state indicates that the peer has activated successfully.

Related Information

Updated: Jan 28, 2008
Document ID: 17562