Функции коммутатора устранять ошибки коммутации
Для устранения неполадок мы должны пройти путь от нижней части модели 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 -довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи. давайте рассмотрим это в следующей стать
Топ-5 причин выхода коммутатора из строя: перегрузка и другие поводы
Поломку коммутационного оборудования могут спровоцировать внешние и внутренние факторы.
Нарушение базовых правил эксплуатации
К выходу свитча из строя может привести банальная неаккуратность. На качество работы влияют различные механические воздействия:
резкие выдергивания сетевых кабелей;
случайные удары по корпусу;
падения с большой высоты.
Среди причин повреждения внутренних компонентов также стоит упомянуть возгорание микросхем в результате контакта с водой или какой-либо другой жидкостью.
Чтобы защитить свитч от человеческого фактора, достаточно соблюдать правила безопасной эксплуатации, детально описанные в пользовательском руководстве.
Некачественное программное обеспечение
С проблемой недостаточно надежного ПО сталкиваются владельцы бюджетных коммутаторов от неизвестных производителей, а также пользователи контрфактного сетевого оборудования (подделок продукции известных брендов).
Вернуть работоспособность свитчу в случае сбоя в работе ПО может повторная прошивка.
Нестабильность электрической сети
Скачок электрического напряжение или короткое замыкание губительны практически для любого сетевого оборудования. В особенности подвержены повреждениям свитчи, маршрутизаторы, точки доступа и другие устройства во время грозы.
Для защиты девайсов от токов КЗ и резких перепадов напряжения следует использовать источники бесперебойного питания и внешний стабилизаторы.
Повреждения портов для подключения оборудования
Если сам коммутатор по визуальным признакам работает без перебоев, а подключить какое-либо устройство к нему не удается, проблема кроется в сетевых портах. Скорее всего, в результате продолжительной эксплуатации «входы» просто износились и стали непригодными для использования.
Решить эту проблему можно в любом сервисном центре. Специалисты быстро произведут замену поврежденных портов и вернут устройству функциональные возможности.
Выход из строя одного из внутренних элементов коммутатора
Если коммутатор перестал включаться, причину поломки стоит искать внутри. Возможно, сгорела плата памяти устройства, вышла из строя одна из микросхем или перестал работать встроенный блок питания.
Устранить все эти поломки поможет поход в сервис или же самостоятельная замена неисправных запчастей.
Не стоит паниковать и сразу после возникновения сбоев в работе коммутатора искать ему замену. Большинство проблем можно устранить, потратив на ремонт гораздо меньше средств, чем на покупку нового устройства.
Проблемы, с которыми приходится сталкиваться в коммутируемой сетевой среде, мало чем отличаются от сбоев в разделяемой среде передачи.
Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:
Устанавливая в сети коммутатор, вы фактически создаете отдельный коллизионный домен на каждом порту – именно таков принцип работы коммутаторов. Если к порту подключить концентратор, ресурсы которого используются совместно, то коллизионный домен может увеличиться до максимально допустимого для данного варианта Ethernet размера. Коммутирующее оборудование постоянно дешевеет, поэтому в большинстве современных сетей к каждому порту подключается всего одна рабочая станция, и в этом случае коллизионный домен состоит из единственного кабельного сегмента.
Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.
Если на каждом порту создается собственный широковещательный домен, то возможности диагностики сильно ограничены. Кроме того, организация отдельного широковещательного домена на каждом порту требует от коммутатора выделения для маршрутизации значительной части ресурсов центрального процессора на продвижение всего сетевого трафика. В реальной жизни очень трудно представить себе сеть, где требовалось бы обрабатывать и перенаправлять каждый запрос и отклик по отдельности. При отсутствии очень веских оснований создания именно такой структуры сети следует избегать.
К сожалению, весьма распространена конфигурация, когда в одну подсеть или широковещательный домен помещаются все серверы, а пользователи распределены по некоторому количеству других подсетей или широковещательных доменов. В таком случае практически все запросы должны маршрутизироваться. Если ради удобства обслуживания необходимо разместить все серверы в одном помещении (серверной), то их рекомендуется распределить по нескольким виртуальным сетям VLAN. Пользователей, которые обращаются к конкретному серверу, следует отнести к той же виртуальной сети. В такой конфигурации матрица коммутатора может использовать для обычного трафика мост на втором уровне модели OSI, поэтому маршрутизироваться будут только нетипичные или редкие запросы. Если сервер обслуживает более одного сообщества пользователей, то установите в него дополнительные сетевые карты, чтобы связь осуществлялась на втором уровне модели OSI.
ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ
Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.
При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.
Другая стратегия – дождаться, пока от пользователей начнут поступать жалобы. Во многих сетях применяется именно такой подход, который не стоит недооценивать из-за внешней простоты – на самом деле, он очень эффективен. Пользователи чутко реагируют на состояние сети, несмотря на то, что представление о ее работе больше основывается на подсознательном восприятии, чем на логических заключениях. Заметив малейшее ухудшение
в работе сети, пользователь обычно тут же обращается с жалобой в отдел ИТ или к системному администратору. Так что работу по поиску и устранению неисправности можно начать с его рабочего места. Такой подход называется реактивным, поскольку предполагает реагирование на уже произошедший сбой.
Напротив, профилактические, проактивные методы направлены на то, чтобы не допустить возникновения сбоя. Для этого проводится регулярный опрос коммутаторов, мониторинг качества трафика на каждом порту коммутатора и в каждом сегменте. Когда проблема уже появилась (поступила жалоба, либо вы сами обнаружили сбой), диагностировать ее можно разными методами, каждый из которых имеет свои плюсы и минусы.
МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ
Получить информацию о работе коммутатора можно как минимум десятью основными способами. Каждый предполагает свой порядок действий и имеет свои положительные и отрицательные стороны. Как обычно, единого рецепта на все случаи жизни не существует. Выбирать подходящее решение из разных вариантов следует, прежде всего, исходя из доступности ресурсов, опыта специалиста, проводящего работы, и оценки последствий для функционирования сети (приостановка, перерывы в работе) при использовании того или иного метода.
Однако даже сочетание всех методов не позволяет следить за коммутируемой сетью в таких подробностях, как это можно было делать в сетях на базе концентраторов. Увидеть и отследить абсолютно весь трафик и все ошибки, относящиеся к коммутатору, практически невозможно. Большинство диагностических процедур подразумевает, что трафик проходит между рабочей станцией и соответствующим сервером или направляется на магистральный порт. Если две рабочие станции обмениваются данными напрямую через одноранговое (пиринговое) соединение, то трафик не проходит ни через магистральный порт, ни через какой-либо другой порт коммутатора. Такие соединения редко обнаруживаются, если только не искать их специально. Обычно ошибки не распространяются за пределы порта коммутатора, однако для некоторых их типов и определенных настроек коммутаторов возможна и дальнейшая трансляция.
Для простоты представим себе минимальный сегмент сети: сервер, подключенный к коммутатору. В одних случаях мы будем предполагать, что пользователи, испытывающие проблемы, подключены к тому же самому коммутатору, в других — что они будут пытаться получить доступ к серверу через магистральный порт, ведущий либо к другому коммутатору, либо к маршрутизатору. Диагностика начинается в ответ на жалобу о медленной работе сети при обращении к серверу. К сожалению, такое описание проблемы ничего не говорит специалисту ИТ. Если речь идет не об обычном сбое, а взломе системы защиты, причем предполагаются последствия юридического характера, то необходимо принять дополнительные меры, чтобы обеспечить достоверность и юридическую силу собираемых данных.
Информация, относящаяся сразу к нескольким методам, будет приводиться в описании того метода, в котором она раскрывается наиболее полно. Большая часть описаний относится также к методам, отличным от того, которому посвящен конкретный раздел, причем она может иметь как тривиальные, так и фундаментальные последствия для конечного результата.
МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ
Получить доступ к настройкам коммутатора можно разными способами, включая следующие:
подключиться через последовательный порт коммутатора.Некоторые коммутаторы обладают рядом встроенных диагностических средств, которыми можно воспользоваться, но следует помнить, что их функциональные возможности существенно различаются в зависимости от производителя и модели коммутатора. Расширенные команды операционной системы позволяют провес-ти более глубокий анализ транслируемого трафика, однако имеющийся интерфейс нельзя назвать дружественным к пользователю. Чтобы успешно применить такие функции, надо обладать значительным опытом и глубоким знанием теории сетей.
Плюсы. Консольный доступ – очень эффективный метод диагностики, он широко распространен и используется чаще других. Множество самых разных проблем в сети вызвано именно неправильными настройками коммутаторов и выполняемыми в соответствии с этими настройками действиями.
Получить доступ к консоли управления коммутатором можно всегда — одним из вышеперечисленных способов. Почти повсеместная доступность беспроводных сервисов и услуг передачи данных, предоставляемых мобильной связью, позволяют управлять сетью из любой точки планеты. Настроив систему управления сетью на отправку уведомлений на мобильные устройства, вы сразу узнаете о возникновении сбоя.
Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.
Минусы. Старшие системные администраторы и другие ведущие сотрудники отделов ИТ, обладающие паролями для доступа к настройкам коммутаторов, при проведении диагностики уделяют столь повышенное внимание конфигурации, что никакие другие варианты даже не приходят им в голову, пока этот метод себя полностью не исчерпает. Между тем, отказ от прочих подходов может существенно задержать устранение сбоя и дополнительно осложнить ситуацию. С помощью только консольного доступа удается выявить и устранить только часть сетевых проблем.
Обычные команды, подаваемые с помощью консоли, позволяют установить средние уровни использования, но не дают информации о конкретных видах сетевой активности или исходной причине сбоя того или иного протокола. Более того, данные, получаемые с помощью консольного доступа, указывают, скорее, на то, как сеть должна работать, а не сообщают о реальном положении дел, поэтому они мало помогут в случае, например, некорректного функционирования части коммутатора. Просмотр конфигурации не позволяет выявить программные ошибки в операционной системе или неточности и упущения в настройках. Иногда, выведя дамп конфигурации на экран, нельзя узнать настройки по умолчанию, поскольку выдаются только изменения по сравнению с настройками по умолчанию. Между тем, причиной снижения производительности сети вполне могут быть именно эти настройки.
Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.
Если речь идет о критически важных сегментах сети, то консольный доступ из удаленных точек может быть либо запрещен, либо разрешен только с конкретной группы жестко фиксированных адресов. Обычно пароли для доступа к коммутаторам не известны рядовому персоналу отделов ИТ и служб технической поддержки, поэтому они не имеют возможности использовать консольный доступ. Инженеры более высокого уровня, располагающие паролями, как правило, не участвуют в ежедневной работе по устранению сбоев в сетях. А теперь представьте, каким образом специалист, в прямые обязанности которого входит постоянное поддержание производительности сети, сможет эффективно работать, если консольный доступ ему запрещен?
О других методах диагностирования коммутаторов мы расскажем в следующих выпусках рубрики.
Сетевой коммутатор — это электронный прибор, объединяющий несколько компьютеров и/или других цифровых устройств в локальную сеть и позволяющий им обмениваться данными. Имеет ещё одно распространённое название — свитч, которое происходит от английского слова switch (коммутатор, переключатель).
Что такое свитч простыми словами
С каждым годом нас окружает всё больше и больше компьютеров, ноутбуков, мобильных и других цифровых устройств. Они используются дома, в офисах, административных и многих других помещениях. Становится всё более актуальной проблема их соединения для передачи данных — такого, которое избавило бы от необходимости переносить информацию, например, на USB-флешке. В недавнем прошлом её решали с помощью концентраторов, но к настоящему моменту их почти вытеснили более интеллектуальные устройства — сетевые коммутаторы, или свитчи. Говоря простыми словами, это — устройства, позволяющие объединить несколько компьютеров в сеть и играющие в ней роль её ядра. Это действительно удобно, причём в самых разных ситуациях:
на предприятии или в офисе, в котором установлено большое количество компьютеров, сетевых принтеров и другой цифровой техники;
в небольшой домашней локальной сети — к примеру, состоящей из нескольких компьютеров, ноутбука и современного телевизора;
в составе масштабной системы видеонаблюдения с большим количеством камер;
в промышленной сети с многочисленными датчиками, контролирующими техпроцессы и передающими данные на диспетчерский пункт;
вомногих других случаях.
Принцип работы коммутатора
За вопросом о том, что такое коммутатор, закономерно следует ещё один: по какому принципу он работает? Всё одновременно и просто, и сложно. Свитч получает данные от обращающихся к нему устройств и постепенно заполняет таблицу коммутации их MAC-адресами. При последующих обращениях коммутатор считывает адрес устройства-отправителя, анализирует таблицу коммутации и определяет по ней, на какое устройство нужно переслать данные. Прочие компьютеры при этом не «знают» о факте передачи информации, поскольку она не имеет к ним отношения. Благодаря этому обеспечивается работа сети в так называемом полнодуплексном (full duplex) режиме.
Выше был описан принцип действия так называемого неуправляемого коммутатора, который работает на втором (канальном) уровне OSI. Помимо таких, существуют более продвинутые модели, работающие на третьем и четвёртом уровнях. Они значительно функциональнее, поскольку допускают ручное управление (в частности, через интерфейс командной строки), поддерживают QoS, VLAN, зеркалирование, обнаружение штормов трафика, ограничение скоростей передачи данных для разных портов и многие другие полезные функции. Такие устройства включают в состав сложных и разветвлённых сетей — в частности, тех, что развёрнуты на больших предприятиях.
Режимы коммутации
Есть три режима, в которых свитч передаёт данные узлам-адресатам. Ключевые особенности каждого режима — степень надёжности передачи и связанное с ней время ожидания.
Первый режим называется Cut-Through — сквозной. Свитч принимает данные, считывает из них только адрес узла-получателя и без каких-либо дополнительных проверок отправляет их по назначению. Время ожидания в этом случае минимально, но возникает вероятность передачи данных с ошибками.
Второй режим называется Store and Forward — с промежуточным хранением. Коммутатор не только считывает адрес получателя, но и анализирует всю поступившую информацию с целью поиска ошибок. Лишь после этого данные передаются по назначению. Время ожидания в сравнении с предыдущим режимом увеличивается — оно необходимо свитчу для проверки.
Третий режим называется Fragment-Free — бесфрагментный, или гибридный. Он представляет собой сочетание двух описанных выше режимов. Коммутатор принимает кадр данных, считывает адрес получателя, а затем проверяет информацию на предмет ошибок, но не всю, а лишь первые 64 байта. После проверки свитч отправляет данные получателю.
Условия передачи данных непостоянны — они меняются со временем. Полезно иметь коммутатор, в котором реализована адаптивная подстройка под эти условия. В начале работы такое устройство включает сквозной режим коммутации для всех портов. Затем те порты, на которых появляется слишком много ошибок, автоматически переводятся в гибридный (бесфрагментный) режим. Наконец, если и после этого ошибок остаётся слишком много, порты переводятся в режим с промежуточным хранением данных.
Отличие коммутатора (switch) от концентратора (hub)
В недавнем прошлом были широко распространены концентраторы (hub). Эти устройства работают на основе широковещательной модели. Выражаясь проще, концентратор, принимая сетевой трафик, просто рассылает его всем без исключения подключенным к нему устройствам. Функция определения адресата, которая есть в коммутаторе, в нём не реализована, и в этом — основное отличие hub от switch. Широковещательная передача данных таит как минимум два подводных камня: во-первых, она сильно загружает сеть и заметно замедляет передачу данных, во-вторых, она влечёт риск появления большого количества ошибок, особенно — при добавлении в сеть новых компьютеров. Использование сетевых коммутаторов избавляет от этих проблем — и именно поэтому эти устройства к настоящему времени почти вытеснили собой концентраторы.
Отличие коммутатора (switch) от маршрутизатора (router)
Коммутатор более функционален, чем концентратор, но ещё больше функций реализовано в маршрутизаторе (или, как его ещё называют, роутере). Это устройство работает на третьем уровне OSI и отвечает не только за распределение трафика по узлам-адресатам, но и за связь между разными сетями с отличающимися архитектурами. В его память записана таблица маршрутизации, на основе данных из которой router решает, куда следует переслать поступивший пакет данных. Пересылка выполняется в соответствии с правилами, заданными администратором при настройке маршрутизатора.
Роутер позволяет снизить загрузку сети, разделяя её на широковещательные домены и фильтруя пакеты. Он даёт возможность объединить Ethernet-сеть и соединения WAN — например, для организации выхода в Интернет. В этом случае маршрутизатор не только транслирует адреса, но и играет роль межсетевого экрана, обеспечивая тем самым информационную безопасность. По сути, любой маршрутизатор — это миниатюрный компьютер с большим количеством настраиваемых параметров. К слову, именно поэтому роль роутера может играть любой персональный компьютер — при условии, что на нём установлено и настроено специализированное программное обеспечение для маршрутизации.
Как выбрать коммутатор
В продаже представлено великое множество моделей коммутаторов, которые существенно отличаются друг от друга как по функциональности, так и по цене. IT-специалисту нужно знать основные характеристики свитчей (читай — критерии выбора).
Базовая скорость передачи
В большинстве случаев в характеристиках коммутаторов указано сразу несколько значений скорости (пример записи — 10/100 Мбит/сек). Нужно ориентироваться на высшее значение — это максимум для данного устройства. Если данные будут поступать на свитч со скоростью меньшей, чем этот максимум, он автоматически подстроится под неё. Модели верхнего ценового диапазона могут работать на скоростях 10/20/100/200/1000/2000Мбит/сек. Принимайте во внимание особенности вашей сети и характеристики входящих в неё устройств и делайте правильный выбор.
Количество портов
В продаже представлены модели с количеством портов от 5 до 48. Выбирайте свитч с учётом не только фактического количества устройств, которые будут к нему подключены немедленно, но и перспективы расширения сети в будущем. Опыт показывает, что для сетей, развёрнутых дома и в небольших офисах, оптимальны коммутаторы с количеством портов от 5 до 15. Для предприятия подойдёт устройство с количеством портов от 15 до 48.
Исполнение (способ установки)
настольные коммутаторы. Это — компактные модели для небольших сетей. Они не вызывают ни малейших сложностей при установке — их можно просто положить на стол;
настенные модели. Также сравнительно компактны, однако имеют специальные пазы, позволяющие зафиксировать их на стене. Как показывает опыт, многие настенные свитчи можно и не крепить на вертикальном основании, а просто положить на стол;
стоечные коммутаторы. В эту категорию входят наиболее продвинутые модели для предприятий, которые устанавливаются в стандартную 19-дюймовую стойку для телекоммуникационного оборудования.
Возможность управления
Одну категорию образуют неуправляемые коммутаторы. Они не позволяют выполнить тонкую настройку, что минус для крупного предприятия, но плюс для использования дома или в небольшом офисе. Неуправляемые модели, как правило, компактны и имеют невысокую стоимость.
Ко второй категории относятся управляемые модели. Они допускают гибкую настройку с помощью специализированного ПО или web-интерфейса. Администратор может менять многочисленные параметры управляемого коммутатора — приоритеты подключенных устройств, общие параметры сети и другие. Такие модели хорошо подходят для использования в сложных и разветвлённых сетях, однако для их настройки нужны специальные познания и определённый опыт.
Поддержка PoE
Выбирайте коммутатор с этой функцией, если вам нужна подача питания к устройствам непосредственно по сетевому кабелю (витой паре). Один из возможных примеров — IP-камеры, включенные в локальную сеть. PoE (Power over Ethernet) — очень удобная функция: она избавляет от необходимости использовать силовые кабели, нисколько не снижая качество передачи данных.
Наличие портов SFP
Свитч с такими портами понадобится, если нужно соединить его с другими коммутаторами или устройствами более высокого уровня. Обратите внимание: SFP — это лишь порт, в него нужно предварительно установить специальный модуль, который, в свою очередь, даст возможность нестандартного подключения (например, по оптоволокну).
Наличие функции энергосбережения
Коммутаторы с такой функцией становятся всё более востребованными — играет роль растущий интерес к защите экологии. Эти интеллектуальные модели следят за подключенными к ним устройствам, выявляют неактивные порты и временно переводят их в спящий режим. Производители утверждают, что функция энергосбережения, реализованная в свитчах, позволяет сэкономить до 80% (!) электроэнергии.
Поддержка VLAN
Выбирайте модель с такой функцией, если нуждаетесь в логическом разграничении отдельных участков локальной сети. Вы сможете создать свои сегменты для разных отделов, подразделений и филиалов компании, организовать сеть общего доступа.
Наличие функции сегментации трафика
Коммутаторы с такой функцией позволяют настраивать порты или их группы так, чтобы они были полностью отделены друг от друга, но при этом имели доступ к серверу.
Поддержка стекирования
Устройство с такой функцией понадобится, если вам нужно создать единый логический коммутатор с количеством портов большим, чем 48. Несложно понять, что поддержка стекирования требуется в масштабных, разветвлённых сетях, развёрнутых на крупных предприятиях.
Наличие защиты от широковещательного шторма
Одно из частных проявлений такого шторма — DDoS-атака на локальную сеть. Если в последнюю входит обычный коммутатор без защиты от широковещательного шторма, в результате атаки вся сеть может попросту «лечь». Модели, в которых такая защита реализована, выявляют флуд и своевременно отсекают его, благодаря чему сеть остаётся стабильной.
Читайте также: