Друзья, периодически здесь будут появляться статьи, написанные изначально для других ресурсов мной или другими членами нашей группировки ЛинкМиАп. Но мы считаем их интересными для этого ресурса тоже.

Сегодня статья, написанная для nag.ru

===================================

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

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

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

Для отслеживания таких проблем используются протоколы 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

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, но это от лукавого
В общем решение предоставлено, инженер счастлив, а я узнал для себя что-то новое.