Guest

IP Tunneling

Configuring STUN SDLC over Frame Relay

Document ID: 12380



Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Configure
      Network Diagram
      Configurations
Verify
Troubleshoot
      Troubleshooting Commands
      Sample show and debug Output
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This is a sample configuration for Serial Tunnel (STUN) Synchronous Data Link Control (SDLC) over Frame Relay. The relevant states in the show stun command output and state changes in the debug command output are highlighted in the Sample show and debug Output section of this document.

Note: In the Sample show and debug Output section, the SDLC broadcast address FF is activated first, followed by the end user’s C1 address. Although the debug stun packet and debug stun event commands should not cause excessive CPU utilization, the logging buffered command is used to copy the output to the log file.

When you are troubleshooting, remember that many STUN SDLC issues are caused either by incorrect Nonreturn to Zero (NRZ) or Nonreturn to Zero Inverted (NRZI) encoding, or by an SDLC address mismatch.

Note: The default encoding is NRZ. To change the encoding to NRZI, issue the NRZI-encoding command under the serial interface.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on Cisco IOSĀ® Software Release 12.1(5).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Configure

In this section, you are presented with the information to configure the features that are described in this document.

Note: To find additional information on the commands that are used in this document, use the Command Lookup Tool ( registered customers only) .

Network Diagram

This document uses this network setup:

stunframesdlcl1.gif

Configurations

This document uses these configurations:

Kilcot

Building configuration...

 version 12.1
 service timestamps debug datetime msec
 !
 hostname kilcot
 !
 !
 stun peer-name 100.1.1.1
 stun protocol-group 5 sdlc
 stun remote-peer-keepalive
 !
 !
 interface Loopback0
  ip address 100.1.1.1 255.0.0.0
 !
 interface Serial0/0
  ip address 10.1.1.1 255.0.0.0
  encapsulation frame-relay
  no ip mroute-cache
  frame-relay interface-dlci 16
  frame-relay lmi-type ansi
 !
 interface Serial1/4
  no ip address
  encapsulation stun
  load-interval 30
  clockrate 64000
  stun group 5
  stun sdlc-role secondary
  sdlc address C1
  stun route address C1 tcp 200.2.2.2
  stun route address FF tcp 200.2.2.2
 !
 !
 router rip
 network 10.0.0.0
 network 100.0.0.0
 !
 !
end

Party

Building configuration...

 version 12.1
 service timestamps debug datetime msec
 !
 hostname party
 !
 !
 stun peer-name 200.2.2.2
 stun protocol-group 5 sdlc
 stun remote-peer-keepalive
 !
 !
 interface Loopback0
  ip address 200.2.2.2 255.255.255.0
 !
 interface Serial0
  no ip address
  encapsulation stun
  load-interval 30
  clockrate 64000
  stun group 5
  stun sdlc-role primary
  sdlc address C1
  stun route address C1 tcp 100.1.1.1
  stun route address FF tcp 100.1.1.1
 !
 interface Serial1
  ip address 10.1.1.2 255.0.0.0
  encapsulation frame-relay IETF
  no ip mroute-cache
  frame-relay interface-dlci 17
  frame-relay lmi-type ansi
 !
 !
 router rip
 network 10.0.0.0
 network 200.2.2.0
 !
end

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

This section provides information that you can use to troubleshoot your configuration.

Troubleshooting Commands

Certain show commands are supported by the Output Interpreter Tool ( registered customers only) , which allows you to view an analysis of show command output.

Note: Before you issue any debug commands, refer to Important Information on Debug Commands.

  • show stun

  • debug stun packet

  • debug stun event

Sample show and debug Output

For an explanation of the debug command output shown in this section, refer to the debug stun packet section of Debugging SDLC.

kilcot# show stun

This peer: 100.1.1.1

 *Serial1/4  (group 5 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
C1     TCP 200.2.2.2        open               35        39         0
FF     TCP 200.2.2.2        open                6         4         0

party# show stun

This peer: 200.2.2.2

 *Serial0  (group 5 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
C1     TCP 100.1.1.1        open               10         5         0
FF     TCP 100.1.1.1        open                4         7         0

The debug stun packet and debug stun event command output has been copied to the log file. Use this information to interpret the debug command output:

  • Serial Data Incoming (SDI)—Packets that are received from the SDLC interface.

  • Network Data Incoming (NDI)—Packets that are de-encapsulated from the WAN.

kilcot# show log

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 813 messages logged
    Trap logging: level informational, 46 message lines logged

 Log Buffer (100000 bytes):

 Dec 27 11:12:05.465: %STUN-6-PASSIVEOPEN: passive open 200.2.2.2(11027) -> 1994
 Dec 27 11:12:05.485: %STUN-6-OPENED: PHDR: peer (FF[5])200.2.2.2/1994 opened,
                      [previous state closed]
 Dec 27 11:12:05.485: STUN: Change state for peer (FF[5])200.2.2.2/1994
                      (closed->open)
 Dec 27 11:12:05.485: STUN sdlc: 00:13:07 Serial1/4 NDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.493: STUN sdlc: 00:00:00 Serial1/4 SDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.577: STUN sdlc: 00:00:00 Serial1/4 NDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.609: STUN sdlc: 00:00:00 Serial1/4 SDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.733: STUN sdlc: 00:00:00 Serial1/4 NDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.761: STUN sdlc: 00:00:00 Serial1/4 SDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.885: STUN sdlc: 00:00:00 Serial1/4 NDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:05.917: STUN sdlc: 00:00:00 Serial1/4 SDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:06.037: STUN sdlc: 00:00:00 Serial1/4 NDI: (0FF/008) U: XID PF:1
 Dec 27 11:12:07.049: STUN sdlc: 00:00:01 Serial1/4 SDI: (0C1/008) U: SNRM PF:1
 Dec 27 11:12:07.053: STUN: Change state for peer (C1[5])200.2.2.2/1994
                      (closed->opening)
 Dec 27 11:12:07.053: STUN: Change state for peer (C1[5])200.2.2.2/1994
                      (opening->open wait)
 Dec 27 11:12:07.053: %STUN-6-OPENING: CONN: opening peer (C1[5])200.2.2.2/1994, 3
 Dec 27 11:12:07.081: %STUN-6-OPENED: CONN: peer (C1[5])200.2.2.2/1994 opened,
                      [previous state open wait]
 Dec 27 11:12:07.081: STUN: Change state for peer (C1[5])200.2.2.2/1994
                      (open wait->open)
 Dec 27 11:12:10.049: STUN sdlc: 00:00:03 Serial1/4 SDI: (0C1/008) U: SNRM PF:1
 Dec 27 11:12:10.089: STUN sdlc: 00:00:00 Serial1/4 NDI: (0C1/008) U: UA PF:1
 Dec 27 11:12:10.101: STUN sdlc: 00:00:00 Serial1/4 SDI: (0C1/008) S: RR PF:1 NR:000
 Dec 27 11:12:10.189: STUN sdlc: 00:00:00 Serial1/4 NDI: (0C1/008) I PF:1 NR:000
                      NS:000
 Dec 27 11:12:10.229: STUN sdlc: 00:00:00 Serial1/4 SDI: (0C1/008) I PF:0 NR:001
                      NS:000

party# show log

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 1155 messages logged
    Trap logging: level informational, 67 message lines logged

Log Buffer (100000 bytes):

Dec 27 11:12:05.422: STUN sdlc: 00:13:05 Serial0 SDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.422: STUN: Change state for peer (FF[5])100.1.1.1/1994
                     (closed->opening)
Dec 27 11:12:05.422: STUN: Change state for peer (FF[5])100.1.1.1/1994
                     (opening->open wait)
Dec 27 11:12:05.422: %STUN-6-OPENING: CONN: opening peer (FF[5])100.1.1.1/1994, 3
Dec 27 11:12:05.454: %STUN-6-OPENED: CONN: peer (FF[5])100.1.1.1/1994 opened,
                     [previous state open wait]
Dec 27 11:12:05.454: STUN: Change state for peer (FF[5])100.1.1.1/1994
                     (open wait->open)
Dec 27 11:12:05.510: STUN sdlc: 00:00:00 Serial0 NDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.538: STUN sdlc: 00:00:00 Serial0 SDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.650: STUN sdlc: 00:00:00 Serial0 NDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.690: STUN sdlc: 00:00:00 Serial0 SDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.802: STUN sdlc: 00:00:00 Serial0 NDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.846: STUN sdlc: 00:00:00 Serial0 SDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.958: STUN sdlc: 00:00:00 Serial0 NDI: (0FF/008) U: XID PF:1
Dec 27 11:12:05.998: STUN sdlc: 00:00:00 Serial0 SDI: (0FF/008) U: XID PF:1
Dec 27 11:12:07.094: %STUN-6-PASSIVEOPEN: passive open 100.1.1.1(11001) -> 1994
Dec 27 11:12:07.114: %STUN-6-OPENED: PHDR: peer (C1[5])100.1.1.1/1994 opened,
                     [previous state closed]
Dec 27 11:12:07.114: STUN: Change state for peer (C1[5])100.1.1.1/1994
                     (closed->open)
Dec 27 11:12:07.114: STUN sdlc: 00:00:01 Serial0 NDI: (0C1/008) U: SNRM PF:1
Dec 27 11:12:10.066: STUN sdlc: 00:00:02 Serial0 NDI: (0C1/008) U: SNRM PF:1
Dec 27 11:12:10.070: STUN sdlc: 00:00:00 Serial0 SDI: (0C1/008) U: UA PF:1
Dec 27 11:12:10.118: STUN sdlc: 00:00:00 Serial0 NDI: (0C1/008) S: RR PF:1 NR:000
Dec 27 11:12:10.138: STUN sdlc: 00:00:00 Serial0 SDI: (0C1/008) I PF:1 NR:000
                     NS:000
Dec 27 11:12:10.270: STUN sdlc: 00:00:00 Serial0 NDI: (0C1/008) I PF:0 NR:001
                     NS:000
Dec 27 11:12:10.278: STUN sdlc: 00:00:00 Serial0 NDI: (0C1/008) I PF:1 NR:001
                     NS:001

NetPro Discussion Forums - Featured Conversations

Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology.
NetPro Discussion Forums - Featured Conversations for IBM
Network Infrastructure: Enterprise Data Centers

Related Information



Updated: Sep 09, 2005Document ID: 12380