Encaminamiento y plano de control

Un encaminador toma una decisión local para cada datagrama que llega: ¿qué enlace de salida debe transportarlo a continuación? El plano de datos realiza esa búsqueda mediante la tabla de reenvío. El plano de control determina el contenido de la tabla utilizando información sobre los destinos y la red más allá del encaminador.

Dos formas de organizar el control

Con el control por encaminador, cada encaminador ejecuta software de encaminamiento e intercambia mensajes con otros encaminadores. OSPF y BGP utilizan esta organización. Con el control lógicamente centralizado, el software de control de red obtiene una visión de toda la red y utiliza un controlador para instalar reglas de reenvío en los dispositivos. Este es el enfoque de SDN. «Lógicamente centralizado» describe el servicio de control que ven sus usuarios; el servicio puede ejecutarse en varios servidores físicos.

El reenvío es una operación local rápida, a menudo implementada en hardware. El encaminamiento responde en una escala de tiempo más lenta a cambios en la conectividad, los costes y las políticas. Un datagrama no espera a que se calcule una nueva ruta de extremo a extremo en cada salto. Sigue las entradas ya instaladas.

Representa la red como un grafo ponderado

En un grafo $G=(N,E)$, los nodos son encaminadores y las aristas son enlaces. Un par conectado directamente tiene un coste de enlace $c(x,y)$. Un enlace directo inexistente tiene coste $\mathrm{\infty }$. En los grafos de los ejemplos resueltos, los costes son simétricos: $c(x,y)=c(y,x)$. El operador elige qué representa el coste: velocidad del enlace, retardo, dinero u otra medida útil.

Suma los costes a lo largo de un camino. Si A–B cuesta 3 y A–C y C–B cuestan 1 cada uno, el camino directo cuesta 3 mientras que A–C–B cuesta 2. A envía a C el tráfico destinado a B. Contar enlaces daría aquí una decisión equivocada; el número de saltos solo equivale al coste del camino cuando cada enlace tiene coste 1.

Clasifica el algoritmo según su información

Un algoritmo global utiliza información completa de la topología. Esto no requiere una sola computadora: OSPF ejecuta de forma independiente un algoritmo global de estado de enlace en cada encaminador. Un algoritmo descentralizado construye su respuesta mediante intercambios locales, como hace el encaminamiento por vector de distancias.

Otras clasificaciones describen cuándo cambian las rutas. Las rutas estáticas cambian lentamente, a menudo mediante modificaciones manuales. Los protocolos dinámicos reaccionan a los cambios de la red. Los costes sensibles a la carga siguen la congestión actual; los insensibles a la carga no lo hacen. OSPF y BGP son protocolos dinámicos cuyas métricas de ruta habituales no siguen la carga de cada momento.

Relaciona el encaminamiento con el reenvío

Un algoritmo es el cálculo; un protocolo proporciona formatos de mensajes, temporizadores y reglas de intercambio. El algoritmo de Dijkstra es un cálculo. OSPF es un protocolo que proporciona sus datos de entrada.

La entrada final de reenvío asigna un prefijo de destino a un enlace de salida. Cada encaminador elige su propio siguiente salto, por lo que el camino completo surge de las tablas de los encaminadores. Durante la convergencia, las tablas incoherentes pueden crear bucles; el TTL acaba eliminando un datagrama IPv4 en bucle. Entre organizaciones, una buena ruta también debe cumplir las políticas: un operador puede rechazar un camino de bajo coste porque implicaría transportar tráfico que no ha aceptado transportar.

En el encaminamiento por estado de enlace, cada encaminador describe sus enlaces conectados y difunde esa descripción por inundación en toda la red. Una vez que las bases de datos coinciden, todos los encaminadores tienen el mismo grafo. Cada encaminador ejecuta el algoritmo de Dijkstra tomando como origen a sí mismo, por lo que los mismos datos de entrada producen un árbol con una raíz distinta en cada encaminador.

Distingue los costes provisionales de los definitivos

Para el origen $u$, $D(v)$ es el coste más barato a $v$ encontrado hasta el momento y $p(v)$ es su predecesor en ese camino. El conjunto $N^{\mathrm{\prime }}$ contiene los encaminadores cuyos costes mínimos son definitivos. Comienza con el origen en ese conjunto, sus vecinos directos con los costes de sus enlaces y todos los demás encaminadores con coste infinito.

En cada iteración, elige el menor coste provisional fuera de $N^{\mathrm{\prime }}$ y añade ese encaminador, $w$, al conjunto. Para cada vecino $v$ que siga fuera, compara la estimación existente con una ruta a través de $w$:

Si la segunda ruta es más barata, registra $w$ como predecesor. Los costes de enlace no negativos hacen que esta decisión definitiva sea segura. Un valor que simplemente se ha actualizado sigue siendo provisional hasta que su encaminador se incorpora a $N^{\mathrm{\prime }}$.

Trabaja desde el encaminador A

Utiliza estos enlaces: A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 y E–F 5. Al principio B tiene coste 3, C tiene coste 1 y D, E y F tienen coste infinito.

Por ejemplo, añadir E cambia D porque $3+1=4$ es menor que 6. D se actualizó dos veces antes de ser definitivo. Tomar su primera estimación de 7 como respuesta haría que se pasaran por alto ambas mejoras.

Recupera los caminos y los primeros saltos

Sigue los predecesores hacia atrás: F ← D ← E ← C ← A. Invierte esa secuencia para obtener A–C–E–D–F. Su coste es $1+2+1+3=7$. Los costes definitivos desde A son B 2, C 1, D 4, E 3 y F 7.

Una tabla de reenvío almacena el primer salto, no el predecesor del destino. Todos los caminos de este ejemplo comienzan por A–C, por lo que el siguiente salto de A es C para los cinco destinos. El predecesor de F es D, pero D no es el siguiente salto de A.

Costes iguales, trabajo y cambios de carga

Si dos candidatos empatan con el menor coste, cualquiera puede hacerse definitivo primero. Los costes mínimos siguen siendo iguales, aunque el camino elegido puede diferir. OSPF puede conservar varios caminos de igual coste para repartir la carga.

El algoritmo sencillo examina los candidatos en cada una de sus $n-1$ iteraciones, lo que da un tiempo de ejecución $O(n^2)$; una cola de prioridad puede mejorarlo. La inundación de estado de enlace también consume mensajes porque la información modificada de un enlace debe llegar a todos los encaminadores de su ámbito de inundación.

Los costes sensibles a la carga pueden crear una retroalimentación. Todos los encaminadores ven un camino poco cargado, trasladan el tráfico a él y lo encarecen; el siguiente cálculo devuelve el tráfico al camino anterior. Los costes insensibles a la carga evitan esta retroalimentación concreta. Aleatorizar los momentos de cálculo también puede reducir los cambios sincronizados; de lo contrario, los encaminadores que empiezan en momentos distintos pueden acabar sincronizándose.

Un encaminador puede aprender caminos útiles sin conocer todo el grafo. En el encaminamiento por vector de distancias, conoce los costes de sus enlaces conectados y las estimaciones de coste más recientes recibidas de cada vecino. Utiliza esas estimaciones para construir su propio vector de distancias, una lista de costes estimados a todos los destinos.

Suma el primer enlace a la estimación del vecino

Para un destino $y\mathrm{\ne }x$, la ecuación de Bellman–Ford es

Prueba cada vecino $v$. Suma el coste de llegar a ese vecino al coste del vecino hasta el destino y después elige el menor total. El vecino que da el mínimo se convierte en el siguiente salto. El coste de un encaminador hacia sí mismo permanece en 0; no se sustituye por una ruta a través de un vecino.

Durante el intercambio, los encaminadores utilizan estimaciones $D$ en lugar de las distancias definitivas $d$. Estas estimaciones pueden cambiar a medida que la información llega más lejos en la red.

Inicia, recibe, recalcula y anuncia

Al arrancar, un encaminador registra 0 hacia sí mismo, los costes de los enlaces directos a sus vecinos e infinito para los demás destinos. Envía ese vector a sus vecinos. Un nuevo vector de un vecino o un cambio en un enlace local desencadena un recálculo. Si el propio vector del encaminador cambia, este anuncia el nuevo vector; de lo contrario, no tiene ninguna estimación modificada que transmitir.

El proceso es distribuido, iterativo y asíncrono. Los encaminadores no necesitan actualizarse en rondas sincronizadas. La información puede llegar igualmente a encaminadores distantes porque la estimación revisada de cada vecino se convierte en entrada de otro cálculo.

Calcula un ejemplo de tres encaminadores

Los enlaces A–B 4, B–C 1 y A–C 7 dan estos vectores iniciales, ordenados por destino A, B, C:

Después de recibir información de B, A compara sus dos rutas a C:

Elige B como siguiente salto. C hace el cálculo correspondiente para A y obtiene 5 a través de B. Otro intercambio deja los vectores sin cambios. Con costes de enlace fijos y un funcionamiento correcto, los encaminadores han convergido.

Las entradas de reenvío de A son «B → B, coste 4» y «C → B, coste 5». A sabe que B anuncia un coste de 1 a C. No necesita conocer el camino completo de B ni disponer de un dibujo de los enlaces más allá de B.

Cómo proporciona RIP el protocolo

El protocolo de información de encaminamiento (RIP) implementa el encaminamiento por vector de distancias utilizando el número de saltos. Cada enlace cuesta 1, el camino más largo que puede utilizarse tiene 15 saltos y 16 significa inalcanzable. RIP envía actualizaciones periódicas cada 30 segundos mediante el puerto UDP 520. Una ruta que no se ha renovado durante 180 segundos caduca.

Los mensajes periódicos pertenecen al protocolo; la regla del algoritmo subyacente sobre vectores modificados describe cuándo hay información nueva que propagar. RIP también utiliza actualizaciones desencadenadas para enviar los cambios antes. Confundir estos niveles puede llevar a afirmar que un encaminador RIP estable no envía ningún mensaje.

Las estimaciones de vector de distancias no se calculan una vez para quedar después fijas. Un nuevo anuncio de un vecino puede cambiar el siguiente salto preferido aunque todos los enlaces locales permanezcan sin cambios. A la inversa, recibir un mensaje no tiene por qué cambiar el propio vector del encaminador si ninguno de los nuevos totales mejora o sustituye sus rutas seleccionadas.

Una actualización de vector de distancias puede describir un camino que depende del encaminador que la recibe. Si esa dependencia no es visible, dos encaminadores pueden creer que el otro tiene una ruta utilizable. Por eso, un aumento del coste de un enlace puede ser más difícil de propagar que una disminución.

Un enlace más barato se comunica rápidamente

Supongamos que A–B cuesta 2, B–C cuesta 1 y A–C cuesta 20. B llega a A directamente con coste 2; C llega a A a través de B con coste 3. Si A–B baja a 1, B anuncia 1 y C cambia su coste a 2. Cuando C anuncia 2 a B, B mantiene su ruta directa. La mejora se estabiliza tras estas dos actualizaciones con cambios.

Un enlace más caro deja al descubierto información desactualizada

Ahora volvemos a partir de los costes 2, 1 y 20, y aumentamos A–B a 40. B todavía conserva el anuncio anterior de C de coste 3 a A. Elige C porque $1+3=4$ es menor que 40. C sigue enviando a B. Los datagramas destinados a A rebotan ahora entre B y C hasta que se agota su TTL.

C recibe el coste 4 de B y calcula 5. B recibe 5 y calcula 6. Las estimaciones siguen aumentando aunque ninguna describe un camino independiente a A. Esto es la cuenta hasta infinito: las malas noticias avanzan mediante una cadena de estimaciones engañosamente pequeñas.

En este caso, una alternativa acaba rompiendo el bucle. Cuando B anuncia 20, C compara su coste directo de 20 con el coste de 21 a través de B y selecciona su enlace directo. B se estabiliza entonces en 21 a través de C. Sin una alternativa utilizable o un valor finito para el infinito, la cuenta puede continuar mucho más tiempo.

Anuncia la dependencia con inversión envenenada

Con la inversión envenenada, un encaminador comunica al vecino que utiliza para llegar a un destino que su distancia a ese destino es infinita. Al principio, C utiliza B para llegar a A, por lo que C anuncia infinito a B. B ya no puede confundir a C con una alternativa independiente.

Tras el aumento del coste, B elige por tanto su coste directo de 40. C recibe 40 y selecciona su enlace directo con coste 20. Ahora C puede anunciar 20 a B, y B elige el coste 21 a través de C. El valor anunciado depende del destinatario: C puede comunicar su coste real a otros vecinos mientras envenena la ruta hacia B cuando B es su siguiente salto.

El horizonte dividido omite esa ruta de la actualización en lugar de anunciar infinito. La inversión envenenada evita este bucle de dependencia entre dos encaminadores, pero aún pueden producirse bucles más largos. Las actualizaciones desencadenadas aceleran la propagación de los cambios. RIP también define el infinito como 16, lo que limita tanto la duración de la cuenta como el tamaño utilizable de la red.

Compara las dos familias de encaminamiento

Una ronda completa de difusión de estado de enlace requiere del orden de $n\cdot e$ mensajes para $n$ encaminadores y $e$ enlaces. El cálculo local sencillo es cuadrático. Los mensajes de vector de distancias dependen de cuántas estimaciones sucesivas cambien; comunicarse solo con los vecinos no garantiza una convergencia rápida.

OSPF e IS-IS utilizan encaminamiento por estado de enlace. RIP utiliza vectores de distancias. BGP es un protocolo relacionado de vector de caminos: la secuencia de AS que anuncia muestra las dependencias y permite a los encaminadores rechazar caminos que contienen su propio número de AS.

Internet es demasiado grande y su gestión está demasiado distribuida entre entidades independientes para tratar cada encaminador como un nodo de un único sistema de encaminamiento plano. Cada organización necesita controlar su propia red interna y, al mismo tiempo, ofrecer rutas utilizables a otras organizaciones. Los sistemas autónomos proporcionan esa división.

Identifica la frontera administrativa

Un sistema autónomo, o AS, es un grupo de encaminadores bajo una misma administración que presenta una política de encaminamiento coherente al exterior. Los números públicos de AS, o ASN, identifican estos sistemas en todo el mundo. Los registros regionales de internet distribuyen los recursos de números de AS. El espacio de números original era de 16 bits, hasta 65 535; los ASN modernos utilizan 32 bits.

Un AS es un dominio de encaminamiento, mientras que un ISP es una empresa. Una universidad o un proveedor de contenidos puede gestionar un AS, y un ISP puede gestionar varios. Tratar estos términos como intercambiables oculta las verdaderas fronteras de las políticas.

Utiliza distintos protocolos para distintas tareas

Un protocolo de pasarela interior (IGP) proporciona rutas internas. Dentro de un dominio de encaminamiento, los encaminadores utilizan un IGP común para poder intercambiar la información que necesita. Los distintos AS pueden elegir diferentes IGP. Un proveedor que utiliza IS-IS puede conectarse a una universidad que utiliza OSPF porque su intercambio de encaminamiento externo usa BGP.

La jerarquía satisface dos necesidades. Reduce la cantidad de detalles de todo el mundo que deben procesar los encaminadores internos y preserva la autonomía administrativa. Un cambio en un enlace local no necesita revelar la topología interna completa a todos los demás AS.

Combina la elección de una salida con un camino interno

Un encaminador de frontera se conecta a otro AS. Para un destino externo, BGP identifica una ruta utilizable y la dirección de su encaminador de siguiente salto. El protocolo interno proporciona el camino hacia esa dirección. Estas decisiones se combinan para producir la entrada de reenvío utilizada para un paquete que llega.

Supongamos que el encaminador R aprende que puede llegar a 198.51.100.0/24 a través del encaminador de frontera G. OSPF indica que el camino de R a G comienza por el vecino H. La entrada de reenvío de R para el prefijo externo utiliza el enlace a H. G es la salida del AS, mientras que H es el siguiente salto inmediato de R; esas funciones no tienen por qué corresponder al mismo encaminador.

Reconoce cuándo basta una salida

Un cliente pequeño con una sola conexión externa no tiene otra salida entre la que elegir. Una ruta IPv4 predeterminada, 0.0.0.0/0, puede enviar el tráfico externo hacia esa conexión. Aprender todas las rutas de internet no crearía una salida alternativa.

Con varios encaminadores de frontera, la información de accesibilidad importa: uno puede ofrecer un prefijo que otro no ofrece, o una política puede favorecer a un proveedor. BGP distribuye las opciones de ruta; el IGP sigue transportando los paquetes hasta la salida elegida.

Dentro de un AS, un operador puede elegir los costes de los enlaces para cumplir objetivos de rendimiento internos. Entre AS, el coste compite con los acuerdos sobre tránsito de pago, pares y el tráfico que un operador transportará. Por eso, elegir una ruta de internet implica algo más que extender un cálculo de caminos mínimos a través de la siguiente frontera administrativa.

OSPF (Open Shortest Path First) es un IGP de estado de enlace. Cada encaminador conoce la topología dentro de su área, ejecuta el algoritmo de Dijkstra desde sí mismo y obtiene rutas a las subredes. OSPFv2 sirve a IPv4; OSPFv3 se diseñó para IPv6.

Elige costes y descubre vecinos

El operador establece los pesos de los enlaces. Si todos los pesos son 1, se obtienen rutas de saltos mínimos. Una regla ilustrativa inversa a la velocidad con una referencia de 10 Gbit/s es

Da pesos de 1, 10 y 100 para enlaces de 10 Gbit/s, 1 Gbit/s y 100 Mbit/s. El peso es una medida de encaminamiento configurada, no una distancia en kilómetros.

Los paquetes Hello descubren y mantienen vecinos. Una configuración habitual de LAN envía paquetes Hello cada 10 segundos y utiliza un intervalo de inactividad de 40 segundos. Por tanto, perder un solo Hello es diferente de declarar inactivo al vecino. Los encaminadores vecinos sincronizan sus bases de datos mediante paquetes Database Description, Link State Request, Link State Update y Link State Acknowledgment. Los encaminadores con bases de datos sincronizadas forman una adyacencia.

Difunde descripciones actualizadas de los enlaces

Un anuncio de estado de enlace (LSA) describe información de encaminamiento. Un LSA de encaminador registra los enlaces de un encaminador y sus costes. Los LSA viajan en paquetes Link State Update; un LSA es la información anunciada, no el nombre de todos los paquetes OSPF.

Los cambios de enlaces desencadenan nuevos anuncios. Los encaminadores también renuevan sus propios LSA al menos cada 30 minutos. Un LSA que alcanza la antigüedad máxima de una hora se elimina. La información de secuencia y la antigüedad permiten distinguir las descripciones actualizadas de las antiguas.

OSPF se transporta directamente en IP utilizando el número de protocolo 89. Proporciona sus propios acuses de recibo y retransmisiones. En redes de difusión, 224.0.0.5 llega a todos los encaminadores OSPF y 224.0.0.6 llega a los encaminadores designados.

Reduce las adyacencias en una LAN

Una LAN elige un encaminador designado (DR) y un encaminador designado de respaldo (BDR). Los demás encaminadores forman adyacencias completas con esos dos, en lugar de que cada par se vuelva adyacente. El DR anuncia la LAN compartida en un LSA de red.

Para seis encaminadores, una malla completa necesitaría $6\times 5\mathrm{/}2=15$ adyacencias. Cuatro encaminadores ordinarios se conectan lógicamente cada uno al DR y al BDR, más una adyacencia DR–BDR: $4\times 2+1=9$. Los vecinos pueden escucharse entre sí sin que todos se vuelvan completamente adyacentes.

Recalcula tras el fallo de un enlace

Considera los enlaces A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 y E–F 5. A llega inicialmente a E con coste 3, a D con coste 4 y a F con coste 7 a través de C y E.

Cuando falla C–E, C y E difunden por inundación nuevos LSA de encaminador que eliminan el enlace. El recálculo da a A los costes B 2, D 6, E 7 y F 9. Los caminos a D y F ahora utilizan C–B–D. El primer salto de A sigue siendo C: un cambio en el camino completo no requiere que cambie el primer salto de reenvío.

OSPF admite mensajes de encaminamiento autenticados y encaminamiento multitrayecto de igual coste (ECMP). La autenticación criptográfica es más sólida que una contraseña en texto claro; comprueba que el origen del mensaje esté autorizado y que se mantenga su integridad. ECMP permite a un encaminador conservar varios caminos de igual coste. Estas funciones trabajan con información de estado de enlace, no con tablas intercambiadas de distancias estimadas a los destinos.

Un encaminador de un AS grande no necesita procesar cada enlace interno como parte de un único grafo detallado. Las áreas OSPF dividen la base de datos de estado de enlace y el trabajo de caminos mínimos. Los encaminadores conservan los detalles locales y aprenden rutas que describen destinos más allá de su propia área.

Conecta las áreas mediante el área troncal

El área troncal es el área 0, también escrita como 0.0.0.0. Las demás áreas se conectan a ella. El tráfico entre dos áreas no troncales viaja hasta el área troncal y después entra en el área de destino.

Un encaminador de frontera de área (ABR) conecta áreas, incluida el área troncal. Mantiene una base de datos separada para cada área conectada y anuncia rutas entre ellas. La información sobre una subred remota puede cruzar la frontera sin revelar todos los encaminadores y enlaces del área remota. La sumarización también puede combinar prefijos adecuados; no requiere que todas las subredes remotas desaparezcan dentro de un único agregado.

Un encaminador de frontera de sistema autónomo (ASBR) introduce rutas externas al dominio de OSPF, como rutas aprendidas de otro AS. Un ABR cruza una frontera de área; un ASBR introduce información de encaminamiento externa. Un dispositivo puede desempeñar ambas funciones.

Relaciona los anuncios con su propósito

Los tipos 1 y 2 describen el grafo detallado del área. Los tipos 3 y 4 transportan información de accesibilidad interárea. El tipo 5 normalmente se propaga por el AS, aunque los tipos especiales de áreas restringen los anuncios externos.

Sigue un paquete interárea

El paquete de un sistema terminal comienza en el área 7 y está destinado al área 9. Primero sigue las rutas dentro del área 7 hasta un ABR, cruza el área 0 hasta un ABR conectado al área 9 y después sigue las rutas dentro del área 9. Esta es una jerarquía dentro de un AS; cruzar una frontera de área no convierte el paquete en tráfico inter-AS.

Un encaminador interno tiene todas sus interfaces en una sola área. Un encaminador troncal tiene al menos una interfaz en el área 0. Un ABR también es un encaminador troncal, por lo que los nombres de las funciones no son mutuamente excluyentes.

Comprende qué cambia un fallo local en otras áreas

Dividir unos 400 encaminadores en cuatro áreas de unos 100 puede reducir considerablemente el grafo detallado de cada encaminador, aunque añade rutas interárea. El tamaño exacto de la base de datos también depende de los encaminadores de frontera y de las redes anunciadas.

Si un enlace falla repetidamente dentro de un área, sus LSA detallados y el recálculo completo de caminos mínimos permanecen en esa área. Si el cambio también altera el coste o la accesibilidad anunciados de un destino, el ABR envía resúmenes modificados. Los encaminadores de otras áreas actualizan las rutas interárea afectadas. Por tanto, las áreas limitan los detalles y los cálculos que se propagan; no ocultan todos los efectos de un fallo.

Tener menos detalles tiene un coste. Una ruta interárea sigue la jerarquía de áreas y puede diferir de la ruta de coste mínimo global en un grafo plano de todo el AS. El operador obtiene bases de datos más pequeñas y cambios más contenidos, pero renuncia a cierta libertad para elegir caminos.

BGP-4 intercambia información de accesibilidad para prefijos de destino. Un anuncio indica que la red que lo emite ofrece una ruta hacia ese prefijo. Otras redes pueden aceptarlo, compararlo con alternativas o rechazarlo según sus políticas.

Establece una sesión

Los encaminadores BGP intercambian mensajes mediante una conexión TCP de larga duración por el puerto 179. eBGP une encaminadores de distintos AS; iBGP une encaminadores del mismo AS. Las sesiones internas distribuyen la información de accesibilidad externa dentro del AS y no tienen por qué corresponder a enlaces físicos directos.

El diseño básico de iBGP utiliza una malla completa entre los encaminadores BGP. Las redes más grandes pueden utilizar reflectores de rutas para reducir el número de sesiones. iBGP no sustituye al IGP: el IGP sigue proporcionando los caminos internos necesarios para llegar a los siguientes saltos BGP.

Añade el número de AS a medida que una ruta viaja hacia el exterior

El AS 64503 origina 203.0.113.0/24. Su anuncio al AS 64502 tiene el AS-PATH «64503». El AS 64502 distribuye la ruta internamente mediante iBGP y después la anuncia al AS 64501 con el AS-PATH «64502 64503». La propagación externa antepone el número del AS que anuncia; la distribución interna ordinaria no añade otra copia de ese número.

Una ruta BGP combina el prefijo con atributos. AS-PATH registra la secuencia de AS, con el más reciente primero. NEXT-HOP identifica la dirección del encaminador hacia la que debe enviarse el tráfico, normalmente una interfaz del encaminador de frontera vecino. Un encaminador interno utiliza el IGP para determinar un camino hasta esa dirección.

Rechaza un bucle a nivel de AS

Un encaminador rechaza una ruta cuyo AS-PATH contenga su propio número de AS. Si el AS 64501 recibe «64502 64501 64503», aceptarla enviaría tráfico por una secuencia de AS que vuelve a 64501. Llevar esta dependencia convierte a BGP en un protocolo de vector de caminos y evita el problema de la cuenta hasta infinito del vector de distancias ordinario.

Un camino de AS no es una lista de todos los encaminadores del trayecto del paquete. Dos saltos entre AS pueden incluir muchos enlaces físicos y las políticas pueden seleccionar un camino de AS más largo. Su longitud por sí sola dice poco sobre el retardo medido.

Interpreta los mensajes básicos

El estándar sugiere un tiempo de espera de 90 segundos y mensajes de mantenimiento cada 30 segundos. Los parámetros negociados pueden ser diferentes. Un encaminador retira las rutas aprendidas mediante una sesión cuando esta falla; mantener abierta una conexión TCP es distinto de demostrar que funciona cada destino anunciado.

Tras el intercambio inicial, BGP envía cambios incrementales en lugar de enviar periódicamente la tabla completa. La limitación de tasa puede reducir los anuncios repetidos de un prefijo; el estándar sugiere 30 segundos entre esos anuncios eBGP.

TCP proporciona entrega ordenada entre los dos encaminadores. Los propios atributos de BGP, las reglas de política y el procesamiento de actualizaciones determinan qué rutas se conservan y propagan. El transporte fiable por sí solo no demuestra que un vecino tenga derecho a originar el prefijo anunciado.

Varios encaminadores de frontera pueden ofrecer una ruta al mismo prefijo. Un encaminador BGP aplica primero la política de importación y después compara las rutas aceptadas y utilizables en un orden definido. Se detiene en la primera diferencia decisiva; una ventaja posterior no puede anular una preferencia anterior.

Compara los atributos en orden

1. Prefiere el LOCAL_PREF más alto, establecido por el operador local.
2. Prefiere el AS-PATH más corto.
3. Prefiere el valor de ORIGIN más bajo: IGP, después EGP y después INCOMPLETE.
4. Prefiere el MED más bajo entre rutas del mismo AS vecino.
5. Prefiere una ruta aprendida mediante eBGP frente a una aprendida mediante iBGP.
6. Prefiere el menor coste IGP hasta NEXT-HOP.
7. Prefiere el identificador BGP más bajo del encaminador que anuncia cuando las comparaciones anteriores empatan.

Las implementaciones de encaminadores pueden añadir pasos como un peso local específico del fabricante. LOCAL_PREF se distribuye dentro del AS y permanece allí. MED permite a un AS vecino sugerir un punto de entrada preferido; la regla habitual no compara valores MED de AS vecinos distintos.

Compara dos salidas

R, en el AS 64501, aprende mediante iBGP dos rutas a 203.0.113.0/24. G1 ofrece el AS-PATH «64502 64503» con coste IGP 3; G2 ofrece «64504 64503» con coste IGP 5. Ambas tienen LOCAL_PREF 100 y el mismo ORIGIN. Los caminos contienen dos AS cada uno. MED no decide entre estos distintos AS vecinos y ambas rutas son anuncios internos.

Por tanto, decide el coste IGP: R elige G1 porque $3<5$. Esto es encaminamiento de patata caliente: enviar el tráfico por la salida interna de menor coste entre rutas iguales en los demás aspectos.

Si las rutas a través del AS 64504 reciben LOCAL_PREF 200, G2 gana inmediatamente. Su mayor coste interno ya no importa. Con el mismo LOCAL_PREF, un camino que contenga solo «64503» vencería a ambos caminos de dos AS antes de considerar el encaminamiento de patata caliente.

Determina cómo llegar al siguiente salto ganador

BGP ha elegido una ruta a través de G1, pero R puede no tener un enlace directo a G1. OSPF proporciona el camino interno de coste mínimo hasta esa dirección de siguiente salto. Si el camino comienza por la interfaz I, la entrada de reenvío pasa a ser «203.0.113.0/24 → I». La decisión necesita ambos protocolos: BGP selecciona la accesibilidad externa y el IGP determina la entrega interna hacia ella.

Distintos encaminadores internos pueden tener costes diferentes hasta G1 y G2, por lo que elecciones BGP iguales en los demás aspectos pueden llevarlos a usar distintas salidas. Las políticas independientes en el otro extremo también pueden hacer que el trayecto de vuelta del paquete sea distinto del de ida. El encaminamiento de internet suele ser asimétrico.

Aplica la misma selección a anycast

Con el direccionamiento IP anycast, varias ubicaciones de un servicio anuncian el mismo prefijo. Los encaminadores eligen entre los anuncios mediante la selección BGP habitual. Un cliente llega a la instancia preferida por la política de encaminamiento, el camino de AS y los costes internos, que no tiene por qué ser la instancia geográficamente más cercana.

Esto funciona bien para intercambios breves como las consultas DNS. Un cambio de encaminamiento durante una conexión TCP larga puede enviar paquetes posteriores a otra instancia que no tenga el estado de la conexión.

Anunciar una ruta es una invitación a enviar tráfico hacia ella. Por tanto, la política de exportación de un operador determina qué tráfico ofrece transportar la red. Las relaciones entre clientes, proveedores y pares explican las reglas habituales.

Distingue el tránsito de la interconexión entre pares

Un cliente paga a un proveedor por el tránsito hacia y desde el resto de internet. Dos pares intercambian tráfico para sí mismos y sus clientes, a menudo sin pagos entre ellos. Las redes suelen establecer la interconexión entre pares en un punto de intercambio de internet (IXP).

La interconexión entre pares no suele proporcionar una ruta a todo lo que el par puede alcanzar a través de sus propios proveedores. Ese servicio más amplio es el tránsito. Una relación entre pares describe un acuerdo sobre el tráfico, no simplemente un cable físico entre encaminadores.

Separa las decisiones de importación y exportación

La política de importación elige qué anuncios recibidos aceptar y qué preferencia asignarles. La política de exportación elige qué rutas anunciar a cada vecino. Una ruta puede aceptarse y utilizarse localmente sin ofrecerse a todos los demás vecinos.

Las preferencias habituales de importación favorecen las rutas de clientes, después las de pares y finalmente las de proveedores. LOCAL_PREF puede expresar ese orden. El tráfico de clientes genera ingresos, el de pares suele evitar cargos de tránsito y el de proveedores incurre en costes de tránsito. Esta preferencia puede tener más peso que la longitud de AS-PATH.

Aplica las reglas habituales de exportación

Un AS también anuncia sus propios destinos según sus acuerdos. La tabla describe el patrón comercial habitual; los operadores aplican las políticas mediante filtros y preferencias explícitos.

Anunciar ampliamente una ruta de cliente atrae tráfico hacia el cliente que paga. Restringir a los clientes las rutas aprendidas de pares y proveedores evita ofrecer tránsito no remunerado entre redes externas. Lo relevante es de dónde se aprendió la ruta y a quién se anunciará, no en qué dirección viaja un paquete concreto.

Sigue a un cliente conectado a múltiples proveedores

El cliente X, AS 64510, tiene los proveedores B y C. X anuncia su propio prefijo a ambos para obtener accesibilidad y resiliencia. Acepta rutas de ambos, pero excluye de los anuncios a C las rutas aprendidas de B. También excluye de los anuncios a B las rutas de C. De lo contrario, un proveedor podría enviar tráfico a través de X hacia destinos situados detrás del otro proveedor.

En un ejemplo de pares, A y B son pares y W es cliente de A. B puede utilizar la ruta «A W» y exportarla a sus clientes. B no comunica esa ruta aprendida de un par a otro par C. Exportarla a C ofrecería tránsito entre pares a través de B.

Dentro de un AS, un solo operador puede optimizar los costes internos. Entre AS, operadores independientes controlan el precio, las obligaciones de tráfico y las contrapartes aceptables. La ausencia de un anuncio puede ser una negativa deliberada a transportar tráfico, incluso cuando existe un camino físico.

Los anuncios BGP básicos no demuestran la titularidad de un prefijo ni autentican el AS-PATH completo. Un anuncio incorrecto puede propagarse por muchas redes a menos que las políticas y la validación lo detengan. Dos fallos importantes son los secuestros de prefijos y las fugas de rutas.

Reconoce qué falla

Un secuestro de prefijo anuncia un prefijo no autorizado o una parte más específica del prefijo de otra entidad. Los encaminadores que aceptan la ruta pueden enviar tráfico hacia el origen equivocado. Una vez instaladas rutas para distintas longitudes de prefijo, el reenvío utiliza la coincidencia de prefijo más largo. Una ruta /24 dentro de un /22 gana para las direcciones coincidentes, incluso si el /22 tiene un AS-PATH más corto. Las comparaciones de BGP entre rutas a un mismo prefijo y las comparaciones de reenvío entre distintos prefijos son decisiones separadas.

Una fuga de rutas exporta una ruta más allá de la frontera prevista por la política. Por ejemplo, un cliente transmite a otro proveedor rutas aprendidas de un proveedor y se convierte en una red de tránsito no deseada. El origen del prefijo puede ser legítimo mientras que la propagación es incorrecta.

Aprende de un incidente real

El 24 de febrero de 2008, Pakistan Telecom, AS 17557, anunció 208.65.153.0/24 como parte de un bloqueo de YouTube dentro de su país. Su proveedor propagó internacionalmente esa ruta más específica. Gran parte del tráfico destinado a esas direcciones de YouTube fue atraído hacia Pakistán.

El incidente, visible de forma generalizada, duró desde las 18:47 hasta las 21:01 UTC, algo más de dos horas. YouTube anunció el /24 por sí mismo y después dos prefijos /25 mientras intentaba recuperar el tráfico. El incidente terminó cuando el proveedor retiró la ruta falsa. Un cambio previsto para el ámbito local se había convertido en un fallo internacional de accesibilidad porque falló el filtrado de exportación.

Filtra antes de que se propague un error

Un proveedor puede aceptar solo los prefijos que un cliente está autorizado a originar. Un límite máximo de prefijos puede detener una sesión que anuncie de repente muchas más rutas de las acordadas. Muchas redes también filtran los prefijos IPv4 más largos que /24 y los prefijos IPv6 más largos que /48. Estos filtros limitan qué anuncios se propagan; una ruta técnicamente más específica solo tiene efecto allí donde se acepta.

Comprueba el origen autorizado con RPKI

La infraestructura de clave pública de recursos (RPKI) permite a los titulares de direcciones publicar autorizaciones de origen de ruta (ROA) firmadas. Una ROA indica el ASN de origen permitido, un prefijo y la longitud máxima permitida del prefijo.

Supongamos que el AS 64503 está autorizado para 203.0.113.0/24 con longitud máxima /24:

Si varias autorizaciones validadas cubren una ruta, una autorización que coincida con el origen y la longitud la hace válida. Si hay autorizaciones que la cubren pero ninguna coincide, la ruta es inválida. Las redes eligen cómo actuar ante estos estados; rechazar rutas inválidas bloquea muchos orígenes no autorizados. «No encontrado» significa que falta una autorización, no que se haya demostrado un origen incorrecto.

La validación de origen comprueba el ASN de origen final, no cada AS de tránsito ni la relación de exportación. Por tanto, falsificar un camino que termine con un origen autorizado puede superar esta comprobación, y una fuga puede conservar un origen válido. BGPsec añade mecanismos de firma de caminos, pero la validación de origen, los filtros de rutas y la supervisión siguen siendo defensas distintas.

Las redes definidas por software (SDN) separan el reenvío de paquetes del software que decide el comportamiento de la red. Los conmutadores aplican reglas de flujo, mientras que las aplicaciones utilizan un controlador para leer el estado de la red e instalar las reglas que necesitan. Esta organización hace que el control sea programable.

Identifica los tres componentes

Los conmutadores del plano de datos realizan el reenvío basado en coincidencias y acciones. Un flujo puede coincidir con campos de varias capas, incluidas direcciones Ethernet, direcciones IP y puertos de transporte. Las acciones pueden reenviar, descartar, modificar o enviar un paquete al controlador.

El controlador mantiene el estado de la red y se comunica con los dispositivos. Las aplicaciones de control de red toman decisiones, como calcular una ruta o elegir una regla de equilibrado de carga. Una aplicación de encaminamiento puede seguir utilizando el algoritmo de Dijkstra. SDN cambia la ubicación y las interfaces del control sin requerir un nuevo método de caminos mínimos.

Las características que lo definen funcionan conjuntamente: reenvío basado en flujos, separación de los planos de control y de datos, funciones de control fuera de los conmutadores y aplicaciones de software que programan el comportamiento de la red.

Sigue las capas del controlador

La interfaz hacia los dispositivos conecta el controlador con los dispositivos. OpenFlow es un ejemplo conocido; los protocolos de gestión como SNMP y NETCONF también pueden facilitar la comunicación con los dispositivos. La interfaz hacia las aplicaciones conecta las aplicaciones con el controlador, a menudo mediante una API REST. Estos nombres describen funciones del software, no posiciones físicas en un bastidor de red.

Distingue la centralización lógica de la física

Las aplicaciones ven un servicio de controlador coherente con una visión de toda la red. Ese servicio puede ejecutarse en un servidor o en un clúster replicado. Un clúster puede compartir la carga y continuar después de que falle un servidor, siempre que el intercambio de estado y la conmutación por error funcionen correctamente. La centralización lógica no requiere una sola máquina física.

Un controlador en un solo servidor es un único punto de fallo para su servicio de control. La replicación reduce esa exposición, pero el controlador sigue siendo una parte crítica de la red. Las aplicaciones dependen de una visión precisa de la topología para producir reglas útiles.

Sigue una solicitud de encaminamiento

Supongamos que un controlador registra los enlaces disponibles entre cuatro conmutadores. Una aplicación de encaminamiento lee esa topología mediante la API hacia las aplicaciones y calcula un camino de coste mínimo. Pide al controlador que instale las entradas de reenvío correspondientes. El controlador traduce la solicitud en mensajes hacia los dispositivos destinados a los conmutadores afectados. Los paquetes posteriores siguen esas entradas instaladas localmente.

Por tanto, cambiar una aplicación de encaminamiento puede cambiar el comportamiento de la red sin modificar el software de encaminamiento integrado en cada conmutador. El mismo hardware de reenvío puede admitir encaminamiento, control de acceso o equilibrado de carga según las reglas instaladas.

SDN se utiliza dentro de redes de organizaciones, como centros de datos y redes privadas de área extensa. B4 de Google es un ejemplo de control centralizado para una red privada que conecta centros de datos. ONOS y OpenDaylight son ejemplos de plataformas de controlador de código abierto. En las fronteras entre redes independientes, BGP sigue intercambiando información de accesibilidad; el control SDN dentro de un AS y BGP entre AS pueden funcionar juntos.

OpenFlow transporta comandos y eventos entre un controlador y los conmutadores. Utiliza TCP, con el puerto registrado 6653, y puede proteger la conexión con TLS. El controlador necesita comunicarse en ambos sentidos: modifica el estado de reenvío y recibe indicios de que el estado o la topología han cambiado.

Interpreta una entrada de flujo

Una entrada de flujo tiene campos de coincidencia, una prioridad, contadores, acciones y tiempos de expiración. En una tabla, la entrada coincidente de mayor prioridad determina cómo se procesa el paquete. Por tanto, una coincidencia amplia puede perder frente a una regla más específica con mayor prioridad.

En OpenFlow 1.3, una entrada de ausencia de coincidencia en la tabla de menor prioridad puede procesar un paquete que no coincida con ninguna entrada ordinaria. Su acción puede enviar el paquete al controlador. Si no existe esa entrada, un paquete sin coincidencia se descarta de forma predeterminada. La ausencia de coincidencia por sí sola no requiere un mensaje packet-in.

Relaciona los mensajes con sus funciones

Flow-mod y port-mod son dos formas de modificar el estado del conmutador, pero solo flow-mod modifica entradas de reenvío. Packet-out gestiona un paquete concreto; por sí solo no instala una regla para paquetes posteriores.

Repara caminos tras un fallo

Considera los conmutadores S1 a S4. El enlace S1–S2 falla mientras sigue disponible otra ruta a través de S3 y S4.

1. S1 detecta que su puerto queda inactivo y envía port-status.
2. El controlador elimina el enlace averiado de su visión del estado de la red.
3. La aplicación de encaminamiento recibe el evento mediante su suscripción en la interfaz hacia las aplicaciones.
4. La aplicación recalcula caminos sobre la topología revisada.
5. Un componente de cálculo de tablas de flujos convierte esos caminos en reglas para los conmutadores.
6. El controlador envía mensajes flow-mod a los conmutadores cuyas entradas deben cambiar, como S1, S3 y S4.

El conmutador que informa proporciona un evento; no calcula por sí solo una reparación para toda la red. La aplicación también necesita que se instalen reglas en los conmutadores afectados, no solo que se almacene un nuevo camino en el controlador.

Instala antes del tráfico o reacciona a su primer paquete

Con la instalación proactiva, las entradas están listas antes de que lleguen los paquetes. Con la instalación reactiva, una acción configurada envía el primer paquete de un nuevo flujo al controlador en un packet-in. El controlador puede establecer una regla y utilizar packet-out cuando necesite enviar un paquete.

La configuración reactiva añade retardo al primer paquete y trabajo al controlador. Una vez que existe la entrada, los paquetes coincidentes posteriores permanecen en el plano de datos. El controlador procesa eventos y paquetes seleccionados, no todos los paquetes de todos los flujos. Las entradas que expiran pueden generar posteriormente notificaciones flow-removed, lo que permite a las aplicaciones seguir los cambios en el estado instalado.

ICMP transporta informes y pruebas de la capa de red dentro de datagramas IP. ICMPv4 utiliza el número de protocolo IPv4 1. Sus mensajes tienen un tipo, un código y una suma de comprobación. El tipo indica el propósito general; el código lo precisa.

Relaciona un error con el paquete que lo causó

Un error ICMPv4 incluye la cabecera IP original y al menos los primeros 8 bytes de la carga útil original. Ese fragmento reproducido suele proporcionar la información de transporte necesaria para identificar el flujo afectado. El error se envía al emisor original, que puede relacionar el informe con un paquete que envió.

El tipo 4, supresión en origen, está obsoleto y no es un mecanismo moderno de control de congestión.

Relaciona el fallo con su informe

Un encaminador que reduce el TTL a 0 descarta el datagrama e informa de tiempo excedido. Un encaminador sin ruta puede informar de red inaccesible. Un sistema terminal de destino que recibe UDP para un puerto sin uso puede informar de puerto inaccesible. Son fallos distintos: llegar al sistema terminal no garantiza llegar a una aplicación que esté escuchando.

Los errores ICMP no son confirmaciones fiables de entrega. El filtrado, la pérdida de mensajes o la limitación de tasa pueden impedir que un informe llegue al emisor. Por tanto, una prueba sin respuesta deja varias explicaciones posibles.

IPv4 suprime los errores sobre otro error ICMP, sobre tráfico de difusión o multidifusión y sobre fragmentos que no sean el primero. Estas reglas evitan cascadas de errores y respuestas excesivas. Los dispositivos también limitan la tasa de generación de errores.

Distingue ICMPv6

ICMPv6 utiliza el valor de cabecera siguiente IPv6 58. Sus tipos de error son 1, destino inaccesible; 2, paquete demasiado grande; 3, tiempo excedido; y 4, problema de parámetros. La solicitud y la respuesta de eco son los tipos 128 y 129. El descubrimiento de vecinos también utiliza ICMPv6 y asume en IPv6 la función de resolución de vecinos de ARP.

Las reglas de error de IPv6 incluyen excepciones para multidifusión: se puede enviar un mensaje de paquete demasiado grande en respuesta a un paquete de multidifusión, y también ciertos errores de opción desconocida. Aplicar a ICMPv6 la supresión general de multidifusión de IPv4 impediría el comportamiento requerido.

Sigue el descubrimiento de la MTU del trayecto

En el descubrimiento clásico de la MTU del trayecto en IPv4, el emisor activa no fragmentar. Un encaminador que encuentra una MTU menor en el enlace de salida descarta un datagrama demasiado grande y devuelve el tipo 3, código 4, indicando la MTU del siguiente enlace. El emisor puede reducir el tamaño de los paquetes posteriores.

Por ejemplo, un datagrama IPv4 de 1500 bytes llega a un enlace con MTU de 1400 bytes mientras está activado no fragmentar. El encaminador lo descarta e informa de que se necesita fragmentación con una MTU de 1400. El emisor ajusta el tamaño de su paquete IP; el valor de 1400 bytes incluye la cabecera IP, por lo que no es la carga útil máxima de la aplicación.

Los encaminadores IPv6 nunca fragmentan los paquetes reenviados. Devuelven un mensaje de paquete demasiado grande para que el origen pueda ajustarlos. Bloquear todo ICMP elimina esta información y puede crear un agujero negro de descubrimiento de la MTU del trayecto: los paquetes pequeños funcionan mientras que los más grandes desaparecen. El filtrado selectivo preserva los mensajes necesarios para el funcionamiento de la red.

Ping pide a un destino que responda. Traceroute utiliza sondas que expiran en saltos sucesivos para encontrar los encaminadores que responden a lo largo del trayecto de ida. Ambos informan de mediciones de ida y vuelta, que combinan el viaje de ida, la generación de la respuesta y el viaje de vuelta.

Interpreta un resultado de ping

Para IPv4, ping envía solicitudes de eco, tipo 8 código 0, y recibe respuestas de eco, tipo 0. Cada intercambio satisfactorio proporciona un RTT. Si tres de cuatro sondas reciben respuesta, una de cuatro queda sin respuesta: la pérdida observada es del 25 %.

Una respuesta confirma que un intercambio con el destino funcionó en ese momento. La ausencia de respuesta puede significar un fallo del destino o del trayecto, pero también puede significar que los mensajes de eco están filtrados o sujetos a una limitación de tasa. Ping comprueba estos mensajes, no todos los protocolos de aplicación que podrían utilizar el sistema terminal.

Revela saltos sucesivos con un TTL limitado

Traceroute envía primero una sonda con TTL 1. El primer encaminador lo reduce a 0, la descarta y puede devolver un mensaje ICMP de tiempo excedido. TTL 2 llega al siguiente encaminador antes de expirar. Aumentar el TTL repite este proceso más lejos en el trayecto. El origen registra la dirección y el tiempo transcurrido para cada respuesta.

El traceroute clásico de Unix utiliza sondas UDP dirigidas a puertos de destino poco probables, a partir de 33434. En el destino, puerto inaccesible indica que se ha llegado. Tracert de Windows utiliza solicitudes de eco y reconoce una respuesta de eco en el destino. Es habitual enviar tres sondas por cada TTL; distintas sondas pueden seguir distintos trayectos debido al equilibrado de carga.

Interpreta un trazado completo

El destino responde en el salto 5. El RTT medido aumenta $95-12=83$ ms del salto 3 al salto 4 y permanece alto después. Eso es compatible con un tramo más lento o más largo cerca de ese punto, pero la resta no es el retardo de ida del enlace intermedio. Las respuestas son paquetes distintos, pueden utilizar diferentes trayectos de retorno e incluyen distintos retardos de procesamiento y de cola. Estos RTT por sí solos no permiten deducir la longitud de ningún enlace.

Explica el silencio y los RTT inusualmente altos en saltos intermedios

Una línea que muestra «* * *» significa que las sondas con ese TTL no recibieron una respuesta a tiempo. Si responden saltos posteriores, los paquetes están llegando más lejos en la red. El encaminador silencioso puede reenviar con normalidad mientras suprime sus propias respuestas ICMP.

Un encaminador intermedio también puede mostrar un RTT mayor que los encaminadores posteriores. La creación de una respuesta ICMP puede recibir menor prioridad que el reenvío de tráfico, por lo que una respuesta lenta del plano de control no demuestra que exista un enlace de reenvío lento. Los aumentos persistentes que continúan en saltos posteriores merecen una atención distinta de la de un pico aislado.

Ten presentes los límites del trayecto observado

Traceroute revela las interfaces de encaminadores que responden, no una lista de números de AS. Asociar esas direcciones con las redes que las anuncian es un paso adicional. El trazado tampoco muestra el trayecto de retorno, aunque este contribuye a cada RTT. Las políticas de encaminamiento y las elecciones de patata caliente pueden hacer que el sentido inverso siga redes distintas, por lo que un trazado inverso independiente puede mostrar un resultado diferente.

La gestión de red conecta los objetivos de un operador con las observaciones y los cambios en los dispositivos. Su marco tiene cinco partes: un servidor de gestión, dispositivos gestionados, los datos de los dispositivos, agentes que exponen esos datos y un protocolo que conecta los agentes con el servidor.

Identifica los objetos y los mensajes

SNMP, el protocolo simple de gestión de red, suele utilizar UDP. Los agentes escuchan en el puerto 161; los gestores reciben notificaciones en el puerto 162. GetRequest lee objetos, GetNextRequest avanza por su orden de nombres y GetBulkRequest lee muchos valores de forma eficiente. SetRequest modifica objetos en los que se permite escribir. Response transporta el resultado.

Una notificación no confirmada (trap) es una notificación no solicitada sin acuse de recibo a nivel de aplicación. Una InformRequest recibe un acuse del receptor. Un agente puede así informar de un evento sin esperar a la siguiente consulta de supervisión.

Una base de información de gestión (MIB) define objetos gestionados en módulos mediante el lenguaje de definición de datos SMI. Cada objeto tiene un identificador de objeto (OID) en un árbol de nombres mundial. El OID identifica un objeto definido; el agente proporciona su valor actual.

Por ejemplo, sysUpTime, OID 1.3.6.1.2.1.1.3, mide el tiempo transcurrido desde que se reinició el sistema de gestión del dispositivo. ifInOctets, OID 1.3.6.1.2.1.2.2.1.10, define contadores de bytes recibidos por interfaz. Una entrada de tabla también necesita la instancia de interfaz para identificar el valor de qué interfaz se está leyendo.

Calcula la utilización a partir de dos consultas

El contador de una interfaz de 100 Mbit/s aumenta de 1 250 000 000 a 1 475 000 000 bytes durante 60 segundos. Primero determina la cantidad recibida:

Convierte los bytes en bits y divide por el tiempo transcurrido:

La utilización de entrada es $30\mathrm{/}100=\mathrm{0,30}$, o 30 %. Un contador es un total acumulado, no una tasa; se necesitan tanto la diferencia como el tiempo transcurrido. Distinguir entre bytes y bits evita un error por un factor de ocho.

Reconoce el retorno cíclico y el reinicio

ifInOctets es de 32 bits y vuelve a cero después de $2^{32}$ bytes. A 1 Gbit/s, eso tarda unos $2^{32}\times 8\mathrm{/}{10}^9\approx 34$ segundos. Un intervalo de 60 segundos puede ocultar varios retornos a cero, por lo que los dos valores por sí solos no permiten recuperar el total de tráfico. El contador de 64 bits ifHCInOctets es adecuado para interfaces rápidas.

Cuando ha ocurrido como máximo un retorno a cero y no se ha producido ningún reinicio, suma $2^{32}$ a una diferencia negativa. Un reinicio del dispositivo o del contador necesita un tratamiento distinto; considerar toda disminución como un retorno cíclico puede crear un pico de tráfico falso.

Elige una supervisión segura y cambios estructurados

SNMPv1 y SNMPv2c utilizan cadenas de comunidad en texto claro. SNMPv3 admite autenticación, cifrado y control de acceso a nivel de objeto; selecciona los ajustes de seguridad que proporcionen esas protecciones.

SNMP se utiliza ampliamente para supervisar. Una SetRequest valida los cambios solicitados antes de aplicarlos como grupo en un dispositivo. Si falla la asignación, el agente intenta deshacer los cambios; una respuesta undoFailed informa de que la propia recuperación ha fallado. No crea una transacción entre varios dispositivos. Editar objetos MIB individuales también resulta engorroso para configuraciones grandes. Una CLI puede utilizarse con comandos escritos a mano o mediante scripts, pero los comandos de texto para cada dispositivo son más difíciles de coordinar a gran escala; NETCONF ofrece operaciones de configuración estructuradas.

NETCONF lee y modifica la configuración estructurada de los dispositivos. YANG define la estructura, los tipos y las restricciones de los datos gestionados. El protocolo transporta y aplica los datos; el modelo describe qué significan esos datos y qué valores están permitidos.

Abre una sesión segura y comprueba las capacidades

NETCONF normalmente funciona sobre SSH mediante el puerto 830; el transporte seguro también puede usar TLS. El cliente y el servidor intercambian mensajes hello que anuncian las capacidades admitidas. Las solicitudes y respuestas son llamadas a procedimientos remotos (RPC) codificadas en XML.

Las capacidades importan. Un gestor debe comprobar que se admiten la configuración candidata, la validación o la confirmación con reversión automática antes de depender de ellas.

Separa las configuraciones activa, preparada y de arranque

El almacén de configuración activa (running) está activo. Un almacén de configuración candidata (candidate), cuando se admite, es una copia de trabajo para los cambios propuestos, y un almacén de configuración de arranque (startup), cuando se admite, contiene la configuración cargada al arrancar. Editar solo la configuración candidata deja sin cambios la activa. Una confirmación copia la configuración candidata preparada para su uso activo.

Un bloqueo evita modificaciones incompatibles mientras trabaja el gestor. La validación comprueba las reglas de la configuración candidata; no demuestra que el tráfico seguirá comportándose como se desea después de la activación.

Coordina dos dispositivos sin suponer una sola confirmación atómica

Para cambiar la MTU de un enlace entre R1 y R2, el gestor bloquea ambas configuraciones candidatas, envía edit-config a cada uno y valida ambas. Si cualquiera de las validaciones falla, descarta los dos cambios preparados y libera los bloqueos antes de la activación.

Si la validación tiene éxito, confirma los cambios en cada dispositivo y comprueba las respuestas. Las confirmaciones son independientes: R1 puede cambiar antes que R2, o una confirmación puede tener éxito mientras la otra falla. El gestor debe detectar este resultado parcial y recuperarse, por ejemplo, restaurando la configuración anterior.

Con la confirmación de cambios con reversión automática, un dispositivo revierte automáticamente el cambio si el gestor no lo confirma dentro de un plazo establecido. Esto ayuda cuando una nueva configuración corta el acceso de gestión. Cada dispositivo sigue teniendo su propia operación y su propio temporizador; esta confirmación no convierte el par en una sola transacción para toda la red.

Utiliza un modelo para rechazar un valor inválido

Un módulo YANG organiza los datos en contenedores, listas y hojas. Una hoja llamada mtu podría tener el tipo uint16 y el intervalo permitido 68–65535. El valor 40 incumple el intervalo, aunque cabe en el tipo entero sin signo. La validación del modelo comprueba tanto el tipo como las restricciones.

Las herramientas pueden utilizar modelos YANG para comprobar XML de NETCONF o JSON de RESTCONF. Los modelos estándar de interfaces del IETF, los modelos de fabricantes y los modelos OpenConfig ofrecen distintas definiciones de datos. La telemetría en flujo continuo puede enviar datos de estado modelados a intervalos, como complemento de las consultas.

SNMP sigue siendo útil para supervisar objetos individuales. NETCONF proporciona operaciones de configuración basadas en sesiones y mecanismos de coordinación a nivel de dispositivo. Ninguno de los dos protocolos garantiza por sí solo que dispositivos separados activen simultáneamente un cambio en toda la red.