Протокол IP : Serial Tunnel (STUN)

Настройка и устранение неполадок последовательного туннелирования (STUN)

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Последовательное туннелирование (STUN) – это туннелирование кадров SDLC через WAN. В традиционном мире системной сетевой архитектуры (SNA) удаленные контроллеры присоединены к препроцессору (FEP) через ряд модемов, подключенных по POTS (Обычная телефонная сеть) или выделенные линии.

Перед началом работы

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Предварительные условия

STUN SDLC чаще всего используется в средах двух типов: FEP к удаленному контроллеру и AS/400 к удаленному контроллеру.

Используемые компоненты

Устранение проблем STUN с помощью команд Cisco IOS₩½ Software, а также AS/400 к конкретным вопросам удаленного контроллера.

Общие сведения

Поскольку сети двигают интеграцию, и удаленные офисы требуют разного типа сервисов (таких как NetBIOS, IP, IPX), это было целесообразно от обслуживания и стоило точки зрения для интеграции всех их в одиночное устройство. Например, в следующей схеме мы видим интеграцию 3270 терминалов к хосту с Трафиком NetBIOS станций Windows.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-3.gif

STUN разрешает вам использовать IP в качестве транспорта для кадров Протокола SDLC через глобальную сеть (WAN) или другую сеть сред. Это избавляет от необходимости иметь дополнительную выделенную линию или POTS. Одной из функций SDLC маршрутизаторов Cisco является преобразование передающей среды. В преобразовании форматов разных сред передачи маршрутизатор преобразовывает сеанс от SDLC до Управления логическим Каналом (LLC), типа 2 (LLC2). Это обсуждено подробно в Понимании и Устранении проблем SDLC к LLC Network Media Translation.

Есть два типа конфигураций STUN: STUN Basic и STUN SDLC. Первый используется для любого типа кадров, созданныхм Высокоуровневое Управление Каналом Передачи Данных (HDLC), а второй используется только для кадров, созданных протоколом SDLC. STUN basic может также использоваться для SDLC, но не могут быть использованы функции, такие как local-ack. Распространено использовать STUN basic для SDLC для целей устранения проблем, так как специфичные для SDLC параметры не должны быть настроены на маршрутизаторе.

Конфигурация STUN

В первую очередь при любой конфигурации STUN (Basic или SDLC) выполняется команда stun peer-name. Маршрутизатор не позволяет продолжать конфигурирование без имени однорангового узла STUN.

Задача Команда
Включите STUN для определенного IP - адреса.
stun peer-name ip-address

Следует выбрать из маршрутизатора допустимый IP-адрес. Этот IP-адрес должен быть самым надежным интерфейсом в коробке. Для лучших результатов настройте маршрутизатор с интерфейсом обратной связи. (Сведения о настройке интерфейсов кольцевой проверки см. в документации Cisco).

Следующий этап – это определение режима STUN, который следует использовать. Один режим должен быть STUN Basic, в котором происходит поиск начала и разделителя кадра [7e] и перемещение кадра на другую сторону. В этом режиме работы STUN не заботится об определенном состоянии сеанса или подробной информации о SDLC, как опрашиваемый адрес. Другой режим – STUN SDLC. Этот режим требует более подробных решений в маршрутизаторе, особенно если запущено локальное подтверждение приема или любой другой тип многоточечной передачи. В представленной ниже таблице объясняются команды, используемые для настройки режима режима STUN:

Задача Команда
Укажите основную группу протоколов и задайте номер группы.
stun protocol-group group-number basic 
Укажите группу протокола SDLC и присвойте номер группы.
stun protocol-group group-number sdlc

Следующий шаг должен настроить последовательный интерфейс для STUN. Выбранная в интерфейсе группа должна соответствовать группе, указанной в группе протоколов. При наличии виртуальных многоточечных сетей можно также создать группу протоколов STUN с различными номерами для каждой виртуальной многоточечной сети. Всегда удостоверяйтесь, что вы настроили только один вспомогательный интерфейс на stun group, пока вы не настраиваете sdlc-tg. См. stun protocol-group.

Задача Команда
Включите функцию STUN на последовательном интерфейсе..
encapsulation stun
Поместите интерфейс в ранее определенную группу STUN.
stun group group-number

Примечание: Не настраивайте это на Cisco 7000, Cisco 7500 или любом другом маршрутизаторе, который имеет CxBUS, CyBUS в течение времени рабочей сети. Эта конфигурация заставляет маршрутизатор изменять MTU интерфейса к 2032 байтам, который приводит к Вырезанию буфера CBUS и делает все интерфейсы сильного удара маршрутизатора (сброс). В Среде Token Ring это может означать, что Token Ring выключатся в течение максимум 16 секунд. Кроме того, так как Cisco 7000 часто является центром ядра, где этот тип ошибки влияет на многих пользователей.

Следующий этап настройки конфигурации STUN состоит в добавлении инструкции маршрута stun. Можно определить это, как stun route all или stun route [address]. Параметры конфигурации будут объяснены далее.

Задача Команда
Передайте весь Трафик TCP для этого IP-адреса.
stun route all tcp ip-address

Укажите инкапсуляцию TCP.
stun route address address-number tcp ip-address [priority] [tcp-queue-max]

Указанные выше команды используются для одноранговых узлов инкапсуляции TCP. Можно также настроить STUN для непосредственной инкапсуляции, но редко используется эта конфигурация. Наиболее часто используемые из всех конфигураций – настройка локального подтверждения STUN.

Эти командные параметры описаны ниже:

  • Параметр приоритета в инструкции маршрута stun используется для создания многократных каналов TCP между двумя одноранговыми узлами STUN таким образом, что структура с приоритетами может быть создана с помощью настраиваемой очереди или формирования очереди по приоритету.

  • Параметр tcp_queue_max увеличивает или уменьшает очереди TCP между двумя точками вызова STUN. Это полезно, если сеанс TCP между узлами не очень надежен и необходимо определить неисправность между узлами. Эта опция не часто используется в конфигурации STUN, за исключением STUN FEP-to-FEP, где используется намного больше трафика.

Команды использовали настраивать STUN с локальным подтверждением, описаны ниже.

Задача Команда
Назначьте Маршрутизатор с функцией STUN основная роль SDLC.
stun sdlc-role primary
Назначьте Маршрутизатор с функцией STUN дополнительная роль SDLC.
stun sdlc-role secondary

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-2.gif

С помощью этих команд определяется "роль" установки STUN. В случае хоста в вышеупомянутой схеме маршрутизатор установлен в основного, что означает, что хост является тем, который инициирует сеанс. Поэтому 3174 становится вспомогательным. Использование STUN Basic, не требует определения роли, потому что не нужно знать, кто будет начинать сеанс. Но локальное подтверждение требует подробных данных самой линии, и определение роли позволяет маршрутизатору знать поток запуска сеанса, который маршрутизатор должен проверить прежде, чем переместиться в локальное подтверждение.

Примечание: В средах STUN AS/400, делающих локальное подтверждение, очень важно установить роль (на описании линии) к *pri от *отрицательный. Причина для этого состоит в том, что в слабом окружении (прямое подключение с помощью модема), AS/400 может выполнить согласование о роли. Путем кодирования роли, которой мы собираемся быть в линии, можно гарантировать, что роль маршрутизатора противоположна от AS/400. Вы обычно хотите, чтобы AS/400 инициировал сеанс (с, "варьируются на" линии). Перейдите к конфигурации с командной строки и настройте это для *pri. Описание линии AS/400 см. ниже. Это можно сделать только во время создания/копирования описания строки.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-3.gif

Ниже описывается команда настройки STUN с локальным подтверждением.

Задача Команда
Установите локальное подтверждение SDLC с помощью инкапсуляции TCP.
stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

Важный параметр здесь является ошеломить маршрутом [адрес] с local-ack. Помните, что локальное подтверждение STUN выполняется с помощью инкапсуляции TCP и Frame Relay (с использованием RFC 1490).

Как в RSRB и DLSw, пакеты Keepalive в STUN текут между узлами TCP, чтобы гарантировать, что одноранговое соединение подключено. Вы можете настроить параметры keepalive, если стороны отключаются или включаются по причине утери keepalive. Команды STUN, используемые для настройки параметров проверки активности, описаны ниже:

Задача Команда
Включите обнаружение удаленного потерянного узла.
stun remote-peer-keepalive seconds

Число раз для попытки узла connetion прежде, чем объявить узел "вниз". stun keepalive – подсчет количества

Базовый пример конфигурации STUN

Простейшим вариантом конфигурации STUN является STUN Basic. В этом режиме все пакеты, которые маршрутизатор получает от одной стороны, транспортируются в следующее. Конфигурацию STUN basic показывают в приведенном ниже рисунке:

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

Маршрутизаторы в схеме выше настроены следующим образом:

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 basic
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 basic
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.1

Образец конфигурации последовательного туннеля для SDLC

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc address DD
 stun route address DD tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1

Пример конфигурации многоточечного STUN (с локальным подтверждением приема)

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

4700 2522
hostname s5e
!
!
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 idle-character marks
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc K 1
 sdlc address 01
 sdlc address DD
 stun route address 1 tcp 10.17.5.2 local-ack
 stun route address DD tcp 10.17.5.2 local-ack
!

hostname rick
!
!

!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack
!
interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Примечание: На маршрутизаторе AS400 используется sdlc k1 и метки простоя. Для получения дополнительных сведений см. раздел "Предупреждение для поля".

Команды "show"

Первая команда показа, используемая с STUN, является show stun. Вывод данной команды зависит от того, используется ли STUN Basic или STUN SDLC с локальным подтверждением. В части STUN basic, показанной ниже, вы только видите пакеты, переданные и полученные.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        closed           5729      5718         0

В SDLC STUN с частью local-ack, показанной ниже, вы получаете дополнительные сведения, потому что теперь известно состояние сеанса.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
DD     TCP 10.17.5.1        open       *      182        94         0
 
 
  Serial3  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
1     TCP 10.17.5.1        open       *      209        89         0
 
SDLC Local Acknowledgement:
 
 *Serial2  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
DD     TCP 10.17.5.1                  Active    1    0        0        0
 
  Serial3  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
1     TCP 10.17.5.1                  Active    1    0        3        3

Выходные данные команды show interface различаются в зависимости от того, используется STUN Basic или STUN SDLC. Show interface для STUN basic совпадает с для обычной последовательной линии. Документация Cisco предоставляет определенные пояснения для каждой записи выходных данных show interface, выборку которых показывают ниже.

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Команда show interface для STUN SDLC с локальным подтверждением позволяет получить дополнительные сведения. Пример выходных данных для последовательного интерфейса с Local-ACK приводится ниже.

Serial3 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
    Router link station role: PRIMARY (DCE)
    Router link station metrics:
      slow-poll 10 seconds
      T1 (reply time out) 3000 milliseconds
      N1 (max frame size) 12016 bits
      N2 (retry count) 20
      poll-pause-timer 10 milliseconds
      poll-limit-value 1
      k (windowsize) 7
      modulo 8
  sdlc addr 01 state is CONNECT
      VS 1, VR 0, Remote VR 1, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 16/12
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 316/0 SNRMs 2/0 DISC/RDs 1/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 01/01
  Last input 0:00:00, output 0:00:00, output hang never
  Last clearing of "show interface" counters 1d06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 1 packets/sec
     332226 packets input, 664647 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     332227 packets output, 665220 bytes, 0 underruns
     0 output errors, 0 collisions, 3444 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Блоки выходных данных описаны ниже:

  • MTU является физическим размером буфера, который использует интерфейс.

  • PRIMARY (DCE) означает, что это опросная станция, и что мы обеспечиваем синхронизацию. Если мы были бы, смотря на сторону, которая присоединена к фактическому основному устройству, эти выходные данные были бы ВТОРИЧНЫ.

  • N1 является значением применимого размера кадра SDLC, который может быть принят последовательным интерфейсом маршрутизатора.

  • T1 является периодом времени, что мы ожидаем ответ на опрос, прежде чем линия будет вызвана таймаут.

  • poll-pause-timer – дельта времени в мс между опросами.

  • k – размер окна или количество кадров, которые могут ожидать выполнения между окончаниями опроса.

  • состояние является текущим статусом сеанса, который может быть одним из состояний ниже:

    • DISCONNECT

    • СВЯЗАННЫЙ

    • THEMBUSY (обычно установленный в результате этого маршрутизатора, получающего RNR.)

    • USBUSY (обычно результат не возвращения ответа на сетевой стороне.)

  • RNR – это количество отправленных или полученных RNR.

  • DTR/RTS являются линиями, используемыми в большинстве полудуплексных многоточечных сред. Когда вы отлаживаете любую среду STUN и смотрите на расположение контроллера, обращаете пристальное внимание на RTS. Если это выключается периодически, в то время как DTR и CTS высоки, это наиболее вероятно результат DTE, являющегося полудуплексом.

Последняя важная команда show для STUN – это show tcp command, которая отображает информацию о TCP-сеансе между одноранговыми устройствами. Ниже приводится пример выходных данных:

Stand-alone TCP connection from host 10.17.5.1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.17.5.2, Local port: 1994
Foreign host: 10.17.5.1, Foreign port: 11035
 
Enqueued packets for retransmit: 0, input: 0, saved: 0
 
Event Timers (current time is 0x1B2E50):
Timer          Starts    Wakeups            Next
Retrans           229          0             0x0
TimeWait            0          0             0x0
AckHold           229          0             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
 
iss: 2847665974  snduna: 2847667954  sndnxt: 2847667954     sndwnd:   9728
irs: 3999497423  rcvnxt: 3999499452  rcvwnd:       9672  delrcvwnd:    568
 
SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms
Flags: passive open, higher precedence
 
Datagrams (max data segment is 1460 bytes):
Rcvd: 459 (out of order: 0), with data: 229, total data bytes: 2028
Sent: 457 (retransmit: 0), with data: 228, total data bytes: 1979

Устранение неисправностей

Порядок устранения неполадок для конфигурации STUN аналогичен правилам любого однорангового соединения. При испытании проблем в транспорте это должно быть диагностировано, прежде чем можно будет начать устранять неполадки части SDLC/STUN. Обычно, первый шаг должен пропинговать от узла до узла, чтобы удостовериться, что IP установлен правильно. Кроме того, пропингуйте с расширенными типами пакета, чтобы удостовериться, что транспорт надежен.

Диагностика протокола синхронного управления передачей данных SDLC Basic

Этот раздел покрытия, устраняющие неполадки настройки STUN basic. В данном примере предположите, что глобальная сеть (WAN) функционирует правильно.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

Этот сценарий имеет настройку STUN basic для соединения 5494 с AS/400. Первая вещь проверить с любой настройкой STUN состоит в том, что узлы установлены в маршрутизаторе. Чтобы определить это, используйте команду show stun peer. Это предоставляет сведения о состоянии узла и пакетов, которые были переданы/получены. Ниже приводится пример выходных данных:

rick#sh stun peer
This peer: 10.17.5.2

 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        open             5729      5718         0

Если узел открыт, как выше, используйте показ interfacecommand для определения то, что происходит с пакетами. Пример выходных данных для этой команды показывают ниже:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Во-первых, проверьте, имеет ли маршрутизатор все последовательные сигналы. У основания выходных данных выше, мы видим, что все сигналы подключены "Serial2" на 2522. DTR и RTS указывают, что контроллер уже активировал саму линию и ждет AS/400 для передачи начального диалога.

Затем, проверьте show interface для стороны маршрутизатора AS/400. В выходных данных, показанных ниже, мы видим, что последовательный интерфейс, который подключает к AS/400, вниз/вниз. Это означает, что AS/400, вероятно, “выключен”." Если линия "варьируется на", и вы не можете разбудить линию или выполняете полудуплекс, тогда необходимо проверить соединение RS-232/V.35.

Serial1 is down, line protocol is down
  Hardware is HD64570
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input never, output 1:51:24, output hang never
  Last clearing of "show interface" counters 0:00:01
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=down  RTS=down  CTS=up
s5e#

На этом этапе проверьте, "Работают со Статусом конфигурации" для того определенного контроллера, который является экраном AS/400, который похож:

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-1.gif

Затем, варьируйтесь на определении линии. Затем вы увидите, что маршрутизатор вводит линю в работу. Если линия прибывает up/up, но контроллер все еще не подходит, проверьте интерфейс, чтобы проверить, поразили ли какие-либо пакеты интерфейс, входящий от AS/400. Если количество является нулем, проверьте механизм кодирования для линии SDLC на AS/400. Это расположено на описании строки дисплея, как показано ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-4.gif

Примечание: На этом экране можно видеть, что шифрование линии установлено "NRZI". Ее необходимо включить при помощи настройки конфигурации nrzi-encoding на маршрутизаторе.

Эта настройка не требует NRZ/NRZI, кодирующего End to End, как в обычных условных обозначениях точка-точка SDLC, но может быть NRZI в одной стороне и NRZ в другом. Но помните, что кодирование действительно должно быть тем же между устройствами, которые совместно используют линию SDLC.

NRZI требует должного внимания. В новых маршрутизаторах как Cisco 2500 и 4500, NRZI установлен с помощью программного обеспечения. Но с более старыми платформами, включая NP-2T для Cisco 4000, необходимо изменить перемычки на самих платах. В таких случаях, вероятно, легче изменить AS/400 на NRZ/NRZI. Но, если необходимо изменить перемычки, обратитесь к Оборудованию CISCO documenation для определенной платформы.

Если проблема сохраняется, сделайте debug stun packet 1. Эта команда дает нам следующую информацию:

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down
STUN basic: 0:00:38 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINK-3-UPDOWN: Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down

Можно видеть несколько XID, идущих от AS/400, но им не было ответа (CO – это адрес опроса, а bf – это XID). Мы знаем, что пакет прибывает из AS/400, потому что пакет произошел из SDI. Существует два типа входящих пакетов в этих выходных данных команды:

  • SDI: Последовательные входящие пакеты – пакеты, полученные через интерфейс SDLC.

  • NDI: Входящие данные сети, которые являются пакетами, извлеченными из пакета от глобальной сети (WAN).

Затем, посмотрите на часть XID самого кадра. В данном примере AS/400 передает XID наряду со своим IDBLOCK и IDNUM, 05645253.

Это - проблема времени ожидания, потому что не отвечает контроллер. В AS/400 посмотрите на "sysopr очередь сообщений", чтобы видеть, существуют ли какие-либо сообщения, указывающие на проблему. Экран "SYSOPR" со сбоем показывают ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-2.gif

Теперь на этих 2522, включите debug stun packet 1, чтобы видеть, становятся ли пакеты передаваемыми контроллеру. Ниже представлен пример выходных данных команды:

STUN basic: 0:00:34 Serial2         NDI:   Data: c0bf324c056452530000
STUN basic: 0:00:42 Serial2         NDI:   Data: c0bf324c056452530000

Это показывает нам, что XID, который произошел на стороне AS/400, проходит к контроллеру, но контроллер не отвечает, что означает, что это - сбой контроллера. Show interface показывает нам, если весь контроль ведет, подключены или нет:

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 0:50:56, output 0:00:23, output hang never
  Last clearing of "show interface" counters 0:02:06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1 packets output, 78 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Контрольные выводы работают, и интерфейс находится в состоянии up/up. Мы можем также видеть, что маршрутизатор выводит пакеты, но не поступают никакие пакеты. Это указывает на некорректные адреса опросов, настроенные на AS/400, так что следующим шагом является проверка адресов опроса контроллера.

Каждый тип контроллера имеет уникальный способ настроить опрашиваемый адрес, таким образом, необходимо проверить это с руководствами по контроллеру для контроллера.

В данном примере мы узнали, что контроллер использовал опрашиваемый адрес "DD". После изменения этого на AS/400 выходные данные debug stun packet становятся:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000
STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000
STUN basic: 0:00:00 Serial2         NDI:   Data: dd93
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd102f00000200016b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
.
.
.
.
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd71
STUN basic: 0:00:00 Serial2         NDI:   Data: dd362f00020080004b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Эти выходные данные отладки помогают определять следующую информацию:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

Эта строка содержит XID, отправленный с AS/400 на контроллер. Это связано с NDI (происходит из облака), dd (опрашиваемый адрес), bf (XID), а также с IDBLOCK и IDNUM (05645253).

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

Это - ответ от контроллера. Ответ распознается SDI (идущим от канала SDLC) и совпадает с ответом, приведенным выше, за исключением ответа XID (073000dd), т. к. это "5494".

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

Это SNRM (93) от AS/400 контроллеру, первичному в этой конфигурации.

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Здесь мы видим, что контроллер отвечает (SDI) UA (73), что означает, что сеанс в порядке. Затем, мы должны видеть, что разъединение прибывает из AS/400, поскольку линия варьировалась прочь.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Эти строки отображают DISC (53) и ответ UA. Теперь линия не работает. Придерживающееся является таблицей со значениями, должен был отладить эти проблемы.

Контрольное поле - Ненумерованный (1 байт)
000z 0011  
0001 0111  
0001 0111  
0001 1111  
0011 0011  
0101 0011  
0101 0011  
0101 0011  
0111 0011  
1001 0011  
1001 0111  
101z 1111  
110z 0111  
111z 0011  
 
03-13    UI  
07-17    SIM  
07-17    RIM  
0F-1F    DM  
23-33    UP  
43-53    DISC  
43-53    RD  
43-53    RD  
63-73    UA  
83-93    SNRM  
87-97    FRMR  
AF-BF    XID  
C7-D7    CFGR  
E3-F3    TEST  
 
Unnumbered Information   
Set Initialization mode  
Request Intialization Mode   
Secondary in Disconnect Mode  
Unumber Poll  
Disconnect  
Request Disconnect  
Secondary Requests Disconnect  
Unnumbered Acknowledgement  
Set Normal Response Mode  
Frame Reject  
Exchange Identification  
Configure  
I-Field contains test pattern 
   

Контрольное поле - Контрольный (2 байта)
rrrz cc01  
rrrz 0001  
rrrz 0101  
rrrz 1001  

 
xx-xx  
x1-x1  
x5-x5  
x9-x9  
 
 
Supervisory Format  
Receiver Ready  
Receiver Not Ready  
Reject  
  
   

Контрольное поле - Фреймы информации (2 байта)
rrr1 sssz 

 
xx-xx
 
 
Information format
  
   

Ключ:

z = последний бит опроса может быть 0 или 1

rrr – номер блока, ожидаемого к получению

sss = номер отправляемого блокаа

Устранение неполадок в STUN SDLC с локальным подтверждением и без него

В этом разделе описан такой же сценарий с настроенным локальным подтверждением приема.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

В отличие от STUN basic, SDLC STUN требует, чтобы вы задали корректный опрашиваемый адрес, или маршрутизатор даже не будет видеть, что входят пакеты. Это - то, почему иногда STUN basic используется для обнаружения опрашиваемого адреса, когда вы не имеете информации или не можете добраться до хоста или AS/400. Схема выше показов многоточечный сценарий с local-ack.

В традиционной среде с двухточечным соединением опрос идет End to End. Когда локальное подтверждение представлено, опрос завершается на каждом краю облака, так что каждый маршрутизатор должен обслуживать конечный автомат. Эта машина отслеживает все сеансы и ей нужно знать состояние линии каждой опрашиваемой станции. Из-за этого необходимо удостовериться, что станции придерживаются протокола SDLC.

Во-первых, проверьте, что вы находитесь в корректной роли STUN. AS/400s испытывают затруднения при согласовании о роли с контроллером в традиционных средах с двухточечным соединением. Описание линии см. ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-5.gif

Это показывает, что интерфейс маршрутизатора следует настроить для дополнительной роли. Всегда проверьте линию и проверьте, что это *PRI, потому что настройки по умолчанию AS/400 к *NEG при создании его. NRZI установлен в *ДА, таким образом, необходимо закодировать nrzi-encoding. Кроме того, idle-character marks кода и набор окно к одному (1) sdlc k 1 использования. (См. Полевое Предупреждение FNA-IOS-0696-02 для всестороннего описания того, почему idle-character marks требуется на интерфейсе.) Это кодирование показывают ниже:

interface Serial1
no ip address
encapsulation stun
idle-character marks
nrzi-encoding 
clockrate 56000 (real clockrate on the line; see note about as400 line speed)
stun group 1
stun sdlc-role secondary (this must be secondary because the line is primary)
sdlc K 1
sdlc address 01
sdlc address DD
stun route address 1 tcp 10.17.5.2 local-ack
stun route address DD tcp 10.17.5.2 local-ack

Примечание: Синхронизация, которую предоставляет маршрутизатор, независима от параметра Скорости линии, который настроен на линии AS/400. (Этот параметр используется для производительности calulations; это можно оставить в по умолчанию 9600.) Идентификатор Exchange, который настроен на линии, является идентификатором AS/400, такого как XID, который передаст AS/400. Максимум контроллеров – это число номеров PU (контроллеров), которые могут быть созданы и присоединены к этой линии.

Первый из двух контроллеров, подключенных к этому каналу, IBM 5494, показан ниже на экране.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-6.gif

Как показано на рисунке, в качестве первого контроллера используется PU 2.1, так как для контроллера выбрана категория "*APPC"." Это - сокращение для Усовершенствования Межпрограммная Связь, которая может только быть выполнена через соединение T2.1. Идентификатор удаленной сети снова отнесен к APPN/APPC и называемый "NETID". "*NETATR" является параметром, который задает использование NETID, определенного в области данных, вызванной "Сетевые атрибуты. Можно отобразить эту область данных с помощью команды DSPNETA и заменить значения соответствующим образом. "Точка дистанционного управления" или "CP_name" является именем контрольной точки, которое вы настроили в PU2.1. В этом случае это - CP5494. Роль канала передачи данных можно оставить как *NEG. "Адрес станции" должен совпасть с "DD sdlc address", который был настроен на обоих вспомогательный интерфейс, а также один из основных интерфейсов.

interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack

Таким образом, большая часть данных в описании контроллера относится к физическому устройству и не может быть изменена в маршрутизаторе.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-7.gif

На этом экране второй контроллер (PU) является фактически 3174, который является типом 2 PU. XID, настроенный в этом 3174, 05600001. "Адрес станции" или sdlc address, быть используемым равняется 01. Вам нужен "sdlc address 01" настроенный на вспомогательном интерфейсе и одном из удаленных основных интерфейсов. Как вы можете видеть ниже, конфигурация для PU2 менее включена, чем PU2.1.

interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Дисплейные атрибуты сети (DSPNETA) в AS/400 показаны ниже:

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-8.gif

На данном экране показано, что AS/400 настроен для сетевого идентификатора "NETA", а значит 5494 должен быть настроен для той же сети. Это, а также остаток специфичной для APPN конфигурации, может быть найдено на втором окне конфигурации в 5494. Название Точки локального управления AS/400 является "RTP400A". Название LU AS/400 является "LU9404"; это должно совпасть с тем, что настроено в Партнерском поле Определения LU 5494. Описание режима, которое используется 5494 потребностями совпасть с тем, что находится в описании устройства. Например, если устройство говорит "*NETATR", то это должно совпасть с по умолчанию "ПРОБЕЛА".

Описание устройства APPC, созданного для 5494, приведено ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-9.gif

Этот экран показывает, что описание устройства для этих 5494 имеет Удаленное название CP "CP5494"; это должно совпасть с тем, что настроено на 5494. NETID и Локальное расположение приняли значение по умолчанию к "*NETATR", которые были закодированы к LU9404 и NETA в предыдущем примере. Снова, они должны совпасть с Партнерским названием LU и полями NETID в 5494.

Заключительная часть настройки устройства, относящаяся к получению установленного подключения, показана ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-10.gif

Этот экран показывает, что режим, используемый режим в описании устройства - "QRMTWSC". Это не значение по умолчанию из *NETATR, следовательно, оно было переназначено в описании устройства. Это - один из режимов по умолчанию, предоставленных IBM как часть основной Поддержки APPN на AS/400. Если вы видите что-либо другое, свяжитесь с IBM, потому что они работают с описанием режима, которое они создали. Данный пример устанавливает основное подключение; если вы хотите отобразить информацию о режимах, доступных, можно использовать команду WRKMODD или Work Mode Descriptions.

Описание режима см. ниже.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-11.gif

Этот экран ясно определяет Определения режима, предоставленные IBM.

Устранение неполадок интерфейса SDLC с многоточечной полнодуплексной передачей

При выполнении локального подтверждения в многоточечной среде с устройствами AS/400 необходимо тщательно выполнить реализацию дуплексного многоточечного интерфейса SDLC на базовых мини-компьютерах AS/400, SYS/38 и SYS/36. Оповещение при эксплуатации FNA-IOS-0696-02 (приведенное ниже) содержит тип проблем, которые могут возникнуть в данной ситуации.

Краткое описание

Изменение кабеля маршрутизатора для подключения "обнаружения несущей" к клемме "земля" не поможет избежать периодических сбросов канала SDLC из AS/400, если к AS/400 был применен IBM PTF# MF10030. Данное предупреждение применяется только к полнодуплексным многоточечным соединениям STUN с AS/400, где кабель SDLC маршрутизатора был изменен таким образом, что обнаружение несущей было отключено.

Влияние

Пользователи могут наблюдать периодическую перезагрузку соединения STUN и всех вспомогательных устройств SDLC, что приводит к неустойчивости соединения.

Полное описание / Общие сведения

В многоабонентской среде AS/400 ведет себя по-другому от других устройств IBM. Принимая во внимание, что FEP принимает или 0x7E символы (флаги) или 0xFF символы (метки), поскольку "простаивающее" пространство между кадрами, AS/400 рассматривает флаги и метки по-другому. Только метка интерпретируется как символ бездействия. Флаг интерпретируется, чтобы означать, что "линия все еще активна - больше данных находится на рассмотрении". Маршрутизатор Cisco может быть настроен для передачи или флагов или меток, но не обоих. Это не чередуется между двумя для отражения состояния линии. По умолчанию для маршрутизатора для передачи флагов.

Это различие излагает проблему в полнодуплексных многоабонентских средах. Обычно AS/400 идет с устройства на устройство, опрашивая каждого для данных. Если устройство будет не в состоянии отвечать, и AS/400 думает, что линия все еще активна, то это перезагрузит всю линию. Поскольку по умолчанию маршрутизатор посылает флаги, AS/400 будет всегда иметь информацию об активной линии и будет выполнять сброс линии, а не просто опрашивать следующее устройство.

Во избежание таких проблем компания Cisco всегда рекомендовала пользоваться модификацией кабеля, которая исключает сигнал обнаружения несущей (CD). Эта модификация использует логику AS/400, которая интерпретирует отсутствие несущей как "состояние свободной линии"." Следовательно, с модификацией, AS/400 всегда обнаруживает состояние свободной линии независимо от межкадровых символов, передаваемых маршрутизатором. Так, если дополнительное устройство будет не в состоянии отвечать, то AS/400 проверит CD, видеть свободную линию и перейти для опроса следующей станции.

В последнее время IBM выпустил исправление ошибок AS/400 PTF# MF10030, которые изменяют логику обнаружения несущей на многоабонентские линии. С этим установленным исправлением AS/400 полностью игнорирует состояние CD на полнодуплексных многоабонентских линиях. В результате модификация кабеля Cisco больше не является эффективной при предотвращении периодического сброса линии.

Обходной путь

В зависимости от модели маршрутизатора и используемой версии Cisco IOS доступно два варианта временного решения. Обе опции требуют изменений конфигурации к маршрутизатору, связанному с AS/400.

Вариант 1

Измените символ бездействия SDLC от символа флага по умолчанию до символа метки. Символ бездействия может быть заменен с помощью команды router interface configuration:

idle-character marks 

Добавьте эту команду к последовательному интерфейсу SDLC, связанному с AS/400. Эта команда заставит маршрутизатор всегда передавать символы метки для паузы между кадрами. Таким образом, если вторичное устройство не участвовало в опросе, AS/400 найдет незанятый канал и перейдет к опросу следующего устройства. К сожалению, это также означает, что даже в случае отправления устройством кадров данных AS/400 будет воспринимать линию как свободную. Даже если бит опроса/завершения будет 0, AS/400 только подтвердит первый кадр. Это тогда проигнорирует все последующие кадры и опросит следующее устройство, причиняющее повторные передачи необязательного кадра. Чтобы избежать повторных передач следует также установить размер окна SDLC равным 1, воспользовавшись командой:

sdlc k 1 

Примечание: Команда idle-character поддерживается в Cisco IOS версии 10.0(5.2) и выше и действует на маршрутизаторах 2500s, 4x00 с NP-4T и 70x0/75xx.

Вариант 2

Включите обнаружение неактивных дополнительных устройств с интерфейсной командой:

stun quick-response

Эта команда заставит маршрутизатор отвечать "режимом разъединения" (DM) кадр для любого неактивного дополнительного устройства, опрошенного AS/400. AS/400 тогда продолжит опрашивать следующее устройство, не перезагружая линию.

Примечание: Эта команда поддерживается в Cisco IOS 11.1, 11.0 (3.1) и позже или 10.3 (7.2) и позже.

Совет: При испытании каких-либо проблем, поднимающих многоточечную линию с настроенным быстрым откликом используйте опцию 1. Код stun quick-response в маршрутизаторе является частью блока конечных состояний для local-ack, который может добраться не в ногу с некоторыми PU. Мы испытали код в лабораторных условиях и проверили его пригодность к использованию с 5494, 5394 и Perl494E. Возможно столкнуться с проблемами, если PU, который вы пытаетесь подключить, установили таймеры по-другому от того, что ожидает quick_response.


Дополнительные сведения


Document ID: 16398