vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

LAG и средства обнаружения проблем 10

Дата публикации: 15.05.2013
Количество просмотров: 22148

Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку?

Всё здесь прекрасно, LAG обеспечивает резервирование – один линк падает, LACP удаляет его и работаем на оставшихся. Казалось бы. Но известная многим проблема в том, что LACP никак не отследит такую ситуацию:

Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

Для отслеживания таких проблем используются протоколы UDLD – UniDirectional Link Detection. К ним относятся BFD и Ethernet OAM. Оба они прекрасно справляются со своей задачей: если связь с удалённым устройством пропадает, UDLD вынуждает маршрутизатор перевести соответствующий порт в состояние Down. В случае, который я хочу рассмотреть , схема несколько более сложная:

То есть между двумя маршрутизаторами ещё сеть SDH. OSN принимает Ethernet-кадры, инкапсулирует их в SDH-фреймы и отправляет их в плавание. С другого конца другой OSN вылавливает их, декапсулирует обратно Ethernet и возвращает их назад в IP-сеть.

Инженер остановил свой выбор на Ethernet OAM для детектирования проблемы и... ошибся. Сам я прежде не сталкивался с данным протоколом, поэтому в лаборатории собрал тестовый стенд без SDH сети – всё работает. SDH не стал настраивать по той простой причине, что это транспорт – какая ему разница, что передавать? Резать и дропать он ничего не должен – что получил, то и отправил. У меня работает, у заказчика нет – начинаем углубляться в детали.

Для начала разберёмся, что такое OAM вообще и как применяется.

OAM – Operation, Administration and Maintenance

Существует их два вида:

EFM OAM – Ethernet in First Mile. Преследует следующие цели: обнаружение партнёра, мониторинг линка, уведомление об авариях, Remote Loopback. EFM OAM соответствует стандарту 802.3ah и ориентирован на отслеживание состояния простого линка.

Ethernet CFM – Connectivity Fault Management – 802.3ag. Это механизм масштаба сети и призван обеспечивать End-to-End связность. Это достаточно мощный протокол и теоретически может использоваться для данных целей, но это всё равно, что поднимать OSPF между своим DLink и компьютером. Можно, но зачем?

Итак, поскольку был выбран EFM OAM, то копнём его поглубже.

EFM определяется на конкретном интерфейсе и может работать в двух режимах – Active и Passive. Только Active инициирует поиск соседа путём отправки OAMPDU в линк. Passive же слушает и отвечает на пришедшие запросы, но не может инициировать поиск соседа. Таким образом, хотя бы один из двух подключенных друг к другу интерфейсов должен иметь EFM в режиме Active. Вот типичная конфигурация:

interface GigabitEthernet1/1/4
eth-trunk 22
efm enable
efm trigger if-down

Последняя команда вынуждает устройство переводить интерфейс в состояние Down при наличии проблем. А вот так выглядит обмен любезностями и успешное установление сессии:

И вот тут, глядя на вид OAMPDU, я начинаю подозревать, что наличие SDH-сети в промежутке может играть фатальную роль. В качестве адреса отправителя стоит MAC-адрес Eth-trunk интерфейса, а вот в качестве получателя, какой-то специальный MAC-адрес, и EtherType – Slow Protocol.

Протоколы управления Ethernet – это часть стандарта 802.3. Они разделяются на два типа:
  • Быстрые. Они должны отрабатывать моментально для предотвращения потери производительности. Как правило они реализуются аппаратно. Примером может служить механизм PAUSE – когда порт устройства получает трафика больше, чем может обработать, он отсылает PAUSE Frame противоположному узлу с просьбой понизить скорость отправки.
  • Медленные – те самые Slow Protocols. У них не такие большие аппетиты на частоту отправки и задержки. Они реализуются программно. OAM и LACP относятся именно к этому виду. Для них используется специальный MAC-адрес: – 0180-с200-0002, и EtherType 8809.

Выдержка из Annex 57A к стандарту 802.3:

This address is within the range reserved by ISO/IEC 15802-3 (MAC Bridges) for link-constrained protocols. As such, frames sent to this address will not be forwarded by conformant MAC Bridges; its use is restricted to a single link

Дело в том, что EFM OAM относится к группе протоколов, скажем так, "одного линка". Их данные не могут покинуть один простой линк. Как только противоположное устройство принимает такой фрейм, оно его обрабатывает нужным образом и уничтожает, не передавая никуда дальше. То есть, когда с обратной стороны у нас стоит маршрутизатор/коммутатор с настроенным EFM на интерфейсе, он, приняв OAMPDU, проверяет его и отправляет ответ на R1, а старый кадр уничтожает. R1 получает OAMPDU от R2 и сессия установлена в лучшем виде.

[R2]dis efm ses al
Interface                        EFM State           Loopback Timeout
----------------------------------------------------------------------
GigabitEthernet1/1/4               detect                   --
GigabitEthernet1/1/6               detect                   --

В нашем же случае OSN, получив такой фрейм, просто отбрасывает его, потому что никакого EFM на нём не запущено.

[R1]dis efm session all
Interface                 EFM State                  Loopback Timeout
----------------------------------------------------------------------
GigabitEthernet1/1/4      discovery                         --
GigabitEthernet1/1/6      discovery                         --

Для очистки совести я собрал полностью аналогичную схему и увидел, что R1, как активный член партии отсылает данные, но ничего не получает в ответ. А на R2 совсем всё тихо.

debugging efm interface GigabitEthernet 1/1/4 all
Info: Operation succeeded.
May 14 2013 09:18:26.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00


May 14 2013 09:18:27.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

May 14 2013 09:18:28.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.

Спасение

Единственный здесь выход – это использование BFD – Bidirectional Forwarding Detection. В то время, как EFM свои данные инкапсулирует напрямую в Ethernet, BFD использует IP и UDP. То есть для него никакой трудности не представляют промежуточные L2-устройства.

BFD отправляет свои пакеты на мультикастовый адрес 224.0.0.184 и, если противоположное устройство настроено соответствующим образом, оно высылает ответные пакеты – BFD-сессия поднимается. Вот пример конфигурации, которая принуждает устройство погасить интерфейс в случае проблем:

R1
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 10
discriminator remote 11
process-interface-status
commit

R2
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 11
discriminator remote 10
process-interface-status
commit

Первой строкой задаём привязку BFD к физическому интерфейсу. Далее определяем дискриминаторы – обязательный параметр BFD, позволяющий различать сессии. И командой process-interface-status указываем, что устройство должно гасить интерфейс, если BFD обнаружил проблему.

[R1]dis bfd session all
--------------------------------------------------------------------------------
Local     Remote     PeerIpAddr    State     Type         InterfaceName
--------------------------------------------------------------------------------
11          10        224.0.0.184    Up     S_IP_IF     GigabitEthernet1/1/4
21          20        224.0.0.184    Up     S_IP_IF     GigabitEthernet1/1/6
--------------------------------------------------------------------------------
           Total UP/DOWN Session Number : 2/0

В случае проблемы на линке BFD это сразу замечает:

May 14 2013 09:45:45+03:00 R2 %%01BFD/4/STACHG_TODWN(l)[23]:Slot=1;BFD session changed to Down. (SlotNumber=1, Discriminator=20, Diagnostic=DetectDown, Applications=IFNET, ProcessPST=False, BindInterfaceName=GigabitEthernet1/1/6, InterfacePhysicalState=Up, InterfaceProtocolState=Down)

Статус интерфейса принимает вид:

[R2]dis int br
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface                 PHY        Protocol      InUti      OutUti       inErrors    outErrors
Aux0/0/1                  down         down          0%         0%             0           0
Eth-Trunk22                up           up          0.05%      0.05%           0           0
GigabitEthernet1/1/4       up           up          0.05%      0.05%           0           0
GigabitEthernet1/1/6       up           up(b)         0%         0%            0           0

[R2]dis int gig1/1/6
GigabitEthernet1/1/6 current state : UP
Line protocol current state : UP(BFD status down)

Разумеется, BFD также детектирует обрыв одного оптического кабеля. Правда смысл LACP в такой ситуации, так или иначе, теряется. Ещё одно из преимуществ BFD (скорость реакции)  - это уровень миллисекунд.

Вообще говоря, многие устройства поддерживают команды, которые позволяют "прокидывать" данные Slow Protocls, но это от лукавого.
В общем решение предоставлено, инженер счастлив, а я узнал для себя что-то новое.

 

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/23120/lag-i-sredstva-obnarujeniya-problem.html

Комментарии:(10) комментировать

20 мая 2013 - 17:03
Robot_NagNews:
#1

Материал:
Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку?

Полный текст


20 мая 2013 - 17:07
insekt:
#2

А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол.

И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol.


20 мая 2013 - 17:08
DelSt:
#3

Цитата

Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.


Дальше не читал. Это что за оборудование так работает?


20 мая 2013 - 17:12
srg555:
#4

Просмотр сообщенияDelSt (20 мая 2013 - 16:08) писал:

Цитата

Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.


Дальше не читал. Это что за оборудование так работает?



Обычный односторонний линк. Что именно вас удивило?


20 мая 2013 - 17:59
visir:
#5

Цитата

То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.


А вот это в лабе проверили, или теоретизируете?

Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон.

В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт.

Нну, что вы на это скажете?!


20 мая 2013 - 19:06
sio:
#6

Просмотр сообщенияsrg555 (20 мая 2013 - 16:12) писал:

Просмотр сообщенияDelSt (20 мая 2013 - 16:08) писал:

Цитата

Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.


Дальше не читал. Это что за оборудование так работает?



Обычный односторонний линк. Что именно вас удивило?


Видимо то, что LACP прекрасно отрабатывает односторонний линк. Другое дело, что автор писал про Huawei, у этого вендора раньше были баги с LACP, сейчас уже поправили патчами и новым софтом. Впрочем багов с BFD было никак не меньше, если не больше.


20 мая 2013 - 19:21
visir:
#7

Цитата

Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.


То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так?
А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :)


22 мая 2013 - 20:41
Valaskor:
#8

Как то давно у меня были свитчики Allied-Telesyn, между которыми был настроен link-aggr на двухволоконных модулях.
Спокойствие нарушила стая "оптических" мышек, погрызших пигтейлы в ODFе. Произошла как раз ситуация, описанная в начале статьи.
Минут пятнадцать я вообще не мог понять что произошло - просто часть хостов отвалилось, как казалось, вообще в разнобой.
Более подробное разбирательство выявило, что по умолчанию в веб морде включается только static-режим агрегации.
А вот в консоли нашелся полноценный LACP. Перевели на него, протестировали разрывы отдельных волокон - в случае асимметрии линк отлично выводится из агрегации.


23 мая 2013 - 21:23
eucariot:
#9

Просмотр сообщенияinsekt (20 мая 2013 - 16:07) писал:

А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол.

И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol.



Huawei OSN какой-то из средней линейки. Точнее не скажу.

Для Slow протоколов вполне логичное поведение - Ethernet порт SDH мукса работает по стандартам - получил кадр Slow Protocols - отбросил его. До SDH даже не доходит.

Просмотр сообщенияvisir (20 мая 2013 - 16:59) писал:

Цитата

То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.


А вот это в лабе проверили, или теоретизируете?

Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон.

В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт.

Нну, что вы на это скажете?!



Разумеется в лабе на живом оборудовании. Чтобы не быть голословным - NE40E-X3 и CX600-X3. Между ними OSN. Возможно, это такая реализация LACP, тут спорить не буду.

Просмотр сообщенияvisir (20 мая 2013 - 18:21) писал:

Цитата

Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.


То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так?
А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :)



Нет, SDH ничего не знал об LACP - просто отрабатывал, отбрасывая кадры, предназначенные для данного мультикастового MAC-адреса.


24 мая 2013 - 1:50
BorodaSpb:
#10

В железе Nortel/Avaya есть небольшая надстройка надо LACP для борьбы с подобными проблемами - VLACP, небольшие сигнальные пакеты для определения доступности пира. Отлично работает.


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться