Кратко

  • maximum-prefix ограничивает количество маршрутного состояния, но не определяет законность маршрута, который пересёк порог. При разрыве сессии один дополнительный маршрут может убрать все пути, полученные от этого соседа.
  • Надёжная политика задаёт границу отдельно для соседа и семейства адресов, уточняет подсчёт до или после фильтрации, учитывает нормальный рост, выбирает соразмерное действие и подтверждает эффект в RIB, FIB и пакетах.

Что именно разрешает число

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

Если выбрано завершение, маршрут, переведший счётчик из N в N+1, не обязан быть ошибочным. Он может иметь допустимый префикс, происхождение и атрибуты. После превышения получатель закрывает соединение, а первые N маршрутов тоже теряют источник. Часть трафика перейдёт на резервные пути; часть может выбрать худший маршрут; для некоторых направлений альтернативы не окажется.

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

Варианты, предусмотренные BGP

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

RFC 4486 определяет для этого причину Cease с подкодом 1, Maximum Number of Prefixes Reached. Дополнительные данные могут содержать AFI, SAFI и четырёхоктетную верхнюю границу. Они позволяют отличить срабатывание количественной политики от административного закрытия, коллизии или общего сбоя ресурсов.

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

Количество не проверяет содержание

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

Префиксные и AS_PATH-фильтры, RPKI origin validation, правила next hop и community оценивают свойства маршрута и отношения. maximum-prefix оценивает объём. Они дополняют друг друга, поскольку корректное состояние тоже потребляет ресурсы, но отвечают на разные вопросы.

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

До политики или после неё

Одинаковая цифра может описывать разные границы.

В документации BGP FRRouting maximum-prefix по умолчанию считает принятые префиксы. Параметр force включает все полученные, в том числе отклонённые входной политикой, и требует хранения соответствующего входного состояния. Документация также предупреждает, что разрушение сессии намного серьёзнее, чем отклонение нежелательных маршрутов.

Junos разделяет две задачи. prefix-limit применяется к полученным префиксам, accepted-prefix-limit — к прошедшим политику. Возможны разрыв, отбрасывание излишка и его скрытие, причём остаточное состояние и восстановление различаются.

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

Кроме того, префикс не всегда равен пути. ADD-PATH, VPN-семейства и внутренние структуры способны хранить несколько путей к одному назначению. Нужно проверить семантику работающей версии, а не переносить число по знакомому названию команды.

Четыре действия — четыре формы сбоя

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

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

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

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

Сходные термины производителей не гарантируют одинакового результата. Cisco описывает процент предупреждения, разрыв по умолчанию, режим только предупреждения и необязательный интервал перезапуска. Arista EOS описывает отключение peering, а также предупреждающий режим, способный сохранить сессию и отбрасывать последующие маршруты. Сравнивать нужно оставшееся состояние.

Порог вырастает из отношений

RFC 7454 рекомендует отдельные значения для каждого peering. Для соседа с ограниченным ожидаемым набором граница ниже полной интернет-таблицы может обнаружить её ошибочный экспорт. Для upstream, который должен передавать полную таблицу, максимум должен быть выше ожидаемого объёма, но оставаться в безопасной ёмкости получателя.

Расчёт начинается с легитимного набора по договорённости. К нему добавляют наблюдаемую вариативность, достоверный рост, подключение клиентов, допустимую деагрегацию и миграции. Прогноз сравнивают с возможностями платформы и стоимостью выбранного действия. У значения должны быть владелец, дата пересмотра и аварийный путь изменения.

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

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

Таймер не доказывает исправление

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

Прошедшее время не является доказательством изменения. Для обоснованного возврата нужны подтверждённое снятие излишка, исправленная export policy, одобренный новый порог или новая ёмкость. Ручной clear без этого лишь заменяет таймер человеком.

RFC 8538 предлагает считать Cease по maximum-prefix условием hard reset в Graceful Restart. Намеренно выполненная количественная политика не должна выглядеть как обычный рестарт из-за молчаливого сохранения устаревших маршрутов.

Цепочка от счётчика до пакетов

Доказательство начинается с эффективной конфигурации по соседу и AFI/SAFI, включая наследование, предупреждение и действие. Сохраняются версия ПО и документированное определение полученного против принятого, префикса против пути.

При событии фиксируются последнее допущенное обновление, переход счётчика, код и подкод Cease, AFI/SAFI/граница, состояние сессии, таймеры и журналы, которые могли ограничиваться по частоте. Отозванные, отброшенные, скрытые и сохранённые маршруты разделяются.

Затем проверяется достижимость. Какие назначения сменили лучший путь? Были ли альтернативы в RIB и установились ли в FIB? Хватило ли ёмкости принимающим каналам? Дошли ли тестовые пакеты до критических классов? Одинаковое итоговое число не доказывает одинаковые префиксы, атрибуты или next hop.

Контроль успешен только тогда, когда названный ресурс остаётся в безопасной цели, а состояние сервиса соответствует одобренному компромиссу. Сам счётчик не доказывает ни того, ни другого.

Источники