ES2617196T3 - Identificación de rutas en una red de dispositivos de enrutamiento/conmutación mezclados - Google Patents

Abstract

Un método implementado por ordenador de identificar un salto siguiente a partir de un dispositivo de enfoque en una ruta de dispositivos interconectados incluyendo dispositivos de conmutación (14) y de enrutamiento (12), donde un dispositivo de conmutación (14) opera según un protocolo de dirección de conmutación y un dispositivo de enrutamiento (12) opera según un protocolo de dirección de enrutamiento, teniendo el método implementado en un ordenador de gestión (16) una ruta de consulta a los dispositivos interconectados e incluyendo: para un dispositivo de enfoque que está configurado para recibir tráfico dirigido a un destino terminal y para actuar como un dispositivo de enrutamiento (12) del tráfico, enviar un mensaje de consulta conteniendo una clave de consulta en base a un identificador de destino para el destino terminal desde el ordenador de gestión (16) al dispositivo de enfoque para identificar la dirección de enrutamiento siguiente del tráfico dirigido al destino terminal; recibir un mensaje de resultado conteniendo una nueva dirección de enrutamiento que es la dirección de enrutamiento siguiente; y averiguar a partir de la nueva dirección de enrutamiento la dirección de conmutación correspondiente que es la dirección de conmutación para conmutar tráfico en un dispositivo de conmutación (14) en una dirección al destino terminal, donde la dirección de conmutación es utilizable en una clave de consulta para una consulta dirigida a un dispositivo de enfoque que es un dispositivo de conmutación (14).

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Identificacion de rutas en una red de dispositivos de enrutamiento/conmutacion mezclados

La presente invencion se refiere a la identificacion de una ruta en una red de dispositivos interconectados, donde los dispositivos incluyen dispositivos de conmutacion y de enrutamiento.

Las redes de ordenadores forman la base para la infraestructura IT (tecnologfa de la informacion) en una amplia variedad de contextos. Tales redes de ordenadores incluyen dispositivos interconectados de varios tipos. La finalidad de la red es soportar el flujo de mensajes entre dichos dispositivos con el fin de suministrar informacion, aplicaciones y servicios, etc, por la red. Se dispone de varias tecnicas para gestionar una red. En este contexto, gestionar una red incluye supervisar la red para identificar puntos de fallo y otras zonas problematicas, tal como puntos calientes, y proporcionar informacion a administradores y usuarios de la red para poder resolver los problemas. Hay varias herramientas disponibles para proporcionar una topologfa de red. La topologfa de una red identifica como estan conectados ffsica o logicamente uno a otro los dispositivos en la red. Asf, cualquier dispositivo concreto unico puede tener una o varias conexiones a un dispositivo contiguo. Hay disponibles herramientas computerizadas que “descubren” una red, y crean topologfas de red que definen la interconexion de los dispositivos en la red, y la naturaleza de dichos dispositivos.

La determinacion de la topologfa de red se puede hacer de muchas formas. Las tecnicas que pueden ser utilizadas por separado o en combinacion obteniendo una buena representacion de la conectividad de red incluyen, por ejemplo:

• Protocolo de descubrimiento de Cisco (CDP)

• Protocolo de descubrimiento de capa de enlace (LLDP)

• Protocolo de gestion de red SynOptics (SoNMP)

• Protocolo de arbol de expansion (STP)

• IP Traceroute

• Descubrimiento de vecinos IPv6

• Adiciones / modificaciones / borrados de usuario

Conocer la topologfa de una red es sumamente util, pero no proporciona una solucion a todos los problemas que pueden producirse. Las redes se utilizan cada vez mas para proporcionar la infraestructura para soportar la distribucion de aplicaciones y servicios entre posiciones geograficas remotas, o por distancias largas o en redes sumamente complejas con gran numero de dispositivos interconectados. Los administradores de red y usuarios estan cada vez mas interesados en conocer no necesariamente todos los detalles de la red, sino en entender el funcionamiento del suministro de aplicaciones y servicios por una red. Asf, la denominada supervision de “extremo a extremo” cada vez es mas popular. Con supervision de “extremo a extremo”, el rendimiento de las aplicaciones que implican flujo de mensajes desde un dispositivo fuente a un dispositivo destino es supervisado cuando son distribuidas entre dichos dispositivos fuente y destino. Los parametros de rendimiento pueden ser usados para estimar o averiguar posibles fallos en la red, aunque no proporcionan informacion espedfica acerca de la posicion de los fallos y por lo tanto no apuntan directamente a una solucion.

A menudo, un dispositivo fuente es un servidor que proporciona un servicio concreto, y el dispositivo destino es un terminal de cliente que esta conectado al servidor mediante la red y que requiere el uso de dicho servicio. El termino “dispositivo” usado aqrn pretende cubrir cualesquiera dispositivos que puedan estar conectados en una red. El termino “servidor” se usa para denotar un dispositivo que es responsable de distribuir un servicio o aplicacion, y el termino “cliente” se usa para denotar un dispositivo (basado en usuario u otra maquina dependiente o servidor) que depende de dicha aplicacion o servicio.

Una dificultad significativa al averiguar donde podna estar un problema cuando se puede ver que se esta deteriorando el rendimiento de una aplicacion, es una falta de comprension de la ruta a traves de la red que podna haber tomado el flujo de mensajes para dicha aplicacion. Las redes dependen de muchos tipos de dispositivos de red (por ejemplo, routers, conmutadores, cortafuegos, equilibradores de carga, etc) para conectar sus dispositivos de punto final, de tal manera que es sumamente diffcil decir con respecto a cualquier punto final fuente dado como el mensaje de dicho punto final sera dirigido a traves de la red a un punto final de destino dado. La complejidad de tal determinacion de ruta es exacerbada por el uso de multiples rutas alternas, rutas redundantes, equilibrio de carga, etc.

Se ha intentado predecir como un paquete concreto sera enrutado a traves de una red. Tales predicciones se basan

5

10

15

20

25

30

35

40

45

50

55

60

65

en un modelo complejo de la topolog^a de red con juntamente con indicaciones en base a dispositivo sobre como se comportara un dispositivo concreto en la red. Los dispositivos de red pueden ser altamente sofisticados, y se ha desarrollado gran numero de algoritmos complejos para determinar una estrategia de enrutamiento en cualquier dispositivo concreto. Ademas, dicha estrategia de enrutamiento puede depender del trafico y otras consideraciones medioambientales que afectan a la red (tal como fallo de otros dispositivos, etc). Los algoritmos complejos que pueden ser aplicados por un dispositivo para determinar una estrategia de enrutamiento pueden incluir por ejemplo:

• Tecnologfa de interfaz de entrada y de interfaz de entrada

• Cabeceras de paquete (L2, L3, MPLS, ATM, etc)

• Rutas estaticas y conectadas directamente

• Tablas de enrutamiento compartidas (conocimiento pleno de BGP, OSPF, RIP, EIGRP, etc - vecinos activos, estados de enlace, costos de ruta, pesos de ruta, etc).

• Tablas de enrutamiento MAC aprendidas

• Listas de control de acceso

• Tecnologfas de superposicion de red (por ejemplo, MPLS, 802,1q VLANs), etc.

• Tecnologfas de prevencion de bucle - por ejemplo, PVSTP

• Protocolos de tunelizacion (MPLS, IPSEC, SSL, GRE)

• Carga equilibrada / enlaces redundantes

• Puertas de enlace por defecto

Sin embargo, aunque en principio es posible predecir donde se enviara un paquete dado a continuacion en un dispositivo concreto, esto requiere una amplia cantidad de datos cuya recogida es lenta, y que pueden quedar atrasados en segundos debido a la naturaleza en tiempo real de la operacion de los dispositivos de enrutamiento. Ademas, la mera adquisicion de estos datos puede imponer una carga significativa tanto a los dispositivos de red como a las redes.

Ademas, los modelos requeridos para simular modernos dispositivos de enrutamiento son sumamente complejos y, sin el modelo completo, su comportamiento no se puede prever correctamente. Para mantener completo el modelo, es necesario que tales soluciones sean actualizadas regular y rapidamente incluyendo desarrollos en las tecnologfas de enrutamiento. El problema se complica mas en rutas que contienen una mezcla de dispositivos de enrutamiento (por ejemplo, capa 3) y conmutacion (por ejemplo, capa 2) dispositivos.

US2009/190478A1 describe un metodo para descubrir y actualizar la informacion de topologfa en una red con el fin de realizar enrutamiento y conmutacion. Cuando un dispositivo de enfoque/prueba recibe un paquete a enviar a un destino, dicho dispositivo de enfoque decide si el envfo implica enrutamiento o conmutacion. Si se necesita enrutamiento, entonces se obtiene y usa informacion de salto siguiente. Si se necesita conmutacion, entonces se usan tablas de conmutacion predefinidas.

Resumen

En el acercamiento aqrn detallado, los dispositivos de red son consultados sobre que hanan con un paquete hipotetico (en contraposicion a la consulta de especificidades de protocolo de enrutamiento); no hay que conocer ni mantener los protocolos de enrutamiento que alimentan las tablas de envfo y enrutamiento de los dispositivos.

En particular, la presente invencion es util en una red que tiene una mezcla de dispositivos de enrutamiento y de conmutacion, o routers/conmutadores combinados.

Segun un aspecto de la presente invencion, se facilita un metodo implementado por ordenador de identificar un salto siguiente de un dispositivo de enfoque en una ruta de dispositivos interconectados incluyendo dispositivos de conmutacion y de enrutamiento, donde un dispositivo de conmutacion opera segun un protocolo de direccion de conmutacion y un dispositivo de enrutamiento opera segun un protocolo de direccion de enrutamiento, teniendo el metodo implementado en un ordenador de gestion una ruta de consulta a los dispositivos interconectados e incluyendo: para un dispositivo de enfoque que esta configurado para recibir trafico dirigido a un destino terminal y para actuar como un dispositivo de enrutamiento del trafico, enviar un mensaje de consulta conteniendo una clave de consulta en base a un identificador de destino para el destino terminal desde el ordenador de gestion al dispositivo de enfoque para identificar la direccion de enrutamiento siguiente para trafico dirigido al destino terminal;

5

10

15

20

25

30

35

40

45

50

55

60

65

recibir un mensaje de resultado conteniendo una nueva direccion de enrutamiento que es la direccion de enrutamiento siguiente; y averiguar a partir de la nueva direccion de enrutamiento la direccion de conmutacion correspondiente que es la direccion de conmutacion para conmutar trafico en un dispositivo de conmutacion en una direccion al destino terminal, donde la direccion de conmutacion es utilizable en una clave de consulta para una consulta dirigida a un dispositivo de enfoque que es un dispositivo de conmutacion.

La presente invencion es especialmente util cuando se usa para localizar el puerto de salida de un dispositivo de enfoque. Entonces puede ser usada con un nuevo acercamiento para identificar las rutas tomadas a traves de una red de dispositivos interconectados para un flujo concreto de mensajes. El concepto se basa en usar una cantidad minima de datos recogidos “por adelantado” - espedficamente la topologfa de red estatica y la posicion de host final (que clientes y servidores estan conectados a que conmutadores de acceso / borde), y recoge cualquier otra cosa necesaria al vuelo y de forma altamente selectiva segun sea preciso para tales datos altamente dinamicos. Para modernos entornos dinamicos, la capacidad de calcular la ruta de extremo a extremo ahora, es decir, en tiempo real, tiene amplia aplicabilidad. La recogida de los datos y su procesado tiene que ser muy rapida para que el algoritmo sea de valor factible cuando se use con redes del mundo real a gran escala.

El comportamiento en un dispositivo concreto se denomina “comportamiento por salto” (PHB). PHB en sf mismo no puede proporcionar una ruta de extremo a extremo. Sin embargo, conocer que un paquete sale del dispositivo en una interfaz espedfica es util en varios escenarios. Si se conoce que dispositivo e interfaz estan conectados a la interfaz, usando topologfa de red acoplada con PHB, el calculo directo de una ruta de extremo a extremo a traves de la red para un flujo de aplicacion puede realizarse con un algoritmo de hallazgo de ruta.

Los aspectos de la invencion aqrn descrita son especialmente utiles al manejar una ruta de dispositivos interconectados que incluyen una mezcla de dispositivos de conmutacion y de enrutamiento, o conmutador/routers combinados. En este contexto, la direccion de conmutacion puede ser averiguada a partir de una tabla de aplicacion que mapea direcciones de enrutamiento a direcciones de conmutacion. La tabla de mapeado puede ser una tabla de mapeado global, por ejemplo, mantenida en el ordenador supervisor o accesible por el ordenador supervisor. Es posible que la tabla de mapeado global sea mantenida en asociacion con alguno de los dispositivos, pero esto es insolito. La tabla de mapeado puede ser una tabla de protocolo de enrutamiento de direccion (ARP) segun el modelo de interconexion de sistemas abiertos. Esta tabla puede mantenerse en el dispositivo de enfoque. Por ejemplo, los dispositivos de enrutamiento son dispositivos de enrutamiento de capa 3 segun el modelo de interconexion de sistemas abiertos usando un protocolo de direccion de enrutamiento de protocolo de Internet (IP).

Los dispositivos de conmutacion son, por ejemplo, dispositivos de capa 2 segun el modelo de interconexion de sistemas abiertos usando un protocolo de direccionamiento de control de acceso a medio (MAC).

La presente invencion tambien proporciona un ordenador de gestion para identificar un salto siguiente en una ruta de dispositivos interconectados, incluyendo el ordenador de gestion:

una interfaz conectada a los dispositivos interconectados para transmitir consultas y recibir respuestas; un procesador operable para ejecutar un programa de ordenador que realiza el metodo definido anteriormente; y un medio de almacenamiento para almacenar una topologfa de red.

El ordenador de gestion tambien puede incluir un medio de almacenamiento para almacenar un registro de dispositivos de salto identificados como un registro de ruta.

La invencion tambien proporciona un producto de programa de ordenador que incluye instrucciones legibles por ordenador que, cuando es ejecutado por un procesador, implementa el metodo definido anteriormente.

En realizaciones, la topologfa de red incluye tanto interconectividad de dispositivos de red como posicion de host final. A su vez, los dispositivos fuente y destino usados para sembrar el algoritmo de hallazgo de ruta son determinados por el flujo de mensajes de interes. Finalmente, la ruta espedfica tomada por un paquete hipotetico entre dispositivos fuente y destino es calculada dinamicamente.

La consulta transmitida a cada dispositivo esta adaptada para consultar cada dispositivo para determinar la identificacion de un puerto de salida que represente los puertos de salida que el dispositivo usana para un mensaje hipotetico dirigido a un destino identificado por el identificador de destino. Observese que el identificador de destino para cualquier consulta dada puede ser o no ser el identificador de destino del dispositivo terminal dependiendo de la posicion en la red del dispositivo consultado. Esto se puede lograr, cuando el dispositivo es un router, consultando que hay en su tabla de enrutamiento activa al tiempo en que se recibe la consulta.

La consulta propiamente dicha puede acomodarse en un mensaje o senal transmitida desde el ordenador supervisor al dispositivo que este siendo consultado (dispositivo de enfoque). El mensaje o la senal de consulta no constituyen el flujo de mensajes para el que la ruta ha de ser determinada. En cambio, cada consulta contiene un identificador

5

10

15

20

25

30

35

40

45

50

55

60

65

de destino que consulta al dispositivo de enfoque para hallar como gestionana el dispositivo de enfoque un mensaje hipotetico dirigido a dicho destino si tuviese que hacer la decision al tiempo de recibirse la consulta. Asf, el dispositivo de enfoque devuelve un resultado que identifica un puerto de salida immediate que se habna usado entonces para un mensaje real dirigido a ese destino. Las consultas pueden transmitirse mientras la red es activa y mientras tiene lugar el flujo de mensajes. Sin embargo, tambien pueden transmitirse cuando el flujo de mensajes propiamente dicho no es activo - la tecnica puede ser usada en cualquier contexto.

Donde la consulta tiene forma de un mensaje o paquete, por ejemplo, el mensaje puede ser un mensaje SNMP con una direccion IP de destino, llevara su propia direccion de destino y sera distribuido por la red del ordenador supervisor al dispositivo de enfoque. En ese caso, la direccion de destino del mensaje de consulta es la del dispositivo de enfoque. Esto no es lo mismo que el identificador de destino que se incluye en la consulta propiamente dicha. En una disposicion alternativa, se puede enviar una senal o senales de consulta desde el ordenador supervisor a traves de conexiones directas a los dispositivos de enfoque, tal como a traves de un mecanismo CLI o XML API.

El metodo aqrn descrito permite varias tecnicas de analisis de red utiles. Permite una determinacion de ruta a demanda de modo que un administrador que intente determinar la ruta para una aplicacion particular puede preguntar de forma mas o menos instantanea al ordenador supervisor y recibir un resultado de la ruta.

Permite el descubrimiento de rutas multiples. Es decir, debido a cambios en el entorno en la red, los dispositivos de enrutamiento pueden enrutar un flujo de mensajes de forma diferente dependiendo de dichos cambios. Asf, un primer conjunto de consultas para identificar una ruta podna registrar una primera ruta, mientras que un segundo conjunto de consultas podna identificar una segunda ruta, incluso cuando el conjunto de consultas primero y segundo esten muy cerca uno de otro en el tiempo. La informacion acerca de multiples rutas entre puntos finales comunes (es decir, el mismo dispositivo fuente y el mismo dispositivo destino) puede presentarse grafica o visualmente para mostrar al usuario no solamente la naturaleza de la ruta, sino el porcentaje de tiempo que cada ruta es adoptada para un flujo de mensajes concreto. Esto se puede lograr facilmente porque las consultas propiamente dichas no representan una carga significativa para la red, y por lo tanto pueden enviarse multiples conjuntos de consultas sin afectar de forma significativa al rendimiento.

El metodo permite la deteccion de cambio de ruta legitimado rapido. Es decir, un ajuste en la red puede hacer que la ruta cambie y esto puede ser detectado y senalizado al usuario en una interfaz de usuario grafica visual.

Donde hay multiples rutas entre dispositivos fuente y destino comunes, las rutas pueden llevar diferentes latencias. A veces, un dispositivo de enrutamiento que realiza enrutamiento inteligente puede producir un fenomeno conocido como “aleteo de ruta” donde un flujo concreto de mensajes cambia continuamente de una ruta a otra. Puede ser util para que un administrador de red identifique estos casos debido a las implicaciones de tales cambios de ruta en latencia de extremo a extremo y las implicaciones de tal “oscilacion” de conversaciones telefonicas de voz por IP, por ejemplo.

El metodo puede ser usado para localizar un fallo de ruta. Es decir, en la realizacion preferida del metodo, se envfan consultas y se reciben y analizan resultados para identificar el dispositivo siguiente hasta que un dispositivo es identificado como el dispositivo destino. A veces, sin embargo, hay un fallo en la red, de tal manera que la red no llevara el flujo de mensajes al dispositivo destino. El metodo permite la identificacion de esa situacion porque opera a lo largo de una ruta de extremo a extremo hasta que la ruta no puede seguir y esta posicion de red se le puede notificar despues a un administrador.

Ademas, el metodo puede permitir la posibilidad de volver a arrancar en un dispositivo posterior en dicha ruta, usando estimaciones basadas en la topologfa de red. El metodo de identificacion de ruta puede adoptarse entonces de nuevo hasta que se llegue al dispositivo destino desde el punto de fallo. De esta forma, porciones de la red de las que el ordenador supervisor no tiene visibilidad (por ejemplo, dispositivos que no tienen una interfaz de gestion apropiada, o que pertenecen a una organizacion diferente) se pueden dejar a un lado y continuar el analisis de ruta.

El metodo tambien permite la identificacion de enrutamiento asimetrico. No es insolito que el flujo de mensajes entre un dispositivo fuente y un dispositivo destino adopte rutas diferentes dependiendo de su direccion. Es decir, se puede utilizar una ruta directa desde el dispositivo fuente al dispositivo destino para el flujo de mensajes, y una ruta de retorno desde el dispositivo destino al dispositivo fuente que sea diferente.

La ruta es registrada en una memoria o almacenada en el ordenador supervisor o accesible por el ordenador supervisor. El registro de ruta incluye un conjunto de dispositivos conectados e interfaces. Esto puede presentarse en forma de un inventario ordenado de los dispositivos (componentes de red) entre los dos puntos finales. Esto permite supervisar la disponibilidad de rutas de red, incluyendo notificacion de eventos, reportes, SLAs (Acuerdos de nivel de servicio); gestion de red proactiva incluyendo reportes de dispositivos con fallo, CPU de dispositivo alta, memoria de dispositivo baja, congestion de puertos, etc, y analisis de impacto (planificacion de capacidad, analisis “que si”).

5

10

15

20

25

30

35

40

45

50

55

60

65

Una ventaja significativa de aspectos de la presente invencion es que un mapeado entre la aplicacion o el servicio distribuido por la red y los dispositivos de red o componentes propiamente dichos puede ser conocido a traves de la identificacion de la ruta. Esto representa un avance significativo en la gestion de redes.

Para una mejor comprension de la presente invencion y para mostrar como se puede poner en practica, ahora se hara referencia, a modo de ejemplo, a los dibujos acompanantes, en los que:

La figura 1 es un diagrama esquematico de una red.

Las figuras 2a a 2c son una ilustracion diagramatica de un algoritmo de descubrimiento de ruta en proceso.

La figura 3 es un diagrama de flujo para un algoritmo de descubrimiento de ruta.

La figura 4 representa una ruta descubierta.

La figura 5 es la estructura de una tabla de enrutamiento lineal.

La figura 6 ilustra un conjunto de resultados que surgen de combinar una direccion de destino con multiples mascaras de ruta.

La figura 7 representa una estructura de una tabla ARP.

La figura 8 es un diagrama esquematico de un ordenador supervisor.

La figura 9 es un diagrama esquematico de un router de capa 3.

La figura 10 es un diagrama esquematico de un conmutador de capa 2.

Las figuras 11a a 11d son un diagrama de flujo de una utilidad ejecutada en el ordenador supervisor.

La figura 12 es un diagrama de flujo de un programa de ejecucion de bucle.

La figura 13 es un diagrama de flujo que representa un proceso de terminacion del programa de ejecucion de bucle. La figura 14 es un diagrama de flujo que representa la opcion C del programa de ejecucion de bucle.

La figura 15 es un diagrama de flujo que representa la opcion S del programa de ejecucion de bucle.

La figura 16 es un diagrama de flujo que representa la continuacion del proceso en la opcion S.

La figura 17 es un diagrama de flujo que representa el proceso en la opcion del programa de ejecucion de bucle.

La figura 18 es un diagrama de flujo que representa una continuacion del proceso de la figura 17.

La figura 19 es un diagrama de flujo que representa el proceso de la opcion c del programa de ejecucion de bucle.

La figura 20 es un diagrama de flujo que representa el proceso de la opcion A.

La figura 21 ilustra un proceso para obtener una indicacion VLAN.

La figura 22 es un proceso para obtener un puerto conectado y dispositivo conectado a almacenar en un registro de ruta.

La figura 23 es un diagrama de flujo que representa un proceso iterativo para hallar una ruta que es utilizada en algunas de las opciones precedentes.

Las figuras 24, 25 y 26 ilustran tres procesos iniciadores.

La figura 27 es un diagrama de flujo que ilustra un proceso de hallazgo de ruta que se utiliza en el proceso iterativo de hallazgo de ruta de la figura P.

Y la figura 28 ilustra un proceso para buscar una entrada de base de datos de envfo de un dispositivo de enfoque.

La figura 1 es un diagrama esquematico de una red. La red se extiende por varios lugares geograficos diferentes. En cada lugar geografico de extremo hay dispositivos de punto final y dispositivos de red o nodos. Los dispositivos de red incluyen routers y conmutadores. El nucleo de la red incluye una pluralidad de dispositivos de red. Con respecto

5

10

15

20

25

30

35

40

45

50

55

60

65

al lugar geografico indicado Londres, terminales de cliente 2 pueden actuar como dispositivos de punto final. Igualmente, un servidor 4 puede actuar como un dispositivo de punto final y la impresora 6 puede considerarse un dispositivo de punto final. Se representan dispositivos similares en los lugares geograficos Pans y Nueva York con diferentes configuraciones (Nueva York representa un centro de servidores o centro de datos). Observese que en el lugar Nueva York una pluralidad de servidores 8 representa dispositivos de punto final de servicio o aplicacion clave.

Se debera apreciar que la red representada en la figura 1 se ofrece a modo de ejemplo. Hay una amplia variedad de redes posibles y la presente invencion puede usarse en cualquier red de dispositivos interconectados. En particular, la naturaleza de los dispositivos de punto final y los dispositivos de red espedficos o nodos puede variar. En la red concreta que se describe, los dispositivos de red pueden ser dispositivos de capa 3 o de capa 2.

El modelo OSI (interconexion de sistemas abiertos) define siete capas dentro de las que los protocolos de los sistemas de comunicaciones pueden caracterizarse. El algoritmo de hallazgo de ruta aqrn descrito calcula rutas de red usando informacion disponible en las capas 2 y 3.

Los dispositivos que operan en la capa 2 (la capa de enlace de datos) tienen conocimiento de dispositivos inmediatamente adyacentes y tienen la responsabilidad de llevar paquetes desde un dispositivo de capa 2 al dispositivo de capa 2 siguiente (en base a direccion MAC (control de acceso a medio) de capa 2).

Los dispositivos que operan en la capa 3 (la capa de red) son responsables de propagar paquetes desde un punto en una red a otro punto en la red -a menudo separados muchas decenas o cientos de dispositivos. Para calcular que dispositivos deberan participar en una ruta de capa 3 dada (aqrn denominados los saltos de capa 3), los dispositivos de capa 3 intercambian informacion de enrutamiento y usan protocolos de enrutamiento para calcular la(s) ruta(s) mas deseable(s). Para pasar paquetes entre dispositivos de capa 3 consecutivos en una ruta, se usan dispositivos que operan en la capa 2; a menudo con muchos dispositivos de capa 2 (aqrn denominados los saltos de capa 2) entre cada dispositivo de capa 3.

Asf, las redes grandes estan subdivididas realmente en multiples segmentos, conteniendo ffpicamente cada uno multiples dispositivos de capa 2, conectados por dispositivos de capa 3.

La figura 9 es un diagrama altamente esquematico de un dispositivo de enrutamiento de capa 3. El dispositivo incluye un controlador 90 por ejemplo, en forma de un microprocesador que ejecuta codigo de control, microprogramas o cualquier otra implementacion adecuada. El controlador 90 puede acceder a una tabla de

enrutamiento 92 que se explica con mas detalle mas adelante con referencia a la figura 5. El dispositivo de

enrutamiento de capa 3 tiene puertos Pi/Po. Cada puerto esta conectado a un enlace ffsico como se ilustra en la red de la figura 1. En esta notacion, Pi denota un puerto de “entrada” y Po denota un puerto de “salida”. Esto es por razones de conveniencia de la notacion, en la practica, los dispositivos no tienen generalmente puertos dedicados como puertos de entrada o de salida - que sean de entrada o de salida depende de los datos que entonces

transfieran. La mayor parte de los puertos funcionan como de salida y entrada todo el tiempo.

Los identificadores de destino, por ejemplo, IP (direcciones de protocolo de Internet) de los paquetes que llegan a un puerto de entrada Pi pueden ser lefdos por el controlador 90 mediante un bus 94. El controlador 90 accede a la tabla de enrutamiento 92 y en base a informacion derivada de ella controla un conmutador de enrutamiento 96 al que el paquete entrante es dirigido. El conmutador de enrutamiento 96 enruta entonces el paquete entrante a un puerto de salida apropiado Po dependiendo de la informacion presente en la tabla de enrutamiento. El dispositivo de enrutamiento incluye una tabla de mapeado 91 que mapea direcciones de capa 3 a capa 2 para enrutamiento posterior. La operacion de tales dispositivos de enrutamiento es conocida en la tecnica y por ello no se describira mas aqrn. Se indica en este contexto que la tabla de enrutamiento puede ser consultada por paquetes procedentes del ordenador supervisor que llegan por los enlaces al puerto de entrada Pi interceptando tales paquetes en el controlador 90. Tales paquetes de consulta no son suministrados al conmutador de enrutamiento 96 para enrutamiento adicional, sino que en cambio generan una respuesta que es enviada desde el dispositivo de enrutamiento y devuelta a la entidad consultante por la red desde un puerto de salida. En este caso, la entidad consultante es el ordenador supervisor 16. Todos los paquetes transportados por la red (incluyendo los paquetes de consulta) contienen una direccion de fuente y otra de destino - el paquete de consulta tiene una direccion de fuente correspondiente al ordenador supervisor y una direccion de destino correspondiente al dispositivo que es consultado. Cuando la respuesta ha de ser enviada, las direcciones de fuente y de destino se cambian haciendo que la direccion de fuente sea el dispositivo consultado y que la direccion de destino sea el ordenador supervisor.

La figura 10 es una version altamente esquematizada de un conmutador de capa 2. Al igual que un dispositivo de enrutamiento de capa 3, el conmutador de capa 2 tiene puertos Pi/Po, cada uno conectado a un enlace ffsico como se representa, por ejemplo, en la red de la figura 1. Como se ha mencionado antes, los puertos no estan dedicados en general como de entrada o de salida. Los paquetes entrantes en un puerto de entrada Pi son dirigidos a un conmutador 100 que puede acceder a una base de datos de envfo (FDB) de capa 2 102 para determinar como enrutar los paquetes en base a identificadores de destino (normalmente cabeceras) en los paquetes. Una base de datos de envfo de capa 2 mapea un identificador de paquete entrante a un puerto de salida en el que el paquete debera ser enviado. Como ya se ha explicado anteriormente, segun el modelo OSI, los identificadores para los

5

10

15

20

25

30

35

40

45

50

55

60

65

dispositivos de capa 3 de enrutamiento son direcciones IP, mientras que los identificadores para los dispositivos de capa 2 son direcciones MAC.

Como con los dispositivos de capa 3, los de capa 2 son conocidos en la tecnica y por ello no se explicaran mas aqm. Sin embargo, se indica que, de nuevo de forma analoga a los dispositivos de capa 3, pueden recibir una consulta en un paquete en un puerto de entrada Pi y generar una respuesta a esa consulta en la salida del conmutador de capa

2 en un puerto de salida Po. Asf, los paquetes de consulta propiamente dichos no son enrutados en el conmutador, sino que, en cambio, generan una respuesta que es devuelta al dispositivo consultante, en este caso el ordenador supervisor 16.

Un controlador de conmutador 101 en el conmutador es responsable se enviar trafico y de generar respuestas. Algunos dispositivos mas recientes pueden realizar la funcion de capa 3 y capa 2.

Las realizaciones de la presente invencion descritas a continuacion proporcionan un metodo de identificar una ruta tomada por un flujo de mensajes entre un dispositivo fuente dado y un dispositivo destino dado. Por ejemplo, el punto final X podna considerarse un dispositivo fuente y el punto final Y podna considerarse un dispositivo destino. Considerando una red de la figura 1, dista mucho de ser una tarea trivial, como ya se ha explicado anteriormente, establecer que ruta se adoptara a traves de la red entre los puntos finales en cualquier tiempo dado y en cualquier conjunto dado de condiciones medioambientales. La figura 1 representa un ordenador supervisor 16 que ejecuta un programa de descubrimiento de ruta que permite descubrir y registrar esa ruta. La figura 8 es una version altamente esquematica de un ordenador supervisor 16. El ordenador 16 incluye un microprocesador 80 que puede acceder a una memoria 82 en la que se guarda un codigo para ejecucion por el procesador. En el caso presente, el codigo incluye el programa de descubrimiento de ruta. La memoria 82 tambien guarda un registro de ruta 81 tal como lo crea el programa de descubrimiento de ruta. El ordenador tiene una interfaz de usuario 84 que puede incluir un dispositivo de entrada de usuario, un raton o un teclado, y una pantalla para presentar informacion a un usuario. En particular, como se explica aqm con mas detalle, pueden presentarse al usuario en la interfaz de usuario 84 alertas despues del programa de descubrimiento de ruta o informacion con relacion al programa de descubrimiento de ruta. Las figuras 2a a 2c ilustran pasos de la ruta que se describiran ahora.

En un nivel alto, el algoritmo usa la nocion de un “dispositivo de enfoque” que es el dispositivo actualmente consultado acerca de donde enviana un paquete hipotetico siguiente (es decir, desde que interfaz enviana el paquete hipotetico). Comenzando en el dispositivo fuente, el algoritmo avanza hacia el dispositivo terminal (es decir, el ultimo destino del paquete) evaluando cada dispositivo de enfoque por orden - si el dispositivo esta operando en la capa 3, se le consulta que interfaz (puerto de salida) utilizana para enviar paquetes unidos.

Para el salto siguiente en la capa 3 (NHL3); si el dispositivo esta operando en la capa 2, se le consulta que interfaz (puerto de salida) utilizana para enviar paquetes unidos para la siguiente direccion de capa 2 (MAC) de salto a capa

3 (NHL2). Usando la respuesta del dispositivo de enfoque en union con una topologfa de red, se puede determinar el dispositivo siguiente en la ruta. De esta forma, el algoritmo opera a lo largo de la ruta de capa 3, usando los dispositivos de capa 2 para navegar entre los nodos de capa 3 consecutivos.

Antes de comenzar el algoritmo iniciador, se localizan el dispositivo fuente y el dispositivo terminal. Esto puede no ser sencillo y mas adelante se explican tecnicas para lograrlo.

Segun el algoritmo principal, se localiza el primer salto. Se siembra la ruta y el recuento de bucle se pone a cero. El lfmite de bucle controla el numero de veces que se ejecuta un bucle de identificacion de ruta (que se explica mas adelante).

Hallar el primer salto en la capa 3

El primer salto se localiza hallando el salto siguiente inicial (el salto siguiente desde el dispositivo fuente) en la capa 3 (NHL3). En la explicacion siguiente, se utiliza frecuentemente el termino “consulta”. Las consultas son generadas y estructuradas como se describe con mas detalle mas adelante. La finalidad de una consulta es localizar una direccion de salto siguiente y el puerto de salida de un dispositivo de enfoque al que se dirige la consulta. La direccion NHL3 inicial puede determinarse consultando en primer lugar un dispositivo fuente X usando la direccion IP de destino. Es decir, se intenta consultar la tabla de enrutamiento en el dispositivo fuente para NHL3 y el puerto de salida. Si no se halla ninguna ruta, y el dispositivo fuente tiene un conmutador de acceso a capa 3, este conmutador de acceso a capa 3 es consultado con respecto a NHL3 usando la direccion IP de destino. Si eso no tiene exito, se consulta la puerta de enlace por defecto del dispositivo fuente para conocer la NHL3. Si eso no tiene exito, se realiza una consulta usando la direccion IP de destino al conmutador de acceso para la puerta de enlace por defecto. Si no se halla la direccion NHL3, esto se considera como un fallo. Esto no quiere decir que el algoritmo ha fallado, sino que en este punto puede haberse identificado un punto de fallo en la ruta. Alternativamente, puede haber otras razones por las que no se hallo NHL3.

Sembrar la ruta

5

10

15

20

25

30

35

40

45

50

55

60

65

Para sembrar la ruta, se anade el dispositivo fuente a la ruta cuando se haya localizado. La interfaz de salida del dispositivo fuente se localiza y anade a la ruta. Si se halla NHL3 a partir de la tabla de enrutamiento en el dispositivo fuente, se anade a la ruta la interfaz de salida de dispositivo fuente para esta direccion NHL3. Como se explica mas adelante, la direccion de capa 2 (NHL2) correspondiente a la direccion de capa 3 (NHL3) puede averiguarse. Si no se halla ningun puerto de salida para NHL3 a partir de la tabla de enrutamiento en el dispositivo fuente, se usa la tabla de envfo de capa 2 en el dispositivo fuente para NHL2 para hallar el puerto de salida. Si se halla, entonces se anade dicho puerto de salida a la ruta.

Vision general del algoritmo de descubrimiento de ruta

La consulta enviada desde el ordenador supervisor 16 al dispositivo fuente X se representa como una flecha directa en la figura 2a, pero, de hecho, la podna implementar en la red de la figura 1 el ordenador supervisor 16 emitiendo un mensaje o paquete dirigido al dispositivo fuente X. Como se explica, la consulta pregunta al dispositivo fuente la IP de salto siguiente (y puerto de salida) para la IP terminal (IP de destino), que es la direccion de capa 3 del punto de destino Y. La finalidad es hacer que el dispositivo fuente X suministre una respuesta que incluya nHL3 y el puerto de salida para NHL3 (la direccion de IP terminal). Vease el paso S1 de la figura 3 y la figura 2a.

Como se ha explicado anteriormente, puede haber situaciones en las que el dispositivo fuente no pueda suministrar la informacion necesaria. Otras posibilidades mencionadas anteriormente para obtener el primer dispositivo de “enfoque” incluyen consultar al conmutador de acceso conectado sobre informacion de enrutamiento de capa 3 (en caso de que el conmutador de acceso sea un conmutador de capa 3); si esto falla, el algoritmo consulta el conmutador de acceso conectado con respecto a una puerta de enlace por defecto y la direccion IP de la puerta de enlace por defecto usada como la primera NHL3.

En el paso S2, la direccion de capa 2 (MAC) de salto siguiente se resuelve a partir de la direccion NHL3 y NHL2 se pone a esta direccion MAC. Esto se puede lograr consultando una tabla de mapeado 91 que mapea direcciones L3 a L2. Tal tabla de mapeado es una tabla ARP (otras incluyen “mapeado directo” y descubrimiento de vecinos). Esto puede ser la ARP de dispositivo fuente, ARP de dispositivo de salto L3 siguiente o ARP en cache global usando una consulta ARP descrita mas adelante. El puerto de salida identificado en el paso S1 se anade al registro de ruta S1A. En el paso S3, el conmutador de red de inicio (y puerto) se halla usando la posicion de host final en cache (a partir de consultas CAM de conmutador), y se pone como el dispositivo de enfoque. En el paso S4, se halla el conmutador de red terminal usando la posicion de host final en cache (a partir de consultas CAM de conmutador). El conmutador de inicio se anade al registro de ruta.

El metodo esta preparado ahora para entrar en un bucle de identificacion de ruta. En el paso S5 se determina si NHL2 es conocido. En caso afirmativo, el bucle pasa al paso S5A. En caso negativo, el proceso lleva a cabo el paso S5B para resolver NHL2 por una consulta ARP en el dispositivo de enfoque o el dispositivo NHL3. La generacion de una consulta para correlacionar una direccion de capa 3 con una direccion de capa 2 se explica con mas detalle mas adelante con referencia a la figura 7. En resumen, para el dispositivo que es consultado, se obtiene una lista de indices de interfaz (ifindices) a partir de la topologfa de red o recorriendo iflndex a partir de la tabla de interfaces del dispositivo propiamente dicho. Cada iflndex para el dispositivo se combina con la direccion NHL 3 para generar un conjunto de claves a incluir en la consulta al dispositivo. Asf, una consulta conteniendo estas claves es formulada y transmitida al dispositivo de enfoque. El dispositivo de enfoque produce cero o una respuesta exitosa.

Si fallan las dos tecnicas anteriores para resolver NHL2, se accede a ARP global. En el paso S5A, se determina si la direccion NHL3 esta o no en el dispositivo de enfoque actual.

Si NHL3 no esta en el dispositivo actual, en el paso S6, el proceso envfa una consulta para hallar la entrada FDB de capa 2 para que NHL2 obtenga el puerto de salida. La generacion de una consulta en la capa 2 se explica mas adelante. Si tiene exito, se anade el puerto de salida al registro de ruta (S6A), se usa la topologfa en cache 3 para hallar el puerto y el dispositivo en el extremo del enlace (S7), se anade el dispositivo a la ruta (S7A), y el dispositivo de enfoque se pone al dispositivo que acaba de localizarse en el extremo del enlace (salto L2). Los pasos S6A, S7 y S7A pueden denominarse un salto L2. En este punto, consultese la figura 2b. En el paso S5A, el dispositivo de enfoque es el dispositivo A. este recibe una consulta para hallar la entrada FDB de capa 2 y devuelve el puerto de salida. El dispositivo que se determina que esta en el extremo de dicho enlace es el dispositivo B (figura 2c) que recibe una consulta con NHL3 todavfa puesto a la direccion IP de destino.

Si no se hallo una entrada FDB de capa 2, o si en S5A se determino que NHL3 se alojaba en el dispositivo de enfoque, en el paso S8 se realiza una consulta de ruta para determinar si la ruta L3 se halla en el dispositivo de enfoque a la direccion IP de destino. La consulta de ruta puede ser una consulta de ruta unica o recursiva, que se explican mas adelante. Esto establece una IP de salto siguiente y una interfaz de salida. Si no se halla la ruta L3, se indica una ruta rota y el proceso se para - S8A. En el paso S9 (salto L3) se anade la interfaz de salida de tabla de enrutamiento a la ruta, NHL3 se pone a la nueva direccion IP de salto siguiente, y el proceso consulta al dispositivo para averiguar la direccion de capa 2 de NHL3. Si no se puede resolver NHL2, nHL2 se pone a “desconocido”.

5

10

15

20

25

30

35

40

45

50

55

60

65

En el paso S10, la direccion NHL3 actual se compara con la direccion IP de destino. Si NHL3 no es la IP de destino (es decir, el algoritmo de identificacion de ruta aun no esta en el segmento L2 final), en el paso S11 se usa la topologfa en cache para hallar el puerto y dispositivo en el extremo de enlace, el dispositivo se anade al registro de ruta y el enfoque se pone a este dispositivo. El proceso consulta entonces (S12) si el dispositivo de enfoque es el dispositivo terminal. Si el dispositivo de enfoque no es el dispositivo terminal, el proceso vuelve al paso S5, pero usando NHL3 y NHL2 puestos en el paso 9.

Terminacion

El algoritmo termina cuando se llega al dispositivo terminal y se anaden el puerto terminal y el servidor de destino a la ruta. Otras condiciones de terminacion evitan que el algoritmo itere indefinidamente. En cada iteracion de la ruta, se inicia una iteracion poniendo un senalizador conmutado a falso y un senalizador enrutado a falso. Cuando tiene lugar un salto L2 (S7) el senalizador conmutado se pone a verdadero; cuando tiene lugar un salto L3 (S9), el senalizador enrutado se pone a verdadero. Como ya se ha mencionado, el puerto de salida se determina a partir de un dispositivo de enfoque, y la topologfa de red se usa para hallar el dispositivo unido y el puerto de entrada del dispositivo unido. Por cada iteracion se almacena la combinacion de:

“Dispositivo de enfoque, NHL2, NHL3”.

Si el dispositivo de enfoque, NHL2 o NHL3 han cambiado y la nueva combinacion de “dispositivo de enfoque, NHL2, NHL3” se ha visto antes, aparece un evento de bucle detectado y el bucle se para. Si no se ha alcanzado el lfmite de bucle, y se ha producido enrutamiento o conmutacion (es decir, los senalizadores enrutado o conmutado son verdaderos) y el dispositivo de enfoque no es igual al dispositivo terminal, itera de nuevo. Cada vez se averigua si se ha alcanzado el lfmite de bucle de iteracion. Si se ha alcanzado, el algoritmo termina.

Cuando cesa la iteracion, si el dispositivo de enfoque es el dispositivo terminal, el dispositivo terminal se anade a la ruta. Si el dispositivo de enfoque no es el dispositivo terminal, pero el algoritmo se ha parado, se reporta un error de que el algoritmo de hallazgo de ruta habra terminado en un lugar inesperado. Si el dispositivo terminal es un conmutador de acceso, el puerto de salida de conmutador de acceso se anade desde “localizar destino” (S4) a la ruta y el dispositivo de destino derivado del puerto de salida de conmutador de acceso se anade a la ruta - el algoritmo termina entonces. Si el dispositivo terminal es igual al dispositivo destino, el algoritmo termina. El detalle del algoritmo se explicara ahora con mas detalle.

Ejemplo especifico

La figura 4 representa un resultado de la operacion del algoritmo de identificacion de ruta. Es decir, proporciona la ruta que un paquete de datos procedente del dispositivo fuente X dirigido a dispositivo destino Y tomana por la red al tiempo en que el algoritmo de identificacion de ruta consulta la red. La ruta se representa incluyendo dispositivos A-J que forman parte del registro de ruta. El registro de ruta incluye los puertos de entrada y de salida de cada uno de los dispositivos.

Observando de nuevo la red original de la figura 1, se puede ver que la primera parte del registro de ruta representado en la figura 4 deriva de la red de la figura 1, donde se han usado letras correspondientes para denotar los dispositivos seleccionados por el conmutador o dispositivo de enrutamiento previos. Cuando el algoritmo de identificacion de ruta opero, el dispositivo de enrutamiento B habfa determinado enviar el paquete al conmutador C. Sin embargo, sin usar la presente invencion, habna sido sumamente diffcil hacerlo en tiempo real. El dispositivo de enrutamiento B tema igualmente una opcion de enrutar el paquete al router F en la red de nucleo. Consultando el dispositivo de enrutamiento B en tiempo real (o mas o menos en tiempo real), en base al paquete hipotetico dirigido al destino Y, el dispositivo de enrutamiento B devuelve la decision que habna tomado si hubiese llegado un paquete real con esa direccion. Averiguando que el dispositivo de enrutamiento B enviara el paquete al conmutador C, y estableciendo a continuacion que el conmutador C esta conectado, el extremo lejano de su dispositivo de enrutamiento de puerto de salida D, C y D se ha anadido al registro de ruta 81. De esta forma, el algoritmo de identificacion de paquete ha pasado a traves de la ruta que el paquete hipotetico habna tomado al tiempo en que el algoritmo de identificacion de ruta consulta los dispositivos en la red. El recuadro adyacente al dispositivo de enrutamiento D denota los parametros para NHL3 y NHL2, es decir, NHL3 se pone a la direccion IP del dispositivo E que se ha establecido como el dispositivo de extremo lejano para el dispositivo de enrutamiento D en base a la tabla de enrutamiento actualmente activa en D, y NHL2 ha sido establecida como la direccion MAC para el dispositivo E por el dispositivo consultante D para su entrada ARP para el dispositivo E.

Topologia de red

Como se ha mencionado previamente, la topologfa de red incluye tanto interconectividad de dispositivos de red como localizacion de host final. La topologfa de red 3 puede facilitarla un servidor de topologfa que proporcione detalles de conexiones de puerto a puerto. Asf, cuando un puerto de salida es identificado en un dispositivo, el puerto de entrada del dispositivo conectado se puede conocer usando conexion de puerto a puerto identificada en la topologfa. Ambos puertos de salida y de entrada pueden anadirse al registro de ruta. El servidor de topologfa

5

10

15

20

25

30

35

40

45

50

55

60

65

tambien proporciona una CAM global, un ARP global y credenciales de dispositivo. Ademas, por cada dispositivo registrado en la topologfa hay preferiblemente una lista de indices de interfaz (Iflndex), y una lista VLAN (red de area local virtual). Los dispositivos VLAN no se han explicado todavfa. Se explican mejor aqm. Cuando se devuelve una respuesta al ordenador supervisor 16, el ordenador supervisor consulta la topologfa 3 en el orden siguiente al manejar respuestas de capa 2. En este contexto, una respuesta de capa 2 es una respuesta que ha identificado un puerto de salida de un dispositivo conmutador de capa 2. El orden de consulta es CDP, LLDP, STP y SONMP, IPv6 ND.

Localizacion de dispositivo fuente

Como se ha mencionado antes, la localizacion del primer dispositivo en la ruta (el dispositivo conectado al dispositivo fuente) no es necesariamente sencilla. En una realizacion, el ordenador supervisor 16 implementa el algoritmo para intentar hallar en primer lugar la fuente como un host conectado y, si eso falla, intenta hallar la fuente como un dispositivo de red. Al intentar hallar la fuente como un host conectado, consulta al dispositivo fuente con respecto a la direccion de capa 2 (MAC) para la fuente IP. Esto se puede realizar de la misma forma que la consulta en un dispositivo de enfoque como se ha descrito anteriormente en el paso S5B. Es decir, el proceso envfa una consulta para hallar la entrada ARP para la direccion IP fuente.

Si no hay direccion de capa 2 procedente del dispositivo fuente, se consulta la tabla ARP en cache global en el servidor de topologfa. En la realizacion descrita, estas se denominan tablas ARP, pero se puede utilizar cualesquiera tablas que mapean las direcciones de capa 3 a capa 2. Si se halla una direccion MAC que corresponde a la direccion IP fuente, se consulta el servidor de topologfa con respecto a la localizacion MAC de IPs fuente consultando tablas de envfo de capa 2 en cache globales en el servidor de topologfa para hallar puertos que hayan tenido trafico procedente de esta direccion MAC. Se espera que el servidor de topologfa devuelva una localizacion de MAC fuente unica quitando multiples coincidencias (la fuente MAC vista en muchos puertos), filtrando puertos senalizados como lmeas principales, puertos con excesivos numeros de MACs (las entradas FDB de los puertos de conmutador de acceso tienen tipicamente una sola direccion MAC 'vista'), puertos con topologfa entre redes (por ejemplo, si un puerto tiene informacion de adyacencia CDP no puede ser un puerto en un conmutador de acceso), etc.

Si no se puede hallar la fuente como un host conectado, se intenta hallar la fuente como un dispositivo de red. Esto se puede lograr consultando el servidor de topologfa con respecto a todas las direcciones IP halladas en todos los dispositivos de red gestionados para ver si la direccion IP esta en un dispositivo de red. Si esta, ese dispositivo de red se pone como el dispositivo de enfoque.

Localizacion de dispositivo destino

Se aplican consideraciones similares a la localizacion del dispositivo destino. En primer lugar, se intenta hallar el dispositivo destino como un host conectado, y si eso falla, se intenta hallar el destino como un dispositivo de red. Para hallar el dispositivo destino como un host conectado, se consulta el dispositivo destino con respecto a su direccion de capa 2, o se consultan tablas de mapeado de capa 3 a capa 2 en cache globales en el servidor de topologfa (igual que con respecto al dispositivo fuente explicado anteriormente). Despues se consultan tablas de envfo de capa 2 en cache globales en el servidor de topologfa para hallar puertos que han tenido trafico procedente de esta MAC (de nuevo, como se ha descrito anteriormente con referencia a la localizacion de dispositivo fuente).

Para hallar el destino como un dispositivo de red si falla lo anterior, el servidor de topologfa puede ser consultado con respecto a todas las direcciones IP halladas en todos los dispositivos gestionados para ver si la direccion IP esta en un dispositivo de red. El dispositivo de red se puede poner entonces como el dispositivo terminal.

Utilidad por salto

Con el fin de implementar el algoritmo de identificacion de ruta, el ordenador supervisor 16 ejecuta un programa de ordenador como se ha explicado. Este programa de ordenador proporciona una utilidad que maneja consultas “por salto”. Es decir, el algoritmo de identificacion se basa en enviar una consulta desde el ordenador supervisor a un dispositivo de enfoque y recibir del dispositivo de enfoque un puerto de salida que puede ser usado para acceder a la topologfa. Esto no se puede lograr necesariamente con una sola consulta. Como se ha descrito anteriormente, el algoritmo requiere un salto siguiente inicial en la capa 3 (NHL3). La utilidad intenta consultar una tabla de enrutamiento en el dispositivo fuente para NHL3 y el puerto de salida, usando la direccion IP de destino. Si no se halla ninguna ruta, consulta la tabla de enrutamiento en el conmutador de acceso en caso de que sea un conmutador de capa 3 (que es el primer dispositivo conectado al dispositivo fuente para NHL3). Si no se halla ninguna ruta, el dispositivo fuente es consultado con respecto a la puerta de enlace por defecto para NHL3. Si no se halla ninguna ruta, el primer dispositivo es consultado con respecto a una puerta de enlace por defecto.

Para consultar una tabla de enrutamiento para hallar NHL3 (como se ha descrito anteriormente), se halla una ruta para la direccion IP en cuestion (la direccion IP 'buscada') consultando el dispositivo de enrutamiento usando una tecnica de manipulacion especulativa explicada mas adelante. Si se halla la ruta pero no se especifica el puerto de

5

10

15

20

25

30

35

40

45

50

55

60

65

salida, se devuelve la direccion IP de salto siguiente y se usa como NHL3. Si se halla la ruta con una interfaz de salida iflndex superior a cero, el puerto de salida es devuelto con la direccion NHL3 y se anade el puerto de salida a la ruta. Si se halla la ruta con la interfaz de salida iflndex igual a cero, la utilidad reitera poniendo la IP buscada a la IP de salto siguiente (de la consulta previa) y hallando la ruta para la IP buscada consultando el dispositivo usando manipulacion especulativa (como se explica mas adelante). Esto se repite hasta que el iflndex devuelto sea no cero.

El paso de hallar la ruta para la IP buscada usa la tecnica de manipulacion especulativa para devolver una entrada de ruta. Si se halla la entrada de ruta, la utilidad sondea la direccion de salto siguiente a partir de ipRouteNextHop.NetworkAddress. La utilidad tambien sondea la interfaz de salida a partir de ipRouteIflindex.NetworkAddress y sondea ipRouteType.NetworkAddress. Si ipRouteType es 'directo', la IP buscada se pone al salto siguiente, puesto que un tipo de ruta IP de directo indica que esta conectado directamente al segmento de red.

Es posible que se devuelvan multiples coincidencias de una tabla de enrutamiento en un dispositivo. En ese caso, es apropiado determinar si se estan utilizando multiples rutas, por ejemplo, cuando un dispositivo es responsable de trafico de equilibrio de carga. Si solamente se esta usando activamente una sola ruta, debera determinarse la ruta activa. Si se estan utilizando multiples rutas, la ruta podna dividirse en este punto y el registro de ruta podna contener los resultados del algoritmo de hallazgo de ruta aplicado a toda y cada ruta hallada desde este punto en adelante. En muchos casos, multiples opciones de enrutamiento en un dispositivo es indicativo de un dispositivo que enruta inteligentemente en base a diversa metrica. Esta metrica tambien puede ser consultada y devuelta para registro en el ordenador supervisor.

La utilidad tambien es responsable de hallar el salto siguiente inicial en la capa 2 consultando la tabla de mapeado de capa 3 a capa 2 91 en el dispositivo de enfoque. Si no se halla la direccion de capa 2, donde el dispositivo de enfoque es el dispositivo fuente, la utilidad consulta el conmutador de acceso (si es un conmutador de capa 3 debera proporcionar un mapeado de capa 3 a capa 2). Si no se halla la direccion de capa 2, la utilidad consulta las tablas ARP en cache global en el servidor de topologfa 3. Una consulta de una direccion de capa 2 en un dispositivo se lleva a cabo como se ha explicado anteriormente con referencia al paso S5B.

Si la direccion NHL 3 no esta en el dispositivo de enfoque, la utilidad sondea el dispositivo de enfoque con respecto a un puerto de salida para la direccion de capa 2 NHL2. El paso de sondear el dispositivo de enfoque con respecto al puerto de salida nHL2 incluye sondeo espedfico VLAN (red de area local virtual). Es decir, incluye el paso de establecer en que VLANs esta participando el dispositivo segun la topologfa 3 y como se ha registrado en el dispositivo. Estas VLANs se usan para ayudar a hallar entradas de tabla de envfo para VLANs espedficas (las FDBs se dividen a menudo segun las VLAN con las que estan relacionadas - por ejemplo, para el Protocolo de arbol de expansion por VLAN (PVSTP) es necesario realizar las consultas FDB en el contexto de cada VLAN para intentar hallar una coincidencia).

Si no se halla el puerto de salida a partir de la capa 2 FDB (usando una VLAN espedfica o la VLAN nativa), entonces la utilidad intenta hallar que interfaz se dirige hacia NHL2 a partir de registros ARP sondeando ipNetToMedia-PhysAddress 71 (figura 7). Es decir, la utilidad intenta aprender de que interfaz se aprendio la relacion de capa 2 a capa 3.

Una vez que la utilidad ha hallado un puerto de salida usando la direccion de capa 2, anade el puerto de salida al registro de ruta y usa el servidor de topologfa 3 para hallar el puerto remoto unido al puerto de salida. Este puerto remoto se registra como el puerto de entrada en el dispositivo siguiente.

Canales de puerto/Puertos multiplexados

Si no se halla ningun puerto remoto, o el nombre de puerto de salida impone el uso de puertos de capa superior o inferior, la utilidad comprueba los puertos de capa inferior o los puertos de capa mas alta. Es decir, puede haber un escenario donde haya un mapeado de salidas de ruta virtual a puertos ffsicos. Para que el algoritmo de identificacion de ruta tenga exito, tiene que identificar un puerto de salida ffsico para acceder al servidor de topologfa. En un escenario donde la comprobacion de puertos de capa inferior revela la presencia de puertos de capa inferior, estos puertos de capa inferior pueden ser usados como los puertos de salida y se accede al servidor de topologfa para hallar los puertos remotos (puertos de entrada del dispositivo siguiente) unidos a los puertos de salida. En este punto, la ruta se divide en multiples rutas separadas, cada una de las cuales es seguida independientemente desde este punto en adelante.

Si se identifican puertos de capa mas alta, el puerto de capa mas alta se usa para el puerto de salida. El servidor de topologfa se usa para hallar el puerto remoto unido a este puerto de salida de capa mas alta.

Salto siguiente

Poner los senalizadores enrutado y conmutado a falso. Usando el servidor de topologfa o consultas directas al dispositivo de enfoque, conocer si el dispositivo de enfoque aloja o no la direccion NHL3 IP en alguno de sus

5

10

15

20

25

30

35

40

45

50

55

60

65

puertos. Si aloja la direccion NHL3 IP, la utilidad pasa entonces a consultar la tabla de enrutamiento de dispositivo de enfoque con respecto a rutas a la IP de destino usando la tecnica de manipulacion especulativa. Si la utilidad localiza una ruta candidata, la direccion de capa 2 NHL2 siguiente se pone consultando el dispositivo de enfoque (o tablas ARP en cache global) para mapeado de capa 3 a capa 2 y el senalizador enrutado se pone a verdadero. Si NHL3 es igual a la IP de destino, eso indica que la utilidad ha llegado al ultimo dispositivo de capa 3 mas proximo al destino de modo que todavfa no hay necesidad de mover este dispositivo puesto que el salto siguiente seffa un salto de capa 2. Por lo tanto, la utilidad anade los puertos de salida de ruta candidato a la ruta. Si NHL3 no es igual a la IP de destino, indica que no esta en el segmento de capa 2 final y el puerto de salida de ruta candidato se anade a la ruta.

Si no se produjo enrutamiento durante esta iteracion (el senalizador enrutado todavfa esta puesto a falso), entonces la utilidad sondea el dispositivo de enfoque con respecto a un puerto de salida para la direccion de capa 2 NHL2. El paso de sondear el dispositivo de enfoque con respecto al puerto de salida NHL2 incluye sondeo espedfico de VLAN (red de area local virtual) (como se ha descrito anteriormente). Si el puerto de salida no se halla a partir de la FDB de capa 2 (usando una VLAN espedfica o la VLAN nativa), la utilidad intenta hallar que interfaz se dirige hacia NHL2 desde registros ARP sondeando con respecto a ipNetToMediaPhysAddress 71. Es decir, la utilidad intenta aprender de que interfaz se aprendio la relacion de capa 2 a capa 3. Una vez que la utilidad ha hallado un puerto de salida usando la direccion de capa 2, anade el puerto de salida al registro de ruta y usa el servidor de topologfa 3 para hallar el puerto remoto unido al puerto de salida. Este puerto remoto se registra como el puerto de entrada en el dispositivo siguiente. Si se halla un puerto de salida usando consultas FDB o consultas ARP, el senalizador conmutado se pone a verdadero.

Si, al consultar el servidor de topologfa, no se halla ningun puerto remoto, o el nombre de puerto de salida impone el uso de puertos de capa superior o inferior, entonces se realiza una comprobacion de puertos de capa inferior o mas alta, como se ha descrito anteriormente. Si se halla un puerto de salida, se anade a la ruta, el dispositivo conteniendo el puerto se anade a la ruta y el dispositivo de enfoque se pone al dispositivo remoto.

Este paso “Salto siguiente” se repite hasta que se llega a un lfmite preestablecido en el numero de iteraciones o la ruta llega a un final (es decir, no se produjo conmutacion ni enrutamiento).

Si el proceso termina en el dispositivo terminal previamente identificado y es dispositivo es un conmutador de acceso, el puerto de salida se anade desde “localizar destino” al registro de ruta, y el dispositivo destino se anade al registro de ruta. Si el dispositivo terminal es el dispositivo destino propiamente dicho, la utilidad termina.

Las figuras 11A a 11D muestran un diagrama de flujo de la operacion de la utilidad ejecutada en el ordenador supervisor.

Equilibrador de carga

Como se ha mencionado anteriormente, si el dispositivo de enfoque es el dispositivo terminal, el dispositivo terminal se anade con el destino al registro de ruta. Si el dispositivo terminal es un equilibrador de carga, entonces se obtiene la IP virtual para mapeado de grupo de servidores para el equilibrador de carga. Esto permite identificar el servidor para mapeado de servidor ffsico para el equilibrador de carga. La ruta se retiene hasta la ruta “rafz” (hasta que el dispositivo equilibrador de carga). Entonces, por cada direccion IP de servidor ffsico, se ejecuta una utilidad de descubrimiento de ruta adicional desde el equilibrador de carga a la direccion IP de servidor ffsico, anteponiendo la ruta “rafz” a cada ruta adicional.

Consulta de tabla de enrutamiento

Uno de los factores que hacen el algoritmo de ruta especialmente eficiente es la capacidad de generar eficientemente una consulta a un dispositivo de enrutamiento, es decir, generar una consulta a la que el dispositivo de enrutamiento puede responder en un corto peffodo de tiempo sin carga significativa. La figura 5 ilustra la estructura de una tabla de ruta lineal direccionable mediante SNMP. Para establecer una ruta a un destino concreto, ipRouteDest es el mdice requerido a la tabla de ruta. Esto se indica con 48 en la figura 5. Las entradas de interes en la tabla son ipRoutelfindex 50 que define la interfaz de salida, ipRouteNextHop 52 que define la direccion IP del salto siguiente (IP de salto siguiente) e ipRouteType 54 que define el tipo de entrada de enrutamiento (no valida/directa/indirecta). El acceso a la tabla requiere normalmente el conocimiento de ipRouteMask 56: esto permitiffa localizar una direccion IP de red espedfica. Sin embargo, como se puede ver en la figura 5, IpRouteMask propiamente dicho esta embebido en ipRouteEntry y por lo tanto no se conoce que esta puesto en la consulta. Lo que hay que hacer es hallar una coincidencia para:

<IP de interes> & <ipRouteMask.X> == <ipRouteDest.X>

con el fin de hallar la clave IpRouteDest 48 que representa el mdice a la tabla. La figura 27 ilustra el proceso Como observaron los autores de la invencion, solamente hay 33 posibilidades de IpRouteMask (/32.../0), es decir

5

10

15

20

25

30

35

40

45

50

55

60

65

255.255.255.255, 255.255.255.254, 255.255.255.252, ... 0.0.0.0. Un numero de estos produce IDs de red duplicadas para la misma direccion IP, a causa del numero de ceros en la direccion IP. Se produce una lista de las 33 mascaras de red posibles (Z2), y se aplica a la direccion IP (Z3). La figura 6 representa la aplicacion de las 33 mascaras de red a la direccion IP 10.44.1.213 = OA.2C.01.D5 = 0000 1010 0010 1100 0000 0001 1101 0101.

Esto genera 12 valores unicos (etiquetados 32, 31, 29, 27, 25, 24, 23, 13, 12, 10, 6, 4). Asf, ahora solamente hay que hacer 12 consultas SNMP (que pueden presentarse en un solo paquete de consulta) para hallar la ruta. Despues de los pasos Z4 a y Z5 para determinar si estan permitidas rutas por defecto y quitar redes consiguientemente, los 12 resultados se comparan con la tabla de ruta del dispositivo de enfoque y cuando se halla una coincidencia, los elementos requeridos ipRoutelfIndex (egresslfindex), ipRouteNextHop e ipRouteType son recuperados (Z12) y devueltos en una respuesta al ordenador supervisor 16.

La interfaz de resultado se pone a egresslnterface (Z13).

La reduccion del numero de consultas requerido para hallar la ruta se denomina aqm “manipulacion especulativa” y permite realizar la consulta de tabla de ruta en tiempo real de manera muy eficiente.

Al examinar tablas de enrutamiento reales, no es insolito que la ruta hallada para una direccion IP dada no tenga una interfaz de salida valida y solamente proporcione una direccion de salto siguiente. En estos casos, la direccion de salto siguiente se usa para una consulta posterior de la tabla de enrutamiento para intentar obtener una interfaz de salida para dicha direccion de salto siguiente. Esta reutilizacion de la direccion de salto siguiente se repite hasta que se obtiene una interfaz de salida. Segun este acercamiento, en un primer paso una consulta de hallazgo de ruta unica usa manipulacion especulativa para hallar una entrada de enrutamiento para la direccion IP especificada (IPx) como acaba de esbozarse. Si el ipRouteType asociado es “directo”, se devuelven IPx (e ipRouteIfIndexx) en una respuesta al ordenador supervisor como el salto siguiente. Es decir, esta conectado directamente y por lo tanto no tiene salto siguiente de capa 3.

Si el ipRouteType asociado no es directo, se devuelven ipRouteNextHop e ipRoutelfIndex en respuesta al ordenador supervisor.

El proceso de hallazgo de ruta tambien toma en cuenta tablas de enrutamiento entre dominios sin clase IP que son mas diffciles de consultar. En este caso, si el paso Z10 no da lugar a una direccion IP, el proceso pasa al paso Z14 donde se envfa una consulta SNMP (Obtener siguiente) al dispositivo, usando IPcidrRouteDest + direccion de red + mascara de red. Si el resultado no es una direccion IP, el proceso itera de nuevo al paso Z7 y realiza los pasos Z8, Z9, Z10 de nuevo. Si el resultado es una direccion IP, se extrae la direccion de red del OID devuelto. Entonces se determina si la direccion de red de OID coincide con la direccion de red de consulta. En caso negativo, el proceso vuelve al paso Z7. En caso positivo, la ruta hallada se pone a verdadera, la clave CIDR se pone al OID de la consulta devuelta con IPcidrRouteDest quitado, es decir,, el mdice a la tabla de ruta CIDR. El proceso prosigue despues permitiendo una consulta SNMP para obtener salto siguiente, ifIndex de salida y tipo de ruta.

Como se representa en la figura P, en el proceso FindRoutelterative, se realiza el paso FindRoute F1 para la direccion IP requerida (IPx). Si no se halla ruta, se devuelve un fallo. Si se halla una ruta, pero no hay interfaz de salida, se devuelve ipRouteNextHop. Si se halla la ruta e ipRoutelfindex es igual a cero, entonces se realiza un paso FindRoutelterative posterior para la direccion IP de ipRouteNextHop, con los mismos cuatro resultados posibles.

Aunque la manipulacion especulativa es una tecnica especialmente buena para la consulta eficiente de grandes conjuntos de datos, su principal aplicabilidad es cuando se consultan datos que estan indexados con una clave derivada de la que ya se conoce una clave parcial. Por esa razon es especialmente util en el contexto del analisis de tabla de ruta SNMP y la consulta de tabla SNMP ARP. Sin embargo, el comportamiento de envfo rapido por dispositivo de red tambien se puede conocer usando otras tecnicas de consulta, por ejemplo, acceso CLI y XML API.

Consulta ARP

Ahora se hara referencia a la figura 7 para describir una tecnica eficiente de consultar una tabla ARP usando manipulacion especulativa. La generacion de una consulta se explica con mas detalle mas adelante con referencia a la figura 7. Para el dispositivo consultado, se obtiene una lista de indices de interfaz (Iflndices) de la topologfa de red o recorriendo IfIndex del dispositivo propiamente dicho. Cada iflndex del dispositivo se combina con la direccion NHL 3 para generar un conjunto de claves a incluir en la consulta al dispositivo. Asf, se formula una consulta conteniendo dichas claves y se transmite al dispositivo de enfoque. El dispositivo de enfoque produce cero o una respuesta exitosa. La figura 7 ilustra un formato de tabla ipNetToMediaEntry que permitina en principio determinar la direccion MAC para cualquier direccion IP dada. Dado que no puede hallarse una unica entrada para una direccion IP espedfica a no ser que se conozca de que interfaz se aprendio la entrada ARP, se usa manipulacion especulativa combinando la direccion IP con todos y cada iflndex en el dispositivo. Es decir, cada clave de consulta puede ser creada combinando la direccion IP con un ifIndex. De esta forma, el numero de consultas SNMP es el numero de interfaces en el dispositivo que tipicamente es mucho menor que el numero de entradas ARP en el dispositivo y por

5

10

15

20

25

30

35

40

45

50

55

60

65

ello es significativamente mas eficiente.

En manipulacion especulativa, multiples claves de consulta pueden contenerse en un solo mensaje de consulta.

Sigue una descripcion de algoritmos alternativos para identificacion de ruta. Ahora se hara referencia a la figura 12 para describir un proceso de iteracion de bucle. La entrada al bucle principal se indica en la parte superior de la figura 12 con la flecha de entrada 4. La flecha de entrada 4 denota el estado al final de los procesos iniciadores que se describiran mas adelante. El estado de entrada incluye:

<Opciones, dispositivo de enfoque, NHL 3, NHL 2, VLAN>

Estos elementos se ponen por los procesos iniciadores que se describiran mas adelante. A continuacion se denominan “variables de estado”. La variable de estado titulada “opciones” tiene una secuencia ordenada de opciones de bucle. En el ejemplo presente, la secuencia ordenada incluye CSRAcr.

La variable de estado titulada “VLAN” es el identificador de red de area local virtual (numero) para la VLAN con el que el paquete hipotetico es etiquetado actualmente en este punto en la ruta.

En el paso L01 del bucle, se selecciona y ejecuta la primera opcion (cabeza de la lista). Estas opciones se explican mas adelante. Despues de la ejecucion de la opcion, el proceso vuelve al punto de retorno L02 y se crea un nuevo estado (L03) siguiendo los pasos de procesado implementados por la opcion de cabeza de lista. Se determina (L04) si este estado se ha producido antes, y en caso negativo, se almacena el estado (L05). Si el estado se ha producido antes, se genera un informe “bucle descubierto” y el lfmite de bucle se pone a cero, lo que tendra el efecto de terminar el bucle.

En el paso L07, se decrementa el lfmite de bucle. Si el lfmite de bucle es menor o igual a cero o no hay mas opciones disponibles en la secuencia de opciones, o el dispositivo de enfoque es igual al dispositivo terminal, entonces se pone una condicion “terminar es igual a verdadero”. En el paso L08, se lleva a cabo una comprobacion en la condicion de terminacion, y si la condicion de terminacion es verdadera, el bucle principal termina. De otro modo, vuelve al punto de entrada de bucle principal usando el nuevo estado que se creo en el paso L03.

Observese que en la ejecucion de cada opcion en una iteracion de bucle, el primer paso en la ejecucion de la opcion es quitar dicha opcion de la secuencia ordenada en la variable de estado opciones.

Al final de los pasos de procesado de la opcion, puede ser que dicha opcion se resetee de nuevo a la secuencia, o puede haberse quitado permanentemente, dependiendo de la opcion y los resultados de los pasos de procesado.

Observese tambien que en la ejecucion de los pasos de procesado de una opcion, las otras variables de estado (dispositivo de enfoque, NHL3, NHL3, VLAN) pueden alterarse individualmente o en total. La alteracion de cualquier variable de estado da lugar a un nuevo estado, que puede constituir un estado de entrada nuevo para una iteracion de bucle siguiente.

Ahora se hara referencia a la figura 12 para describir la segunda parte del proceso de bucle principal. En el paso L09 se determina si se ha llegado o no al dispositivo terminal esperado. En caso afirmativo, en el paso L10 se determina si el dispositivo terminal es un conmutador de acceso conectado a la IP de servidor. Si no lo es, entonces el proceso termina despues de indicar un descubrimiento exitoso de ruta completa y devuelve una ruta completa. Si el dispositivo terminal es un conmutador de acceso conectado a la IP de servidor, se anade a la ruta la conexion de puerto de acceso y la IP de servidor, y entonces el proceso procede a completar el descubrimiento de ruta exitoso y devuelve una ruta completa antes de terminar en parada.

Si se determina en el paso L09 que no se ha llegado al dispositivo terminal esperado, entonces en el paso L14 se pregunta si NHL3 es la IP de servidor o no. Si no lo es, se determina que el descubrimiento de ruta completa ha tenido exito, y se devuelve una ruta parcial antes de parar. Si NHL era la IP de servidor, esto indica que el proceso en el segmento L2 final y por ello el proceso puede saltar al destino incrementando el contador de segmentos de salto y poniendo el dispositivo de enfoque a NHL3.

La figura 14 ilustra la opcion C. En el primer paso C1, se quita la opcion de la secuencia en la variable opciones. En el paso C2, se realiza una comprobacion para una sola interfaz cuya direccion de red coincide con el destino (IP de servidor). Si es asf, esto indica que el algoritmo ha llegado a la porcion de red de conmutacion final, y NHL3 se pone a la IP de servidor. En el paso C3, el dispositivo de enfoque es consultado para hallar la entrada ARP para IP de servidor, y NHL2 se pone al resultado. El proceso vuelve entonces al bucle principal (C4) para permitir que otra opcion decida la interfaz de salida. La consulta al dispositivo de enfoque se realiza usando SNMP a la tabla ARP en el dispositivo de enfoque, o si no se halla, se consulta el cache ARP del sistema de gestion de red. Estas consultas se realizan segun tecnicas que se describen mas plenamente mas adelante.

En el paso C2, si falla la comprobacion de la unica interfaz para IP de servidor de destino, no se identifica una sola

5

10

15

20

25

30

35

40

45

50

55

60

65

interfaz. Las variables de estado no son actualizadas. En este caso, todo lo realizado es evaluar (y desechar) la opcion “C” y hallar que no es productiva.

La figura 15 ilustra la opcion S. Segun el paso S101, la opcion S se quita de la secuencia ordenada. En el paso S102, se realiza una consulta al sistema de gestion de red o se usan consultas SNMP al dispositivo de enfoque para hallar si el dispositivo de enfoque aloja NHL3. Si NHL3 esta en el dispositivo de enfoque, el proceso vuelve al punto de retorno de bucle principal (S104). Si la direccion de enrutamiento NHL3 no esta en el dispositivo de enfoque, se determina si la direccion de conmutacion NHL2 esta puesta, y el dispositivo de enfoque es consultado en la tabla de mapeado (ARP) con respecto a NHL2 dado NHL3. Las consultas se hacen como se describe mas plenamente mas adelante. En el paso S106 se determina si la indicacion VLAN esta puesta o no. Las indicaciones VLAN se explicaran mas adelante. En caso negativo, en el dispositivo de enfoque se determina una lista de VLANs a partir del dispositivo de enfoque o a partir del sistema de gestion de red. Se selecciona una VLAN de la lista y se realiza una busqueda para la entrada de base de datos de envfo usando el dispositivo de enfoque, NHL2 y VLAN. La busqueda de la entrada de base de datos de envfo ilustrada en el paso S109 se representa en un diagrama de flujo en la figura X. Volviendo al paso S106, si la indicacion VLAN esta puesta, el proceso va directamente al paso 1l0, que es una busqueda de entrada FDB como en el paso S109 usando la indicacion VLAN como la VLAN consultada dentro de la FDB. En el paso S112 (tambien S111), se determina si hay o no una entrada hallada en la base de datos de envfo. Si la hay, el proceso pasa a la segunda parte de la opcion S que se representa en la figura 16 (flecha de entrada 5). Si, despues del paso S111, no se halla entrada FDB, se introduce un bucle VLAN hasta que se determina si hay una entrada FDB o que el proceso debera volver al bucle principal. El punto de entrada a la segunda parte de la opcion S se muestra en la flecha 5 en la parte inferior de la figura 15. Esto tambien se muestra en la parte superior de la figura 16. Como se ha descrito, antes, si se halla una entrada de base de datos de envfo, esto indica el puerto de salida para la ruta S115. Esto puede usarse para obtener el dispositivo conectado siguiente de la topologfa de red, como se representa en el paso S117, y se describe mas plenamente mas adelante. El paso S116 es el paso de obtener una indicacion VLAN que se representa en la figura 2 y se explicara mas adelante.

El paso S117 se representa en la figura 22, que es un diagrama de flujo que ilustra el proceso para obtener el puerto conectado y por lo tanto el dispositivo conectado posterior del sistema de gestion de red en base al puerto de salida devuelto de la base de datos de envfo: si se halla el puerto conectado en el paso S118, el puerto conectado y el dispositivo conectado se anaden a la ruta identificada (paso S119) y en el paso S120 el dispositivo de enfoque se cambia al dispositivo conectado. En el paso S121, las opciones de bucle se resetean a CSRAcr. El procesador vuelve entonces al bucle principal en el paso S122. Volviendo al paso S118, si no se halla el puerto conectado, el proceso salta hacia delante a NHL3 incrementando un contador de segmentos de salto 89 (figura 8) y cambiando el dispositivo de enfoque a NHL3. El contador de segmentos de salto se implementa en el ordenador de gestion en hardware, microprogramas o software y permite indicar los segmentos de la ruta como saltados donde sea claro que el dispositivo conectado siguiente no se pueda conocer facilmente a partir de los pasos de proceso precedentes. En el paso S124 se determina si el dispositivo de enfoque no es el destino (IP de servidor). Si no lo es, las opciones de bucle se resetean a CSRAcr en el paso S125. Si el dispositivo de enfoque es el servidor destino, en el paso 126 se determina si el destino esta en un conmutador de acceso conocido, y si es asf, NHL 3 se pone a la direccion de conmutacion de acceso de servidor. Despues de poner las opciones de bucle en el paso S125, en el paso S128 el dispositivo de enfoque es consultado con respecto a NHL2 usando la direccion NHL3 que se puso en el paso S127, consultando la tabla ARP del dispositivo de enfoque o un NMS.

Observese que la opcion S incluye el paso de quitarla de las opciones disponibles en el paso S101, y luego resetearla de nuevo a las opciones disponibles en los pasos S121 y S125 en base a los resultados de los pasos de procesado.

Ahora se hara referencia a la figura 17 para describir las opciones R y r. Cada una de dichas opciones comienza con la extraccion de dicha opcion de la secuencia ordenada en la variable opcion, pasos R1, r1. En el paso R2, r2, se provoca un proceso para buscar la ruta a la IP de destino (IP de servidor) usando un proceso iterativo de hallazgo de ruta que se ilustra en la figura P. En la opcion R, el proceso opera donde no hay ruta permitida (la ruta por defecto permitida es igual a falso). En la opcion r, el proceso permite una ruta por defecto (ruta por defecto permitida es igual a verdadero). Si no se halla ruta, paso R3, el procesador vuelve al bucle principal. Si se halla una ruta, entonces se envfa una consulta al dispositivo de enfoque usando un NHL3 candidato que ha sido determinado a partir de la tabla de enrutamiento a partir de la se hallo la ruta. Esta consulta se hace a la tabla ARP del dispositivo para determinar un NHL2 candidato que corresponda al NHL3 candidato. Si no se halla ningun NHL2 candidato, el proceso pasa al punto de entrada 6 para la segunda parte de la opcion R/r. Si se halla un NHL2 candidato a partir de la consulta ARP, entonces se realiza una comprobacion en el paso R8 para determinar si el NHL2 candidato es el mismo que NHL2 que esta registrado como la variable de estado en el estado de entrada al proceso R/r. Si son los mismos, entonces el proceso pasa al punto de entrada 6. Si no son los mismos, paso R8 siguiente, si el NHL2 candidato no es el mismo que el estado de entrada NHL2, entonces NHL3 se pone a la IP de salto siguiente de la ruta candidato, y NHL2 se pone al NHL2 candidato. En el paso R10 se determina si las consultas de tabla de enrutamiento en R2 y r2 tambien proporciono un puerto de salida. En caso afirmativo, el proceso pasa al punto de entrada 6. En caso negativo, las opciones se resetean a CSRAcr en el paso R11. La figura 18 ilustra el punto de entrada 6 en la parte superior de la figura. En el paso siguiente R12, se determina si la tabla de enrutamiento proporciona un puerto de salida. En caso negativo, el proceso vuelve al bucle principal. En el paso R13, el proceso de obtencion de indicacion

5

10

15

20

25

30

35

40

45

50

55

60

65

VLAN se realiza segun la figura 21 y se describira mas adelante.

Entonces se realiza el proceso de obtencion de puerto conectado como se ilustra en la figura 22. En el paso R15, se determina si el puerto conectado se halla o no. En caso afirmativo, el puerto de salida, el puerto conectado y el dispositivo conectado se anaden a la ruta. El dispositivo de enfoque se cambia al dispositivo conectado y las opciones de bucle se resetean a CSRAcr. Si no se halla puerto conectado, no se realiza nada en esta etapa. El proceso pasa al paso R20 donde se determina si se ha actualizado NHL3. Si no se ha actualizado, el proceso vuelve al bucle principal. Si se ha actualizado, se consulta el dispositivo de enfoque antiguo con respecto al NHL2 candidato, dado el NHL3 candidato de la tabla de enrutamiento. Si, despues de dicho paso, se ha resuelto NHL2, el proceso vuelve al bucle principal. Si no, se consulta el nuevo dispositivo de enfoque con respecto al candidato NHL 2 dado el NHL3 candidato.

Se hara referencia a la opcion c con referencia a la figura 19. En el primer paso c1, se quita c de las opciones en la variable de estado. En el paso c2 se lleva a cabo una comprobacion con respecto a una sola interfaz cuya direccion de red coincide con la direccion NHL3 de red. Si no se halla una unica interfaz, el proceso vuelve al bucle principal. Si se halla una unica interfaz, y hay un nombre de interfaz de salida, se lleva a cabo el proceso de indicacion VLAN que se describira con referencia a la figura 21. Despues del paso C4, el puerto conectado se obtiene usando el proceso de obtencion de puerto conectado representado en la figura 22.

En el paso c7, se determina si se halla un puerto entre pares. Si se halla, el puerto de salida, el puerto entre pares y el dispositivo entre pares se anaden a la ruta y el dispositivo de enfoque se pone al dispositivo entre pares. Las opciones disponibles se resetean a CSRAcr en c8. Si no se halla puerto entre pares en el paso c7, el proceso vuelve al bucle principal.

Ahora se hara referencia a la figura 20 para describir la opcion A. En el paso A1, se quita la opcion A de la secuencia de opciones en la variable de estado. En el paso A2, se halla la entrada SNMP ARP para mapeado de NHL3 a NHL2. Si no se halla mapeado, el proceso vuelve al bucle principal.

Si se halla mapeado, el proceso usa SNMP para hallar el iflndex de la interfaz de la que se aprendio la relacion. En el paso A5, se determina si se ha hallado o no una unica interfaz. En caso negativo, el proceso vuelve al bucle principal. En caso positivo, el proceso pasa al paso A6 donde se determina si hay disponible un nombre de interfaz de salida. Si lo hay, se provoca el proceso de indicacion VLAN como se describira con referencia a la figura 21. Entonces, en A8, se provoca el proceso de obtencion de puerto conectado como se ilustra en la figura 22.

Si, como resultado del proceso de obtencion de puerto conectado, se halla un puerto entre pares, el puerto de salida se anade a la ruta, el puerto entre pares y el dispositivo entre pares se anaden a la ruta y el dispositivo de enfoque se pone al dispositivo entre pares. Ademas, las opciones disponibles se resetean a CSRAcr. Si no se halla puerto entre pares, el proceso vuelve al bucle principal.

Ahora se hara referencia a la figura 21 para explicar el proceso de indicacion VLAN. Este proceso se uso en la opcion A en el paso A7, la opcion c en el paso c5, la opcion R/r en el paso R13 y la opcion S en el paso S116. Ademas, se usa en uno de los procesos iniciadores que todavfa no se han explicado. El proceso empieza en el paso VL1 con un nombre de puerto de acceso. En el paso VL2 se determina si el nombre tiene forma de “VL+ un numero”, y, en caso afirmativo, se extrae el numero y se almacena como una indicacion VLAN en el paso VL3.

En caso negativo, entonces en el sistema de gestion de red se pide una lista de todas las VLANs en la interfaz. El paso VL5 comprueba cualesquiera VLANs contradictorias. Si no hay ninguna, entonces se almacena la unica VLAN como una indicacion VLAN en el paso VL6. Si hay VLANs contradictorias, cualquier indicacion VLAN que ya haya sido almacenada se deja sin cambiar.

Las indicaciones VLAN resuelven el problema que puede surgir en ciertas redes que usan una tecnica de conmutacion llamada STP (Protocolo de arbol de expansion) que se usa para no tener bucles logicos en porciones conmutadas (capa 2) de la red (para evitar que el trafico itere de forma infinita). El protocolo se usa para decidir adonde un dispositivo de conmutacion debera enviar un paquete dado.

Es decir, si el dispositivo esta conmutando, el conmutador observara la cabecera de capa 2 (MAC/Ethernet) y observara la direccion destino de capa 2 (NHL2) y luego consultara una base de datos interna (FDB - base de datos de envfo) para conocer desde cual de sus puertos se debera enviar el paquete. Muchas empresas usan una extension a STP llamada PVSTP (Protocolo de arbol de expansion por VLAN) por lo que cada paquete se marca tambien con un identificador VLAN. El conmutador mantiene entonces FDBs separadas - una por VLAn.

Esto se hace parcialmente por razones de eficiencia y en parte para permitir topologfas virtuales mas complejas. Asf, es perfectamente posible (y no insolito) que dos paquetes con el mismo destino de capa 2 salgan por puertos diferentes cuando se les etiqueta como que estan en VLANs diferentes aunque su destino sea el mismo dispositivo/puerto.

5

10

15

20

25

30

35

40

45

50

55

60

65

La consecuencia de esto es que el proceso no puede rastrear simplemente todas las FDBs por VLAN hasta que se halle una coincidencia. Es importante conocer a priori de que VLAN es el paquete etiquetado como elemento de la misma.

Este etiquetado VLAN puede tener lugar en diferentes lugares en la red, por ejemplo, en el puerto de acceso fuente - es decir, donde el dispositivo fuente esta ffsicamente conectado, o en algun otro lugar en la red - no es insolito que una etiqueta VLAN sea sustituida por otra (esto se denomina enrutamiento entre VLAN).

Por ejemplo, dado un paquete que llega al dispositivo de red D (en la ruta A->B->C->D), D solamente puede ser consultado con respecto a la interfaz de salida correcta si se conoce la VLAN en la que estana el paquete procedente de A en el punto en que llegue a D. Puede ser, por ejemplo, que A ponga el paquete en VLAN 100, B lo pase (usando VLAN 100), luego C cambie 100 a 200 y luego D lo conmute usando VLAN 200.

Por esta razon hay que 'llevar' una indicacion VLAN a traves de la red desde nuestro dispositivo fuente a nuestro dispositivo destino como parte del paquete hipotetico que se rastrea. Asf, donde sea aplicable, la indicacion VLAN se usa, anula, resetea o actualiza.

Como ya se ha mencionado, la figura 23 ilustra el proceso findRoutelterative que se usa en las opciones R y r. El proceso implica un bucle de hallazgo de ruta que comienza en el paso F1 y termina en una comprobacion de lfmite de ruta F2. El proceso findRoutelterative determina entonces si se ha hallado una ruta y permite que se localice un mdice de salida perteneciente a la ruta.

Antes de embarcarse en el bucle principal, hay tres procesos iniciadores que se implementan con el fin de poner el estado de entrada para la primera iteracion del bucle. Un primer proceso iniciador se representa en la figura 24, que pone como punto de inicio el conmutador de acceso o el dispositivo de red identificado para el dispositivo fuente (que en la figura 24 se denomina el lado de cliente. Igualmente, un conmutador de acceso o dispositivo de red es almacenado como un punto de parada, en base al dispositivo destino, denominado en la figura 24 el lado de servidor. En la figura 24, la IP de cliente y la IP de servidor son las direcciones fuente y destino respectivamente.

La figura 25 es un proceso iniciador para establecer las direcciones de estado de entrada inicial NHL3 y NHL2.

La figura 26 ilustra un tercer proceso iniciador que pone el dispositivo de enfoque para el estado de entrada inicial.

Observese que el primer proceso iniciador de la figura 24 conduce al segundo proceso iniciador de la figura 25, y el segundo proceso iniciador de la figura 25 conduce al tercer proceso iniciador de la figura 26. El tercer proceso iniciador conduce al punto de entrada principal 4 del bucle principal representado en la figura A.

Tecnologias/protocolos adicionales

El algoritmo de identificacion de ruta utilizado anteriormente proporciona una forma efectiva de identificar una ruta concreta que probablemente seguira un paquete o mensaje concreto a traves de la red de dispositivos interconectados que operan segun protocolos de red conocidos en general. Surgen situaciones en las que, por una u otra razon, el algoritmo de identificacion de ruta se enfrenta a un reto particular. Algunos de estos retos se explican a continuacion.

En algunos casos, la utilidad ejecutada en el algoritmo tiene que atravesar un segmento de red conmutado etiquetado multi-protocolo (MPLS). Lo lleva a cabo hallando la asignacion de etiqueta inicial (en el punto donde el trafico entra en el segmento MPLS) y rastreando a traves de la red MPLS por salto usando detalles por salto de despliegue, empuje y envfo de etiqueta hasta que el trafico haya desplegado su etiqueta final y salga del segmento MPLS.

Otro reto es atravesar lfmites NAT que pueden ser realizados sondeando tablas NAT del dispositivo NAT. Esto puede requerir sondeo especulativo en tiempo real para NAT dinamico, pero podna ser posible usar sondeo de fondo para NAT estatico.

Para protocolos de tunel, tal como IPSEC/GRE/SSL, etc, la utilidad comprueba una ruta directa desde un extremo del tunel al otro (tfpicamente con un salto de capa 3 desconocido que representa todos los nodos entremedio). La utilidad tambien comprueba informacion topologica espedfica de protocolo y comprueba en las tablas de enrutamiento/interfaces la presencia de saltos de cripto/tunelizacion.

Otro reto es la virtualizacion. Es importante que el algoritmo identifique puertos de salida ffsicos de modo que a un dispositivo ffsico conectado al puerto de salida pueda accederse desde la topologfa. Muchas redes operan en varias capas de virtualizacion diferentes. Los conmutadores virtuales pueden ser consultados usando APis adicionales, y para asegurar que el servidor de topologfa tenga informacion oportuna acerca de la posicion de host final, podna ser necesario integrar el servidor de topologfa con plataformas de gestion de virtualizacion para obtener actualizaciones relativas a reasignacion de maquina virtual para permitir un sondeo proactivo de la posicion de host final en

conmutadores virtuales afectados.

La utilidad negocia tablas de enrutamiento y envfo virtualizadas (VRF) consultando la tabla de envfo (enrutamiento) de IP apropiada requerida para un identificador VRF espedfico. En SNMP, por ejemplo, esto se puede hacer usando 5 cadenas comunitarias contextualizadas VRF.

Claims (18)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   REIVINDICACIONES

   1. Un metodo implementado por ordenador de identificar un salto siguiente a partir de un dispositivo de enfoque en una ruta de dispositivos interconectados incluyendo dispositivos de conmutacion (14) y de enrutamiento (12), donde un dispositivo de conmutacion (14) opera segun un protocolo de direccion de conmutacion y un dispositivo de enrutamiento (12) opera segun un protocolo de direccion de enrutamiento, teniendo el metodo implementado en un ordenador de gestion (16) una ruta de consulta a los dispositivos interconectados e incluyendo:

   para un dispositivo de enfoque que esta configurado para recibir trafico dirigido a un destino terminal y para actuar como un dispositivo de enrutamiento (12) del trafico, enviar un mensaje de consulta conteniendo una clave de consulta en base a un identificador de destino para el destino terminal desde el ordenador de gestion (16) al dispositivo de enfoque para identificar la direccion de enrutamiento siguiente del trafico dirigido al destino terminal;

   recibir un mensaje de resultado conteniendo una nueva direccion de enrutamiento que es la direccion de enrutamiento siguiente; y

   averiguar a partir de la nueva direccion de enrutamiento la direccion de conmutacion correspondiente que es la direccion de conmutacion para conmutar trafico en un dispositivo de conmutacion (14) en una direccion al destino terminal, donde la direccion de conmutacion es utilizable en una clave de consulta para una consulta dirigida a un dispositivo de enfoque que es un dispositivo de conmutacion (14).
2. 2. Un metodo segun la reivindicacion 1, donde el resultado incluye un puerto de salida (Po) del dispositivo de enfoque.
3. 3. Un metodo segun la reivindicacion 2, donde un dispositivo de salto siguiente es identificado a partir del puerto de salida (Po) recibido en el ordenador de gestion (16).
4. 4. Un metodo segun la reivindicacion 1, donde la direccion de conmutacion se averigua a partir de una tabla de mapeado (91) que mapea direcciones de enrutamiento a direcciones de conmutacion.
5. 5. Un metodo segun la reivindicacion 1, donde:

   si el dispositivo de enfoque aloja la direccion de enrutamiento siguiente, entonces enviar un mensaje de consulta al dispositivo de enfoque conteniendo la direccion de enrutamiento de un dispositivo de destino final en la ruta con el fin de averiguar una nueva direccion de enrutamiento siguiente junto con una nueva direccion de conmutacion de esta nueva direccion de enrutamiento, y el puerto de salida (Po) para mensajes dirigidos a esta nueva direccion de enrutamiento siguiente.
6. 6. Un metodo segun la reivindicacion 1, donde, si el dispositivo de enfoque no aloja la direccion de enrutamiento siguiente, entonces enviar un mensaje de consulta al dispositivo de enfoque para averiguar el puerto de salida (Po) para mensajes dirigidos a la direccion de conmutacion de la direccion de enrutamiento siguiente.
7. 7. Un metodo segun la reivindicacion 1, donde el dispositivo de enfoque es un dispositivo fuente (X) para trafico transportado por la ruta, y el paso de identificar la direccion de enrutamiento siguiente incluye enviar una consulta al dispositivo fuente (X), conteniendo una direccion de enrutamiento del destino terminal en la ruta, y averiguar a partir de la respuesta el identificador de direccion de enrutamiento siguiente.
8. 8. Un metodo segun la reivindicacion 1, que se usa para localizar un dispositivo fuente (X) para trafico transportado sobre la ruta dirigiendo una consulta a un dispositivo de enfoque que se espera que sea el dispositivo fuente (X) y usando la direccion de conmutacion para consultar un dispositivo de conmutacion (14) conectado al dispositivo fuente (X).
9. 9. Un metodo segun la reivindicacion 4, donde la tabla de mapeado (91) es una tabla de mapeado global que mapea direcciones de enrutamiento a direcciones de conmutacion para cada dispositivo.
10. 10. Un metodo segun cualquier reivindicacion precedente, donde los dispositivos de conmutacion (14) son dispositivos de capa 2 segun el modelo de interconexion de sistemas abiertos usando un protocolo de direccionamiento de control de acceso a medio.
11. 11. Un metodo segun cualquier reivindicacion precedente, donde los dispositivos de enrutamiento (12) son un dispositivo de enrutamiento de capa 3 segun el modelo de interconexion de sistemas abiertos usando un protocolo de direccionamiento de enrutamiento de protocolo de Internet.
12. 12. Un metodo segun la reivindicacion 4, donde la tabla de mapeado (91) es una tabla de protocolo de enrutamiento de direccion (ARP) segun el modelo de interconexion de sistemas abiertos.

    5

    10

    15

    20

    25
13. 13. Un metodo segun cualquier reivindicacion precedente, donde la consulta es transmitida desde el ordenador de gestion (16) al dispositivo de enfoque en un mensaje que es transmitido por la red.
14. 14. Un metodo segun la reivindicacion 13, donde el mensaje toma la forma de al menos un paquete dirigido al dispositivo que esta siendo consultado.
15. 15. Un metodo segun la reivindicacion 3, donde el dispositivo de salto siguiente es identificado a partir del puerto de salida (Po) averiguando un puerto de entrada (Pi) conectado al puerto de salida usando conexiones de puerto a puerto identificadas en una topologfa de red (3) y se almacena en un registro de ruta accesible por el ordenador de gestion (16).
16. 16. Un ordenador de gestion (16) para identificar un salto siguiente en una ruta de dispositivos interconectados, incluyendo el ordenador de gestion (16):

    una interfaz conectada a los dispositivos interconectados para transmitir consultas y recibir respuestas;

    un procesador (80) operable para ejecutar un programa de ordenador que realiza el metodo de cualquiera de las reivindicaciones 1 a 15; y

    un medio de almacenamiento (81) para almacenar una topologfa de red (3).
17. 17. Un ordenador de gestion segun la reivindicacion 16, incluyendo un medio de almacenamiento (82) para almacenar un registro de dispositivos de salto identificados como un registro de ruta.
18. 18. Un producto de programa de ordenador que incluye instrucciones legibles por ordenador que, cuando es ejecutado por un procesador (80), implementa el metodo de cualquiera de las reivindicaciones 1 a 15.