Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel

Switchport trunk allowed vlan ADD и потеря управления коммутатором

Community Member
В этот раз мы рассмотрим такую частую и крайне неприятную ситуацию, как случайная потеря управления коммутатором Cisco Catalyst при неправильном добавлении VLAN в транк на аплинке. Многие инженеры с этой ситуацией сталкивались, и знают, насколько эта ошибка элементарна, обидна и неприятна. Кратко о самой проблеме.
Давайте представим, что у нас есть некая сеть, в которой (например, на уровне доступа) находятся несколько коммутаторов. Графически наш пример можно изобразить так:

Для определенности покажем конфигурации портов коммутаторов:

Access-Switch-2#sh run int f0/1
Building configuration...
Current configuration : 293 bytes
!
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 8,102,103,112,113,122,123,192,193,202,203,212
switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,323
switchport trunk allowed vlan add 392,393
switchport mode trunk
end
Access-Switch-2#sh run int vl 8
Building configuration...
Current configuration : 63 bytes
!
interface Vlan8
ip address 192.168.5.123 255.255.255.0
end
Access-Switch-2#
Access-Switch-1#sh run int f0/24
Building configuration...
Current configuration : 294 bytes
!
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 8,102,103,112,113,122,123,192,193,202,203,212
switchport trunk allowed vlan add 213,222,223,292,293,302,303,312,313,322,323
switchport trunk allowed vlan add 392,393
switchport mode trunk
end
Access-Switch-1#sh run int vl8
Building configuration...
Current configuration : 62 bytes
!
interface Vlan8
ip address 192.168.5.16 255.255.255.0
end
Access-Switch-1#

    Обычно один из VLAN на коммутаторе выбирается как VLAN управления. Именно через этот VLAN осуществляется удаленное управление каждым устройством по telnet, SSH, HTTP (нужное подчеркнуть), и именно в этом VLAN коммутатор имеет собственный IP адрес. Для нашего примера VLAN управления имеет VLAN id равный 8. Адреса управления коммутаторами представлены на схеме. Теперь давайте предположим, что какому-то инженеру необходимо добавить какой-то VLAN (например, 62) на этих коммутаторах и затерминировать этот VLAN на каком-то маршрутизаторе. После добавления нового VLAN на нужных коммутаторах нужно не забыть разрешить его на соответствующих транковых портах (дотянуть, так сказать, VLAN от какого-то коммутатора до точки терминации). Собственно в этом процессе наша проблема и кроется. Если инженер, настраивая Access-Switch-1 (через telnet или SSH), создаст на нем новый VLAN, а затем попытается этот VLAN разрешить на аплинке этого коммутатора (порту Fa0/24) не совсем корректной командой, то управление этим коммутатором потеряется:

Terminal_server#telnet 192.168.5.16
Trying 192.168.5.16 ... Open
User Access Verification
Username: admin
Password:
Access-Switch-1>en
Password:
Access-Switch-1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Access-Switch-1(config)#vlan 62
Access-Switch-1(config-vlan)#name NEW_CUSTOMER
Access-Switch-1(config-vlan)#exit
Access-Switch-1(config)#int f0/24
Access-Switch-1(config-if)#sw tr al vl 62

  Дальше в консоли обычно тишина, а в комнате мат.
  Происходит это потому, что забыв в синтаксисе команды switchport trunk allowed vlan дополнительный аргумент add, мы фактически перезаписываем список разрешенных VLAN на данном транковом порту, а не добавляем требуемый VLAN в этот самый список. Связность с коммутатором в VLAN управления пропадает, инженер расстривается. При этом восстановить управление по IP в новом VLAN не представляется возможным, если в новом VLAN не был создан интерфейс с каким-то IP адресом (как в примере выше).
Классический способ решения этой проблемы - это перезагрузка коммутатора. К коммутатору кого-то отправляют, чтобы перезагрузить его по питанию, и в результате свич загружается с прежней конфигурацией, где злополучного изменения еще нет.
  Однако есть способ восстановить управление таким коммутатором более быстрый и не требующий физического присутствия у коммутатора. Способ этот связан с технологией кластеризации коммутаторов. Технологию эту поддерживает подавляющее большинство актуальных на данный момент коммутаторов (с актуальными софтами) семейства Cisco Catalyst, а также модели, которые уже End-of-Life или End-of-Sale, но все еще повсеместно встречаются на сетях и пользуются большой популярностью (включая 2950, 3560, 3750 и прочие).
  Сразу скажу, что эту технологию нельзя путать со стекированием коммутаторов (например, с технологией StackWise). Стек из коммутаторов - это некое множество свичей, объединенных друг с другом с применением специального кабеля, соединяющего коммутаторы через специальные порты. В результате получается возможность управлять всем множеством коммутаторов как одним устройством, и сам стек ведет себя как один большой коммутатор.
  Кластеризация коммутаторов предполагает возможность управления множеством свичей (до 16 штук) с использованием всего одного IP адреса. При этом коммутаторы могут быть подключены друг к другу с использованием любых (по скорости и среде передачи) Ethernet линков. Коммутаторы продолжают вести себя как и ранее, не происходит их объединения в стек: они по-прежнему являются индивидуальными активными устройствами в L2 домене.
  Для начала посмотрим, как эта технология поможет нам решить нашу проблему с потерей управления коммутатором, а потом разберем, как именно она работает.
  Итак, мы потеряли управление одним коммутатором, но у нас осталась возможость открыть сессию управления до вышестоящего коммутатора (Access-Switch-2). Именно в этой сессии мы и будем работать.Для начала на этом коммутаторе мы включим поддержку кластеризации. Для этого служит простая команда cluster enable TEST-CLUSTER, в которой вам нужно задать имя нового кластера (в моем примере TEST-CLUSTER):

Access-Switch-2(config)#cluster enable TEST-CLUSTER
Access-Switch-2(config)#
  После ее ввода вам необходимо посмотреть, какие из соседних для нашего Access-Switch-2 коммутаторов подходят для объединения в кластер. В этом нам поможет команда show cluster candidates:


  В выводе этой команды мы видим, что наш Access-Switch-2 обнаружил одного кандидата на включение в кластер. Собственно поскольку в моем примере другие коммутаторы отсутствуют, нет сомнений, что речь идет именно о Access-Switch-1 (его hostname в графу Name не влезает полностью). Здесь нас больше всего будет интересовать МАС адрес утраченного коммутатора (0016.c819.d080). Его на этом этапе мы запоминаем.
  Как уже упоминалось, мы будем восстанавливать управление потерянным коммутатором со свича Access-Switch-2. Для того, чтобы это получилось, в транке между этими свичами должен быть хотя бы один живой VLAN. На утерянном коммутаторе собственно один единственный такой VLAN и остался (тот самый VLAN 62, добавление которого привело к возникновению проблемы), а вот на коммутаторе Access-Switch-2 этот VLAN в транк нужно добавить:

Access-Switch-2(config)#vlan 62
Access-Switch-2(config-vlan)#name NEW_CUSTOMER
Access-Switch-2(config-vlan)#exit
Access-Switch-2(config)#int f0/1
Access-Switch-2(config-if)#sw tr al vl add 62
Access-Switch-2(config-if)#

  Кстати, в этот момент, инженер уже обычно помнит про необходимость добавления аргумента add в момент добавления VLAN в транк.
  Итак, на данном этапе мы имеем два коммутатора, соединенные друг с другом транковым линком, в котором разрешен один лишь VLAN (в нашем случае 62). Далее в режиме глобальной конфигурации мы даем команду cluster member mac-address <MAC>, где указываем MAC адрес кандидата на включение в кластер (Access-Switch-1):

Access-Switch-2(config)#cluster member mac-address 0016.c819.d080
%ERROR:  member unreachable
Access-Switch-2(config)#

  По факту выполнения этой команды произойдет попытка подключения коммутатора с указанным MAC адресом в наш новосозданный кластер TEST-CLUSTER. Если вы получаете ошибку, которая представлена на примере, это значит, что придется чуть-чуть повозиться. Дело в том, что в этой команде также есть возможность задать VLAN для этого подключения, а также пароль дальнего коммутатора. Поэтому если с первого раза добавление не прошло успешно, можно попробовать выполнить cluster member mac-address <MAC> vlan <VLAN-ID>:

Access-Switch-2(config)#cluster member mac-address 0016.c819.d080 vlan 62
%ERROR:  member unreachable
Access-Switch-2(config)#

  Если это не помогает, то необходимо добавить к команде пароль для подключения к удаленному коммутатора. В качестве пароля должен фигурировать enable password коммутатора, управление которым вы восстанавливаете:

Access-Switch-2(config)#cluster member mac-adress 0016.c819.d080 password cisco vlan 62        
Access-Switch-2(config)#


  В моем примере это сработало, но если вы по-прежнему получаете ошибку, то нужно попробовать создать на коммутаторе Access-Switch-2 интерфейс в VLAN 62 и присвоить ему какой-нибудь IP адрес (возможно из той сети, которую вы с самого начала хотели присвоить этому VLAN) и повторить попытки с командой cluster member mac-address <MAC> password <password> vlan <VLAN id>.
   В результате ваши попытке должны привести к тому, что Access-Switch-2 просто примет команду к исполнению. Это означает, что ваш утерянный Access-Switch-1 подключен к вашем кластеру TEST-CLUSTER. Проверить это можно командой show cluster members:



  В этой команде нас будет интересовать индекс (или номер), с которым наш Access-Switch-1 добавился в кластер. Тут стоит упомянуть, что свич, на котором был создан кластер (в нашем случае Access-Switch-2) всегда получает индекс 0. После этого в привилегированном режиме нашего Access-Switch-2 выполняете команду rcommand <index> и вуаля:

Access-Switch-2#rcommand 1
Access-Switch-2-1#

  Выскочившее приглашение фактически открывает вам доступ в CLI коммутатора Access-Switch-1. На тот факт, что вы видите странную строчку Access-Switch-2-1 обращать внимания не стоит: так получается, поскольку вы обращаетесь к свичу с индексом 1 с хозяина кластера (Access-Switch-2).
После этого у вас есть возможность на коммутаторе Access-Switch-1 вручную исправить конфигурацию, которая привела к потере управления, и возможно, перерыву сервиса у пользователей. Когда вы восстановите управление по IP коммутатором Access-Switch-1, на коммутаторе Access-Switch-2 можно отключить всю конфигурацию кластера. Сделать это можно простой командой no cluster enable TEST-CLUSTER на коммутаторе Access-Switch-2.

Как это работает.
  Как я уже говорил, кластеризация коммутаторов предоставляет возможность управлять набором до 16 коммутаторов с одного единственного свича. При этом IP связности между этими коммутаторами может не быть, то есть все множество коммутаторов управляется через один и тот же IP адрес. Но вот связность на 2 уровне быть должна. Для того, чтобы организовать кластер из коммутаторов, необходимо распределить роли между ними. Ролей всего две: cluster command switch и cluster member switch. Как нетрудно догадаться, cluster command - это коммутатор, который владеет IP адресом, через который будет осуществляться управление всем кластером. В нашем случае это был коммутатор Access-Switch-2. Собственно когда мы на нем ввели команду cluster enable TEST-CLUSTER, мы его на эту роль и назначили.
  После этого cluster command пытается обнаружить соседние коммутаторы, которых он может подключить к новоиспеченному кластеру, то есть кандидатов. Здесь важно уточнить, что кандидаты - это еще не cluster members. То есть это коммутаторы которые могут быть включены в кластер, но еще не включены. Кандидаты должны удовлетворять следующим требованиям:

    1. Правильный софт, поддерживающий технологию кластеризации (http://cisco.com/go/fn наше все).

    1. Включенный глобально и на траковом порту CDP версии 2.

    1. Отсутствие членства в других кластерах (каждый коммутатор независимо от роли может являться частью только одного кластера).

    1. Подключение к cluster command коммутатору с использованием хотя бы одного VLAN (да-да, тот самый наш VLAN 62).

  При этом обнаружение кандидатов возможно как в топологии звезда, так и в других. Особых ограничений на схему подключения кандидатов, cluster member и cluster command нет.
Обнаружение кандидатов ведется с использованием протокола CDP, поэтому его функционирование критично для решения нашей задачи. Вообще с использованием CDP коммутаторы кластера могут обнаруживать новых кандидатов на расстоянии максимум 7 (но по умолчанию 3) хопов от границы кластера. Границей кластера является тот порт cluster member, через который нет подключения к другому (следующему) cluster member, но есть подключение к кандидату. Например:



  Cluster command коммутатор (Switch1), представленный на рисунке, сможет обнаружить коммутаторы Switch5, 6, 7 и 8 как кандидатов на включение в кластер. Тут мы предполагаем, что коммутаторы Switch2, 3, 4 уже включены в кластер и являются cluster member. Switch 9 не будет обнаружен как кандидат, поскольку он находится на расстоянии 4 хопов от границы кластера, а по умолчанию ограничение на "дальность обнаружения" составляет 3 хопа.
  Кстати, если между свичами, поддерживающими кластеризацию, включен вразрез какой-нибудь тупой хаб, который просто транслирует CDP сообщения, то проблем с обнаружением не будет. Но если между коммутаторами находится свич, который не поддерживает кластеризацию, то потенциальные кандидаты, находящиеся за таким коммутатором, обнаружены не будут. Например:




  Switch 2 на данном рисунке будет нормально обнаружен на cluster command (Switch1), а вот Switch4 - не будет, поскольку Switch3 не поддерживает кластеризацию.
Собственно в нашем примере после того, как мы назначили Access-Switch-2 на роль cluster command, ему при соблюдении всех условий не составляет обнаружить наш Access-Switch-1 как кандидата, что мы и наблюдаем в выводе show cluster candidates. Далее мы делаем из нашего кандидата настоящего cluster member (немного поиграв с конфигурацией), и после этого можем обращаться к нашему новоиспеченному cluster member с нашего cluster command с использованием команды rcommand.
  Кстати, еще одно применение этой прекрасной технологии состоит в том, что она позволяет "цеплять" по управлению абсолютно ненастроенные коммутаторы при подключении их к действующей сети. Например, в ситуации, когда вам нужно установить новый коммутатор где-то на сети доступа, обычно необходимо заранее этот коммутатор настроить для того, чтобы после установки сразу получить к нему удаленное управление. Эта настройка обычно включает в себя конфигурацию VLAN управления, адреса в этом VLAN, шлюза по умолчанию и какой-нибудь учетной записи для аутентификации. Но при использовании кластеризации, эту начальную конфигурацию можно вообще не производить. Коммутатор с завода прямо в коробке может быть отправлен прямо на требуемую площадку для установки. Как только он будет установлен в стойку и подключен к какому-нибудь коммутатору, управление которым у вас есть (по telnet или SSH), то использование этого нехитрого способа позволит вам получить доступ к новому коммутатору вообще без наличия IP связности с ним. Да здравствуют включенный по умолчанию CDP и присутствующий по умолчанию VLAN 1.
---
Андрей Петрунин,
Учебный центр Fast Lane
1 Комментарий
Community Member

Отличная статья! Был в такой ситуации сам. Иногда возможности перезагрузить коммутатор просто нет, так что данное решение - это просто спасение утопающих :) Большое спасибо.

5478
Просмотры
5
Полезный материал
1
Комментарии