Резюме

  • Оператор спросил в NANOG, практичен ли плоский домен IS-IS уровня 2 примерно с 300 маршрутизаторами, включая устройства агрегации примерно со 100 нижестоящими смежностями.
  • Saku Ytti рассказал об опыте работы с несколькими тысячами узлов IS-IS на значительно более старых управляющих плоскостях, а Mark Tinka отметил, что его сеть уже работала примерно с 300 узлами в 2009 году.
  • Tom Beecher заявил, что такой масштаб в целом реализуем, но связал ответ с географическим распределением, размером базы данных состояния каналов и настройкой задержки SPF. Dan Snyder добавил аппаратное обеспечение, размер домена сбоя и целевые показатели сходимости.
  • Недавно проиндексированный ответ Matthew Petach переформулировал решение: ёмкость протокола не определяет, какую часть сети может нарушить одна ошибка автоматизации, обрыв волокна или длительный цикл ремонта.
  • Документы IETF подтверждают это архитектурное различие. Области IS-IS ограничивают лавинную рассылку и вычисление кратчайших путей, а иерархия создаёт собственный компромисс между масштабом и оптимальностью путей.
  • Поэтому следующая проверка проекта должна тестировать масштаб сбоя и ухудшенный поток трафика, а не только доказывать, что каждый маршрутизатор способен удерживать топологию.

Обсуждение на NANOG началось с вопроса о ёмкости. Оператор хотел получить практические подтверждения для плоской сети IS-IS уровня 2 примерно на 300 маршрутизаторов и спросил, не станут ли проблемой маршрутизаторы агрегации, поддерживающие примерно 100 нижестоящих смежностей.

Первые ответы сделали числовой ответ необычно ясным. Saku Ytti описал развёртывание IS-IS с несколькими тысячами узлов на управляющих плоскостях двадцатилетней давности. Mark Tinka сообщил, что управляемая им сеть достигла примерно 300 узлов в 2009 году на оборудовании Cisco CRS-1 и ME3600X и платформах Juniper M320, T320 и MX480. Tom Beecher также сказал, что 300 узлов в одной плоской области уровня 2 в целом должны быть реализуемы.

Ни одно из этих сообщений не является эталоном от вендора, и автор вопроса не опубликовал предлагаемую топологию, состав маршрутизаторов, размер LSDB или цель по сходимости. Поэтому обсуждение не может установить универсальный предел. Оно устанавливает нечто более полезное, чем предполагаемый порог: опытные операторы не считали 300 ограничивающим фактом.

Уточнение — отправная точка проектирования

Beecher добавил к обнадёживающему ответу два условия. Географическое распределение может влиять на время SPF, а размер LSDB может потребовать настройки. Он также сделал более острый архитектурный вывод: если база данных достаточно велика, чтобы стать центральной проблемой, решение оставаться плоским, возможно, заслуживает пересмотра.

Dan Snyder свёл эти оговорки к трём переменным: аппаратное обеспечение, приемлемый размер домена сбоя и требуемое время сходимости. Они не взаимозаменяемы. Быстрая управляющая плоскость может быстро вычислять маршруты, хотя домен сбоя остаётся слишком широким. Небольшая LSDB может сочетаться с топологией, оставшиеся пути которой не могут пропустить трафик после серьёзного обрыва.

Более поздний ответ Matthew Petach сделал это разграничение главной новостью. Он предложил начать с радиуса поражения повторяющихся сбоев — ошибок автоматизации, ошибок ручного ввода, аппаратных неисправностей и обрывов волокна — и спросить, где должны находиться «противовзрывные двери». Он согласился с технической оценкой масштаба: 300 узлов, и даже значительно больше, могут быть в пределах возможностей IS-IS. Его возражение касалось отношения к этой возможности как к доказательству хорошей операционной архитектуры.

Фраза «противовзрывная дверь» — это метафора, а не указание механически добавлять области. Она определяет цель управления: один класс ошибок должен иметь чёткую границу, и у операторов должно оставаться место для перенаправления трафика, когда одного поведения кратчайшего пути уже недостаточно для приемлемого результата.

Длительность сбоя меняет ценность границы

Вышедший из строя оптический модуль внутри обслуживаемого объекта и повреждённый магистральный кабель создают разные эксплуатационные проблемы. Первый можно быстро заменить. Второй может оставаться ограниченным достаточно долго, чтобы схемы трафика, резервирование ёмкости и обязательства перед клиентами значили больше, чем номинальная сходимость.

Petach использовал трансокеанские каналы, чтобы показать это различие. Резервные подводные маршруты дороги, физическое разнообразие может скрывать общую судьбу, а немногие оставшиеся после регионального сбоя каналы могут быть достижимы, но неспособны пропустить все потоки, которые плоская топология направляет в их сторону. Это проблема распределения ёмкости после сходимости, а не просто проблема сходимости.

Статья не должна превращать этот пример в утверждение о конкретной кабельной системе. В обсуждении не описано ни одного сбоя и не приведено измерений маршрутов. Его эксплуатационная ценность заключается в предлагаемом тесте: при каждом правдоподобном отказе могут ли выжившие пути пропустить возникающий спрос и предоставляет ли проект более высокий уровень управления до того, как перегрузка станет единственным сигналом?

Иерархия IS-IS ограничивает масштаб, но не бесплатно

Стандарты объясняют, почему различие, проводимое операторами, устойчиво. RFC 5302 говорит, что домен IS-IS можно разделить на области уровня 1, соединённые топологией уровня 2. Удержание LSP внутри области ограничивает размер базы данных состояния каналов и сложность вычисления кратчайших путей.

Тот же RFC отвергает упрощённое правило «иерархия всегда побеждает». Суммирование и абстрагирование могут удалить информацию, необходимую для выбора оптимального пути. Распространение более детальных префиксов по домену улучшает видимость, но расходует память, пропускную способность и вычислительные ресурсы. Инженерный выбор — это компромисс между масштабируемостью и оптимальностью, а не бесплатное снижение риска.

RFC 9377 описывает накладные расходы на обработку и лавинную рассылку как конечное ограничение для одного домена затопления IS-IS и называет несколько доменов уровня 1 плюс магистраль уровня 2 стандартным подходом к масштабированию. RFC 8405 добавляет эксплуатационное предупреждение: параметры отката SPF должны быть согласованы в пределах одной области или уровня, а подходящие значения могут меняться в течение жизненного цикла сети.

Вместе эти документы не подтверждают ни фиксированный предел в 300 узлов, ни разрешение игнорировать границы. Они подтверждают необходимость измерений: размер топологии, число каналов, частота обновлений, рост LSDB, время лавинной рассылки, поведение SPF и ёмкость альтернативных путей — всё это должно входить в решение.

Полезная проверка состоит из четырёх тестов

Первый тест — технический запас. Операторам следует измерять размер LSDB, частоту смены LSP, нагрузку на процессор и память при изменениях топологии, время установления смежности и поведение полного и инкрементального SPF на самой медленной развёрнутой платформе, а не только на новейшем маршрутизаторе.

Второй — локализация сбоев. Проверка проекта должна перечислить ошибки автоматизации конфигурации, ошибки маршрутной политики, потерю устройства, потерю площадки и одновременные обрывы магистральных каналов. Для каждого события следует указать, какие маршрутизаторы пересчитывают маршруты, какой трафик переключается, какая эксплуатационная команда отвечает за реагирование и что должно остаться незатронутым.

Третий — ухудшенная ёмкость. Успешной сходимости недостаточно, если выжившие каналы насыщаются или если маршрутизация по кратчайшему пути направляет трафик туда, где операторы предпочли бы его защитить. Тест должен применять матрицы спроса к состояниям отказа и показывать, где вступают в действие управление трафиком, контроль допуска или приоритизация услуг.

Четвёртый — будущая эксплуатационная пригодность. Petach предложил автору вопроса рассмотреть рост на три, пять и десять лет. Сюда должно входить не только больше узлов, но и новые географические регионы, смешанные поколения оборудования, более крупные домены обслуживания и число инженеров, способных безопасно рассуждать о топологии во время инцидента.

Контрольная точка — первый документально оформленный бюджет отказов

Ни один участник не сможет выбрать правильную архитектуру без сведений о сети автора вопроса. Географически компактное развёртывание с обильной резервной ёмкостью может рационально оставаться плоским. Распределённой сети с медленным ремонтом, сосредоточенными магистральными путями или строгими обязательствами по обслуживанию могут потребоваться границы задолго до того, как масштаб управляющей плоскости станет неудобным.

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

Поэтому для проекта на 300 маршрутизаторов следующим полезным документом будет не очередной рассказ о большем числе узлов. Это бюджет отказов: события, которые сеть рассчитана выдержать, максимальный затрагиваемый масштаб и длительность, ёмкость, оставшаяся после каждого события, и точка управления, доступная, когда обычной маршрутизации по кратчайшему пути уже недостаточно.

Источники