Асинхронный режим передачи (ATM) : Эмуляция LAN (LANE)

Реализация HSRP поверх LANE

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


Содержание


Введение

Цель этого документа состоит в том, чтобы выделить проблемы, с которыми можно встретиться при осуществлении Протокола HSRP в среде Эмуляции LAN (LANE). Это описывает многие специфические особенности HSRP OVER LANE и предоставляет советы по устранению проблем для различных сценариев.

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

Требования

Для этого документа отсутствуют особые требования.

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

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

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

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

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

Таким образом, цель HSRP состоит в том, чтобы позволить хостам в подсети использовать одиночный "действительный" маршрутизатор, поскольку несколька маршрутизаторов шлюза по умолчанию участвуют в протоколе HSRP для избрания активного маршрутизатора, который принимает роль шлюза по умолчанию и резервного маршрутизатора в случае, если отказывает активный. Результат состоит в том, что шлюз по умолчанию, будет всегда казаться, произойдет, даже если изменится физический первый маршрутизатор перехода. Полное описание HSRP может быть найдено в RFC 2281 leavingcisco.com.

HSRP был разработан для использования по мультидоступу, передан в многоадресном режиме или передавал способные LAN (как правило, Ethernet, Token Ring или Интерфейс распределенных данных оптоволоконного канала [FDDI]). Поэтому HSRP должен работать хорошо по ATM - ЛИНИИ.

Могут возникнуть несколько ситуаций, включающих HSRP и Взаимодействие LANE:

  1. Начиная с Cisco Выпуск ПО IOS� 11.2, HSRP может работать "исходно" по LANE. В этом случае резервные команды настроены непосредственно на подчиненных интерфейс ATM, где находятся Клиенты эмуляции LAN (LEC). См. следующий рисунок.

    http://www.cisco.com/c/dam/en/us/support/docs/asynchronous-transfer-mode-atm/lan-emulation-lane/10446-hsrp1.gif

  2. Также существует экземпляр, где HSRP настроен на интерфейсах LAN (локальной сети), но часть подсети охватывает Облако LANE. Это выполнено промежуточным звеном коммутатора локальной сети (LAN) с ATM-интерфейсом (таким как Cisco Catalyst 5000 с Модулем LANE). См. следующий рисунок.

    http://www.cisco.com/c/dam/en/us/support/docs/asynchronous-transfer-mode-atm/lan-emulation-lane/10446-hsrp2.gif

  3. Наконец, существует "гибридная" ситуация, где некоторые маршрутизаторы HSRP подключены LANE, и другие находятся на LAN позади коммутатора локальной сети (LAN).

    http://www.cisco.com/c/dam/en/us/support/docs/asynchronous-transfer-mode-atm/lan-emulation-lane/10446-hsrp3.gif

Наглядные примеры

1) Собственный HSRP OVER LANE

Маршрутизаторы, участвующие в HSRP, передают "привет" пакеты по средству широковещания, чтобы учиться друг о друге и выбрать активные и резервные маршрутизаторы. Эти пакеты переданы к адресу групповой адресации 224.0.0.2 со Временем жизни (TTL) 1 и MAC-адресом пункта назначения групповой адресации 0100 5E00 0002.

LANE не представляет новых проблем здесь, таким образом, подробные данные, описанные в RFC 2281 leavingcisco.com все еще, применяются – посредством обмена привет, удачный ход, и оставляют пакеты, активные и резервные маршрутизаторы избраны.

Пакеты приветствия передаются по серверу широковещательных и неизвестных сообщений (ШИНА), и ниже приводится, что показал бы пакет атм отладки (на Групповой адресации Прямой виртуальный канал [VC]) и debug standby:

Medina#show run
[snip]interface ATM3/0.1 multipoint
 ip address 1.1.1.3 255.255.255.0 
 no ip redirects 
 no ip directed-broadcast
 lane client ethernet HSRP
 standby 1 ip 1.1.1.1
[snip]
Medina#show lane client
LE Client ATM3/0.1  ELAN name: HSRP  Admin:
up  State: operational
Client ID: 2                
LEC up for 14 minutes 34 seconds
ELAN ID: 0
Join Attempt: 7
Last Fail Reason: Config VC being released
HW Address: 0050.a219.5c54   Type: ethernet            
Max Frame Size: 1516
ATM Address: 47.00918100000000604799FD01.0050A2195C54.01
VCD  rxFrames  txFrames  Type      ATM Address
  0        0         0  configure  47.00918100000000604799FD01.00604799FD05.00
 12        1         3  direct     47.00918100000000604799FD01.00604799FD03.01
 13        2         0  distribute 47.00918100000000604799FD01.00604799FD03.01
 14        0       439  send       47.00918100000000604799FD01.00604799FD04.01
 15       453        0  forward    47.00918100000000604799FD01.00604799FD04.01
Medina#show atm vc 15
ATM3/0.1: VCD: 15, VPI: 0, VCI: 40
UBR, PeakRate: 149760
LANE-LEC, etype:0xE, Flags: 0x16C7, VCmode: 0x0
OAM frequency: 0 second(s)
InARP DISABLED
Transmit priority 4
InPkts: 601, OutPkts: 0, InBytes: 48212, OutBytes: 0
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
TTL: 0
interface =  ATM3/0.1, call remotely initiated,
call reference = 8388610
vcnum = 15, vpi = 0, vci = 46, state = Active(U10)
 , multipoint call
Retry count: Current = 0
timer currently inactive, timer value = 00:00:00
Root Atm Nsap address: 47.00918100000000604799FD01.00604799FD04.01
, VC owner: ATM_OWNER_UNKNOWN

Важный смотрит на то, что Клиент эмуляции ЛВС (LEC) получает по ШИНЕ (например, посредством групповой адресации вперед):

Medina#debug atm packet 
interface atm 3/0.1 vcd 15
ATM packets debugging is on
Displaying packets on interface ATM3/0.2 VPI 0, VCI 46 only
Medina#debug standby
Hot standby protocol debugging is on
*Feb 18 06:36:05.443: SB1:ATM3/0.1 Hello in 1.1.1.2
Active pri 110 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.007: SB1:ATM3/0.1 Hello out 1.1.1.3
Standby pri 100 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.439: ATM3/0.1(I):
VCD:0xF VPI:0x0 VCI:0x40 Type:0xE, LANE, ETYPE:0x000E
LECID:0x0004 Length:0x4A
*Feb 18 06:36:08.439: 0004 0100 5E00 0002 0000 0C07
AC01 0800 45C0 0030 0000 0000 0111 D6F8 0101
*Feb 18 06:36:08.443: 0102 E000 0002 07C1 07C1 001C
AAEE 0000 1003 0A6E 0100 6369 7363 6F00 0000
*Feb 18 06:36:08.443: 0101 0101 0001 0001 000C

Этот шестнадцатеричный дамп преобразовывает в придерживающееся:

VCD:0xF VPI:0x0 VCI:0x28: VCD number 15, VPI=0 and VCI=400
004: LECID from the sender of the packet
0100 5E00 0002: Destination MAC address for HSRP hellos
0000 0C07 AC01: Virtual MAC address of HSRP (the last octet is actually the standby group number)
0800: Type = IP
45C0 0030 0000 0000 0111 D6F8: IP header - UDP packet
0101 0102: Source IP = 1.1.1.2
E000 0002: Destination IP = 224.0.0.2
07C1 07C1 001C AAEE: UDP header - Source & Destination ports = 1985
00: HSRP version 0
00: Hello packet (type 0)
10: State (of the sender) is Active (16)
03: Hellotime (3 sec)
0A: Holdtime (10 sec)
6E: Priority = 110
01: Group
00: Reserved
6369 7363 6F00 0000: Authentication Data
0101 0101: Virtual IP address = 1.1.1.1

То, что примечательно, - то, что пакеты приветствия получены активным маршрутизатором с Виртуальным MAC - адресом (VMAC) как источник с MAC-адресом – это выбираемо, потому что обучающиеся мосты (коммутаторы), которые передают эти пакеты, обновят свою таблицу ассоциативной памяти с соответствующим местоположением VMAC.

Ключ к HSRP находится в сопоставлении между IP-адресом и MAC-адресом.

В самом простом выражении виртуальный IP - адрес постоянно связан с виртуальным MAC - адресом, и единственный аспект для волнения о - то, что коммутаторы всегда знают, где расположен этот виртуальный MAC - адрес. Это обеспечено, потому что hellos получены VMAC.

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:00.006
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:08
  Standby router is local
  Standby virtual mac address is 0000.0c07.ac01

Другая опция - то, что маршрутизаторы используют свой записанный - в (standby use-bia) адреса, сопоставленные с виртуальным IP - адресом. В этом случае сопоставление между виртуальным IP и MAC-адресом переключает время – недавно, активный маршрутизатор отсылает Протокол ARP для объявления о новом ВИРТУАЛЬНОМ IP К MAC-АДРЕСУ сопоставлении. ARP является просто незапрашиваемым ARP response.-

Примечание: Определенные, некоторый (более старые) стеки IP могут не понять ARP.

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100, use bia
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:02.130
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:09
  Standby router is local
  Standby virtual mac address is 0050.a219.5c54

Примечание: Для представления LANE ключ - то, что поверх ВИРТУАЛЬНОГО IP К MAC-АДРЕСУ сопоставления, там должен составлять VMAC-to-Network-Service-Access-Point (NSAP) сопоставление адресов. Это сопоставление просто решено через Протокол преобразования адресов для эмуляции локальной сети (LE-ARP) процесс: LEC, желающий передать трафик к активному шлюзу, будет использовать LE-ARP для VMAC (или физический МАС при использовании фиксированного MAC - адреса [BIA]).

Теперь рассмотрите то, что происходит, когда новый маршрутизатор становится активным: для LEC, которые будут информированы о новом местоположении активного шлюза (новое Сопоставление VMAC-NSAP), должна модифицироваться Таблица le-arp. По умолчанию таймаут записей LE-ARP каждые пять минут, но, в большинстве случаев, полагаясь на этот таймаут является недопустимой конвергенцией, должно быть быстрее. Решение зависит от того, выполняет ли LEC, принимающий новое Состояние Активно, Версию LANE (эмуляции локальной сети) 1 или версию 2 (см. ATM Forum.com leavingcisco.com для Спецификаций эмуляции локальной сети (LANe)):

  • Версия LANE (эмуляции локальной сети) 1

    Когда маршрутизатор становится активным, в дополнение к шагам, описанным в RFC 2281 leavingcisco.com, он отсылает LE-NARP для создания новой привязки VMAC К АДРЕСУ ТОЧКИ ДОСТУПА К СЕТЕВОЙ СЛУЖБЕ (NSAP) известной. Согласно Спецификациям эмуляции локальной сети (LANe), после приема LE-NARP, LEC может принять решение очистить или обновить запись LE-ARP, соответствующую MAC-адресу. Тенденция в Cisco состоит в том, чтобы принять больше консервативного подхода и принять решение очистить запись LE-ARP – это вызовет LEC к сразу переLE-ARP, не имея необходимость ждать пятиминутного таймаута.

    Примечание: Это решение может вызвать проблему совместимости, описанную ниже.

  • Версия LANE (эмуляции локальной сети) 2

    В Версии LANE (эмуляции локальной сети) 2 были облегчены определенные, некоторый недостатки Версии LANE (эмуляции локальной сети) 1: LE-NARP был заменен targetless LE-ARP и LE-NARP без источников. targetless LE-ARP, как может замечаться, как механизм объявляет новые связывания, тогда как цель LE-NARP без источников состоит в том, чтобы представить устаревший существующая привязка MAC К АДРЕСУ ТОЧКИ ДОСТУПА К СЕТЕВОЙ СЛУЖБЕ (NSAP). Путем это внедрено, то, что, если маршрутизатор изменяется от Резерва до Активного, это отсылает targetless LE-ARP (это используется для объявления Сопоставления MAC-NSAP), и если это изменяется от Активного до Резерва, это отсылает LE-NARP без источников (это используется для рендеринга устаревшей Привязки MAC-NSAP).

Проблема - совместимость

Существует проблема, которая возникает достаточно часто для получения более всестороннего исследования. Спецификации Версии LANE (эмуляции локальной сети) 1 сообщают, что LE-NARP должен задать "старую привязку", которая делается устаревшей путем определения (старого) целевого NSAP (T-NSAP) адрес. Как правило, маршрутизаторы, участвующие в HSRP, не поддерживают данные, направляет друг между другом.

Поэтому недавно активный маршрутизатор не знает эту информацию, и это примет решение не завершить это поле, так как это не знает лучше. Это - несущественное нарушение спецификаций, и некоторые поставщики проигнорируют эти пакеты, если Поле адреса t-snap будет всеми нолями. К сожалению, нет никакого обходного пути для этого – если LE-NARP проигнорирован, положитесь на таймаут LE-ARP (как правило, пять минут), прежде чем будет изучена корректная привязка.

Когда LE-ARP или LE-NARP передаются с Полем адреса t-snap всех нолей, это называют "targetless". Как замечено выше, с появлением Версии LANE (эмуляции локальной сети) 2 (и Многопротокольная коммутация по ATM [MPOA]), это стало стандартным, и проблема прекращает существование.

Это - то, что сделано в Версии LANE (эмуляции локальной сети) 1, где могут возникнуть проблемы:

  • Если маршрутизатор знает "старую привязку", это могло бы также повиноваться спецификациям. Эти отладки теперь взяты на Контроле, Распределяют VC:

    ATM0/0.1(I):
    VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
    FF00 0101 0008 0000 0000 0018 0003 0000 0000 0000 0000 0000 0001 0000 0C07
    AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 4700 9181
    0000 0000 101F 2D68 0100 102F FBA4 0101 0000 0000 0000 0000 0000 0000 0000
    FF00: Marker = Control Frame
    0101: ATM LANE version 10
    008: Op-code = LE_NARP_REQUEST
    0000: Status
    0000 0018: Transaction ID0003: Requester LECID0000: Flags
    0000 0000 0000 0000: Source LAN destination 
    (not used for an LE-NARP)
    0001 0000 0C07 AC01: Target LAN destination
    (the 0001 indicates a MAC address as opposed to a route descriptor)
    4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401: Source NSAP address
    (new NSAP address to be bound)
    0000 0000: Reserved
    4700 9181 0000 0000 101F 2D68 0100 102F FBA4 0101: Target NSAP address
    (old NSAP address to be rendered obsolete)
  • Если это не знает "старую привязку", это прилагает все усилия и по крайней мере объявляет новое:

    ATM0/0.1(I):
    VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
    FF00 0101 0008 0000 0000 0014 0003 0000 0000 0000 0000 0000 0001 0000 0C07
    AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

    Примечание: На этот раз Адрес T-NSAP является пробелом.

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

Примечание: Программное обеспечение, которое поддерживает MPOA также, поддерживает Версию LANE (эмуляции локальной сети) 2.

Советы по поиску и устранению неполадок

Собственный HSRP OVER LANE не должен порождать слишком много проблем кроме потенциальной проблемы совместимости из-за LE-NARP, лишенного T-NSAP.

Если маршрутизаторы испытывают затруднения в установлении, являются ли они Активными или Резервными, используйте команду debug standby, чтобы видеть, замечены ли hellos с обеих сторон. В противном случае тогда ШИНА, вероятно, правильно не передает пакеты.

2) HSRP по маршрутизаторам позади LANE

Когда HSRP настроен на интерфейсах LANE маршрутизаторов, расположенных позади Облака LANE, как проиллюстрировано на рисунке 2, ситуация становится более сложной.

Примечание: Этот рисунок логически изображает факт, что маршрутизатор является подключенным не-ATM. Это должно не обязательно быть в устройстве, отдельном к коммутатору локальной сети (LAN) (Модульный коммутатор с функциями маршрутизатора [RSM] в Cisco Catalyst 5000 подпадает под этот случай).

Снова, трудность возникает из-за сопоставления MAC-address-to-NSAP-address, наложенного LANE. Как обращено внимание выше, когда VMAC переключается на устройство (когда новый маршрутизатор становится активным), который соответствует другому Адресу точки доступа к сетевой службе (NSAP), всем устройствам, подключенным к Облаку LANE, нужно сообщить. Это довольно легко внедрено в собственной среде HSRP OVER LANE при помощи LE-NARP (или targetless LE-ARP).

Проблема в этом втором случае состоит в том, что LEC не знают ни о какой информации об уровне 3 (IP), они исключительно разработаны к передачам пакета по мосту между двумя другими средами (LAN и ATM).

Например, на рисунке 2, если бы Маршрутизатор 2 внезапно стал Активным, то было бы выбираемо для коммутатора локальной сети (LAN) 2 сообщить всем устройствам, связанным с ATM (LANE) облако о новом Сопоставлении VMAC-NSAP. LEC в коммутаторе локальной сети (LAN) 2, как говорят, проксирует для всех MAC-адресов, которые находятся позади него. Устройства по LANE, желающему передать трафик к этим MAC-адресам, должны сделать так посредством настройки направления передачи данных к этому LEC. Интуитивно, можно было думать, что это не будет большой проблемой с тех пор, как только Маршрутизатор 2 принимает Активное состояние, он начнет получать hellos с VMAC как источник с MAC-адресом. Эта информация была бы тогда изучена всеми коммутаторами локальной сети (LAN), и все будет сходиться быстро. Это истинно в несредах эмуляции локальной сети (LANe), но LANE является особенным по придерживающейся причине:

В LANE пакет данных может обычно передаваться через два пути:

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

  • ШИНА для одноадресных одноадресных и многоадресных сообщений.

Поэтому тот же MAC-адрес будет отправляемые пакеты, которые будут получены коммутатором локальной сети (LAN) более чем два других пути. Многоадресные сообщения и одноадресные одноадресные поступят посредством ШИНЫ, тогда как известные индивидуальные рассылки поступают посредством направлений передачи данных. Если бы никакое особое усилие не было сделано, коммутатор локальной сети (LAN) продолжал бы изучать этот MAC-адрес или по направлению передачи данных или по ШИНЕ в зависимости от последнего полученного пакета. Это - нежелательный, потому что ШИНА должна только использоваться для передавания пакеты для одноадресных одноадресных или многоадресных сообщений. На данном этапе ничто не изучено по ШИНЕ, но в действительности, примите решение сделать придерживающееся:

Packets received over the BUS are marked with the Conditional Learn (CL) 
bit set to 1(this bit is in a control overhead specific to Cisco LAN switches). The LAN switch 
will only update its CAM table with this entry if it does not already have an entry for this 
MAC address (in this VLAN). The idea is that if a switch receives a packet from a source 
that it does not know about, at least it will now know that it is located somewhere across 
the LANE cloud. Future packets for that MAC address will be forwarded to the BUS only as 
opposed to being flooded in the entire VLAN.

Для возврата к примеру безопасно предположить, что все LEC в этом ELAN уже знают о Сопоставлении VMAC-NSAP для Маршрутизатора 1 до того, когда Маршрутизатор 2 становится Активным. Все коммутаторы локальной сети (LAN) также знают, что VMAC находится позади коммутатора локальной сети (LAN) 1. Когда Маршрутизатор 2 становится Активным и получает пакеты приветствия, они переданы Облаку LANE по ШИНЕ. Поэтому ни один из коммутаторов локальной сети (LAN) не обновит их таблицы CAM с этой новой информацией, и все пакеты, переданные к этому VMAC, будут неверно направлены, пока коммутаторы локальной сети (LAN) не "забывают" об этой записи (устаревание по умолчанию, являющееся пятью минутами).

Примечание: Общие возможности подключения могли бы фактически быть потеряны в течение максимум 10 минут, так как таймер устаревания LE-ARP на LEC также составляет пять минут по умолчанию. Сокращение таймера устаревания для MAC-адресов поможет, но фактически не решает проблему.

Существует два решения для этого:

  1. Если коммутаторы локальной сети (LAN) являются не-Cisco, возвращаются к методу, описанному выше: использование прошитого адреса. Если маршрутизаторы только используют свой MAC-адрес для определения источника пакетов приветствия и что сопоставление изменений виртуального IP - адреса каждый раз, когда переключатель происходит, нет никакого беспорядка, возможного как, туда, где расположены эти MAC-адреса.

  2. Если коммутаторы локальной сети (LAN) являются Cisco Catalyst, то продолжайте использовать VMAC для модификаций, предоставленных Distributed Defect Tracking System (DDTS), покрытым идентификаторами ошибок Cisco CSCdj58719 (только зарегистрированные клиенты) и CSCdj60431 (только зарегистрированные клиенты).

    В сущности, когда маршрутизатор принимает Активное состояние, в дополнение к ARP (незапрашиваемый ответ ARP), что это передает в соответствии с RFC 2281 leavingcisco.com, маршрутизатор передает второй ARP с MAC - адресом назначения 0100.0CCD.CDCD. Когда Cisco Catalyst получает этот пакет, это делает две вещи:

    • Это очищает запись LE-ARP, которую это имеет для VMAC.

    • Это изучает VMAC по ШИНЕ.

Из-за этого нет никаких более устаревших записей LE-ARP в различных LEC, и новое местоположение VMAC распространяется ко всем коммутаторам (например, вне Облака LANE). Для этого для работы правильно должны быть встречены придерживающиеся минимальные требования к программному обеспечению:

  • Маршрутизаторы должны иметь, по крайней мере, программное обеспечение Cisco IOS версии 11.1(24), версию 11.2 (13) или всю версию 12.0.

  • Модули LANE должны иметь, по крайней мере, версии версии 3.2 (8). 11.3W4 и позже приемлемы.

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

3) Смешанная среда

Существует одна заключительная проблема, которая может возникнуть в смешанных средах. При взятии сценария выше и добавлении непосредственно связанного конечного устройства LANE (маршрутизатор или рабочая станция), конечному устройству нужно сообщить об изменении местоположения активного шлюза тот же путь как в сценарии 1. Если недавно активный маршрутизатор связан позади коммутатора, единственное решение для самого коммутатора для отсылки LE-NARP от имени маршрутизатора, и это точно, что сделать.

В дополнение к шагам, описанным выше, если Cisco Catalyst берет пакет, предназначенный к 0100 0CCD CDCD, он отсылает LE-NARP (LE-NARP без источников при выполнении Версии LANE (эмуляции локальной сети) 2), какая собственная цель состоит в том, чтобы очистить кэши LE-ARP для VMAC.

Заключение

Как продемонстрировано, HSRP OVER LANE работает хорошо в принципе, но при определенных обстоятельствах пользователи могут потерять подключение для коротких периодов времени при попадении в одну из лазеек, описанных выше.

Важно!: Для обеспечения успеха HSRP OVER LANE придерживайтесь, по крайней мере, этих двух рекомендаций:

  • Для сейфа обновите к, по крайней мере, последней версии программного обеспечения Cisco IOS версии 12.0.

  • В средах mult-поставщика, лучше использовать Версию LANE (эмуляции локальной сети) 2 или прошитый адрес во избежание проблем.

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

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


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


Document ID: 10446