Кратко

  • В версии 07 проекта рабочей группы LSR от 29 сентября удалённый идентификатор участника L2-пучка должен точно совпадать с ненулевым 32-битным локальным идентификатором, который сосед объявляет для того же участника. Версия 06 рекомендовала использовать Port ID, обнаруженный через LLDP. Документ пока проходит IESG Last Call и не является RFC.
  • LLDP и LACP могут помочь установить физический соседний порт, но их значения не обязаны совпадать с требуемым идентификатором. Проверка подлинности объявления IGP подтверждает отправителя сообщения, а не достоверность исходного сопоставления на втором уровне.

Несколько физических линий могут быть представлены как один логический канал. При расчёте пути по отдельному участнику или разборе аварии контроллеру нужно знать, какой кабель первого маршрутизатора соединён с каким кабелем второго. Проект Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members предлагает объявлять удалённые ID участников через OSPF и IS-IS и передавать их потребителю BGP-LS. В новой версии точнее сформулировано не то, как выглядят пучки, а какое утверждение вправе передавать маршрутизатор о соседнем конце.

Редакция 06 от 22 августа предлагала узнавать LLDP Port ID соседа и использовать его как удалённый ID в объявлении. В качестве альтернативы рассматривались номера портов LACP. Редакция 07 отказывается от простого копирования. Каждый маршрутизатор самостоятельно присваивает участникам ненулевые локальные 32-битные идентификаторы. Объявляемый одним концом удалённый ID должен быть ровно тем числом, которое второй конец объявляет как свой локальный ID соответствующего участника. Проверить пару можно только сравнив обе стороны.

Причина не сводится к терминологии. Тип Port ID в LLDP зависит от подтипа и может вообще не быть 32-битным числом. Номера Actor и Partner в LACP имеют ширину 16 бит и назначаются на двух концах независимо. Они помогают найти соседний порт, но не задают автоматически числовой ID из объявления о члене пучка. Как связать обнаруженный порт с объявленным соседом локальным идентификатором, решает реализация. Новая версия выводит получение точного значения за пределы действия спецификации. Настройка или собственные процедуры обнаружения допустимы; LLDP и LACP не запрещены.

Представим только возможную ошибку: участник A на одном конце физически соединён с портом другого маршрутизатора, но ПО неверно связывает найденное имя с его числовым ID X и публикует ложную пару. Аутентификация IGP подтвердит, что объявление отправил этот маршрутизатор. Она не подтвердит, что сведения второго уровня не устарели, не подменены и правильно преобразованы. В расширенном разделе безопасности версия 07 называет это границей доверия. Ошибочная связь может исказить выбор участника для трафика или диагностику отказа. Речь о модели риска, а не о зафиксированном сбое или недостатке конкретного производителя.

Отсутствие значения также нельзя превращать в доказательство отсутствия линии. Удалённый ID может быть не изучен либо не объявлен, в том числе если расширение поддерживает лишь одна сторона. В упорядоченном списке IS-IS ноль может удерживать место неизвестного ID; в BGP-LS такой ноль не экспортируется как действительный удалённый ID. Ретранслятор BGP-LS не проверяет семантику пары. Потребитель должен сопоставить значения и определить реакцию своей системы. При поэтапном внедрении различие между «неизвестно» и «нет участника» сохраняет точность топологии.

Datatracker показывает версию 07 как действующий Internet-Draft на этапе IESG Last Call до 13 октября с предполагаемым статусом Proposed Standard. До публикации RFC формулировки могут измениться. Требование включать объявления только настройкой на конкретных линиях уже присутствовало в версии 06. Новым является более строгий ответ на вопрос, откуда взят номер, которому доверяет контроллер.

Источники