Resumen

  • LOCAL_PREF expresa el orden de preferencia de un AS entre rutas elegibles. No acredita su origen, su seguridad, su coste ni la entrega de tráfico.
  • Una regla de entrada puede influir en las salidas de otros routers mediante IBGP. Su alcance real depende de las rutas que coinciden con la regla y de la visibilidad interna.
  • Las comunidades permiten solicitar un tratamiento, pero el operador conserva la autoridad sobre su aplicación. La comprobación debe llegar hasta las tablas de reenvío y los paquetes.

El cambio que el vecino no ve

Imaginemos un caso ilustrativo, no una avería documentada. Dos routers de borde, A y B, ofrecen rutas viables al mismo prefijo. A anuncia un camino de AS más corto; ambas rutas tienen LOCAL_PREF 100. Los criterios anteriores están empatados, incluido el peso de Cisco si se utiliza ese procedimiento. El operador modifica una regla de entrada y asigna 200 a la ruta recibida por B. Al comparar esas alternativas, la preferencia local puede decidir a favor de B antes de considerar la longitud del camino.

El vecino externo no recibe el atributo interno que explica el cambio. Puede notar sus consecuencias en el tráfico, pero no leer directamente esa decisión en un anuncio EBGP ordinario. Desde dentro, el número parece pequeño y el ajuste sencillo. Desde el servicio, lo relevante puede ser un desplazamiento de carga hacia otro enlace, otra ubicación o una capacidad de reserva distinta. Ninguno de esos efectos está demostrado por haber guardado la configuración.

LOCAL_PREF transporta un grado de preferencia en un entero sin signo de cuatro octetos. La política del AS receptor lo determina para las rutas externas y lo comunica a sus vecinos internos. El valor mayor es el preferido. Fuera de la excepción de las confederaciones, no se envía a vecinos externos ni se acepta como instrucción de uno de ellos. RFC 4271, sección 5.1.5

Esto deja una responsabilidad concreta en manos del operador: explicar por qué una clase merece prioridad sobre otra. El estándar no decide qué proveedor conviene, cuánto vale una reserva ni qué compromiso comercial debe prevalecer. Tampoco prescribe 100 como valor universal por defecto. RFC 4277 lo describe como una práctica habitual de las implementaciones. Confundir costumbre con garantía complica especialmente las migraciones. RFC 4277, sección 8

No todas las rutas llegan a competir

Antes de preguntar cuál gana, hay que determinar cuáles pueden participar. Una preferencia elevada no subsana un rechazo de la política de importación ni convierte un siguiente salto inaccesible en uno alcanzable. Tampoco valida el origen de una ruta. La validación de origen aporta un estado que la política local debe tratar por separado; no proporciona una clasificación universal de salidas. RFC 6483, sección 3

La documentación de los fabricantes muestra por qué importa precisar el ámbito. Cisco evalúa su parámetro de peso, propio del router, antes de LOCAL_PREF. En Junos, la resolución del siguiente salto y la preferencia del protocolo de enrutamiento preceden a la preferencia local BGP. Esa preferencia del protocolo es un mecanismo distinto, aunque aparezca cerca en las pantallas. No cabe presentar la secuencia completa de un fabricante como si fuera idéntica en cualquier sistema. Algoritmo de selección de Cisco, Selección de rutas en Junos

Hay además una trampa frecuente en las demostraciones: comparar destinos distintos. Una preferencia muy alta en un agregado no vence a una ruta más específica instalada para una dirección incluida en él. El reenvío sigue utilizando la coincidencia de prefijo más largo. Probar una dirección cubierta por esa ruta específica no demuestra qué ocurrió con la selección del agregado.

Junos también distingue la conservación de un LOCAL_PREF presente de la aplicación del valor por defecto al exportar rutas hacia BGP. Esa precisión obliga a observar el estado recibido, la política aplicada y el estado anunciado; mirar una sola etapa puede llevar a una conclusión equivocada. Preferencia local en Junos

Solicitar prioridad no equivale a concedérsela

Un cliente con varios accesos puede conocer mejor que su proveedor cuál desea mantener como respaldo. RFC 1998 describe cómo una comunidad permite solicitar una clase de preferencia que el proveedor ha definido. El cliente elige la etiqueta; la red receptora ejecuta la correspondencia. La comunidad no es el propio LOCAL_PREF y su presencia no acredita por sí sola que cualquier vecino tenga derecho a activar esa acción. RFC 1998, sección 3.2

Las Large Communities amplían las posibilidades de expresar acciones y ámbitos, incluidos los geográficos. Su utilidad depende de una interpretación documentada y de un orden de procesamiento claro. Si dos solicitudes entran en conflicto, la secuencia aplicada puede importar tanto como el valor final. El límite operativo debe especificar vecino, rutas autorizadas, alcance y precedencia. RFC 8195, secciones 2.2 y 4.3

Se trata de una delegación acotada, no de una cesión de la política del AS. Por eso una asociación antigua puede ser peligrosa aun cuando cada anuncio sea correcto: la organización puede haber cambiado el significado de una clase sin revisar a quién afecta. La etiqueta sigue siendo válida; la intención que el operador cree estar ejecutando quizá ya no lo sea.

Conviene mantener separados otros instrumentos. MED transmite una indicación del vecino sobre entradas; LOCAL_PREF materializa una decisión de la red receptora. AIGP utiliza una métrica acumulada bajo un acuerdo administrativo delimitado. Una comunidad es un espacio para información o solicitudes de acción. Ninguno de ellos demuestra, por el mero hecho de existir, que la salida elegida cumple el objetivo del servicio.

El número puede ser válido y la decisión equivocada

Los mecanismos de tratamiento de errores no leen la intención del ingeniero. RFC 7606 establece el descarte de LOCAL_PREF recibido de un vecino externo ordinario y el tratamiento como retirada de una actualización interna cuando la longitud del atributo no es de cuatro octetos. Un 200 correctamente codificado donde se pretendía 100 no pertenece a esa categoría de errores de formato. RFC 7606, sección 7.5

Por tanto, una política equivocada puede dejar las sesiones activas y un número de rutas aparentemente normal. El cambio importante estará en la distribución del tráfico. Un incremento de carga en un enlace no prueba por sí solo la causa, pero justifica contrastar qué prefijos cambiaron de salida y qué regla los alcanzó. La unidad de impacto no es la ruta del ejemplo: es todo el conjunto que coincide con la condición, en las familias de direcciones afectadas.

La palabra «local» tampoco significa «solo este router». IBGP lleva el resultado a otros puntos del AS. Sin embargo, no existe una exigencia general de que todos los routers mantengan siempre valores idénticos: RFC 4272 lo señala expresamente. Una diferencia regional puede ser deliberada. Otra cosa es recalcular sin considerar el diseño; RFC 4271 advierte de posibles bucles persistentes al recomputar la preferencia de rutas internas. RFC 4272, análisis de LOCAL_PREF, RFC 4271, sección 9.1.1

La coherencia debe comprobarse en el funcionamiento. Dos routers con el mismo número pueden conocer alternativas distintas. Un reflector puede ocultar una ruta de respaldo. Un siguiente salto puede resolverse de forma diferente en otra ubicación. Estos límites impiden prometer que una sola modificación determina necesariamente la salida de todos los routers.

Graceful Shutdown muestra otra diferencia crucial: bajar la preferencia, incluso a cero, no retira una ruta. La recomendación permite seguir utilizándola mientras se eligen y propagan alternativas. Si es la única opción elegible, puede continuar transportando tráfico. Antes de cortar el enlace hay que comprobar la alternativa y la convergencia; la marca de mantenimiento no hace aparecer capacidad ni caminos que no existen. RFC 8326, secciones 3 y 4

La prueba termina fuera de la configuración

Una verificación defendible conserva la intención y sus límites: responsable de la política, motivo, rutas incluidas y condición de reversión. Después compara las alternativas de Adj-RIB-In y los valores calculados con los anuncios internos y las rutas elegidas en Loc-RIB, en más de un punto relevante. Debe abarcar también la visibilidad detrás de los reflectores. Un colector público exterior no permite observar directamente el atributo interno.

El siguiente paso es comprobar la resolución del siguiente salto y la instalación en la base de información de reenvío, FIB, incluidos los caminos de coste igual que correspondan. Finalmente, las sondas desde los puntos de entrada afectados y los contadores de salida deben respaldar el cambio esperado. Un resultado de control no sustituye la entrega de paquetes; una sonda aislada no representa todos los destinos.

La reversión exige volver a evaluar las rutas y repetir esa comprobación. Puede utilizar el estado retenido o Route Refresh cuando se haya negociado, pero refrescar información no define la política. Restaurar una línea de configuración sin verificar el tráfico deja sin resolver la cuestión principal: si la red ha vuelto a prestar el comportamiento útil que se pretendía proteger.