Resumen

  • 0.0.0.0/0 y ::/0 coinciden con cualquier dirección, pero solo ganan cuando no existe una ruta más larga. Su ámbito real es el conjunto residual de la tabla y cambia sin que cambie el anuncio.
  • Originar, exportar, recibir, aceptar, seleccionar, instalar y entregar son estados diferentes. El peer puede seguir Established y el FIB apuntar al vecino mientras la capacidad de tránsito ya ha desaparecido.
  • La delegación de último recurso debe limitarse a una relación explícita, depender de evidencia próxima al servicio, conservar el rechazo local del receptor y demostrar retirada, failover y recuperación con paquetes.

AS 64580 compra conectividad a AS 64520. Para reducir memoria y complejidad, recibe algunos prefijos regionales y 0.0.0.0/0, no una tabla completa. A las 09:41, AS 64520 pierde el transporte hacia su tránsito principal. El router orientado al cliente sigue encendido, el enlace está activo y la sesión EBGP no cae. También sobreviven varias rutas regionales.

La ruta por defecto fue generada sin condición. AS 64520 continúa anunciándola; AS 64580 continúa prefiriéndola e instalándola. Los probes elegidos por el dashboard consultan un resolver local, el loopback del proveedor y servicios cubiertos por rutas más específicas. Todos responden. Los destinos que dependen realmente de /0 llegan al proveedor y encuentran un egress inexistente.

El caso es sintético, pero no necesita una infracción del protocolo. BGP mantiene una sesión con el vecino, no con todos los destinos que el vecino pretende alcanzar. El UPDATE prueba que el anuncio fue enviado. No prueba que la premisa de forwarding siga siendo cierta.

El prefijo más corto gobierna lo que queda

RFC 1812 define la regla decisiva: entre las rutas que coinciden con una dirección, se conserva la de prefijo más largo. Un /24 vence a /0; un /32 vence al /24. La preferencia de protocolo o la métrica intervienen después entre candidatos comparables, no permiten que una default derrote a una ruta válida más específica.

El prefijo cero no fija ningún bit. Por eso 0.0.0.0/0 coincide con todo IPv4 y ::/0 con todo IPv6. Sin embargo, el tráfico efectivo que reciben depende del resto de la tabla. Cuando aparece 203.0.113.0/24, ese bloque deja de usar la default. Cuando el /24 se retira, vuelve a ella de inmediato.

La autoridad de /0 es dinámica aunque su representación sea estable. Cada alta o baja de una ruta más específica modifica la frontera de la delegación. Un monitor que solo compara el hash, los atributos o la antigüedad de la default no detecta esa ampliación.

RFC 4098 separa la default de una tabla default-free y de una tabla completa default-free. Una única ruta reduce estado y delega la selección externa al proveedor. Una tabla completa concede al cliente más información y más decisiones, a cambio de memoria, CPU y operación. Recibir defaults de dos proveedores tampoco equivale automáticamente a una tabla completa ni a dos riesgos independientes.

La autorización es bilateral y exacta

RFC 4632 exige que las implementaciones acepten el prefijo degenerado 0.0.0.0/0, pero advierte contra su aparición accidental entre dominios: debe anunciarse solo mediante configuración explícita. Esa frase evita que la comodidad del software se convierta en consentimiento interorganizacional.

RFC 7454 recomienda filtrar defaults IPv4 e IPv6 fuera de configuraciones específicas customer/provider. También contempla un cliente que solicita únicamente la ruta por defecto. El mensaje no es “nunca use /0”; es “no confunda un acuerdo limitado con un permiso universal”.

El proveedor decide a qué neighbor promete último recurso. El cliente decide de qué neighbor acepta ese poder. La export policy debe excluir peers, upstreams, route servers y clientes no incluidos. La import policy debe admitir exactamente /0, en la familia y VRF previstas, solo desde el rol autorizado.

Esta duplicación aparente es una característica de autonomía. Si el proveedor aplica mal una plantilla, el cliente conserva su frontera. Si el cliente abre demasiado su filtro, la lista de exportación todavía limita el daño.

RFC 8212 impide que la ausencia de policy se interprete como permiso EBGP. Pero un objeto explícito puede estar equivocado. Una route-map existente puede abarcar un peer-group excesivo o asociar la default a una señal irrelevante. La existencia de policy no sustituye la revisión de su significado.

Una sola luz verde oculta siete transiciones

La frase “tenemos default” debe descomponerse. El emisor crea un candidato, mediante un objeto sintético, una static, una generated route o una ruta BGP. Después, la política de salida permite o niega el anuncio al neighbor. El receptor recibe el UPDATE, aplica import policy, compara alternativas, instala el ganador en su RIB y programa el next hop en la FIB. Solo entonces un paquete intenta atravesar el camino.

Un candidato puede existir sin salir. Un UPDATE puede llegar y ser rechazado. Una ruta aceptada puede perder frente a otra default con mejor LOCAL_PREF. La RIB puede haber cambiado mientras el hardware aún conserva el estado anterior. El hardware puede apuntar correctamente al vecino y ese vecino no disponer de salida hacia el destino.

También hay que separar atributos y realidad. AS_PATH describe cómo se propagó el anuncio /0; no enumera el AS path de cada dirección que terminará bajo su cobertura. NEXT_HOP muestra la siguiente decisión local; su resolución no confirma la ruta completa. LOCAL_PREF expresa intención local, no salud medida.

RFC 4271 permite retirar la ruta mediante UPDATE sin cerrar la sesión. Si la promesa de último recurso falla, puede desaparecer /0 y permanecer el resto de la relación. Reiniciar todo el neighbor como mecanismo habitual destruye alcance, evidencia y estabilidad innecesariamente.

default-originate cambia de significado operacional según la plataforma

La documentación actual de Cisco IOS presenta neighbor ... default-originate como una acción por vecino y no exige que 0.0.0.0 exista en el router local. En Nexus, la default artificial tampoco necesita residir en la routing table ni crearse en el BGP RIB local. Una route-map opcional permite condicionar el anuncio a una ruta instalada que coincida.

FRRouting documenta una protección distinta: BGP no anuncia 0.0.0.0/0 por defecto aunque esté en la routing table. El operador habilita explícitamente neighbor ... default-originate y puede añadir una route-map.

Junos trabaja con active routes y routing policy. Las rutas static, aggregate o generated pueden exportarse a BGP cuando la policy lo permite. Sus ejemplos condicionales muestran que la actividad de una ruta y la evaluación de export forman una cadena.

La consecuencia práctica es grave. Eliminar una static /0 no necesariamente retira una default sintética e incondicional. En otro diseño, la pérdida de la generated route es precisamente lo que desactiva el export. El mismo runbook, trasladado por semejanza de nombres, puede dejar un anuncio huérfano.

El comportamiento debe probarse en la release real. Registrar local RIB, BGP RIB, advertised-routes y la vista del receptor. Mantener viva la sesión customer y eliminar el soporte que supuestamente condiciona la default. Medir reevaluación, withdrawal, nueva selección, FIB y paquetes. La recuperación requiere la prueba inversa.

El predicate debe parecerse a la promesa

Una condición evita el anuncio incondicional, pero no garantiza una buena condición. Cada señal demuestra solo su propio objeto.

Un loopback del proveedor prueba ese loopback. Un interface-up prueba carrier local. Una static activa puede probar únicamente que la configuración conserva una recursión. Un contador de rutas prueba cantidad, no forwarding. BFD prueba continuidad con un peer concreto. Ninguno equivale a todos los destinos que actualmente carecen de una ruta más específica.

Primero se define el servicio. Si /0 representa tránsito público amplio, los probes deben salir por el mismo egress que el tráfico customer, repartirse entre redes independientes y observar más de una dependencia. Si representa una salida privada, la prueba debe limitarse al dominio privado. Una etiqueta comercial amplia no puede rellenar los huecos de una métrica estrecha.

La combinación de señales decide cómo repartir dos errores. Exigir todas puede retirar la última ruta útil cuando falla una sola sonda. Aceptar cualquiera puede mantener el blackhole cuando sobrevive un islote. Quorum, hold-down, hysteresis y criterio de recuperación asignan coste entre retirada prematura y retirada tardía.

Cada entrada y decisión agregada necesita timestamp. Deben poder reconstruirse el fallo del predicate, la retirada del UPDATE, el cambio de best path, la escritura del FIB y la recuperación del paquete. Un estado sano capturado después no explica el intervalo de daño.

Las rutas específicas producen ceguera en dos sentidos

En el ejemplo, los probes pasan porque sus destinos tienen rutas más específicas que vencen a la default. El panel atribuye el éxito a la relación equivocada. Si las sondas se concentran en servicios locales o grandes plataformas con anuncios específicos, la parte residual puede fallar en silencio.

Existe el caso inverso: /0 funciona, pero un /24 roto lo derrota. Una ruta específica obsoleta, un next hop no programado o un leak puede desviar un servicio hacia un blackhole mientras el resto navega correctamente por la default. La salud de /0 no debe cerrar alertas de rutas más largas.

Cada canary debe guardar qué prefix ganó, qué ruta quedó en la RIB, qué next hop entró en hardware y qué egress transportó el paquete. Sin atribución, un resultado HTTP exitoso es demasiado débil para validar una política de routing.

Cuando cambia una ruta específica, también cambia el objeto que prueba la sonda. La observabilidad debe reclasificarla aunque /0 no emita ningún UPDATE. El ámbito de la default es una función de toda la tabla, no un atributo almacenado dentro de ella.

Dos defaults pueden compartir el mismo punto de fallo

El cliente puede recibir /0 de dos carriers y asignar preferencias diferentes. Eso aporta opciones, pero la independencia no se infiere de dos sesiones. Los routers pueden usar la misma fibra metropolitana, el mismo upstream de mayor nivel, el mismo route controller o el mismo sistema de health checks.

Un simulacro que apaga una sesión demuestra la reacción a una sesión caída. No demuestra el escenario inicial, donde la sesión customer sobrevive y falla otra dependencia. Los ensayos deben modelar el fallo real que la condición pretende detectar.

El cliente conserva autoridad para reducir LOCAL_PREF, rechazar una default o quitarla de servicio aunque el proveedor siga enviándola. El proveedor conserva responsabilidad de retirar su promesa cuando su evidencia cae. Esperar que solo una parte actúe crea una dependencia innecesaria.

Una fuga de /0 transfiere todo el residuo

Una default recibida desde la relación equivocada atrae todo destino que la tabla local no conoce mejor. El alcance depende del receptor: puede ser pequeño en un core con full table o casi total en un stub que solo conserva rutas locales.

El export debe vincular la ruta a una lista de customers y comprobar el resultado post-policy. El import debe rechazar defaults de peers y providers no autorizados. IPv4, IPv6 y cada routing instance se verifican por separado. Peer-groups y generadores merecen atención porque una modificación hereda alcance a gran velocidad.

La evidencia externa no sustituye la interna. Adj-RIB-Out muestra lo enviado por un speaker. Adj-RIB-In del vecino muestra llegada; la vista accepted muestra el efecto del filtro. Un collector público puede descubrir propagación posterior, pero no observa todos los enlaces. “No apareció en el collector” no es una prueba de no fuga.

El registro operativo empieza por el significado

Antes de configurar, escribir qué representa la default: Internet general, un conjunto de servicios, una salida WAN o un fallback temporal. Identificar advertiser, receiver, rol, AFI/SAFI, VRF, owner de la decisión y owner del withdrawal.

Guardar el modelo de generación, el predicate, sus fuentes, quorum, timers e hysteresis. Después conservar candidate route, salida post-policy, recepción pre-policy, ruta aceptada, razón de selección, recursión y hardware FIB. Las alternativas y rutas específicas de cada canary forman parte del mismo registro.

Las sondas deben salir desde el receptor, donde la promesa se convierte en una acción. Parte de los destinos debe depender solo de /0; otra parte debe estar cubierta intencionalmente por specifics para demostrar la frontera. Las targets se distribuyen entre redes y se acompañan de información de egress.

El ejercicio retira el verdadero soporte upstream sin apagar el peer customer. Se miden por separado predicate, withdrawal, selección alternativa, FIB y recuperación. Cuando no hay alternativa, se prueba que el cliente deja de enviar al camino muerto en vez de conservar el blackhole.

Rollback significa restaurar generación, condición, temporización, alcance, atributos, preferencia de entrada y monitoring. No termina al aceptar la configuración: termina cuando el estado observado y los paquetes vuelven al contrato anterior.

La coordinación mínima depende de una salida local fuerte

La default permite cooperación con poca información común. El provider resume; el customer decide localmente si usar ese resumen. No hace falta una autoridad central que ordene todas las rutas, y cualquiera de las partes puede cerrar su parte del acuerdo.

Precisamente por ser mínima, la señal no soporta interpretaciones máximas. El rol de provider no certifica el data plane. El UPDATE no prueba el SLA. La aceptación de ayer no obliga a conservar la ruta mañana. La legitimidad viene del consentimiento específico, el control local y la reversibilidad.

Running-Code Primacy organiza la prueba. El contrato expresa intención económica; la configuración, intención técnica; el UPDATE, una declaración enviada; RIB y FIB, la decisión local; el paquete, el comportamiento. Ninguna capa debe presentarse como prueba total de las siguientes.