Технологии IBM : Протокол LLC

Об управлении логическим каналом

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


Содержание


Введение

Стандарт IEEE 802.2 определяет Протокол LLC как канальный уровень, используемый на 802.3, 802.5, и другие сети. IBM первоначально разработал LLC как подуровня в архитектуре Token Ring IBM.

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

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Основное понимание LLC

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

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

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

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

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

Уровень LLC предоставляет и conection-ориентируемую передачу данных без установления соединения.

Передача данных без установления соединения обычно упоминается как тип LLC 1, или LLC1. Сервис без предварительного соединения не требует, чтобы вы установили каналы передачи данных или станции связи. После того, как Точка доступа к сервису (SAP) была включена, SAP может передать и получить информацию к и от удаленного SAP, который также использует сервис без предварительного соединения. <ts font_id="Arial" fsize="10"/>Служба<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>без<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>предварительного<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>соединения<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>не<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>имеет<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>никаких<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>команд<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>настройки<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>режима<ts font_id="MS Sans Serif"/> (<ts font_id="Arial"/>как<ts font_id="MS Sans Serif"/> SABME) <ts font_id="Arial"/>и<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>не<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>требует<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>поддержки<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>информации<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>о<ts font_id="MS Sans Serif"/> <ts font_id="Arial"/>состоянии.

Передача данных с установлением соединения упоминается как тип LLC 2, или LLC2. Служба ориентированная на соединение требует установления станций связи. Когда станция связи установлена, команда mode setting необходима. После того каждая станция связи ответственна для поддержания информации о состоянии канала.

Реализации LLC

LLC2 внедрен каждый раз, когда Системная сетевая архитектура (SNA) работает на основе LAN или виртуальной локальной сети. LLC2 также непосредственно инкапсулируется в Frame Relay. Иногда маршрутизатор просто передает кадры LLC2, а иногда использует конечную станцию LLC2. NetBIOS также использует LLC. NetBIOS использует LLC1 для определения местоположения ресурса. Сеансы с установкой соединения LLC2 тогда установлены.

Когда любая из этих опций активирована, маршрутизатор внедряет стек LLC2:

  • Коммутация соединения передачи данных (DLSw) (соединение с LAN)

  • Удаленное мостовое соединение источник-маршрут (RSRB) c локальным подтверждением ACK

  • Процессор интерфейса канала (CIP)

  • Расширенное взаимодействие одноранговых сетей (SNASwitching (SNASw))

  • Преобразование Управления Синхронным Каналом Передачи данных (SDLC) к LCC (SDLLC)

Основные сведения, которые необходимо знать для устранения проблем

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

В LLC2 могут произойти две категории проблем:

  1. Сеансы, которые не устанавливают

  2. Установленные сеансы это периодически отказывает

Для решения этих проблем, необходимо знать об этих темах:

  • Форматы кадров LLC

  • Режимы LLC2 и установка сеансов

  • Работа в асинхронном сбалансированном режиме LLC2

  • Состояния ошибок LLC2

Форматы кадров LLC

Этот раздел предоставляет сведения о форматах фрейма LLC.

DSAP/SSAP Контроль
Точка доступа к сервису назначения (1 байт) Контрольное поле - Ненумерованный (1 байт)
dddd ddxx
xxxx xx1x
xxxx xxx1
Dest. Addr.
IEEE Defined
Group Address
CCCC CC11
000F 1111
010P 0011
011F 0011
011P 1111
100F 0111
101z 1111
111z 0011
xx-xx
0F-1F
43-53
63-73
6F-7F
87-97
AF-BF
E3-F3
Unnumbered format
Disconnect Mode
Disconnect
Unnumbered Ack.
SABME
Frame Reject
XID
Test
Точка доступа к исходному сервису (1 байт) Контрольное поле - Контрольный (2 байта)
ssss ssxx
xxxx xx1x
xxxx xxx1
Source Address
IEEE defined
Response LPDU
CCCC CC01
0000 0001
0000 0101
0000 1001
xx-xx
01-xx
05-xx
09-xx
Supervisory Format
Receiver Ready
Receiver Not Ready
Reject
Контрольное поле - Фреймы информации (2 байта)
ssss sss0
xxxx
Information format
P = Установленный бит опроса к "1" F = набор Последнего бита к "1" Z = набор Бита опроса/завершения или к "0" или к "1"

Кадр LLC называют LLC Protocol Data Unit (LPDU) и форматируют как показано здесь:

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field
(0 or more bytes)

Поле DSAP

Точка доступа к сервису назначения (DSAP) определяет SAP, для которой предназначен LPDU. DSAP состоит из шести битов адреса, пользователь укусил (U), и Частное лицо/Группа (I/G) укусило, организованный как показано здесь:

D-D-D-D-D-D-D-I/G

U бит указывает, определяется ли адрес протоколом IEEE (1) или пользователем (0). I/G укусил, указывает, является ли SAP групповым адресом (1) или отдельный адрес (0). В наших целях ни один из этих битов не слишком важен. Все, что действительно необходимо знать, - то, что DSAP является назначением LPDU. Некоторые общие появляются много раз.

Поле SSAP

Точка доступа к исходной службе (SSAP) определяет SAP-источник LPDU. SSAP состоит из шести битов адреса, пользователь укусил (U), и Команда/Ответ (C/R) укусила, организованный как показано здесь:

S-S-S-S-S-S-U-C/R

U бит указывает, определяется ли адрес протоколом IEEE (1) или пользователем (0). C/R укусил, указывает, является ли LPDU командой или ответом. При получении кадров LPDU бит C/R не считается частью SSAP. Поэтому точкой SSAP обычно считаются семь крайних левых битов.

Поле управления

Контрольное поле LPDU содержит команду, ответ и информацию о порядковом номере. Необходимо знать, как декодировать контрольное поле для определения то, что происходит на определенном сеансе LLC2. Однако декодирование информации легко доступно.

Существует три typws кадров:

  • I-кадры

  • Кадры управления

  • Ненумерованные кадры

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

X-X-X-X-X-X-X-0 = I Frame

X-X-X-X-X-X-0-1 = Supervisory Frame

X-X-X-X-X-X-1-1 = Unnumbered frame

Следующие несколько разделов объясняют каждый тип контрольного поля.

I-кадр

I-кадры позволяют вам передать последовательно пронумерованные LPDU, которые содержат информацию (с установлением соединения) между станциями связи. Формат кадра I содержит последовательный номер NS и NR. Количество NS является порядковым номером (по модулю 128) LPDU в настоящее время в передаче. Количество Nr является порядковым номером следующего I-кадра LPDU, который отправитель ожидает получать. Запомните, что NR означает "next receive" (следующее получение): это пригодится позже."

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

P/F укусил, вызван, P укусил в команде LPDU, и F укусил в ответ LPDU. P/F укусил, собирается в команде LPDU запросить, чтобы станция удаленного канала передала ответ с этим установленным битом. Только один ответ должен быть получен с установленным битом F для каждой команды, передаваемой с установленным битом P. Существуют некоторые другие подробные данные об использовании бита P/F относительно восстановления работоспособности после сбоя, но это - обычное правило.

Контрольный кадр

Контрольные кадры выполняют функции управления в супервизорном режиме, например, чтобы подтвердить I-кадры (RR), запросить повторную передачу I-кадров (REJ) и запросить временную приостановку (RNR) I-кадров. Контрольные кадры не содержат информационное поле. Поэтому контрольные кадры не влияют на NS в посылающей станции, и так не содержите поле NS. Вот формат контрольного кадра:

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

Биты "S" указывают тип супервизорного кадра.

  • B '00' = готовность приемника

    Станция использует RR, чтобы указать, что станция готова получить и содержит количество Nr следующего I-кадра, который должен поступить. Когда станция передает кадр RR, станция подтверждает получение пронумерованных I-кадров от удаленной станции до Nr - 1.

  • B '01' =Receiver, не готовый

    Станция использует RNR, чтобы указать, что станция временно не готова получить. RNR также содержит количество Nr, которое придерживается того же RR правил. Переходные периоды RNR не всегда показательны из проблемы сети. Если RNR являются персистентными, ищут перегрузку в конечной станции.

  • B '10' =Reject

    Станция использует REJ для запроса повторной передачи LPDU I-кадра начиная с количества, обозначенного в количестве Nr. REJ не показателен из серьезной проблемы (что означает, что это восстанавливаемо). Если вы видите много команд REJ, ищете без вести пропавших (отброшенных) I-кадров в противоположном направлении. Не путайте REJ с Отклонением фрейма (FRMR). FRMR является ненумерованный кадром и всегда показателен из серьезной проблемы.

Ненумерованные кадры

Ненумерованный кадры предоставляют функции управления каналом, например, команды mode setting и ответы. В некоторых случаях ненумерованный информационные кадры могут также быть переданы. Ненумерованный кадры составляют только один байт в длине. Они не содержат поля для количества NRS или Nr. Вот формат ненумерованный кадра:

M-M-M-P/F-M-M-1-1

Биты "M" указывают тип ненумерованного кадра.

  • Ответ B '00011' =DM (0x1F)

    Станция связи передает ответ DM, чтобы сообщить, что это находится в асинхронном режиме разъединения. Это означает, то, что ссылка не активна. Если станция связи была активна и внезапно начинает передавать DM, станция связи была, вероятно, перезагружена.

  • Команда (0x53) B '01000' =DISC

    Станция связи передает DISC для завершения асинхронного сбалансированного режима. Команда DISC сообщает станции удаленного канала, что это приостанавливает операцию. Правильный ответ на команду DISC - UA (если станция находится в режиме ABM) или DM (если станция находится в режиме ADM).

  • Ответ B '01100' =UA (0x73)

    Станция связи передает UA в ответ на команды DISC и SABME.

  • Команда (0x7F) B '01111' =SABME

    Станция связи передает SABME для инициирования передачи данных в асинхронном сбалансированном режиме. Правильный ответ на SABME - UA. Когда станция получает команду SABME, станция перезагружает Nr и NS рассчитывает для обнуления. Передающая станция делает то же самое при получении ответа UA.

  • Ответ B '10001' =FRMR (0x87)

    Станция связи передает Ответное сообщение об отклонении кадра для создания отчетов об ошибке во входящем LPDU от другой станции связи. Когда вы видите FRMR, станция, которая передает FRMR, обнаружила непоправимую ошибку. Это не причина ошибки. Любые кадры, которые поступают после ошибки FRMR, произошли, проигнорированы, пока не получены DISC или SABME.

    Ответ FRMR содержит информацию о причине условия FRMR.

    Байты 0 и 1 содержат содержание контрольного поля LPDU, который вызвал отклонение фрейма. Байты 2 и 3 содержат NS, который Nr считает, соответственно. Байт 4 содержит несколько битов, которые определяют тип ошибки как показано здесь:

    0-0-0-V-Z-Y-W-X

    Бит V означает, что номер NS, содержащийся в контрольном поле в байтах 0 и 1, является недопустимым. NS недопустим, если больше, чем или равен последнему NS плюс максимальный размер окна приема. При возникновении таких условий канальная станция отправляет не ответ FRMR, а REJ LPDU.

    Z укусил, указывает, что Nr, который переносы контрольного поля, обозначенные в байтах 0 и 1, не обращаются или к следующему I-кадру или к I-кадру, который был уже передан, но не подтвержден.

    Примечание: Это в порядке для получения того же количества Nr многократно.

    Количество Nr только недопустимо, если количество ссылается на I-кадр, который был уже подтвержден или если количество переходит непосредственно к тому, которое еще не было передано. Прежний - наиболее распространенный случай этого типа ошибки. Когда вы видите этот тип ошибки, это обычно означает, что кадры были приняты из последовательности, и необходимо искать сеть, которая отправляет кадры не в порядке. Возможно, что станция связи передачи передала их не в порядке, но очень вряд ли.

    Бит Y показывает, что длина поля I в полученном LPDU превышает имеющиеся возможности буфера. Если эта ситуация происходит, ищите проблемы в конечных станциях, не сеть.

    X биты указывают, что LPDU содержал поле I, когда он не должен иметь, или ответ FRMR был получен, который не содержал 5 байтов. Это, кажется, проблема оконечного устройства, не проблема сети.

    Бит W указывает на то, что получен неподдерживаемый LPDU. Это проблема конечной станции.

  • Команда B '10111' XID или ответ

    Станция связи использует команду XID, чтобы передать характеристики узла передачи и заставить станцию удаленного канала отвечать ответом XID. Станции связи могут передать и получить XID в различных форматах, включая форматы SNA.

  • ТЕСТОВАЯ команда B '11100' или ответ

    Станция связи передает команду TEST, чтобы заставить станцию удаленного канала отвечать Тестовым ответом как можно скорее. Команда TEST в основном используется для обнаружения пути для мостов путей от источников.

    /image/gif/paws/12247/llc2_1.gif

Краткое описание контрольного поля управления логической связью (LLC)

Значение Ненумерованные кадры
0x0F or 0x1F Ответ режима разъединения (DM)
0x43 или 0x53 Разъединение (DISC) команда
0x63 или 0x73 Ответ ненумерованного подтверждения (UA)
0x6F или 0x7F Команда установки асинхронного сбалансированного режима (SABME)
0x87 или 0x97 Отклонение фрейма (FRMR) ответ
0xAF или 0xBF Exchange Id (XID) команда или ответ
0xE3 или 0xF3 Тест (ТЕСТ) команда или ответ

Значение Кадры управления
0x01 Приемник готов (RR)
0x05 Receiver Not Ready (RNR)
0x09 Отклонение (REJ)

Значение Фреймы информации
0bnnnnnnn0 Фрейм информации (ИНФОРМАЦИЯ)

Режимы LLC2 и установка сеансов

Существует два режима операции LLC2:

  • Asynchronous Balanced Mode Extended

  • Асинхронный режим разъединения

Улучшенный асинхронный сбалансированный режим (ABME)

ABME является сбалансированным режимом операции между двумя станциями связи. Сбалансированный режим обращается к факту, что любая станция может передать команды в любое время, независимо от другой станции связи. Контрастируйте это с SDLC, который работает в несбалансированном режиме. В несбалансированном режиме вспомогательная станция должна ждать, чтобы быть опрошенной основным, прежде чем это сможет передать данные. В результате работы в сбалансированном режиме опрос не происходит на каналах LLC2 в традиционном смысле. Станция действительно передает пакеты Keepalive, чтобы поддержать сеанс, но необязательно часто передавать их за оптимальной производительностью как в SDLC. Поэтому таймер поддержки активности, как правило, является 10 секундами или больше. Следует отметить, что конечные станции могут увеличить этот таймер поддержки активности для сокращения издержек. Увеличение таймер поддержки активности не имеет никакого негативного эффекта на пропускную способность или время отклика.

Станция вводит ABME после того, как станция передаст или получит UA к к команде SABME. Когда в ABME, станция может передать и получить нумерованные кадры информации.

Режим асинхронного разъединения (ADM)

Прежде и после того, как станция завершает ABME, станция находится в Асинхронном Режиме разъединения. В ADM логически разъединена ссылка; поэтому, никакие I-кадры или контрольные кадры не могут быть переданы. Станция может ввести ADM при этих условиях:

  • Получение команды DISC

  • Станция канала активирована

  • Получение ответа DM

  • Предел повторной попытки, исчерпан

Вот пример последовательности активизации станции связи:

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07F

To1 4000.0840.0001 8800.5a94.7d94 UA F0F173

To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...

To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...

To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

Работа в асинхронном сбалансированном режиме LLC2

Станции, которые работают в ASBM, не имеют строгого определения основных или вспомогательных станций. Станции не должны опрашивать или быть опрошены для передачи данных. Станции могут передать данные к любой станции асинхронно. Станции имеют одноранговые взаимоотношения.

Даже при том, что нет никакого строгого определения основных и вторичных, посылающая станция требует ответа уровня канала, названного подтверждением от принимающей станции для каждого передаваемого нумерованного кадра информации. Станция может продолжить передавать I-кадры к другой станции, пока количество неподтвержденных кадров не достигает предела. Это количество называют "размером окна", и, как правило, настройками по умолчанию к 7. Можно увеличить размер окна на каналах, где существует много задержки для устранения необходимости для посылающей станции, чтобы остановиться и ждать ответа. Это обычно не необходимо, особенно в ситуациях, где локально подтвержден LLC. Когда посылающая станция достигает окна передачи, абонентские телефоны, опрос укусил, чтобы вынудить принимающую станцию передать ответ. В маршрутизаторе размер окна называют llc2 local-window.

Принимающая станция имеет опцию для отказа в подтверждениях, пока или определенное число I-кадров не поступает или таймер, истекает. Эти параметры называются N3 и T2, соответственно. Таким образом, можно одним кадром RR подтвердить передачу сразу нескольких кадров, а также отправить подтверждение поверх I-кадра. Cisco вызывает llc2 ack-max счетчика N3. Значение по умолчанию три указывает, что маршрутизатор отказывает в подтверждении, пока маршрутизатор не получает три I-кадра, или пока не истекает таймер T2 или llc2 ack-delay-time.

Модификация этих параметров на станции без рассмотрения партнерской станции может влиять на время отклика и пропускную способность. Например, рассмотрите то, что произошло бы, если local-window посылающей станции установлен в 5, и принимающая станция имеет значения 7 для Ack-max и 500 миллисекунд для Ack-delay-time.

В этом случае посылающая станция передает пять кадров, затем ждите подтверждения перед продолжением. Поскольку получатель отказывает в подтверждениях, пока семь кадров не будут приняты, он не передаст подтверждение, пока не истекают 500 времен задержки миллисекунды. Можно существенно улучшить производительность при понижении максимального значения уведомления на принимающую станцию.

Другой общий параметр LLC2 называют таймером TWS. Маршрутизатор называет это llc2 idle-time. Когда никакие I-кадры не передаются, цель таймера TWS состоит в том, чтобы поддержать сеанс LLC2 активным в течение периодов. Вы не можете улучшить пропускную способность и производительность при понижении этого значения. При истечении срока таймераTi посылается кадр RR с битом опроса, чтобы получить ответ от приемника. Если станция не отвечает, станция повторена после llc2 tpf-time, пока не истекло количество повторных попыток, определенных llc2 n2. В то время сеанс разъединен.

Увеличьте время простоя для сокращения суммы издержек на канале LLC2, и можно отрегулировать это как альтернативу локальному подтверждению. Рассмотрите пример, где 200 DSPQS связаны с NCP. Каждый из PU поддерживает независимый сеанс LLC2. Если каждый передает поддержку активности каждые десять секунд, существует 20 кадров издержек каждую секунду. При увеличении времени простоя до 30 секунд сумма служебных кадров уменьшает до 6.67 кадров в секунду. Недостаток к этому aproach - то, что станции занимают больше времени, чтобы обнаружить, что их партнер недостижим. Но в зависимости от ситуации, это могло быть хорошей вещью.

Перенастраиваемые параметры LLC2

Команда По умолчанию Описание
llc2 ack-delay-time>/b> msec 100 Количество времени ожидания ответа перед посылкой подтверждения, когда значение ack-max не было получено.
llc2 ack-max count 3 кадра Количество кадров для получения перед отправкой подтверждения.
llc2 idle-time msec 10000 Время между опросами в течение периода простоя.
счетчик llc2 local-window 7 кадров Количество кадров для передачи прежде, чем ждать ответа.
llc2 n2 count 8 повторов Число раз, при котором нераспознанные I-кадры или опросы отправляются без приема ответа, до завершения сеанса.
llc2 t1-time msec 1000 Период времени для ожидания ответа прежде, чем повторно передать I-кадры. На этот раз потребности быть достаточно большим для размещения задержки приема-передачи.
llc2 tbuzy-time msec 9600 Время, которое нужно выждать, прежде чем опрашивать станцию, которая отправила RNR. Измените значение только для увеличивания стоимости для станций, которые имеют необычно долго, интервалы занятости, прежде чем они очистят свой статус.
llc2 tpf-time msec 1000 Время ожидания окончательного ответа перед повторной отправкой кадра опроса.
llc2 trej-time msec 3200 Период времени для ожидания корректного кадра после передачи REJ.

Можно использовать команду show llc для наблюдения значений этих параметров:

ibu-7206#sh llc
LLC2 Connections: total of 1 connections
TokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMAL
V(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127
akmax=3, n2=8, Next timer in 8076
xid-retry timer      0/60000   ack timer       0/1000
p timer              0/1000    idle timer   8076/10000
rej timer            0/3200    busy timer      0/9600
akdelay timer        0/100     txQ count       0/2000

Примеры настроек параметров LLC2

В типичной сети DLSw+ с Локальной сетью Token Ring с обоих концов, конфигурация параметров LLC2 сделана на исходящем интерфейсе Token Ring.

/image/gif/paws/12247/llc2.gif

Имеется два отдельных сеанса LLC2. Поэтому настройте параметры LLC2 как показано здесь:

hostname dlsw1
!
source-bridge ring-group 100
!
dlsw local-peer ...
dlsw remote-peer ...
!
interface token-ring 0
source-bridge 10 1 100
llc2 tpf-timer 2000
llc2 n2 20

hostname dlsw2
! 
source-bridge ring-group 100
! 
dlsw local-peer ...
dlsw remote-peer ...
! 
interface token-ring 0
source-bridge 20 1 100
llc2 tpf-timer 2000
llc2 n2 20

Примечание: Эти упрощенные конфигурации показывают только соответствующие настройки параметров LLC2.

Настройки параметров LLC2 должны совпасть с LLC2 paramters к FEP (к маршрутизатору DLSw1) и ПК (к маршрутизатору DLSw2). Когда узел DLSw+ центрального узла находится на маршрутизаторе CIP, конфигурация немного отличается.

/image/gif/paws/12247/llc2cip.gif

Удаленная конфигурация маршрутизатора DLSw+ остается неизменной. Однако сеанс LLC2 в центральном узле между CIP и стеком LLC2 в IOS. CIP представляет собой мэйнфрейм, а параметры LLC2 от мэйнфрейма к IOS настроены через адаптеры в LAN Token Ring (на CIP). Параметры LLC2 из IOS по направлению к мейнфрейму сконфигурированы на исходящий интерфейс. Это канал интерфейса x/2 (для CIP) и канал интерфейса x/0 (для xCPA). Например:

hostname dlsw1
! 
source-bridge ring-group 100
! 
dlsw local-peer ...
dlsw remote-peer ...
!
interface channel 0/2
llc2 tpf-timer 2000
llc2 n2 20
lan tokenring 0
source-bridge 10 1 100
adapter 0 4000.7513.0000
llc2 tpf-timer 2000
llc2 n2 20

Примечание: Эти упрощенные конфигурации показывают только соответствующие настройки параметров LLC2.

Если маршрутизатор CIP соединяется по LAN с локальной станцией, вы требуете только LLC2 parmameters под адаптерами CIP. Затем параметры LLC2 будут сопоставлены с параметрами ПК. Любые параметры LLC2 под каналом интерфейса 0/2 неэффективны.

/image/gif/paws/12247/llc2cipdirect.gif

hostname rtr1
! 
source-bridge ring-group 100
! 
interface channel 0/2
lan tokenring 0
source-bridge 10 1 100
adapter 0 4000.7513.0000
llc2 tpf-timer 2000
llc2 n2 20

Примечание: Эти упрощенные конфигурации показывают только соответствующие настройки параметров LLC2.

Если подключение устройств в DLSw+ через bridge-group, параметры LLC2 настроены на установке мостовой группы DLSW+ как показано здесь:

/image/gif/paws/12247/llc2bridge.gif

hostname dlsw2
!
dlsw local-peer ...
dlsw remote-peer 
dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20
! 
interface ethernet 0
bridge-group 1
bridge 1 protocol ieee

Примечание: Эти упрощенные конфигурации показывают только соответствующие настройки параметров LLC2.

Примечание: Несмотря на то, что можно настроить LLC2 под ethernet 0 интерфейсов, эти параметры не имеют никакого эффекта. LLC2 DLSw bridge-group был новым в программном обеспечении Cisco IOS версии 11.3.

Когда маршрутизатор настроен как конечная станция (например, SNASw и DSPU), необходимо настроить параметры LLC2 на исходящем интерфейсе. Обратите внимание на то, что не все виртуальные интерфейсы поддерживают конфигурацию параметров LLC2. Например: :

/image/gif/paws/12247/llc2snasw1.gif

Примечание: Эти упрощенные конфигурации показывают только соответствующие настройки параметров LLC2.

hostname snasw1
!
Interface fastethernet 0/0
llc2 tpf-timer 2000
llc2 n2 20
!
snasw cpname neta.snasw1
snasw port FASTETH0 FastEthernet0/0 conntype nohpr

Состояния ошибок LLC2

Некоторые ошибки на сеансах LLC2 являются обычными и восстанавливаемыми, например, случайные пропущенные кадры, или структурирует не в порядке. Они обычно приводят к REJ и ретранслируемым кадрам. Чрезмерный повторно передает, не обычны, и необходимо определить причину и решить вопрос. Чрезмерный повторно передает, может произойти из-за отбрасываний, разнообразных путей, перегрузки и избыточная задержка.

Некоторые ошибки в LLC2 неисправимы и всегда приводят к простою сеанса. Эти ошибки – исключительно ошибки нарушения протокола. Когда станции передают неопределенные контрольные поля или другую ошибочную информацию, они могут произойти. Эти нарушения протокола могут заставить станцию передавать ответ FRMR. Станция, отправившая ответ FRMR, скорее всего является не нарушителем, а лишь средством передачи сообщений. FRMR содержит информацию, которая определяет, почему FRMR передается, который является обычно, когда станция запрашивает другую станцию повторно передать I-кадр, который это уже подтвердило. Поскольку станция не может повторно передать кадр (потому что это уже сбросило от него), это не имеет никакого выбора, кроме как завершать сеанс LLC. Наиболее вероятная причина этого типа ошибок в том, что кадры повреждены.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


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


Document ID: 12247