Почему оптический линк не уходит в Down при обрыве одного из волокон в дуплексной паре?

Отвечен
1
0

Выдержка из документации по UDLD:

UDLD echo-algorithm allows detection of these issues:

  • Link is up on both sides, however, packets are only received by one side.

Если трансивер SFP-шки не получает света, он должен, по идее, уйти в Down, и уведомить противоположный конец о том, что все плохо. Однако этого не происходит, и нам приходится прибегать к помощи UDLD или LACP/PAgP hello для обнаружения unidirectional линка и предотвращения петель.

Что это, недоработка стандарта 1000Base-X?

Вот тут написано, что даже когда по линку когда ничего не передается, передатчик заполняет паузу специальной IDLE последовательностью символов, чтобы не сбить синхронизацию:

Transmission coding is based on the ANSI Fibre Channel 8B/10B encoding scheme. Each 8-bit data byte is mapped into a 10-bit code-group for bit-serial transmission. Like earlier Ethernet versions, each data frame is encapsulated at the physical layer before transmission, and link synchronization is maintained by sending a continuous stream of IDLE code-groups during interframe gaps.

Приемник же должен детектировать отсутствие IDLE и уходить в Down?..

Лучший ответ
1
0

UDLD — простой способ детектировать проблему с физикой в минимальное время. Сейчас кроме как при использовании составных (физически составных) каналов сложно придумать какой-то use case когда оба линка будут в апе с обоих сторон. Только схемы с конверторами и возможно какие-либо транспортные проблемы с DWDM транспондерами, что по сути тот же конвертор.

Документация других вендоров вообще рекомендует использовать LACP для детектирования подобных проблем, собирая один единственный канал в LAG.

Кстати, UDLD успешно туннелируется в MPLS с помощью xconnect (EoMPLS), и некоторыми клиентами эта фича применяется как быстрый способ детектирования наличия проблем на сети провайдера, через которую предоставляется прозрачный L2 канал.

Отличный ответ
1
0

Дело не только в STP. В ситуации, когда для создания etherchannel используется  mode on, без использования udld часть потоков будет балансироваться на тот линк, который up только с одной стороны т.е. в никуда.

Еще бывают конвертеры среды не умеющие корректно класть медный порт при пропадании линка на оптике или класть медный порт на удаленной стороне при падении медного порта локально, udld тут тоже выручает.

0
0

Ребята, я лоханулся с созданием темы. Там же дальше написано про UDLD:

Aggressive mode adds additional detection of these situations:

  • The port is stuck (on one side the port neither transmits nor receives, however, the link is up on both sides).
  • The link is up on one side and down on the other side. This is issue might be seen on fiber ports. When transmit fiber is unplugged on the local port, the link remains up on the local side. However, it is down on the remote side.

Но опять же, возникает вопрос — нафига нужен UDLD, если на той стороне все равно порт DOWN, и никакой петли не возникает? Предположим, наш локальный порт не получит BPDU в течение 50 секунд и, решив, что мы подключены к конечному хосту, оставит порт в UP’е. Если порт на удаленном конце раздуплится, он мгновенно в состояние UP не перейдет, а будет сначала слушать и учиться (listening, learning) и посылать BPDU, и благодаря topology change notification BPDU сеть перестроится и петли не будет.

Получается, UDLD — это защита от свичей, не умеющих Spanning Tree?

0
0

Предположим, наш локальный порт не получит BPDU в течение 50 секунд и, решив, что мы подключены к конечному хосту, оставит порт в UP’е. Если порт на удаленном конце раздуплится, он мгновенно в состояние UP не перейдет, а будет сначала слушать и учиться (listening, learning) и посылать BPDU, и благодаря topology change notification BPDU сеть перестроится и петли не будет.

Получается, UDLD — это защита от свичей, не умеющих Spanning Tree?

Если порт с одной стороны падает в Down, UDLD не нужен.

Не совсем понятна описываемая ситуация «Если порт на удаленном конце раздуплится».

Но UDLD нужен вот на такой сценарий, например: на обоих портах физический линк Up, только на порту коммутатора A пакеты на Rx почему-то теряются. Тогда коммутатор A не слышит BPDU в течение Max Age, переводит порт в Designated. А коммутатор B с другой стороны тоже держит порт в Designated: он исправно получал BPDU от коммутатора A, но они хуже его лучшего BPDU, в норме порт коммутатора B будет Designated. Вот и два Designated порта навстречу друг другу — «петля» в L2-сегменте, broadcast storm, все последствия.

Показано 4 результата
Ваш ответ

для ответа.