Resumen

  • MULTI_EXIT_DISC es una recomendación débil, opcional y no transitiva sobre la entrada preferida entre varios enlaces hacia el mismo AS anunciante; el valor menor cuenta solo si los criterios locales más fuertes empatan.
  • La red receptora conserva el control: puede eliminar o cambiar MED antes de seleccionar, y la regla ordinaria compara valores únicamente entre caminos aprendidos del mismo AS vecino.
  • El uso correcto requiere significado bilateral, suficientes candidatos visibles y prueba en ejecución. Tratar números de redes distintas como una escala única puede causar decisiones incoherentes u oscilación persistente en topologías concretas.

AS 65001 se conecta con AS 65002 en Madrid y Barcelona. Para el mismo prefijo anuncia MED 20 en Barcelona y MED 80 en Madrid. Expresa una preferencia: si los demás atributos importantes son iguales, quiere recibir el tráfico en Barcelona. Puede tener allí más capacidad, menor distancia interna o una restricción en la otra sede.

AS 65002 sigue decidiendo. Quizá su contrato asigne menor LOCAL_PREF al camino de Barcelona. Puede aceptar MED solo de algunas relaciones, borrar el atributo, reemplazarlo o seleccionar desde un router que no ve la alternativa. El número menor no escribe política remota; se evalúa dentro de otro sistema gobernado por separado.

RFC 4271 recoge esa modestia en MULTI_EXIT_DISC: un entero sin signo de cuatro octetos, opcional y no transitivo. A igualdad de todo lo demás, debe preferirse el menor. Recibido por EBGP puede circular por IBGP dentro del AS receptor, pero no debe propagarse a otro AS vecino. La recomendación termina donde termina la relación que le da contexto.

Las facultades del receptor son explícitas. Toda implementación debe permitir eliminar localmente un MED recibido antes de calcular preferencia y seleccionar. También puede modificarlo en esa etapa. El emisor controla el dato que anuncia; el receptor decide si sobrevive y qué consecuencia local produce.

La debilidad fue deliberada. RFC 1773 describía el antiguo inter-AS metric como un factor tardío. El diseño evitaba que un operador remoto obligara a otra red a absorber o expulsar tráfico cuando esta ya había expresado una preferencia superior. LOCAL_PREF, longitud de AS_PATH y pasos anteriores forman la frontera que mantiene condicional el consejo.

Por eso «gana el MED más bajo» es falso. Un camino con 10 puede perder frente a otro con 100 si el segundo tiene mejor LOCAL_PREF o vence antes. RFC 8326 muestra el límite en mantenimiento: elevar MED no drena por completo un enlace si la alternativa pierde antes por LOCAL_PREF o longitud de AS_PATH.

El dominio ordinario es aún más estrecho. RFC 4271 compara MED solo entre rutas del mismo AS vecino, identificado mediante AS_PATH. Tres valores de AS 65001 pueden ordenar sus tres entradas. Una ruta de AS 65003 probablemente usa otra topología, costes y política. Veinte en una relación no es naturalmente menor que cuarenta en otra.

MED no forma un orden total. A puede superar a B por compartir vecino y tener menor MED; B y C, de vecinos distintos, siguen por otros criterios. Eso no coloca A, B y C en una secuencia transitiva. Importan la agrupación, el ganador de cada grupo y los candidatos que conoce el punto de decisión.

IOS XR describe el mecanismo: agrupa caminos por AS vecino, escoge el mejor MED de cada grupo y continúa la selección entre ganadores. Refleja el dominio limitado del protocolo y explica por qué el orden o la integridad de los candidatos puede cambiar la respuesta.

Algunos productos permiten comparar MED de vecinos diferentes. Parece más uniforme porque todos los números compiten juntos; en realidad amplía la influencia concedida a datos remotos. Juniper advierte sobre escalas sin origen común y RFC 3345 rechaza esta opción como arreglo general. El mismo tipo de campo no prueba la misma unidad.

La red receptora puede crear deliberadamente una escala común: reescribir todos los valores con su política o acordar una métrica de servicio con participantes concretos. La comparabilidad nace entonces del significado local. Deben documentarse grupo, derivación, ausencia y precedencia; cuatro octetos no llegan de Internet con unidad incorporada.

La ausencia también necesita una decisión. Al ser opcional, un camino puede llevar MED y otro no. Productos y políticas pueden interpretar el silencio de forma distinta. Hay que comprobar la conducta activa, sin afirmar que ausencia equivale siempre a cero, infinito o la elección de un fabricante.

La visibilidad altera el resultado. Una malla IBGP completa distribuye más salidas; Route Reflection y confederaciones reducen la carga al no mostrar cada candidato en todos los lugares. RFC 4456 advierte que MED no siempre es comparable y la distancia IGP cambia entre routers, de modo que algunas topologías reflejadas eligen distinto que una malla completa.

La jerarquía no queda condenada: su visibilidad entra en la prueba. Si un reflector ve A y B, otro B y C, y la preferencia no es transitiva, cada uno puede tomar una decisión local razonable que retire información necesaria en otro punto. El ahorro de escala ha cambiado la superficie de decisión.

RFC 3345 documenta condiciones acotadas que producen oscilación persistente: determinadas estructuras de reflectores o confederación, visibilidad parcial e incoherente de salidas y decisiones sensibles a MED. Bajo esas condiciones el fenómeno es determinista. No aparece en toda red, pero tampoco es ruido aleatorio.

Los arreglos cambian autoridad o visibilidad: rediseñar reflectores, dar visión mutua a routers de borde, fijar LOCAL_PREF al entrar, normalizar o eliminar MED, limitar relaciones o distribuir más caminos. Comparar todo puede mezclar espacios incompatibles; eliminar todo desperdicia una recomendación útil. La respuesta debe corresponder al mecanismo demostrado.

RFC 5004 atiende un movimiento más estrecho. Si el mejor externo actual y su posible sustituto sobreviven hasta una comparación tardía de identificadores, el speaker puede mantener el actual y evitar un cambio gratuito. Reduce determinadas transiciones y detiene su ejemplo, sin eliminar todas las oscilaciones de RFC 3345.

El orden de llegada merece atención. RFC 4451 registra implementaciones donde conservar la ruta más antigua y ordenar candidatas producía comportamiento temporal no determinista. El resultado debe depender de entradas y política definidas, no de qué UPDATE llegó primero. Una opción de procesamiento estable sigue necesitando evidencia por ruta.

La cadena probatoria empieza antes del tráfico: ruta recibida sin transformar, AS vecino de agrupación, presencia de MED, valor tras política, LOCAL_PREF, AS_PATH y candidatos visibles. Hay que pedir al router la razón del best path y comparar bordes y puntos internos, no un solo looking glass.

Luego se verifica el reenvío. El camino BGP debe producir el NEXT_HOP esperado en el FIB y la telemetría debe mostrar el flujo en la interconexión prevista. Ver un MED bajo no prueba que ganó. Un best path en un RIB no prueba los paquetes de otro ingreso. Un enlace tranquilo puede significar desvío, pérdida o falta de demanda.

La prueba cubre ambas potestades. Se cambia de forma limitada el valor del emisor y se observa recepción y selección; después se elimina o reescribe en el receptor y se confirma la política local. Se ensayan ausencia, igualdad, atributos previos distintos, varios AS, retirada de salida, reflexión, orden de llegada y reversión. El objetivo es demostrar el alcance del consejo.

El acuerdo importa más que la sintaxis. Si un cliente espera que el proveedor acepte MED en dos enlaces privados, ambos deben definir prefijos, familias, enlaces, rangos, LOCAL_PREF anterior, ausencia, derecho de excepción y telemetría para disputas. Sin ese contexto, el atributo es correcto en el cable y ambiguo en el negocio.

El principio de especificación inicial mínima de Heng Lu encaja con MED. El protocolo común proporciona un objeto pequeño: métrica opcional, propagación limitada y comparación condicional. No decide si representa capacidad, coste o política. Eso queda en manos de las redes que operan y asumen las consecuencias.

La primacía del código en ejecución define la aceptación. Documento y commit representan intención; atributo recibido, reescritura efectiva, candidatos visibles, motivo de selección, NEXT_HOP y tráfico entregado forman el sistema. Si los paquetes no entran por la puerta prevista, la métrica no ejerció autoridad práctica.

Soberanía de datos aquí significa controlar el estado operativo propio, no poseer la ruta ajena. El emisor describe su entrada preferida; el receptor acepta cuando coincide con contratos y riesgo. La coordinación funciona porque ninguno entrega su máquina de decisión.

MED funciona cuando ambos comprenden su modestia. Un número menor recomienda una puerta; no garantiza corredor, visibilidad interna, acuerdo de políticas fuertes ni tránsito real. La debilidad no es autoridad incompleta: es la protección que permite aconsejar sin gobernar.

Fuentes