Протокол udld что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Продвинутое руководство по Spanning Tree: Toolkit
Выходим на новый уровень. Для изучения следующей темы вы уже должны хорошо понимать связующее дерево. Связующее дерево (Spanning Tree Protocol STP) — это важная тема. Есть много вещей, которые могут пойти не так, и в этой статье мы рассмотрим ряд инструментов, которые мы можем использовать для защиты нашей топологии связующего дерева.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
UplinkFast и BackboneFast не требуются для rapid spanning tree, поскольку оно уже реализовано по умолчанию. Мы начнем с BPDUguard:
В топологии выше мы имеем идеально работающую топологию остовного дерева. По умолчанию связующее дерево будет отправлять и получать BPDU на всех интерфейсах. В нашем примере у нас есть компьютер, подключенный на интерфейсе fa0/2 коммутатора B. Есть кто-то, кто с враждебными намерениями мог бы запустить инструмент, который сгенерирует BPDU с превосходящим ID моста. Что же произойдет- так это то, что наши коммутаторы будут считать, что корневой мост теперь может быть достигнут через коммутатор B, и у нас будет повторный расчет связующего дерева. Звучит не очень хорошо, правда?
Можно поставить человека (хакера) в середине топологии для атаки так, чтобы никто не знал. Представьте себе, что хакер подключает свой компьютер к двум коммутаторам. Если хакер станет корневым мостом, то весь трафик от коммутатора А или коммутатора C к коммутатору В будет проходить через него. Он запустит Wireshark и подождет, пока произойдет чудо.
BPDUguard гарантирует, что, когда мы получаем BPDU на интерфейс, интерфейс перейдет в режим err-disable.
Чтобы продемонстрировать работу BPDUguard будем использовать два коммутатора. Настроем интерфейс fa0/16 коммутатора B так, что он перейдет в режим err-disable, если он получит BPDU от коммутатора C.
Вот как вы включаете его в интерфейсе. Имейте в виду, что обычно вы никогда не будете делать это между коммутаторами. Вы должны настроить это на интерфейсах в режиме доступа, которые подключаются к компьютерам.
А-а. вот и наш интерфейс.
Portfast также может быть включен глобально для всех интерфейсов, работающих в режиме доступа.
Это полезная команда, позволяющая проверить свою конфигурацию. Вы видите, что portfast и BPDUGuard были включены глобально.
BPDUGuard переведет интерфейс в режим err-disable. Кроме того, можно фильтровать сообщения BPDU с помощью BPDUfilter. BPDUfilter может быть настроен глобально или на уровне интерфейса и есть разница:
Вы должны быть осторожны, когда включаете BPDUfilter на интерфейсах. Вы можете использовать его на интерфейсах в режиме доступа, которые подключаются к компьютерам, но убедитесь, что вы никогда не настраиваете его на интерфейсах, подключенных к другим коммутаторам. Если вы это сделаете, вы можете получить цикл.
Для демонстрации работы BPDUfilter мы будем снова использовать коммутатор B и коммутатор C.
Он перестанет посылать BPDU и будет игнорировать все, что будет получено.
Вы не увидите никаких интересных сообщений, но если вы включите отладку BPDU, то заметите, что он больше не отправляет никаких BPDU. Если вы хотите, вы также можете включить отладку BPDU на коммутаторе C, и вы увидите, что нет ничего от коммутатора B.
Давайте избавимся от команды BPDUfilter на уровне интерфейса.
Вы также можете использовать глобальную команду для BPDUfilter. Это позволит включить BPDUfilter на всех интерфейсах, которые имеют portfast.
Рассмотрим с вами конфигурацию с коммутатором B и коммутатором C.
Давайте убедимся, что коммутатор C не является корневым мостом.
Вот как мы включаем RootGuard на интерфейсе.
Не забудьте включить отладку, если вы хотите увидеть события.
Давайте перенастроим коммутатор B, изменив приоритет на наименьшее возможное значение 0 на коммутаторе C. Он теперь должен стать корневым мостом.
Вот так коммутатор B не будет принимать коммутатор C в качестве корневого моста. Это заблокирует интерфейс для этой VLAN.
Вот еще одна полезная команда, чтобы проверить, работает ли RootGuard.
Связующее дерево становится все более безопасным с каждой минутой! Однако есть еще одна вещь, о которой мы должны подумать…
Если вы когда-либо использовали волоконные кабели, вы могли бы заметить, что существует другой разъем для передачи и приема трафика. Если один из кабелей (передающий или принимающий) выйдет из строя, мы получим однонаправленный сбой связи, и это может привести к петлям связующего дерева. Существует два протокола, которые могут решить эту проблему:
Давайте начнем с того, что внимательно рассмотрим, что произойдет, если у нас произойдет сбой однонаправленной связи.
Представьте себе, что между коммутаторами волоконно-оптические соединения. На самом деле имеется другой разъем для передачи и приема. Коммутатор C получает BPDU от коммутатора B, и в результате интерфейс стал альтернативным портом и находится в режиме блокировки.
Теперь что-то идет не так. transmit коннектор на коммутаторе B к коммутатору C был съеден мышами. В результате коммутатор C не получает никаких BPDU от коммутатора B, но он все еще может отправлять трафик для переключения между ними.
Поскольку коммутатор C больше не получает BPDU на свой альтернативный порт, он перейдет в forwarding режим. Теперь у нас есть one way loop (петля в один конец), как указано зеленой стрелкой.
Один из методов, который мы можем использовать для решения нашего однонаправленного сбоя связи — это настройка LoopGuard. Когда коммутатор отправляет, но не получает BPDU на интерфейсе, LoopGuard поместит интерфейс в состояние несогласованности цикла и заблокирует весь трафик!
Мы снова будем использовать эту топологию для демонстрации LoopGuard.
Используйте команду spanning-tree loopguard по умолчанию, чтобы включить LoopGuard глобально
Обычно это вызвало бы петлю, но, к счастью, у нас есть настроенный LoopGuard. Вы можете увидеть это сообщение об ошибке, появляющееся в вашей консоли. Проблема решена!
Если вы не хотите настраивать LoopGuard глобально, вы т можете сделать это на уровне интерфейса.
Другой протокол, который мы можем использовать для борьбы с однонаправленными сбоями связи, называется UDLD (UniDirectional Link Detection). Этот протокол не является частью инструментария связующего дерева, но он помогает нам предотвратить циклы.
Проще говоря, UDLD — это протокол второго уровня, который работает как механизм keepalive. Вы посылаете приветственные сообщения, вы их получаете, и все прекрасно. Как только вы все еще посылаете приветственные сообщения, но больше их не получаете, вы понимаете, что что-то не так, и мы блокируем интерфейс.
Убедитесь, что вы отключили LoopGuard перед работой с UDLD. Мы будем использовать ту же топологию для демонстрации UDLD.
Существует несколько способов настройки UDLD. Вы можете сделать это глобально с помощью команды udld, но это активирует только UDLD для оптоволоконных линий связи! Существует два варианта для UDLD:
Когда вы устанавливаете UDLD в нормальное состояние, он помечает порт как неопределенный, но не закрывает интерфейс, когда что-то не так. Это используется только для того, чтобы «информировать» вас, но это не предотвратит циклы.
Мы будем использовать коммутатор B и C, чтобы продемонстрировать UDLD. Будем использовать агрессивный режим, чтобы мы могли видеть, что интерфейс отключается, когда что-то не так.
Если вы хотите увидеть, что UDLD работает, вы можете попробовать выполнить отладку.
Это творческий способ создавать проблемы. При фильтрации MAC-адреса UDLD он будет думать, что существует сбой однонаправленной связи!
Вы увидите много отладочной информации, но конечным результатом будет то, что порт теперь находится в состоянии err-disable. 
LoopGuard и UDLD решают одну и ту же проблему: однонаправленные сбои связи.
Они частично пересекаются, но есть ряд различий, вот общий обзор:
Есть еще одна последняя тема, которую хотелось бы объяснить, это не протокол связующего дерева, но речь идет о избыточных ссылках, поэтому я оставлю ее здесь. Это называется FlexLinks.
Вот в чем дело: при настройке FlexLinks у вас будет активный и резервный интерфейс. Мы настроим это на коммутаторе C:
При настройке интерфейсов в качестве FlexLinks они не будут отправлять BPDU. Нет никакого способа обнаружить петли, потому что мы не запускаем на них связующее дерево. Всякий раз, когда наш активный интерфейс выходит из строя, резервный интерфейс заменяет его.
Вы можете видеть, что связующее дерево отключается для этих интерфейсов.
Давайте закроем активный интерфейс.
Вы можете видеть, что fa0/16 стал активным. Вот и все.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Протокол udld что это
Unidirectional Link Detection (UDLD) — проприетарный Cisco протокол второго уровня созданный для автоматического обнаружения потери двухсторонней коммуникации на линиях связи. Обычно он упоминается при обсуждении spanning tree, на прямого отношения к стандарту IEEE 802.1D не имеет. UDLD может быть использован, как для оптических, так и для линий связи на основе UTP (Медный кабель). Не смотря на то, что UDLD является проприетарным протоколом, принципы его работы и формат сообщений определены в RFC 5171.
UDLD как раз и предназначен для обнаружения такого рода состояний. Так-же UDLD может быть полезен на медных линиях связи, которые проходят через пассивные устройства, такие, как медиаконвертеры.
В примере выше, конечная точка с лева не может обнаружить выход из строя удаленного медиаконвертера, т.к. интерфейс подключенный к локальному медиаконвертеру остается в состоянии UP (Конечнко возможность появления такой ситуации зависит от медиаконвертора). UDLD способен обнаружить неисправность удаленного медиаконвертора путем констатации отсутствия UDLD сообщений от удаленного устройства.
По умолчанию, UDLD выключен на всех интерфейсах. Можно включить UDLD глобально на устройстве, или индивидуально на интерфейсе при помощи команды udld port. Это включит UDLD в режиме normal.
Может быть достаточно сложно скоординировать включение UDLD на обоих концах линии связи одновременно, в связи с этим при первом включении UDLD состоянии канала оценивается, как unknown,
что не означает состояние ошибки.
После включения UDLD на интерфейсе соседнего коммутатора, мы наблюдаем, что локальный коммутатор обнаружил соседнее устройство и изменил состояние канала на bidirectional.
UDLD способен отслеживать несколько соседних устройств на одном интерфейсе, но обычно этого не требуется.
Мы можем симулировать отказ канала и отследить реакцию UDLD. При использовании стандартных значений advertisement timer (15 секунд) и hold timer (5 секунд), реакция на проблему со стороны UDLD может занять до 20 секунд.
Как свидетельствует вывод команды debug представленный выше, с момента потери связи с соседним устройством, UDLD отправит сем дополнительных сообщений (по одному в секунду). И вслучае, если ответ не будет получен, статус канала (bidirectional status) станет равным unknown.
Естественно, это не очень большое преимущество т.к. интерфейс продолжает считаться действующим протоколами более высокого уровня и коммутатор продолжает отправлять трафик в этот канал. Как альтернатива режиму normal, можно настроить UDLD в aggressive режим. Режим аggressive отличается тем, что, в случае обнаружения односторонней связи на канале, интерфейс будет помещен в режим error-disabled и трафик перестанет передаваться. Такое состояние привлечет гораздо больше внимания администраторов к проблеме.
Перевод UDLD в режим aggressive, осуществляется добавлением аргумента aggressive к командам используемым ранее. Данный режим должен быть включен по обоим сторонам канала.
Можно убедится, что UDLD работает в режиме aggressive:
После очередной симуляции отказа,мы видим, что UDLD отвечает переводом канала в состояние error-disabled.
После устранения проблемы, можно вернуть интерфейс в рабочее состояние либо при помощи shutdown, no shutdown либо используя команду udld reset, которая автоматически восстановит работоспособность интерфейсов переведенных в состояние error-disabled в результате работы UDLD.
Understand and Configure the UDLD Protocol Feature
Available Languages
Download Options
Contents
Introduction
This document explains how the Unidirectional Link Detection (UDLD) protocol can help to prevent forwarding loops and blackholing of traffic in switched networks.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Problem Definition
Spanning-Tree Protocol (STP) resolves redundant physical topology into a loop-free, tree-like forwarding topology.
This is done by blocking one or more ports. By blocking one or more ports, there are no loops in the forwarding topology. STP relies in its operation on reception and transmission of the Bridge Protocol Data Units (BPDUs). If the STP process that runs on the switch with a blocking port stops receiving BPDUs from its upstream (designated) switch on the port, STP eventually ages out the STP information for the port and moves it to the forwarding state. This creates a forwarding loop or STP loop.
Packets start to cycle indefinitely along the looped path, and consumes more and more bandwidth. This leads to a possible network outage.
How is it possible for the switch to stop receiving BPDUs while the port is up? The reason is unidirectional link. A link is considered unidirectional when this occurs:
The link is up on both sides of the connection. The local side is not receiving the packets sent by the remote side while remote side receives packets sent by local side.
Consider this scenario. The arrows indicate the flow of STP BPDUs.
During normal operation, bridge B is designated on the link B-C. Bridge B sends BPDUs down to C, which is blocking the port. The port is blocked while C sees BPDUs from B on that link.
Now, consider what happens if the link B-C fails in the direction of C. C stops receiving traffic from B, however, B still receives traffic from C.
C stops receiving BPDUs on the link B-C, and ages the information received with the last BPDU. This takes up to 20 seconds, depending on the maxAge STP timer. Once the STP information is aged out on the port, that port transitions from the blocking state to the listening, learning, and eventually to the forwarding STP state. This creates a forwarding loop, as there is no blocking port in the triangle A-B-C. Packets cycle along the path (B still receives packets from C) taking additional bandwidth until the links are completely filled up. This brings the network down.
Another possible issue that can be caused by a unidirectional link is traffic blackholing.
How Unidirectional Link Detection Protocol Works
In order to detect the unidirectional links before the forwarding loop is created, Cisco designed and implemented the UDLD protocol.
UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
UDLD works by exchanging protocol packets between the neighboring devices. In order for UDLD to work, both devices on the link must support UDLD and have it enabled on respective ports.
Each switch port configured for UDLD sends UDLD protocol packets that contain the port’s own device/port ID, and the neighbor’s device/port IDs seen by UDLD on that port. Neighboring ports should see their own device/port ID (echo) in the packets received from the other side.
If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional.
This echo-algorithm allows detection of these issues:
Link is up on both sides, however, packets are only received by one side.
Wiring mistakes when receive and transmit fibers are not connected to the same port on the remote side.
Once the unidirectional link is detected by UDLD, the respective port is disabled and this message is printed on the console:
UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled
Port shutdown by UDLD remains disabled until it is manually reenabled, or until errdisable timeout expires (if configured).
UDLD Modes of Operation
UDLD can operate in two modes: normal and aggressive.
In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.
In aggressive mode, if the link state of the port is determined to be bi-directional and the UDLD information times out while the link on the port is still up, UDLD tries to re-establish the state of the port. If not successful, the port is put into the errdisable state.
Aging of UDLD information happens when the port that runs UDLD does not receive UDLD packets from the neighbor port for duration of hold time. The hold time for the port is dictated by the remote port and depends on the message interval at the remote side. The shorter the message interval, the shorter the hold time and the faster the detection. Recent implementations of UDLD allow configuration of message interval.
UDLD information can age out due to the high error rate on the port caused by some physical issue or duplex mismatch. Such packet drop does not mean that the link is unidirectional and UDLD in normal mode will not disable such link.
It is important to be able to choose the right message interval in order to ensure proper detection time. The message interval should be fast enough to detect the unidirectional link before the forwarding loop is created, however, it should not overload the switch CPU. The default message interval is 15 seconds, and is fast enough to detect the unidirectional link before the forwarding loop is created with default STP timers. The detection time is approximately equal to three times the message interval.
For example: Tdetection
This is 45 seconds for the default message interval of 15 seconds.
It takes Treconvergence=max_age + 2x forward_delay for the STP to reconverge in case of unidirectional link failure. With the default timers, it takes 20+2×15=50 seconds.
It is recommended to keep Tdetection module/port > command:
Issue this command to change the message interval:
The interval can range from 7 to 90 seconds, with the default being 15 seconds.
Refer to these documents for more information on the IOS UDLD configuration:
For Catalyst 6500/6000 switches that run Cisco IOS system software, refer to Configuring UDLD.
For Catalyst 2900XL/3500XL switches, refer to the Configuring UniDirectional Link Detection section of Configuring the Switch Ports.
For Catalyst 2940 switches, refer to Configuring UDLD.
For Catalyst 2950/2955 switches, refer to Configuring UDLD.
For Catalyst 2970 switches, refer to Configuring UDLD.
For Catalyst 3550 switches, refer to Configuring UDLD.
For Catalyst 3560 switches, refer to Configuring UDLD.
For Catalyst 4500/4000 running Cisco IOS, refer to Configuring UDLD.