Кратко

  • 0.0.0.0/0 и ::/0 не фиксируют ни одного бита destination, но соответствуют каждому адресу, оставшемуся после longest-prefix lookup. Их фактический scope меняется вместе с more-specific routes.
  • Создание, export, получение, import, выбор, запись в FIB и доставка packet — разные состояния. Established session доказывает только работу control channel до соседа.
  • Делегирование последнего выхода допустимо лишь для явно заданной связи, с predicate, близким к обещанной услуге, правом локального отказа, default-only canaries и измеренным withdrawal, failover и rollback.

AS 64580 получает от provider AS 64520 несколько региональных префиксов и IPv4 default вместо full table. В 09:41 AS 64520 теряет транспорт к основному upstream. Customer-facing link продолжает работать, EBGP session остаётся Established, несколько региональных routes доступны через другой путь.

Default была создана без условия. AS 64520 продолжает посылать 0.0.0.0/0, AS 64580 продолжает считать тот же next hop лучшим, hardware FIB не меняется. Probes к loopback провайдера, локальному DNS и двум сервисам под surviving more-specifics успешны. Остальные destinations идут по /0 и останавливаются перед исчезнувшим egress.

Сценарий синтетический, но не требует ошибки формата или нарушения BGP. Session соединяет два speaker, а не подтверждает доступность каждого адреса за ними. UPDATE доказывает отправку route; он не доказывает сохранность operating premise.

Нулевой префикс управляет изменяющимся остатком

RFC 1812 задаёт порядок forwarding: из подходящих routes сначала остаётся маршрут с самой длинной маской. /24 побеждает /0 внутри своего блока. Default используется только там, где нет пригодной более точной записи.

Нулевая длина означает, что 0.0.0.0/0 соответствует любому IPv4-адресу, а ::/0 — любому IPv6-адресу. Но множество packets, действительно использующих default, не записано в ней. Когда появляется 198.51.100.0/24, блок выходит из её scope; после withdrawal /24 возвращается.

Поэтому полномочие /0 может расшириться без изменения hash, AS_PATH, NEXT_HOP или возраста route. Исчезновение specific переводит новые destinations под default. Dashboard, наблюдающий лишь существование /0, не видит этого перераспределения.

RFC 4098 различает default route, default-free table и full default-free table. Одна default уменьшает state и переносит решение о неизвестных destinations к provider. Full table даёт customer больше информации и контроля, но требует памяти, CPU и policy operations. Selected specifics плюс default образуют ещё один контракт. Эти варианты не дают одинаковой доказательной базы.

IPv4 и IPv6 также не объединяются одним согласием. Каждому AFI/SAFI, VRF, next hop, filter и probe нужен отдельный scope.

Междоменное объявление должно быть осознанным

RFC 4632 называет 0.0.0.0/0 degenerate default prefix и требует, чтобы реализации умели его принимать. Одновременно документ ограничивает случайное распространение: в другой routing domain route следует объявлять только после explicit configuration, а не как неявную default option.

RFC 7454 добавляет отношение сторон. Вне конкретных customer/provider схем IPv4 и IPv6 defaults обычно не предполагается принимать или объявлять; рекомендуется filtering. При этом customer может легитимно запросить у provider только default, не full table.

Значит, /0 валиден, но его разрешение двустороннее и адресное. Согласие одного customer не разрешает отправку peer, upstream, route server или другому tenant. Peer-group inheritance не должно превращать узкое решение в широкое.

Provider ограничивает export списком одобренных neighbors. Customer принимает exact /0 только от авторизованной роли в нужной family и routing instance. Два фильтра сохраняют автономию: ошибка одной сети встречает локальную границу другой.

RFC 8212 не позволяет отсутствию import/export policy стать молчаливым EBGP-разрешением. Но явная policy может быть неправильной. Route-map способна включить чужого соседа или условие, не связанное с service. Наличие объекта не подтверждает корректность смысла.

За фразой «default есть» скрыты семь переходов

Сначала advertiser создаёт candidate — synthetic per-neighbor, static, generated или BGP-learned. Затем outbound policy решает, отправлять ли её. Receiver получает UPDATE, применяет import policy, сравнивает альтернативы, выбирает route в RIB и программирует next hop в FIB. Лишь после этого packet пытается пройти дальше.

Каждая граница может отказать отдельно. Candidate существует, но фильтруется. UPDATE принят по wire, но rejected. Route accepted, но уступает другой default. RIB обновилась, hardware задержался. FIB правильно указывает на живой интерфейс, но neighbor не имеет дальнейшего пути.

AS_PATH описывает распространение объявления /0, не реальные AS paths каждого residual destination. NEXT_HOP подтверждает локальный следующий шаг и его recursion, а не end-to-end delivery. LOCAL_PREF выражает решение customer, не измерение здоровья provider.

RFC 4271 позволяет withdraw /0, сохранив session и остальные routes. Если ложным стал только last-resort promise, clear всего neighbor избыточен: он расширяет blast radius и стирает часть diagnostic state.

Одинаковое имя команды не означает одинаковую модель

Текущая документация Cisco IOS описывает neighbor ... default-originate как per-neighbor действие и не требует локальной 0.0.0.0. На Nexus artificial default не обязана существовать в routing table или создаваться в local BGP RIB. Опциональная route-map может связать origination с установленной route.

FRRouting по умолчанию не объявляет 0.0.0.0/0, даже если та есть в routing table. Оператор явно включает neighbor ... default-originate и при необходимости добавляет route-map.

Junos использует active route и routing policy. Static, aggregate и generated routes экспортируются в BGP, если policy позволяет. Условные примеры соединяют active state и export decision.

Разница определяет failure behavior. Удаление local static /0 может не затронуть unconditional synthetic announcement. В другой схеме потеря active generated route и есть withdrawal trigger. Runbook нельзя переносить между vendors по похожей терминологии.

Нужно проверить работающую release: local RIB, BGP RIB, advertised-routes и receiver view. Удалить реальную support dependency, сохранив customer session. Отдельно измерить reevaluation, withdrawal, alternate selection, FIB и packets. Затем доказать обратный путь при recovery.

Predicate — свидетель, а не сама услуга

Conditional advertisement безопаснее только тогда, когда condition представляет service, обещанный посредством /0.

Доступный provider loopback доказывает один loopback. Interface up — local carrier. Активная static route может доказывать конфигурацию или recursion. Table count — количество, не выбранный egress. BFD — continuity с конкретным peer. Ни один сигнал не охватывает весь residual set.

Сначала определяется обещание. Если default означает широкий public transit, canaries должны идти через customer egress, обращаться к независимым networks и покрывать несколько dependencies. Если это private WAN exit, тест остаётся в частном scope. Широкое маркетинговое имя не расширяет узкий sensor.

Объединение сигналов создаёт выбор между ошибками. Требование успеха всех может отозвать последний полезный путь из-за одной test target. Успех любого одного может сохранить blackhole при доступной маленькой островной сети. Quorum, hysteresis, hold-down и recovery threshold распределяют стоимость раннего и позднего withdrawal.

State history должна сохранять inputs, aggregate decision, время predicate failure, UPDATE withdrawal, Best Path change, FIB programming и packet recovery. Здоровый snapshot после события не восстанавливает последовательность.

More-specifics скрывают проблему в обе стороны

Probes в исходном сценарии успешны, потому что их destinations используют surviving more-specifics. Сломанную default они не проверяют. Monitoring, сосредоточенный на региональных сервисах и крупных платформах, может принять маленький остров доступности за общее здоровье.

Обратная ситуация так же важна. Здоровая /0 не спасает destination под неисправным /24, поскольку longest match выбирает specific первым. Stale route, неверный next hop или leak может изолировать один сервис, пока остальной Internet работает через default.

Каждая canary должна сохранять winning prefix, RIB entry, FIB next hop и egress. Успех application без attribution не говорит, какая policy прошла проверку. Появление или withdrawal specific меняет класс probe даже при неизменной /0.

Две defaults также не доказывают независимость. Sessions на разных routers могут делить metro fibre, higher-level transit, controller или health target. Отключение одной session проверяет session failover, но не upstream failure при живой customer session.

Leak передаёт соседу весь неизвестный остаток

Default от неправильного relationship отдаёт neighbor все destinations без более точной локальной route. В core с full table residual set может быть мал. В stub customer почти весь внешний traffic способен уйти туда.

Export filter разрешает только определённых customers и блокирует peers, providers, route servers и чужие tenants. Import filter принимает exact zero-length prefix лишь от правильного neighbor в правильных AFI/SAFI и VRF. Peer-group inheritance и dual-stack automation проверяются readbackом.

Configuration показывает intent. Adj-RIB-Out показывает фактическую отправку speaker. Pre-policy и accepted view receiver разделяют прибытие и применение. Public collector способен обнаружить дальнейшее распространение, но не наблюдает каждую связь. Отсутствие у него не является глобальным отрицательным доказательством.

Evidence ledger идёт от обещания до packet

Для каждого default relationship сначала фиксируется смысл: public Internet transit, выбранные внешние services, private WAN exit или временный fallback. Затем advertiser, receiver, role, family, VRF, approval owner и withdrawal owner.

Записываются generation model, predicate, inputs, quorum, timers, hysteresis и failure action. Runtime ledger хранит candidate, post-policy advertisement, pre-policy receipt, accepted route, selection reason, recursion, hardware FIB и alternatives с timestamps.

Canaries запускаются у receiver, где доверие превращается в forwarding. Часть целей должна зависеть только от /0; другая часть намеренно покрывается specifics, чтобы проверить границу. Targets распределяются по реально независимым сетям, а egress сохраняется вместе с результатом.

Failure drill оставляет customer session и удаляет upstream, поддерживающий promise. Condition failure, withdrawal, alternate RIB, FIB и recovery измеряются отдельно. Если альтернативы нет, доказывается прекращение отправки в мёртвый provider path.

Rollback восстанавливает generation, condition, timers, neighbor scope, attributes, import preference и monitoring. Он завершается только после возврата observed state и packets к предыдущему контракту.

Тонкая координация требует сильного локального выхода

Default route может быть эффективной минимальной координацией. Provider не передаёт полную destination map; customer локально выбирает fallback. Центральная authority не нужна, и обе сети сохраняют policy control.

Именно малая информативность запрещает максимальное толкование. Название provider не является data-plane certificate. UPDATE не является SLA. Вчерашнее принятие не отменяет право завтра reject или изменить preference.

Running-Code Primacy упорядочивает доказательства: contract описывает ожидание, configuration — намерение, UPDATE — отправку, RIB/FIB — локальное действие, packet — running result. Каждый слой нужен и ни один не подменяет следующий.