Коммутатор недоступен по управлению
Для устранения неполадок мы должны пройти путь от нижней части модели OSI к верхней. Для этого нам придется начать с протоколов, которые используются для коммутации. Будем думать о VLAN, транкинге, об агрегировании каналов и связующем дерева. Мы рассмотрим различные протоколы и различные сценарии, где "что-то работает" не так. Мы решим эти проблемы с помощью комбинации команд show и debug . Первая остановка . проблемы с интерфейсом!
CASE 1
В этом примере мы имеем коммутатор в центре и два компьютера, которые подключены к нему. Каждый компьютер имеет свой IP-адрес, и они должны иметь возможность пинговать друг друга. Мы будем считать, что компьютеры настроены правильно и там нет никаких проблем.
SwitchA(config) interface fa0/1
SwitchA(config-if)duplex auto
Изменим настройки интерфейса на duplex auto, чтобы коммутатор мог само настроиться.
Может быть, нам повезет. но не в этот раз, пинг не работает.
Интерфейс fa0 / 3 , подключенный к хосту B, также не работает. После проверки кабелей и разъемов мы можем проверить ошибки дуплекса и скорости. Дуплекс включен в режим auto, так что это не является проблемой. Скорость была установлена на 10 Мбит, однако в то время как этот интерфейс является каналом Fast Ethernet (100 Мбит).
SwitchA(config) interface fa0/3
SwitchA(config-if) speed auto
Давайте переключим скорость на авто и посмотрим, что произойдет.
Похоже, что несоответствие скорости привело к тому, что интерфейс перешел в состояние down. Изменение его на auto-speed возвращает интерфейс в состояние up.
Это то, что мы искали. Интерфейсы, с которыми мы работаем, оба показывают состояние up/up. По крайней мере, теперь мы знаем, что нет никаких ошибок в кабеле, скорости или дуплексе.
Теперь наш пинг проходит.
Первый урок усвоен: Проверьте свои интерфейсы и посмотрите, отображаются ли они как up/up.
CASE 2
Та же топология, но здесь другая проблема.
Хост A не может пропинговать хост B. Мы начнем с проверки интерфейсов:
Состояние интерфейса FastEthernet0/3 выглядит нормально, но что-то не так с интерфейсом FastEthernet 0/1.
Давайте изучим его подробнее:
Используйте команду show interfaces status err-disabled , чтобы узнать, почему интерфейс перешел в режим error-disabled . Это сообщит нам, что причина-безопасность порта.
Мы можем посмотреть на конфигурацию безопасности порта, и мы видим, что только 1 MAC-адрес разрешен. Последний MAC-адрес, который виден на интерфейсе - 000с.2928.5c6c.
Выше мы видим, что интерфейс был настроен для обеспечения безопасности на другой MAC-адрес. Именно по этой причине порт перешел в режим err-disabled.
SwitchA(config) interface fa0/1
SwitchA(config-if) no switchport port-security
Давайте уберем port security, чтобы решить эту проблему.
SwitchA(config)interface fa0/1
SwitchA(config-if) shutdown
SwitchA(config-if) no shutdown
Главное, что вы не должны забыть сделать - это после очистки настройки от port security ваш интерфейс все еще находится в режиме err-disabled. Вам нужно выполнить команды отключения и включения порта (shutdown и no shutdown), чтобы он снова заработал!
Консоль сообщает нам, что интерфейс теперь включен.
Как мы видим эхо-запрос проходит между компьютерами. Проблема решена!
Урок 2 усвоен: проверьте, находится ли интерфейс в состоянии err-disabled , и если да, то: а) проверьте, почему это произошло, и Б) решите проблему.
CASE 3
Давайте продолжим с другой проблемой. Та же топология, но опять проблема.
Эти два компьютера не "видят" друг друга.
Интерфейсы выглядят хорошо, никаких ошибок здесь нет.
И так мы видим, что port security отключена на этом коммутаторе. На данный момент мы, по крайней мере, знаем, что нет никаких проблем с интерфейсом и port security не фильтрует никакие MAC-адреса.
В данный момент это хорошая идея, чтобы проверить информацию о VLAN . Вы можете использовать команду show vlan , чтобы быстро проверить, к какой VLAN принадлежат интерфейсы.
Как вы можете видеть, наши интерфейсы находятся не в одной и той же VLAN.
SwitchA(config) interface fa0/3
SwitchA(config-if) switchport access vlan 1
Мы переместим интерфейс fa0/3 обратно в VLAN 1.
Теперь оба компьютера находятся в одной VLAN. Проблема решена! Урок 3 усвоен: убедитесь, что интерфейсы находится в нужной VLAN.
CASE 4
Пришло время для другой проблемы! Наши два компьютера не пингуюся между собой. Вы теперь знаете, как выглядит неудачный пинг, поэтому скрин не будет публиковаться снова.
Интерфейсы не показывают никаких ошибок.
Мы изучим настройку VLAN. Вы видите, что FastEthernet 0/1 находится в VLAN 10, но мы нигде не видим FastEthernet 0/3. Вот возможные причины:
- Что-то не так с интерфейсом. Мы проверили и убедились, что это не так, потому что он показывает состояние up/up, поэтому он кажется активным.
- Интерфейс не в режиме access port, а в режиме trunk.
Быстрый взгляд на информацию о коммутаторе показывает нам, что нам нужно знать. Мы убедились, что интерфейс fa0/3 находится в режиме trunk, а native VLAN - 1. Это означает, что всякий раз, когда хост B отправляет трафик и не использует маркировку 802.1 Q, наш трафик заканчивается в VLAN 1.
SwitchA(config)interface fa0/3
SwitchA(config-if)switchport mode access
SwitchA(config-if)switchport access vlan 10
Мы включим fa0/3 в режим доступа и убедимся, что он находится в VLAN 10.
Оба интерфейса теперь активны в VLAN 10.
Возможно, лучше проверить информацию на коммутаторе.
Урок 4 усвоен : убедитесь, что интерфейс находится в нужном режиме (доступ или магистральный режим).
CASE 5
Те же два компьютера, тот же коммутатор. Однако этот сценарий немного интереснее. Компьютеры не могут пинговать друг друга, поэтому давайте пройдемся по нашему списку "возможных" ошибок:
Интерфейсы выглядят хорошо, up/up-это очень хорошо.
Оба интерфейса находятся в VLAN 10, так что это тоже хорошо.
Просто чтобы быть уверенным. там нет port security. Это очень интересная ситуация. Интерфейсы работают (в состоянии up/up), мы находимся в одной VLAN, и нет никакой защиты портов. Что еще может быть причиной "перекрытия" трафика?
Ага! Это может быть не то, о чем нам может прийти в голову, но мы же можем использовать VACLs (VLAN access-list), чтобы разрешить или запретить трафик в пределах VLAN. Если вы устраняете неполадки коммутаторов, то необходимо проверить эту настройку, если все остальное кажется вам нормальным. В этом случае есть VACL, подключенный к VLAN 10, давайте проверим его.
Есть два порядковых номера . 10 и 20. Порядковый номер 10 соответствует access-list 1, и его задача состоит в том, чтобы отбросить трафик. Давайте посмотрим, что это за access-list 1:
Не смущайтесь из-за заявления о разрешении здесь. Использование оператора permit в access-list означает, что он будет "соответствовать" подсети 192.168.1.0/24. Наши два компьютера используют IP-адреса из этого диапазона. Если он соответствует этому access-list, то VLAN access-map отбросит трафик.
Давайте изменим действие на "forward" и посмотрим, решит ли оно нашу проблему.
Ну вот, все работает.
Урок 5 усвоен : если все остальное кажется нормальным, убедитесь, что нет никакого VACL!
CASE 6
Давайте продолжим урок 6 с другой топологией. Теперь вы знаете, что нам нужно сначала проверить интерфейсы, а затем VLAN. В этом примере у нас есть те же два компьютера, но теперь у нас есть два коммутатора. Пинг от Хост А к Хосту Б не работает, так с чего начнем поиск?
Сначала мы проверим интерфейс fa0/1 на коммутаторе 1. Интерфейс запущен и работает, это switchport, назначенный для VLAN 10. Пока все выглядит неплохо. Port security не включен, так что нам не нужно беспокоиться об этом.
Давайте проверим то же самое на коммутаторе 2. Интерфейс работает, и он был назначен на VLAN 10.
В данный момент мы видим, что интерфейсы, " смотрящие " к компьютерам выглядят хорошо. В этот момент Вы могли бы сделать две вещи:
- Подключите другой компьютер к коммутатору 1 и назначьте его во VLAN 10. Посмотрите, можно ли общаться между компьютерами во VLAN 10, когда они подключены к одному коммутатору. Сделайте то же самое на коммутаторе 2.
- Проверьте интерфейсы между коммутатором 1 и коммутатором 2.
Мы сконцентрируем свое внимание на интерфейсах между коммутатором 1 и коммутатором 2, потому что там много чего может пойти не так!
Интерфейсы не показывают никаких проблем, время проверить информацию о switchport.
Коммутатор A находится в магистральном режиме и использует инкапсуляцию ISL.
Коммутатор B также находится в магистральном режиме, но использует инкапсуляцию 802.1Q. Имейте в виду, что (в зависимости от модели коммутатора) административный режим по умолчанию может быть dynamic auto . Два интерфейса, которые оба работают в dynamic auto режиме, станут портом доступа ( access ). Лучше всего самостоятельно переключить интерфейс в магистральный режим. В нашем случае оба интерфейса магистральные, так что это хорошо, но у нас есть несоответствие протокола инкапсуляции.
SwitchA(config) interface fa0/15
SwitchA(config-if) switchport trunk encapsulation dot1q
Мы изменим тип инкапсуляции, чтобы оба коммутатора использовали протокол 802.1Q.
Проблема решена! И опять все работает.
Урок 6 усвоен : убедитесь, что при настройке магистралей используется один и тот же протокол инкапсуляции.
CASE 7
Вот опять тот же сценарий. Сейчас рассмотрим еще кое-что, что важно проверить при решении проблем trunk. Предположим, мы проверили и убедились, что следующие элементы не вызывают никаких проблем:
- Интерфейсы (скорость/дуплекс).
- Безопасность портов.
- Конфигурация Switchport (назначение VLAN, интерфейс, настроенный в режиме доступа).
К сожалению, эхо-запрос между компьютерами все еще не проходит. Давайте взглянем на интерфейсы fa0/15 на коммутаторах:
Проверим, что оба интерфейса находятся в магистральном режиме и что мы используем один и тот же протокол инкапсуляции (802.1 Q). Здесь нет никаких проблем. Что-нибудь еще, что может пойти не так с этой магистральной связью? Да!
Магистраль может быть работоспособной, но это не означает, что все VLAN разрешены по магистральному каналу связи. В приведенном выше примере вы видите, что разрешена только VLAN 20.
SwitchA(config)interface fa0/15
SwitchA(config-if)switchport trunk allowed vlan all
SwitchB(config)interface fa0/15
SwitchB(config-if)switchport trunk allowed vlan all
Давайте позволим всем VLAN пройти магистраль.
По магистральной линии может передаваться трафик VLAN 10 между двумя коммутаторами. В результате пинг идет между компьютерами. еще одна проблема решена!
Урок 7 усвоен : всегда проверяйте, разрешает ли магистраль все VLAN или нет.
CASE 8
Вот вам новый сценарий. Два компьютера, имеют разные IP-адреса. Коммутатор - это многоуровневый коммутатор. Поскольку компьютеры находятся в разных подсетях, нам приходится беспокоиться о маршрутизации.
Мы видим, что два компьютера не могут связаться друг с другом. С чего мы должны начать устранение неполадок?
Это статья не о настройке windows, но нам нужно обратить внимание на наши хосты. Поскольку компьютеры должны "выйти из своей собственной подсети", мы должны проверить, что IP-адрес шлюза по умолчанию в порядке и доступен.
Хост А может достичь шлюза по умолчанию, поэтому мы, по крайней мере, знаем, что хост А работает нормально.
Вот IP-конфигурация хоста B. Давайте проверим доступность шлюза по умолчанию!
Здесь тоже все работает. Мы знаем, что компьютеры рабочие, потому что они знают, как выйти из своей собственной подсети, и шлюз по умолчанию доступен. Пора проверить коммутатор.
Как мы видим, что хост А находится в VLAN 10 и хост B находится в VLAN 20. Мы не проверяли, включены ли интерфейсы, потому что мы можем пинговать IP-адреса шлюза по умолчанию. Это говорит о том, что fa0/1 и fa0/3 работают, но мы не знаем, к какой VLAN они принадлежат.
Были сконфигурированы два интерфейса SVI . Это IP-адреса, которые компьютеры используют в качестве шлюза по умолчанию. Так почему же наш коммутатор не маршрутизирует трафик?
Наличие IP-адресов на интерфейсах не означает автоматическую маршрутизацию трафика. Для этого нам потребуется таблица маршрутизации. Этот коммутатор не имеет
Давайте включим маршрутизацию на этом коммутаторе.
Давайте сделаем так, чтобы это выглядело получше. Теперь коммутатор знает, куда перенаправлять IP-пакеты на этом коммутаторе.
Вот так. теперь два компьютера могут достучаться друг до друга! Проблема решена! Урок 8 усвоен : если вы используете многоуровневый коммутатор для маршрутизации interVLAN, убедитесь, что интерфейсы SVI настроены правильно и что маршрутизация включена.
Мы рассмотрели наиболее распространенные ошибки, которые могут произойти с нашими интерфейсами, VLAN, транками и проблемами маршрутизации при использовании многоуровневых коммутаторов.
В следующей статье мы рассмотрим связующее дерево. Spanning-tree -довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи. давайте рассмотрим это в следующей стать
Если коммутатор стал недоступен по управлению, можно проверить следующее:
- Выяснить, доходит ли трафик до конечных пользователей.
- Проверить наличие логов по данному коммутатору на syslog сервере. Нет ли чего-либо подозрительного.
- Можно сделать трассировку до проблемного коммутатора, если проблема на последнем хопе, то следует проверить физику, маки,есть ли arp-запись на ближайшем маршрутизаторе.
Если доступа по консоли нет, тогда можно попробовать перезагрузить его по питанию.
Если доступ есть, можно проверить загрузку CPU
Last 5 second CPU USAGE: 1%
Last 30 second CPU USAGE: 1%
Last 5 minute CPU USAGE: 1%
From running CPU USAGE: 99
Last 5 second CPU IDLE: 98%
Last 30 second CPU IDLE: 99%
Last 5 minute CPU IDLE: 99%
From running CPU IDLE: 99%
Type Rate-limit TotPkts CurState DelayCount
ARP 400 5544105 allowed 2581
BFD 200 0 allowed 0
BFD6 200 0 allowed 0
BGP 200 0 allowed 0
BGP4+ 200 0 allowed 0
BPDU_TUNNEL 200 0 allowed 0
CLUSTER-DP 300 0 allowed 0
CLUSTER-DR 300 0 allowed 0
DHCP 200 0 allowed 0
DHCP-SNOOPING 200 0 allowed 0
DHCP_SUPPRESS 200 0 allowed 0
DHCPv6 200 0 allowed 0
DHCPv6-SNOOPING 200 0 allowed 0
DMAC-CPU 300 0 allowed 0
DNS 100 0 allowed 0
DOT1x 100 0 allowed 0
Dot1x-pass 100 0 allowed 0
EAPOU 100 0 allowed 0
EFMOAM 40 0 allowed 0
ERPS 60 1360 allowed 0
FTP 500 0 allowed 0
FTP6 500 0 allowed 0
GMRP 20 0 allowed 0
GVRP 20 0 allowed 0
HSRP 100 0 allowed 0
ICMP-REDIRECT 50 0 allowed 0
IGMP 200 0 allowed 0
IPV6-HOPLIMIT 100 0 allowed 0
IPv6-NTP 50 0 allowed 0
LACP 20 0 allowed 0
LDP 200 0 allowed 0
LLDP 20 91969 allowed 0
LOOPBACK 20 0 allowed 0
MLD 200 0 allowed 0
MRPP 20 4 allowed 0
MULTICAST 20 0 allowed 0
MULTICAST6 20 0 allowed 0
NDP-SNOOPING 500 0 allowed 0
NORMAL 500 5 allowed 0
NS-NA 500 10028 allowed 1
NTP 50 39734 allowed 0
OSPF 100 0 allowed 0
OSPF6 100 0 allowed 0
PIM 200 0 allowed 0
PIM6 200 0 allowed 0
PPPoE 100 0 allowed 0
PTP 0 0 allowed 0
RA-SNOOPING 100 0 allowed 0
RADIUS 100 0 allowed 0
RADIUS6 100 0 allowed 0
RIP 100 0 allowed 0
RIP6 100 0 allowed 0
RS-RA 100 3044 allowed 2
SMART-DISCOVERY 10 0 allowed 0
SNMP 500 0 allowed 0
SNMP6 500 0 allowed 0
SSH 100 0 allowed 0
SSH6 100 0 allowed 0
STP 80 0 allowed 0
TACAS 100 0 allowed 0
TACAS6 100 0 allowed 0
TELNET 100 3233 allowed 0
TELNET6 100 0 allowed 0
TFTP 500 0 allowed 0
TFTP6 500 0 allowed 0
TYPE-TTL0 100 0 allowed 0
ULDP 20 0 allowed 0
ULPP 300 0 allowed 0
UNKNOWN_SMAC 100 0 allowed 0
VRRP 100 0 allowed 0
VRRP6 100 0 allowed 0
Данная команда показывает информацию о принимаемых пакетах в секунду от типа протокола.
TotPkts – сколько всего пакетов; DelayCount - показывает, сколько раз был превышен счетчик принимаемых пакетов в секунду. Параметр Rate-limit можно увеличить, однако нужно учитывать, что загрузка на процессор от этого увеличится.
A.B.C.D IP address of remote logging server
X:X::X:X IPv6 address of remote logging server
executed-commands Command that user input
loghost Log host
source-ip Source ip
facility Set facility
level Logging message level
critical Critical level(2)
debugging Debugging level(7)
informational Informational level(6)
warnings Warnings level(4)
- Проверить трафик на портах, возможно на сети образовался шторм.
- Настроить дебаг:
Если не удается разобраться с причинами, просьба обратиться в техническую поддержку, в ней указать используемую версию ПО (возможно данная версия является нестабильной), выводы команд, указанных выше, а так же show tech-support до и после перезагрузки.
Примечание: Данные советы предполагают, что индикатор Ethernet на вашем коммутаторе горит при подключении компьютера к коммутатору по кабелю, и ваш компьютер работает исправно, если он подключен к роутеру напрямую.
Если индикатор Ethernet не горит, когда компьютер подключён кабелем к коммутатору, то воспользуйтесь следующим FAQ: «Что делать, если Ethernet индикаторы не горят на неуправляемом коммутаторе?»
Проблем может быть несколько: настройки на вашем роутере, или коммутатор работает некорректно.
Для выявления проблемы необходимо последовательно следовать инструкциям ниже:
Шаг 1. Сначала выполните следующий тест.
- Подключите два ваших компьютера кабелями к коммутатору (при этом отключите любые другие кабели от коммутатора и компьютеров); настройте на ваших компьютерах статические IP-адреса. Например, компьютер 1: 192.168.0.2, а компьютер 2: 192.168.0.3 (если не знаете, как это сделать, воспользуйтесь нашим FAQ: «Как настроить параметры TCP/IP у компьютера?»)
- Отключите или удалите антивирус и брандмауэр на обоих ваших компьютерах, т.к данное программное обеспечение может мешать проведению следующего теста. После него вы сможете вернуть ваши настройки обратно. После запустите Ping с вашего первого компьютера на второй (если не знаете, как это сделать, пожалуйста, воспользуйтесь поиском в интернете)
О том, как использовать команду Ping, можно прочитать здесь.
Результаты команды PING:
Шаг 2. Подключите ваш первый компьютер к коммутатору по кабелю и настройте на нём статический IP-адрес в той же локальной сети, в которой расположен ваш роутер и второй компьютер. Затем отключите или удалите антивирус и брандмауэр с вашего компьютера и попробуйте запустить PING с вашего первого компьютера на другой.
Проблемы, с которыми приходится сталкиваться в коммутируемой сетевой среде, мало чем отличаются от сбоев в разделяемой среде передачи.
Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:
Устанавливая в сети коммутатор, вы фактически создаете отдельный коллизионный домен на каждом порту – именно таков принцип работы коммутаторов. Если к порту подключить концентратор, ресурсы которого используются совместно, то коллизионный домен может увеличиться до максимально допустимого для данного варианта Ethernet размера. Коммутирующее оборудование постоянно дешевеет, поэтому в большинстве современных сетей к каждому порту подключается всего одна рабочая станция, и в этом случае коллизионный домен состоит из единственного кабельного сегмента.
Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.
Если на каждом порту создается собственный широковещательный домен, то возможности диагностики сильно ограничены. Кроме того, организация отдельного широковещательного домена на каждом порту требует от коммутатора выделения для маршрутизации значительной части ресурсов центрального процессора на продвижение всего сетевого трафика. В реальной жизни очень трудно представить себе сеть, где требовалось бы обрабатывать и перенаправлять каждый запрос и отклик по отдельности. При отсутствии очень веских оснований создания именно такой структуры сети следует избегать.
К сожалению, весьма распространена конфигурация, когда в одну подсеть или широковещательный домен помещаются все серверы, а пользователи распределены по некоторому количеству других подсетей или широковещательных доменов. В таком случае практически все запросы должны маршрутизироваться. Если ради удобства обслуживания необходимо разместить все серверы в одном помещении (серверной), то их рекомендуется распределить по нескольким виртуальным сетям VLAN. Пользователей, которые обращаются к конкретному серверу, следует отнести к той же виртуальной сети. В такой конфигурации матрица коммутатора может использовать для обычного трафика мост на втором уровне модели OSI, поэтому маршрутизироваться будут только нетипичные или редкие запросы. Если сервер обслуживает более одного сообщества пользователей, то установите в него дополнительные сетевые карты, чтобы связь осуществлялась на втором уровне модели OSI.
ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ
Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.
При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.
Другая стратегия – дождаться, пока от пользователей начнут поступать жалобы. Во многих сетях применяется именно такой подход, который не стоит недооценивать из-за внешней простоты – на самом деле, он очень эффективен. Пользователи чутко реагируют на состояние сети, несмотря на то, что представление о ее работе больше основывается на подсознательном восприятии, чем на логических заключениях. Заметив малейшее ухудшение
в работе сети, пользователь обычно тут же обращается с жалобой в отдел ИТ или к системному администратору. Так что работу по поиску и устранению неисправности можно начать с его рабочего места. Такой подход называется реактивным, поскольку предполагает реагирование на уже произошедший сбой.
Напротив, профилактические, проактивные методы направлены на то, чтобы не допустить возникновения сбоя. Для этого проводится регулярный опрос коммутаторов, мониторинг качества трафика на каждом порту коммутатора и в каждом сегменте. Когда проблема уже появилась (поступила жалоба, либо вы сами обнаружили сбой), диагностировать ее можно разными методами, каждый из которых имеет свои плюсы и минусы.
МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ
Получить информацию о работе коммутатора можно как минимум десятью основными способами. Каждый предполагает свой порядок действий и имеет свои положительные и отрицательные стороны. Как обычно, единого рецепта на все случаи жизни не существует. Выбирать подходящее решение из разных вариантов следует, прежде всего, исходя из доступности ресурсов, опыта специалиста, проводящего работы, и оценки последствий для функционирования сети (приостановка, перерывы в работе) при использовании того или иного метода.
Однако даже сочетание всех методов не позволяет следить за коммутируемой сетью в таких подробностях, как это можно было делать в сетях на базе концентраторов. Увидеть и отследить абсолютно весь трафик и все ошибки, относящиеся к коммутатору, практически невозможно. Большинство диагностических процедур подразумевает, что трафик проходит между рабочей станцией и соответствующим сервером или направляется на магистральный порт. Если две рабочие станции обмениваются данными напрямую через одноранговое (пиринговое) соединение, то трафик не проходит ни через магистральный порт, ни через какой-либо другой порт коммутатора. Такие соединения редко обнаруживаются, если только не искать их специально. Обычно ошибки не распространяются за пределы порта коммутатора, однако для некоторых их типов и определенных настроек коммутаторов возможна и дальнейшая трансляция.
Для простоты представим себе минимальный сегмент сети: сервер, подключенный к коммутатору. В одних случаях мы будем предполагать, что пользователи, испытывающие проблемы, подключены к тому же самому коммутатору, в других — что они будут пытаться получить доступ к серверу через магистральный порт, ведущий либо к другому коммутатору, либо к маршрутизатору. Диагностика начинается в ответ на жалобу о медленной работе сети при обращении к серверу. К сожалению, такое описание проблемы ничего не говорит специалисту ИТ. Если речь идет не об обычном сбое, а взломе системы защиты, причем предполагаются последствия юридического характера, то необходимо принять дополнительные меры, чтобы обеспечить достоверность и юридическую силу собираемых данных.
Информация, относящаяся сразу к нескольким методам, будет приводиться в описании того метода, в котором она раскрывается наиболее полно. Большая часть описаний относится также к методам, отличным от того, которому посвящен конкретный раздел, причем она может иметь как тривиальные, так и фундаментальные последствия для конечного результата.
МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ
Получить доступ к настройкам коммутатора можно разными способами, включая следующие:
подключиться через последовательный порт коммутатора.Некоторые коммутаторы обладают рядом встроенных диагностических средств, которыми можно воспользоваться, но следует помнить, что их функциональные возможности существенно различаются в зависимости от производителя и модели коммутатора. Расширенные команды операционной системы позволяют провес-ти более глубокий анализ транслируемого трафика, однако имеющийся интерфейс нельзя назвать дружественным к пользователю. Чтобы успешно применить такие функции, надо обладать значительным опытом и глубоким знанием теории сетей.
Плюсы. Консольный доступ – очень эффективный метод диагностики, он широко распространен и используется чаще других. Множество самых разных проблем в сети вызвано именно неправильными настройками коммутаторов и выполняемыми в соответствии с этими настройками действиями.
Получить доступ к консоли управления коммутатором можно всегда — одним из вышеперечисленных способов. Почти повсеместная доступность беспроводных сервисов и услуг передачи данных, предоставляемых мобильной связью, позволяют управлять сетью из любой точки планеты. Настроив систему управления сетью на отправку уведомлений на мобильные устройства, вы сразу узнаете о возникновении сбоя.
Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.
Минусы. Старшие системные администраторы и другие ведущие сотрудники отделов ИТ, обладающие паролями для доступа к настройкам коммутаторов, при проведении диагностики уделяют столь повышенное внимание конфигурации, что никакие другие варианты даже не приходят им в голову, пока этот метод себя полностью не исчерпает. Между тем, отказ от прочих подходов может существенно задержать устранение сбоя и дополнительно осложнить ситуацию. С помощью только консольного доступа удается выявить и устранить только часть сетевых проблем.
Обычные команды, подаваемые с помощью консоли, позволяют установить средние уровни использования, но не дают информации о конкретных видах сетевой активности или исходной причине сбоя того или иного протокола. Более того, данные, получаемые с помощью консольного доступа, указывают, скорее, на то, как сеть должна работать, а не сообщают о реальном положении дел, поэтому они мало помогут в случае, например, некорректного функционирования части коммутатора. Просмотр конфигурации не позволяет выявить программные ошибки в операционной системе или неточности и упущения в настройках. Иногда, выведя дамп конфигурации на экран, нельзя узнать настройки по умолчанию, поскольку выдаются только изменения по сравнению с настройками по умолчанию. Между тем, причиной снижения производительности сети вполне могут быть именно эти настройки.
Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.
Если речь идет о критически важных сегментах сети, то консольный доступ из удаленных точек может быть либо запрещен, либо разрешен только с конкретной группы жестко фиксированных адресов. Обычно пароли для доступа к коммутаторам не известны рядовому персоналу отделов ИТ и служб технической поддержки, поэтому они не имеют возможности использовать консольный доступ. Инженеры более высокого уровня, располагающие паролями, как правило, не участвуют в ежедневной работе по устранению сбоев в сетях. А теперь представьте, каким образом специалист, в прямые обязанности которого входит постоянное поддержание производительности сети, сможет эффективно работать, если консольный доступ ему запрещен?
О других методах диагностирования коммутаторов мы расскажем в следующих выпусках рубрики.
Однако, если зайти на коммутатор по SSH и дать команду PING на IP проблемного VLAN, то связи нет, таймаут и адрес недоступен.
Порты в режиме access. Линки подтверждаются и программно и аппаратно. ACL нет, адреса статические. Порты помечены как untagged. Уже и не знаю куда смотреть.
Коммутатор находится в стеке с 5-ю аналогичными. Первый, вышеописанный, соединён оптикой с главным оптическим коммутатором.
Оптический порт - trunk, all vlan, в качестве шлюза адрес оптического коммутатора из подсети коммутаторов, который является маршрутизатором (прописаны все VLAN и ассоциируемые с ними IP-адреса). К оптическому подсоединён третий коммутатор AT-8000GS/24POE, а к нему сервер (порт access, проблемный VLAN). Сервер видит устройства на других коммутаторах этого VLAN, пингует их и общий шлюз на оптическом коммутаторе. Виден также проблемный коммутатор. Брандмауэр вырублен, антивируса нет.
С портов проблемного коммутатора сервер из той же подсети не виден. Если прописать проблемный vlan свободный порт другого коммутатора в стеке, то сервер пингуется, однако с сервера подключенное устройство не видно.
UPD 1 Нарисовал примерно диаграмму:
Коммутаторы все видят друг друга, за исключением тех, что не пингуются. Это 2 промежуточных коммутатора, с них пинг идёт, на них нет.
С 10.5.0.110 пинг проходит вплоть до сервера СКУД, в обе стороны, причём с самого коммутатора только до шлюза 10.0.128.1, а ноутбука в 7-ом VLAN вплоть до сервера.
Что сделал: удалил/прописал заново VLAN 7 на 10.5.0.110 - не помогло.
UPD 2 Перекинул проблемные устройства в соседний стэк. Прописал VLAN 7. Заработало. Схема подключения ничем не отличается, настройки те же. Только оптические порты соседние. Буду разбираться и диагностировать порты.
Destination Mask NextHop Interface Protocol
10.5.0.0 255.255.255.0 10.5.0.92 vlan5-0 INTERFACE
UPD4
Клубок стал распутываться. Ключом стало значение: Destination 10.5.0.0
10.5.0.0 - указан как шлюз. Стал разбираться - а может быть в сети устройство с таким адресом - оказалось нет.
10.5.0.0 - это зарезервированный адрес сети 10.5.0.1-10.5.0.254
Стало быть шлюз не указан вообще.
Это говорит лично мне о том, что маршрутизация на крутом управляемом коммутаторе работает как на тупом хабе, ну или полу-тупом.
Далее: коммутаторы 10.5.0.92 и 10.5.0.97 - оптические, всего с 4-мя резервными(дублирующими) медными портами. Просто так к ним не подключишься. В сети их нет.
Подключился через SSH c помощью преобразователя USB на консольный порт. Выдернул один из транковых оптических портов. Переделал транковый медный порт дублирующий на режим access. Подключился ноутбуком с установленным адресом 10.5.0.15 255.255.255.0 - связи нет. Прописал шлюзом 10.5.0.92 (на нём экспериментировал) и ВУАЛЯ!
Пинга с коммутатором нет, зато нашлись несколько подобных устройств, которых не было видно в сети 10.5.0.0.
Потом удалось сравнить конфиг 10.5.0.92 с полностью аналогичным коммутатором. Нашлось много левых настроек.
Допустим: после команды show ip route
проблемном 92-ом отображается Interface vlan5 , а на аналоге Interface vlan5-0
Хотя во всех других местах VLAN5 отображается одинаково.
В итоге мы имеем отсутствие прописанных шлюзов и , возможно, сегментацию сети, как писал nApoBo3 в комментариях.
Читайте также: