ES2620082T3 - Identificación de rutas tomadas a través de una red de dispositivos interconectados - Google Patents

Abstract

Un método implementado por ordenador para identificar en una red de dispositivos interconectados una ruta a través de la red desde un dispositivo fuente (X) hasta un dispositivo final de destino (Y), comprendiendo la ruta una secuencia conectada de dispositivos, comprendiendo el método en un ordenador monitor 16) conectados a la red: identificar un primer dispositivo conectado al dispositivo fuente (X); transmitir una primera consulta al primer dispositivo, incluyendo la consulta un identificador de destino y solicitando la identificación de un puerto de salida (Po) para mensajes dirigidos al destino identificado por el identificador de destino cuando se recibe la consulta en el primer dispositivo; recibir un mensaje de resultado que identifica el puerto de salida (Po) e identificar un segundo dispositivo conectado al primer dispositivo basado en una topología de red (3) accesible por el ordenador monitor (16); y dirigir una consulta siguiente al segundo dispositivo y recibir un mensaje de resultado siguiente que identifica un puerto de salida (Po) desde el segundo dispositivo; caracterizado por que: identifica desde la topología de red (3) un tercer dispositivo conectado al segundo dispositivo, donde la ruta se identifica para incluir el primer, segundo y tercer dispositivo; comprendiendo además el método: identificar una primera ruta a través de la red desde el dispositivo fuente (X) al dispositivo destino (Y) utilizando un primer conjunto de consultas en una primera vez, y rutas adicionales a través de la red desde el dispositivo fuente (X) hasta el dispositivo destino final (Y) utilizando conjuntos posteriores de consultas; e identificar repetidamente la primera y segunda ruta y determinando el uso de las rutas.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Identificacion de rutas tomadas a traves de una red de dispositivos interconectados

La presente invencion se refiere a la identificacion de una ruta en una red de dispositivos interconectados.

Las redes informaticas constituyen la base de la infraestructura de TI (tecnologfa de la informacion) en una amplia variedad de contextos. Dichas redes informaticas comprenden dispositivos interconectados de diversos tipos. El proposito de la red es soportar el flujo de mensajes entre esos dispositivos para entregar informacion, aplicaciones y servicios, etc., a traves de la red. Hay varias tecnicas disponibles para administrar una red. En este contexto, la administracion de una red incluye la monitorizacion de la red para identificar puntos de fallo y otras areas problematicas, tales como puntos de acceso inalambrico, y proporcionar informacion a los administradores y usuarios de la red para permitir que se resuelvan los problemas. Hay una serie de herramientas disponibles para proporcionar una topologfa de red. La topologfa de una red identifica como los dispositivos de la red estan ffsicamente o logicamente conectados entre sf. Por lo tanto, cualquier dispositivo individual particular puede tener una o mas conexiones a un dispositivo vecino. Las herramientas computarizadas que “descubren” una red estan disponibles, y crean topologfas de red que definen la interconexion de los dispositivos en la red, y la naturaleza de esos dispositivos.

Determinar la topologfa de la red se puede hacer de muchas maneras. Las tecnicas que pueden utilizarse por separado o en combinacion para dar una buena representacion de la conectividad de red incluyen, por ejemplo:

• Cisco Discovery Protocol (CDP)

• Link Layer Discovery Protocol (LLDP)

• SynOptics Network Management Protocol (SoNMP)

• Spanning Tree Protocol (STP)

• Traceroute IP

• IPv6 Neighbour Discovery

• Modificaciones/supresiones de adiciones de usuarios

Saber la topologfa de una red es extremadamente util, pero no proporciona una solucion a todos los problemas que pueden ocurrir. Las redes se utilizan cada vez mas para proporcionar la infraestructura para soportar la entrega de aplicaciones y servicios entre ubicaciones geograficas remotas, ya sea a largas distancias o a redes extremadamente complejas con un gran numero de dispositivos interconectados. Cada vez mas, los administradores de red y los usuarios estan interesados en conocer no necesariamente los detalles completos de la red, sino para comprender el rendimiento de la entrega de aplicaciones y servicios a traves de una red. Por lo tanto, la monitorizacion de “extremo a extremo” se esta volviendo cada vez mas popular. Con la monitorizacion de “extremo a extremo”, las aplicaciones que implican el flujo de mensajes desde un dispositivo fuente a un dispositivo de destino tienen su desempeno monitorizado a medida que se entregan entre ese dispositivo de origen y destino. Los parametros de rendimiento se pueden utilizar para estimar o adivinar posibles fallos en la red, aunque no proporcionan ninguna informacion espedfica sobre la ubicacion de esos fallos y, por tanto, no apuntan directamente a una solucion.

A menudo, un dispositivo de origen es un servidor que proporciona un servicio particular y el dispositivo de destino es un terminal de cliente que esta conectado al servidor a traves de la red y que requiere utilizar dicho servicio. El termino “dispositivo” utilizado en la presente memoria pretende cubrir cualquier dispositivo que pueda conectarse en una red. El termino “servidor” se utiliza para denotar un dispositivo que es responsable de la entrega de un servicio o aplicacion y el termino “cliente” se utiliza para denotar un dispositivo (ya sea basado en el usuario u otra maquina o servidor dependiente) que depende de esa aplicacion o servicio.

Una dificultad significativa en adivinar donde podna estar un problema cuando se puede ver que el rendimiento de una aplicacion se esta deteriorando es una falta de comprension sobre la ruta a traves de la red que el flujo de mensajes para esa aplicacion podna haber tomado.

Las redes dependen de muchos tipos de dispositivos de red (por ejemplo, enrutadores, conmutadores, cortafuegos, equilibradores de carga, etc.) para conectar sus dispositivos de punto final, de tal manera que es extremadamente diffcil decir para cualquier punto final de origen como se dirigira el mensaje desde ese punto final a traves de la red a un punto final de destino determinado. La complejidad de tal determinacion de ruta se ve exacerbada por el uso de multiples rutas alternas, rutas redundantes, equilibrio de carga, etc.

Se han hecho intentos para predecir como un determinado paquete se encaminara a traves de una red. Dichas predicciones se basan en un modelo complejo de la topologfa de la red junto con indicaciones sobre una base por dispositivo en cuanto a como un dispositivo particular se comportara en la red. Los dispositivos de red pueden ser altamente sofisticados, y se ha desarrollado un gran numero de algoritmos complejos para determinar una estrategia de enrutamiento en cualquier dispositivo en particular. Ademas, esa estrategia de enrutamiento puede depender del

5

10

15

20

25

30

35

40

45

50

55

60

65

trafico y de otras consideraciones medioambientales que afectan a la red (como fallos de otros dispositivos, etc.). Los algoritmos complejos que pueden ser aplicados por un dispositivo para determinar una estrategia de enrutamiento pueden incluir, por ejemplo:

Interfaz de entrada y tecnolog^a de interfaz de entrada Cabeceras de paquetes (L2, L3, MPLS, ATM, etc.)

Rutas estaticas y conectadas directamente

Tablas de enrutamiento compartidas (conocimiento completo de BGP, OSPF, RIP, EIGRP, etc. - vecinos activos, estados de enlaces, costes de rutas, pesos de rutas, etc.)

Tablas de reenvo MAC aprendidas Listas de control de acceso

Tecnolog^as de superposicion de red (p. MPLS, VLAN 802.1q), etc.

Tecnolog^as de evitacion de bucle - p. PVSTP Protocolos de tunelizacion (MPLS, IPSEC, SSL, GRE)

Enlaces de carga equilibrada/redundantes Puertas de enlace predeterminadas

Sin embargo, incluso si en principio es posible predecir donde se enviara un paquete dado al siguiente en un dispositivo particular, esto requiere una gran cantidad de datos que es lenta de recopilar y puede estar obsoleta en cuestion de segundos debido a la naturaleza de tiempo real de la operacion de los dispositivos de enrutamiento. Ademas, la mera adquisicion de estos datos puede suponer una carga significativa tanto en los dispositivos de red como en las redes.

Ademas, los modelos necesarios para simular dispositivos de enrutamiento modernos son extremadamente complejos y, sin el modelo completo, su comportamiento no puede predecirse correctamente. Para mantener el modelo completo, es necesario que tales soluciones sean actualizadas regularmente y rapidamente para incluir desarrollos en las tecnologfas de enrutamiento.

El documento US2011/142054A1 describe un metodo para consultar tablas de enrutamiento con el fin de obtener informacion sobre puertos de entrada y salida. Esta informacion se utiliza para configurar nuevas rutas de enrutamiento. El proceso de consulta se realiza mediante un nuevo enrutador configurado que le envfa consultas a toda la red de una manera difundida. La informacion recibida es entonces utilizada por dicho enrutador para aprender la topologfa de red y para configurar rutas de acuerdo con criterios tales como costes de ruta, ancho de banda disponible, seguridad de ruta y asf sucesivamente.

Sumario

Con el enfoque novedoso detallado aqrn, los dispositivos de red se consultan en cuanto a lo que hanan con un paquete hipotetico (en lugar de consultar las especificaciones del protocolo de enrutamiento). Los protocolos de enrutamiento que se alimentan en las tablas de enrutamiento y reenvfo de los dispositivos no necesitan ser conocidos o mantenidos.

De acuerdo con un aspecto de la presente invencion, se proporciona un metodo implementado por ordenador para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo fuente a un dispositivo destino, comprendiendo la ruta una secuencia conectada de dispositivos, comprendiendo el metodo en un ordenador monitor conectado a la red: identificar un primer dispositivo conectado al dispositivo fuente; Transmitir una consulta al primer dispositivo, incluyendo la consulta un identificador de destino y solicitando la identificacion de un puerto de salida para mensajes dirigidos a un destino identificado por el identificador de destino cuando se recibe la consulta en el primer dispositivo; recibir un mensaje de resultado que identifica el puerto de salida e identificar el segundo dispositivo conectado al primer dispositivo basado en una topologfa de red accesible por el ordenador monitor; y dirigir una consulta siguiente al segundo dispositivo y recibir un mensaje de resultado siguiente que identifica un puerto de salida desde el segundo dispositivo; e identificar desde la topologfa de red un tercer dispositivo conectado al segundo dispositivo, y asf sucesivamente, en el que la ruta se identifica para incluir el primer, el segundo y los dispositivos subsiguientes.

La presente invencion utiliza un nuevo enfoque para identificar las rutas tomados a traves de una red de dispositivos interconectados para un flujo particular de mensajes. El concepto se basa en el uso de una cantidad minima de datos recopilados “de antemano”, espedficamente la topologfa de la red estatica y la ubicacion del host final (cuyos clientes y servidores estan conectados a los conmutadores de acceso/borde) y reune todo lo que se requiere sobre la marcha y de forma altamente selectiva segun se requiera para estos datos altamente dinamicos. Para los entornos dinamicos modernos, la capacidad de calcular la ruta de extremo a extremo ahora, es decir, en tiempo real, tiene una amplia aplicabilidad. La recopilacion de los datos y su procesamiento tienen que ser muy rapidos para que el algoritmo sea de valor practico cuando se utiliza con redes de gran escala del mundo real.

El comportamiento en un dispositivo particular se denomina “comportamiento por salto” (PHB). El PHB por sf solo no

5

10

15

20

25

30

35

40

45

50

55

60

65

puede proporcionar una ruta de extremo a extremo. Sin embargo, saber que un paquete deja el dispositivo en una interfaz espedfica puede ser de valor si no se sabe que dispositivo e interfaz estan conectados a esa interfaz. Mediante el uso de la topologfa de red acoplada con el PHB, se puede realizar el calculo directo de una ruta de extremo a extremo a traves de la red para un flujo de aplicacion.

Por lo tanto, la topologfa de red incluye tanto la interconectividad del dispositivo de red como la ubicacion del host final. A su vez, los dispositivos de origen y de destino utilizados para sembrar el algoritmo de busqueda de ruta son determinados por el flujo de interes de interes. Finalmente, la ruta espedfica tomada por un paquete hipotetico entre los dispositivos de origen y de destino se calcula dinamicamente.

La consulta que se transmite a cada dispositivo esta adaptada para consultar cada dispositivo para determinar la identificacion de un puerto de salida que representa los puertos de salida que el dispositivo utilizana para un mensaje hipotetico dirigido a un destino identificado por el identificador de destino. Tenga en cuenta que el identificador de destino para cualquier consulta determinada puede ser o no el identificador de destino del dispositivo terminal dependiendo de la ubicacion en la red del dispositivo que se esta consultando. Esto se puede lograr cuando el dispositivo es un enrutador consultando lo que esta en su tabla de enrutamiento activa en el momento en que se recibe la consulta.

La consulta en sf puede alojarse en un mensaje o senal transmitida desde el ordenador monitor al dispositivo que se esta consultando (dispositivo de enfoque). El mensaje o senal de consulta no constituye el flujo de mensajes para el que se ha de determinar la ruta. En su lugar, cada consulta contiene un identificador de destino que consulta el dispositivo de enfoque para averiguar como el dispositivo de enfoque manejana un mensaje hipotetico dirigido a ese destino si tuviera que tomar la decision en el momento en que se recibio la consulta. Por lo tanto, el dispositivo de enfoque devuelve un resultado que identifica un puerto de salida inmediato que habna sido utilizado en ese momento para un mensaje real dirigido a ese destino. Las consultas se pueden transmitir mientras la red esta activa y mientras el flujo de mensajes esta en su lugar. Sin embargo, tambien pueden transmitirse cuando el flujo de mensajes en sf no esta activo - la tecnica puede utilizarse en cualquier contexto.

Cuando la consulta esta en forma de 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 entregada a traves de la red desde el ordenador monitor 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 en sf. En una disposicion alternativa, una senal o senales de consulta pueden ser enviadas desde el ordenador monitor a traves de conexiones directas a los dispositivos de enfoque, por ejemplo, a traves de un mecanismo CLI o XML API.

El metodo descrito en la presente memoria permite una serie de tecnicas de analisis de red utiles. Permite la determinacion de ruta a peticion para que un administrador que intenta determinar la ruta de acceso para una aplicacion concreta pueda preguntar de forma mas o menos instantanea al ordenador monitor y recibir un resultado de la ruta.

Permite el descubrimiento de rutas multiples. Es decir, debido a los cambios en el entorno de la red, los dispositivos de enrutamiento pueden dirigir un flujo de mensajes de manera diferente dependiendo de esos cambios. Por lo tanto, un primer conjunto de consultas para identificar una ruta de acceso podna registrar una primera ruta, mientras que un segundo conjunto de consultas podna identificar una segunda ruta de acceso, incluso cuando el primer y el segundo conjunto de consultas estan muy proximos entre sf en el tiempo. La informacion sobre multiples rutas entre puntos finales comunes (es decir, el mismo dispositivo de origen y el mismo dispositivo de destino) puede presentarse grafica o visualmente para mostrar al usuario no solo la naturaleza de la ruta, sino el porcentaje de tiempo que cada ruta adopta para un determinado flujo de mensajes. Esto se puede lograr facilmente porque las propias consultas no representan una sobrecarga significativa para la red y, por lo tanto, se pueden enviar multiples conjuntos de consultas sin afectar significativamente el rendimiento.

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

Cuando hay multiples rutas de acceso entre los dispositivos comunes de origen y destino, las rutas pueden llevar diferentes latencias. A veces, un dispositivo de enrutamiento que realiza un enrutamiento inteligente puede causar un fenomeno conocido como “variacion de ruta” donde un flujo particular de mensajes cambia continuamente de ruta a ruta. Puede ser util para un administrador de red identificar estas ocurrencias debido a las implicaciones de tales cambios de ruta en la latencia de extremo a extremo y las implicaciones de dicha “inestabilidad” en las conversaciones telefonicas de voz sobre IP, por ejemplo.

El metodo se puede utilizar para localizar el fallo de ruta. Es decir, en la realizacion preferida del metodo, se envfan consultas y se reciben resultados y se analizan para identificar el dispositivo siguiente hasta que se identifica un dispositivo como el dispositivo de destino. A veces, sin embargo, hay un fallo en la red, de tal manera que la red no entregana el flujo de mensajes al dispositivo de destino. El metodo permite la identificacion de esa situacion al trabajar a lo largo de una ruta de extremo a extremo hasta que la ruta no se pueda recorrer mas y esta ubicacion de

5

10

15

20

25

30

35

40

45

50

55

60

65

red puede entonces notificarse a un administrador.

Ademas, el metodo puede permitir la posibilidad de reiniciar en un dispositivo subsiguiente en esa ruta, utilizando estimaciones basadas en la topologfa de red. El metodo de identificacion de ruta puede entonces ser adoptado de nuevo hasta que se alcance el dispositivo de destino desde el punto de fallo. De este modo, las porciones de la red para las que el ordenador de supervision no tiene visibilidad (por ejemplo, dispositivos que no tienen una interfaz de gestion apropiada o que pertenecen a una organizacion diferente) pueden circunnavegarse y continuar el analisis de ruta.

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

La ruta se registra en una memoria o se almacena en el ordenador monitor o accesible por el ordenador monitor. El registro de ruta comprende un conjunto de dispositivos e interfaces conectados. Esto puede presentarse en forma de un inventario ordenado de los dispositivos (componentes de red) entre los dos extremos. Esto permite la monitorizacion de disponibilidad de ruta de red, incluyendo notificacion de eventos, informes, SLA (acuerdos de nivel de servicio); administracion proactiva de la red incluyendo informes sobre dispositivos que fallan, CPU de alto dispositivo, memoria de dispositivo baja, congestion de puertos, etc., y analisis de impacto (planificacion de capacidad, analisis de “que pasa si”).

Es una ventaja significativa de los aspectos de la presente invencion que una asignacion entre la aplicacion o el servicio suministrado por la red y los dispositivos de red o los componentes mismos se pueda determinar a traves de la identificacion de la ruta. Esto representa un avance significativo en la gestion de las redes.

Segun otro aspecto de la presente invencion, se proporciona un sistema informatico de monitorizacion para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo fuente a un dispositivo destino, comprendiendo el sistema informatico: una interfaz conectada a la red para transmitir consultas y respuestas de recepcion; un procesador operable para ejecutar una herramienta de identificacion de ruta que lleva a cabo el procedimiento como se define aqrn; un primer medio de almacenamiento para almacenar el registro de ruta; y un segundo medio de almacenamiento que almacena la topologfa de red.

Un aspecto adicional de la presente invencion proporciona un producto de programa informatico que comprende instrucciones legibles por ordenador que cuando son ejecutadas por un procesador implementa el metodo como se define aquf

Para una mejor comprension de la presente invencion y para mostrar como puede llevarse a cabo la misma, se hara ahora referencia a modo de ejemplo, a los dibujos adjuntos, en los que:

la figura 1 es un diagrama esquematico de una red;

las figuras 2a a 2c son una ilustracion esquematica 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 muestra una ruta descubierto; la figura 5 es la estructura de una tabla de enrutamiento lineal;

la figura 6 ilustra un conjunto de resultados que se derivan de la combinacion de una direccion de destino con multiples mascaras de ruta;

la figura 7 muestra una estructura de una tabla ARP; la figura 8 es un diagrama esquematico de un ordenador monitor; la figura 9 es un diagrama esquematico de un enrutador de capa 3; la figura 10 es un diagrama esquematico de un conmutador de capa 2; y

las figuras 11A a 11D son un diagrama de flujo de una utilidad ejecutada en el ordenador monitor.

La figura 1 es un diagrama esquematico de una red. La red se extiende sobre un numero de diferentes ubicaciones geograficas. En cada extremo de la ubicacion geografica hay dispositivos de punto final y dispositivos de red o nodos. Los dispositivos de red incluyen enrutadores e conmutadores. El nucleo de la red comprende una pluralidad de dispositivos de red. Teniendo en cuenta la ubicacion geografica marcada en Londres, los terminales del cliente 2 pueden actuar como dispositivos de punto final. De manera similar, un servidor 4 puede actuar como un dispositivo de extremo y la impresora 6 puede considerarse un dispositivo de punto final. Dispositivos similares se muestran en las ubicaciones geograficas de Paris y Nueva York con diferentes disenos (Nueva York mostrando una granja de servidores o centro de datos). Observese que, en la ubicacion de Nueva York, una pluralidad de servidores 8 representa una aplicacion clave o dispositivos de punto final de servicio.

Debe apreciarse que la red mostrada en la figura 1 se da por medio de un ejemplo. Existe una amplia variedad de redes posibles y la presente invencion puede utilizarse en cualquier red de dispositivos interconectados. En particular, la naturaleza de los dispositivos de punto final y los dispositivos o nodos de red espedficos puede variar.

5

10

15

20

25

30

35

40

45

50

55

60

65

En la red particular que se describe, los dispositivos de red pueden ser dispositivos de capa 3 o capa 2.

El modelo OSI (interconexion de sistemas abiertos) define siete capas dentro de las cuales los protocolos de los sistemas de comunicacion pueden ser caracterizados. El algoritmo de busqueda de rutas descrito aqu calcula las rutas de red utilizando la informacion disponible en las capas 2 y 3.

Los dispositivos que funcionan en la capa 2 (la capa de enlace de datos) tienen conocimiento de dispositivos inmediatamente adyacentes y tienen la responsabilidad de obtener paquetes de un dispositivo de capa 2 al siguiente dispositivo de capa 2 (basado en la direccion de la capa 2 de MAC (control de acceso de medios)).

Los dispositivos que operan en la capa 3 (la capa de red) son responsables de propagar paquetes de un punto en una red a otro punto de la red, a muchas decenas o cientos de dispositivos de distancia. Para calcular que dispositivos deben participar en una ruta dado de la capa 3 (denominada en la presente memoria como saltos de la capa 3), los dispositivos de la capa 3 intercambian informacion de enrutamiento y usan protocolos de enrutamiento para calcular las rutas mas deseables.

Para pasar paquetes entre dispositivos de capa 3 consecutivos en una ruta, se utilizan dispositivos que funcionan en la capa 2; a menudo con muchos dispositivos de capa 2 (denominados en la presente memoria como saltos de capa 2) entre cada dispositivo de capa 3.

Asf, las redes grandes se subdividen efectivamente en multiples segmentos, cada uno de los cuales conteniendo ffpicamente dispositivos de capa multiple 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 comprende un controlador 90 por ejemplo, en forma de microprocesador que ejecuta un codigo de control, firmware o cualquier otra implementacion adecuada. El controlador 90 puede acceder a una tabla de enrutamiento 92 que se analiza 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 para la conveniencia de la notacion, en la practica, los dispositivos no suelen tener puertos que se dedican como puertos de entrada o de salida - si son de entrada o de salida depende de los datos que estan transfiriendo en ese momento. La mayona de los puertos funcionan como de salida y de entrada todo el tiempo.

Los paquetes que llegan a un puerto de entrada Pi pueden tener sus identificadores de destino, por ejemplo, IP (direcciones de protocolo de Internet) lefdas por el controlador 90 a traves de un bus 94. El controlador 90 accede a la tabla de enrutamiento 92 y basado en la informacion derivada de la misma controla un conmutador de enrutamiento 96 al que se dirige el paquete entrante. El conmutador de enrutamiento 96 dirige entonces el paquete entrante a un puerto de salida Po adecuado dependiendo de la informacion en la tabla de enrutamiento. El dispositivo de enrutamiento incluye una tabla de asignacion 91 que asigna las direcciones de la capa 3 a la capa 2 para el enrutamiento posterior. El funcionamiento de tales dispositivos de enrutamiento se conoce en la tecnica y por lo tanto no se describiran mas en el presente documento. Se observa en este contexto que la tabla de enrutamiento puede ser consultada por paquetes desde el ordenador monitor que llegan sobre los enlaces al puerto de entrada Pi interceptando dichos paquetes en el controlador 90. Tales paquetes de consulta no se suministran al conmutador de enrutamiento 96 para el enrutamiento adicional, sino que en su lugar generan una respuesta que es emitida desde el dispositivo de enrutamiento y devuelta a la entidad interrogadora a traves de la red desde un puerto de salida. En este caso, esa entidad interrogadora es el ordenador monitor 16. Todos los paquetes transportados a traves de la red (incluidos los paquetes de consulta) contienen una fuente y una direccion de destino; el paquete de consulta tiene una direccion de origen correspondiente al ordenador monitor y una direccion de destino correspondiente al dispositivo que se esta consultando. Cuando se necesita enviar la respuesta, se intercambian las direcciones de origen y de destino para hacer que la direccion de origen sea el dispositivo que se esta consultando y la direccion de destino sea el ordenador monitor.

La figura 10 es una version altamente esquematizada de un conmutador de capa 2. De manera similar a 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 muestra, por ejemplo, en la red de la figura 1. Como se menciono anteriormente, los puertos no suelen ser dedicados como entrada o salida. Los paquetes entrantes en un puerto de entrada Pi se dirigen a un conmutador 100 que puede acceder a una base de datos de reenvfo de capa 2 (FDB) 102 para determinar como encaminar los paquetes basandose en identificadores de destino (normalmente cabeceras) en los paquetes. Las bases de datos de reenvfo de la capa 2 asignan el identificador de un paquete entrante a un puerto de salida en el que se debe reenviar el paquete. Como ya se ha explicado anteriormente, segun el modelo OSI, los identificadores para los dispositivos de enrutamiento de capa 3 son direcciones IP, mientras que los identificadores para los dispositivos de capa 2 son direcciones MAC.

Al igual que con los dispositivos de capa 3, la capa 2 es conocida en la tecnica y, por lo tanto, no se discutira mas en el presente documento. Sin embargo, se observa que de nuevo como 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 a la salida del

5

10

15

20

25

30

35

40

45

50

55

60

65

conmutador de capa 2 en un puerto de salida Po. Por lo tanto, los propios paquetes de consulta no son dirigidos en el conmutador, sino que en su lugar generan una respuesta que se devuelve al dispositivo de consulta, en este caso el ordenador monitor 16.

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

Las realizaciones descritas a continuacion de la presente invencion proporcionan un metodo para identificar una ruta tornado por un flujo de mensajes entre un dispositivo de fuente dado y un dispositivo de destino dado. Por ejemplo, el punto extremo X podna considerarse un dispositivo fuente y el punto final Y podna considerarse un dispositivo de destino. Frente a una red de la figura 1, como ya se ha comentado anteriormente, es una tarea para nada trivial de establecer que ruta se adoptara a traves de la red entre esos extremos en un momento dado y bajo cualquier conjunto de condiciones ambientales. La figura 1 muestra un ordenador monitor 16 que ejecuta un programa de deteccion de ruta que permite descubrir y registrar dicha ruta. La figura 8 es una version altamente esquematica de un ordenador monitor 16. El ordenador 16 comprende un microprocesador 80 que puede acceder a la memoria 82 en la que se almacena codigo para su ejecucion por el procesador. En el presente caso, el codigo incluye el programa de descubrimiento de ruta. La memoria 82 almacena tambien un registro de ruta 81 cuando es creado por el programa de descubrimiento de ruta. El ordenador tiene una interfaz de usuario 84 que puede incluir un dispositivo de entrada de usuario tal como un raton o teclado y una pantalla para mostrar informacion a un usuario. En particular, tal como se describe con mas detalle, las alertas que siguen al programa de descubrimiento de ruta o informacion relativa al programa de descubrimiento de ruta pueden ser mostradas a un usuario en la interfaz de usuario 84. Las figuras 2a a 2c ilustran etapas de la ruta como se describira ahora.

A un nivel alto, el algoritmo usa la nocion de un “dispositivo de enfoque” que es el dispositivo que se esta consultando actualmente a donde enviana un paquete hipotetico a continuacion (es decir, de que interfaz enviana el paquete hipotetico). A partir del dispositivo fuente, el algoritmo viaja hacia el dispositivo terminal (es decir, el destino final del paquete) evaluando cada dispositivo de enfoque a su vez - si el dispositivo esta operando en la capa 3, se consulta cual interfaz (puerto de salida) utilizana para enviar paquetes enlazados para el salto siguiente en la capa 3 (NHL3); si el dispositivo esta funcionando en la capa 2, se consulta cual interfaz (puerto de salida) se usana para enviar paquetes enlazados para la capa 2 (MAC) de la capa 3 de la capa siguiente (NHL2). Utilizando la respuesta del dispositivo de enfoque junto con una topologfa de red, se puede determinar el siguiente dispositivo en la ruta. De esta forma, el algoritmo trabaja a lo largo de la capa 3, utilizando dispositivos de capa 2 para navegar entre los nodos consecutivos de la capa 3.

Antes de comenzar el algoritmo principal, se localizan el dispositivo fuente y el dispositivo terminal. Esto puede no ser sencillo y las tecnicas para lograr esto se discuten mas adelante.

Segun el algoritmo principal, se localiza el primer salto. La ruta se sembro y el recuento de bucle se establece en cero. El lfmite de bucle controla el numero de veces que se ejecuta un bucle de identificacion de ruta (discutido mas adelante).

Encontrar el primer salto en la capa 3

El primer salto se localiza encontrando el siguiente salto inicial (el salto siguiente desde el dispositivo fuente) en la capa 3 (NHL3). En la siguiente explicacion, el termino “consulta” se utiliza con frecuencia. Las consultas se generan y estructuran como se describe con mas detalle mas adelante. El proposito de una consulta es localizar una direccion de salto siguiente y un puerto de salida desde un dispositivo de enfoque al que se dirige la consulta. La direccion del 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 el NHL3 y el puerto de salida. Si no se encuentra ninguna ruta y el dispositivo de origen tiene un conmutador de acceso de capa 3, se consulta este conmutador de acceso de la capa 3 para el NHL3 usando la direccion IP de destino. Si eso no tiene exito, se consulta la puerta de enlace predeterminada en el dispositivo de origen para determinar el NHL3. Si no tiene exito, se realiza una consulta con la direccion IP de destino al conmutador de acceso para la puerta de enlace predeterminada. Si no se encuentra ninguna direccion del NHL3, esto se considera como un error. Esto no significa que el algoritmo ha fallado, sino que un punto de fallo en la ruta puede haber sido identificado en este punto. Alternativamente, puede haber otras razones por las que no se ha encontrado el NHL3.

Sembrar la ruta

Para sembrar la ruta, el dispositivo fuente se agrega a la ruta cuando se ha localizado. La interfaz de salida del dispositivo de origen se encuentra y se agrega a la ruta. Si se encuentra el NHL3 desde la tabla de enrutamiento en el dispositivo fuente, la interfaz de salida del dispositivo fuente para esta direccion del NHL3 se anade a la ruta. Como se explica mas adelante, se puede determinar la direccion de la capa 2 (NHL2) correspondiente a la direccion de la capa 3 (NHL3). Si no se encuentra un puerto de salida para el NHL3 desde la tabla de enrutamiento en el dispositivo de origen, se usa la tabla de reenvfo de capa 2 en el dispositivo de origen para el NHL2 para encontrar el

5

10

15

20

25

30

35

40

45

50

55

60

65

puerto de salida. Si se encuentra, entonces ese puerto de salida se agrega a la ruta.

Descripcion general del algoritmo de deteccion de ruta

La consulta enviada desde el ordenador monitor 16 al dispositivo fuente X se muestra como una flecha directa en la figura 2a, pero de hecho podna implementarse en la red de la figura 1 por el ordenador monitor 16 que emite un mensaje o paquete dirigido a la dispositivo fuente X. Como se ha explicado, la consulta solicita al dispositivo fuente el siguiente salto de IP (y puerto de salida) para la IP del terminal (IP de destino), que es la direccion de capa 3 del punto de destino Y. El objetivo es provocar que el dispositivo fuente X suministre una respuesta que incluye el NHL3 y el puerto de salida para el NHL3 (la direccion IP terminal). Vease la etapa S1 de la figura 3 y la figura 2a.

Como se ha explicado anteriormente, puede haber situaciones en las que el dispositivo fuente no puede proporcionar la informacion necesaria. Otras posibilidades mencionadas anteriormente para obtener el primer dispositivo de “enfoque” incluyen consultar el conmutador de acceso conectado para la informacion de enrutamiento de la capa 3 (en caso de que el conmutador de acceso sea un conmutador de capa 3), si falla el algoritmo consulta el conmutador de acceso conectado para una pasarela predeterminada y la direccion IP de la puerta de enlace predeterminada utilizada como el primer NHL3.

En la etapa S2, la siguiente direccion de la capa de salto 2 (MAC) se resuelve desde la direccion del NHL3 y el NHL2 se establece en esta direccion MAC. Esto se puede conseguir consultando una tabla de asignacion 91 que asigna direcciones L3 a L2. Una de estas tablas de asignacion es una tabla ARP (otras incluyen “asignacion directa” y descubrimiento del vecino). Este puede ser el dispositivo fuente ARP, el siguiente dispositivo ARP de salto L3 o ARP en cache global utilizando una consulta ARP descrita mas adelante. El puerto de salida identificado en la etapa S1 se anade al registro de ruta S1A. En la etapa S3, el conmutador de red de inicio (y el puerto) se encuentra utilizando la ubicacion del host final en cache (desde las consultas CAM del conmutador) y se establece como el dispositivo de enfoque. En la etapa S4, el conmutador de red de terminal se encuentra utilizando la ubicacion de host final almacenada en cache (desde las consultas CAM de conmutador). El interruptor de inicio se agrega al registro de ruta.

El metodo ahora esta listo para introducir un bucle de identificacion de ruta. En la etapa S5 se determina si el NHL2 es conocido. Si es asf, el bucle se desplaza a la etapa S5A. Si no es asf, el proceso lleva a cabo la etapa S5B para resolver el NHL2 mediante una consulta ARP en el dispositivo de enfoque o el dispositivo de NHL3. La generacion de una consulta para correlacionar una direccion de capa 3 con una direccion de capa 2 se discute con mas detalle mas adelante con referencia a la figura 7. En resumen, para el dispositivo que se esta consultando, se obtiene una lista de indices de interfaz (ifIndex) a partir de la topologfa de red o si se camina ifIndex desde la tabla de interfaz del propio dispositivo. Cada ifIndex para el dispositivo se combina con la direccion del NHL 3 para generar un conjunto de claves para incluir en la consulta al dispositivo. Por lo tanto, una consulta que contiene estas claves se formula y se transmite al dispositivo de enfoque. El dispositivo de enfoque produce cero o una respuesta satisfactoria.

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

Si NHL3 no esta en el dispositivo actual, en la etapa S6, el proceso envfa una consulta para encontrar la entrada FDB de la capa 2 para el NHL2 para obtener el puerto de salida. La generacion de una consulta en la capa 2 se discute mas adelante. Si tiene exito, se agrega el puerto de salida al registro de ruta (S6A), se utiliza la topologfa en cache 3 para encontrar el puerto y el dispositivo al final del enlace (S7), se anade el dispositivo a la ruta (S7A), y el dispositivo de enfoque se ajusta al dispositivo que acaba de estar situado en el extremo del enlace (L2 HOP). Las etapas S6A, S7 y S7A se pueden denominar L2 HOP. En este punto, consulte la figura 2b. En la etapa S5A, el dispositivo de enfoque es el dispositivo A. Este recibe una consulta para encontrar la entrada FDB de la capa 2 y devuelve el puerto de salida. El dispositivo que se determina que esta al final de ese enlace es el dispositivo B (figura 2c) que recibe una consulta con el NHL3 todavfa fijado a la direccion IP de destino.

Si no se encontro una entrada FDB de la capa 2, o si en S5A se determino que el NHL3 estaba alojado en el dispositivo de enfoque, en la etapa S8 se realiza una consulta de ruta para determinar si la ruta L3 se encuentra en el dispositivo de enfoque a la direccion IP de destino. La consulta de ruta puede ser una ruta unica o una consulta de ruta recursiva. Esto establece un IP de salto siguiente y una interfaz de salida. Si no se encuentra la ruta L3, se indica una ruta roto y el proceso se detiene - S8A. En la etapa S9 (L3 HOP) se anade la interfaz de salida de la tabla de enrutamiento a la ruta, el NHL3 se establece en la nueva direccion IP de salto siguiente y el proceso consulta el dispositivo para determinar la direccion de la capa 2 del NHL3. Si el NHL2 no puede ser resuelto, el NHL2 se establece en “desconocido”.

En la etapa S10, la direccion actual del NHL3 se compara con la direccion IP de destino. Si el NHL3 no es la IP de destino (es decir que el algoritmo de identificacion de ruta todavfa no esta en el segmento L2 final), en la etapa S11 la topologfa en cache se utiliza para encontrar el puerto y dispositivo al final del enlace, el dispositivo se anade a la ruta y el enfoque se establece en este dispositivo. El proceso entonces consulta (S12) si el dispositivo de enfoque es el dispositivo terminal. Si el dispositivo de enfoque no es el dispositivo terminal, el proceso vuelve a la etapa S5, pero

5

10

15

20

25

30

35

40

45

50

55

60

65

utilizando el NHL3 y el NHL2 establecidos en la etapa 9. Terminacion

El algoritmo finaliza cuando se alcanza el dispositivo terminal y se anaden el puerto de terminal y el servidor de destino a la ruta. Otras condiciones de terminacion impiden que el algoritmo haga un bucle indefinidamente. En cada iteracion de la ruta, una iteracion comienza colocando un indicador cambiado a falso y un indicador dirigido a falso. Cuando se produce un salto L2 (S7), el indicador cambiado se establece en verdadero; cuando se produce un salto L3 (S9), el indicador dirigido se establece en 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 utiliza para encontrar el dispositivo conectado y el puerto de entrada del dispositivo conectado. Para cada iteracion, se almacena la combinacion de:

“Dispositivo de enfoque NHL2, NHL3”.

Si el dispositivo de enfoque del NHL2 o NHL3 ha cambiado y se ha visto la nueva combinacion de “dispositivo de enfoque de NHL2, NHL3”, se produce un evento de bucle detectado y se detiene el bucle. Si no se ha alcanzado el lfmite de bucle y se ha producido el enrutamiento o la conmutacion (es decir, si los indicadores dirigidos o conmutados son verdaderos) y el dispositivo de enfoque no es igual al dispositivo terminal, itera de nuevo. Cada vez se evalua si se ha alcanzado el lfmite de bucle de iteracion. Si lo ha hecho, el algoritmo termina.

Cuando la iteracion cesa, 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 detenido, se informa de un error cuando el algoritmo de busqueda de ruta se habra terminado en una ubicacion inesperada. Si el dispositivo terminal es un conmutador de acceso, el puerto de salida del conmutador de acceso se anade desde el “destino localizado” (S4) a la ruta y el dispositivo de destino derivado del puerto de salida del conmutador de acceso se anade a la ruta. Si el dispositivo terminal es igual al dispositivo de destino, el algoritmo termina. El detalle del algoritmo sera discutido ahora con mas detalle.

Ejemplo Especifico

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

Observando nuevamente la red original de la figura 1, se puede ver que la primera parte del registro de ruta ilustrado en la figura 4 se deriva de la red de la figura 1, en la que se han utilizado letras correspondientes para designar los dispositivos seleccionados por el conmutador anterior o dispositivo de enrutamiento. Cuando el algoritmo de identificacion de ruta funcionaba, el dispositivo de enrutamiento B habfa determinado enviar el paquete al conmutador C. Sin embargo, sin el uso de la presente invencion, hubiera sido extremadamente diffcil trabajar en tiempo real. El dispositivo de enrutamiento B tema similarmente una opcion para encaminar el paquete al enrutador F en la red central. Consultando el dispositivo de enrutamiento B en tiempo real (o mas o menos tiempo real), basado en el paquete hipotetico dirigido al destino Y, el dispositivo de enrutamiento B devuelve la decision que habna tomado si hubiera llegado un paquete real con esa direccion. Comprobando que el dispositivo de enrutamiento B despachara el paquete al conmutador C y estableciendo entonces que el conmutador C ha conectado en el extremo lejano de su dispositivo de enrutamiento de puertos de salida D, C y D se han anadido al registro de ruta 81. De esta manera, el algoritmo de identificacion de paquetes ha pasado por la ruta que el paquete hipotetico habna tomado en el momento en que el algoritmo de identificacion de ruta consulta los dispositivos en la red. La caja adyacente al dispositivo de enrutamiento D indica los ajustes para el NHL3 y el NHL2, es decir, el NHL3 se ajusta a la direccion IP del dispositivo E que se ha establecido como el dispositivo extremo distante para el dispositivo de enrutamiento D basado en la tabla de enrutamiento actualmente activa en D, el NHL2 se ha establecido como la direccion MAC para el dispositivo E consultando el dispositivo D para su entrada ARP para el dispositivo E.

Topologia de la red

Como se menciono anteriormente, la topologfa de red incluye tanto la interconectividad del dispositivo de red como la ubicacion del host final. La topologfa de red 3 puede ser proporcionada por un servidor de topologfa que proporciona detalles de las conexiones puerto a puerto. De este modo, cuando se identifica un puerto de salida en un dispositivo, el puerto de entrada del dispositivo conectado se puede determinar utilizando una conexion puerto a puerto identificada en la topologfa. Tanto los puertos de salida como los de entrada pueden agregarse al registro de ruta. El servidor de topologfa tambien proporciona una CAM global, una ARP global y credenciales de dispositivo. Ademas, para cada dispositivo registrado en la topologfa es preferible una lista de mdice de interfaz (IfIndex) y una lista VLAN (red de area local virtual). Los dispositivos VLAN no se han discutido todavfa. Se discuten mas adelante en este documento. Cuando se devuelve una respuesta al ordenador monitor 16, el ordenador de monitorizacion

5

10

15

20

25

30

35

40

45

50

55

60

65

consulta la topologfa 3 en el orden siguiente cuando se manejan respuestas de capa 2. En este contexto, una respuesta de capa 2 es una respuesta que ha identificado un puerto de salida desde un dispositivo de conmutacion de capa 2. El orden de consulta es CDP, LLDP, STP y SONMP, IPv6 ND.

Localizar el dispositivo de origen

Como se menciono anteriormente, la ubicacion del primer dispositivo en la ruta (el dispositivo conectado al dispositivo de origen) no es necesariamente sencillo. En una realizacion, el ordenador monitor 16 implementa el algoritmo para intentar en primer lugar encontrar la fuente como un host conectado y si falla trata de encontrar la fuente como un dispositivo de red. Al intentar encontrar la fuente como un host conectado, consulta el dispositivo de origen para la direccion de la capa 2 (MAC) para la IP de origen. Esto se puede realizar de la misma manera que la consulta en un dispositivo de enfoque como se ha descrito anteriormente en la etapa S5B. Es decir, el proceso envfa una consulta para encontrar la entrada ARP para la direccion IP de origen.

Si no hay una direccion de capa 2 del dispositivo de origen, se consultara la tabla ARP en cache global del servidor de topologfa. En la realizacion descrita, se hace referencia a estas como tablas ARP, pero pueden utilizarse cualesquiera tablas que asignen las direcciones de la capa 3 a la capa 2. Si se encuentra una direccion MAC que corresponde a la direccion IP de origen, se consulta el servidor de topologfa para la ubicacion MAC de la IP de origen consultando las tablas de reenvfo de capa 2 en cache global en el servidor de topologfa para encontrar puertos que han visto trafico desde esta direccion MAC. Se espera que el servidor de topologfa devuelva una ubicacion MAC de origen unica eliminando varias coincidencias (el MAC de origen visto en muchos puertos), filtrando puertos marcados como troncos, puertos con un numero excesivo de MAC (las entradas FDB de los puertos de conmutador de acceso suelen tener una unica 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 encontrar la fuente como un host conectado, se intentan encontrar la fuente como un dispositivo de red. Esto se puede conseguir consultando el servidor de topologfa para todas las direcciones IP encontradas en todos los dispositivos de red administrados para ver si la direccion IP esta en un dispositivo de red. Si lo es, ese dispositivo de red se establece como el dispositivo de enfoque.

Localizar el dispositivo de destino

Consideraciones similares se aplican a la ubicacion del dispositivo de destino. En primer lugar, se intentan encontrar el dispositivo de destino como un host conectado y, si falla, se intenta encontrar el destino como un dispositivo de red. Para buscar el dispositivo de destino como un host conectado, se consulta el dispositivo de destino para su direccion de capa 2 o se consultan en el servidor de topologfa las capas de asignacion global de capa en cache 3 a la capa 2 (similarmente al dispositivo de origen discutido anteriormente). A continuacion, se consultan las tablas de reenvfo de la capa 2 en cache global en el servidor de topologfa para encontrar puertos que han visto el trafico de este MAC (de nuevo, como se ha descrito anteriormente con referencia a la ubicacion del dispositivo de origen).

Para encontrar el destino como un dispositivo de red si el anterior falla, se puede consultar el servidor de topologfa para todas las direcciones IP encontradas en todos los dispositivos administrados para ver si la direccion IP esta en un dispositivo de red. El dispositivo de red puede configurarse como el dispositivo terminal.

Utilidad por salto

Con el fin de implementar el algoritmo de identificacion de ruta, el ordenador monitor 16 ejecuta un programa informatico tal como se ha discutido. Este programa de computadora proporciona una utilidad que maneja consultas “por salto”. Es decir, el algoritmo de identificacion se basa en enviar una consulta desde el ordenador monitor a un dispositivo de enfoque y recibir desde el dispositivo de enfoque un puerto de salida que puede usarse para acceder a la topologfa. Esto no puede lograrse necesariamente mediante 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 de origen para el NHL3 y el puerto de salida, utilizando la direccion IP de destino. Si no se encuentra ninguna ruta, se 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 de origen para el NHL3). Si no se encuentra ninguna ruta, se pregunta al dispositivo de origen por la puerta de enlace predeterminada para el NHL3. Si no se encuentra ninguna ruta, se pregunta al primer dispositivo por una puerta de enlace predeterminada. Para consultar una tabla de enrutamiento para encontrar el NHL3 (como se ha descrito anteriormente), se encuentra una ruta para la direccion IP en cuestion (la direccion IP buscada) consultando el dispositivo de enrutamiento utilizando una tecnica de clave especulativa discutida mas adelante. Si se encuentra la ruta, pero no se especifica ningun puerto de salida, se devuelve la siguiente direccion IP de salto y se utiliza como el NHL3. Si la ruta se encuentra con una interfaz de salida ifIndex mayor que cero, el puerto de salida se devuelve con la direccion del NHL3 y el puerto de salida se agrega a la ruta. Si la ruta se encuentra con la interfaz de salida iflndex igual a cero, la utilidad se reitera colocando la IP buscada en el siguiente IP de salto (de la consulta anterior) y encontrando la ruta para la IP buscada consultando el dispositivo usando la clave especulativa discutida despues). Esto se repite hasta

5

10

15

20

25

30

35

40

45

50

55

60

65

que ifIndex devuelto no es cero.

La etapa de encontrar la ruta para la IP buscada utiliza la tecnica de clave especulativa para devolver una entrada de ruta. Si se encuentra la entrada de ruta, la utilidad encuesta para la siguiente direccion de salto de ipRouteNextHop.NetworkAddress. La utilidad tambien realiza sondeos para la interfaz de salida de ipRoutelflindex.NetworkAddress y encuesta para ipRouteType.NetworkAddress. Si ipRouteType es “directo”, la IP buscado se establece en el salto siguiente, ya que un tipo de ruta IP de directo indica que esta directamente conectado 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 utilizan varias rutas, por ejemplo, cuando un dispositivo es responsable del trafico de equilibrio de carga. Si se utiliza activamente una unica ruta, se debe determinar la ruta activa. Si se estan utilizando varias rutas, la ruta podna dividirse en este punto y el registro de ruta podna contener los resultados del algoritmo del buscador de rutas aplicado a cada ruta encontrada a partir de este punto. En muchos casos, las multiples opciones de enrutamiento en un dispositivo son indicativas de un dispositivo que esta enrutamiento inteligente basado en varias metricas. Estas metricas tambien pueden ser consultadas y devueltas para su grabacion en el ordenador monitor.

La utilidad tambien es responsable de encontrar el salto siguiente inicial en la capa 2 consultando la capa 3 a la tabla de asignacion 91 de la capa 2 en el dispositivo de enfoque. Si no se encuentra la direccion de la capa 2, donde el dispositivo de enfoque es el dispositivo de origen, la utilidad consulta el conmutador de acceso (si es un conmutador de capa 3, debe proporcionar una capa 3 a la capa 2). Si no se encuentra la direccion de la capa 2, la utilidad consultara las tablas ARP en cache globales del servidor de topologfa 3. Una consulta para una direccion de capa 2 en un dispositivo se lleva a cabo como se ha explicado anteriormente con referencia a la etapa S5B.

Si la direccion NHL 3 no esta en el dispositivo de enfoque, la utilidad sondea el dispositivo de enfoque para un puerto de salida para la direccion 2 de la capa 2 NHL2. La etapa de sondear el dispositivo de enfoque para el puerto de salida NHL2 incluye la consulta espedfica VLAN (red de area local virtual). Es decir, incluye la etapa de establecer en que VLANs participa el dispositivo de acuerdo con la topologfa 3 y como se registran en el dispositivo. Estas VLAN se utilizan para ayudar a encontrar entradas de la tabla de reenvfo para VLANs espedficas (los FDBs se dividen a menudo segun la VLAN con la que estan relacionados); por ejemplo, para el protocolo de arbol de expansion por VLAN (PVSTP) es necesario realizar las consultas FDB en el contexto de cada una VLAN para intentar encontrar una coincidencia).

Si el puerto de salida no se encuentra en el FDB de la capa 2 (utilizando una VLAN espedfica o la VLAN nativa), la utilidad intentara encontrar que interfaz se dirige hacia el NHL2 desde los registros ARP mediante encuesta para ipNetToMediaPhysAddress 71 (figura 7). Es decir, la utilidad intenta aprender de que interfaz se ha aprendido la relacion entre la capa 2 y la capa 3.

Una vez que la utilidad ha encontrado un puerto de salida usando la direccion de capa 2, agrega el puerto de salida al registro de ruta y utiliza el servidor de topologfa 3 para encontrar el puerto remoto conectado 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 encuentra ningun puerto remoto o el nombre del puerto de salida ordena el uso de puertos de capa superior o inferior, la utilidad comprueba si hay puertos de capa inferior o puertos de capa superior. Es decir, puede haber un escenario donde hay una asignacion de salidas de ruta virtual a puertos ffsicos. Para que el algoritmo de identificacion de ruta tenga exito, necesita identificar un puerto de salida ffsico para acceder al servidor de topologfa. En un escenario en el que la comprobacion de puertos de capa inferior revela la presencia de puertos de capa inferior, estos puertos de capa inferior se pueden utilizar como puertos de salida y se accede al servidor de topologfa para encontrar 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 independientes, cada una de las cuales se rastrea independientemente desde este punto en adelante.

Si se identifican puertos de capa superior, se utiliza el puerto de capa superior para el puerto de salida. El servidor de topologfa se utiliza para encontrar el puerto remoto conectado a este puerto de salida de capa superior.

Siguiente salto

Ajustar los indicadores dirigidos y conmutados a falso. Utilizando el servidor de topologfa o las consultas directas al dispositivo de enfoque, comprobar si el dispositivo de enfoque aloja o no la direccion IP del NHL3 en cualquiera de sus puertos. Si aloja la direccion IP del NHL3, la utilidad pasa a consultar la tabla de enrutamiento del dispositivo de enfoque para las rutas al IP de destino mediante la tecnica de clave especulativa. Si la utilidad localiza una ruta candidata, la siguiente direccion de la capa 2 NHL2 se ajusta mediante la consulta del dispositivo de enfoque (o las tablas ARP globales en cache) para la capa 3 a la capa 2 y el indicador dirigido se establece en verdadero. Si el

5

10

15

20

25

30

35

40

45

50

55

60

65

NHL3 es igual al IP de destino, entonces eso indica que la utilidad ha alcanzado el ultimo dispositivo de capa 3 mas cercano al destino, por lo que no hay necesidad de mover este dispositivo todavfa, ya que el siguiente salto seffa un salto de capa 2. Por lo tanto, la utilidad agrega los puertos de salida de la ruta del candidato a la ruta. Si el NHL3 no es igual al IP de destino, esto indica que no esta en el segmento final de la capa 2 y que el puerto de salida de la ruta candidata se agrega a la ruta.

Si no se produjo ningun enrutamiento durante esta iteracion (el indicador dirigido todavfa se ajusta en falso), la utilidad sondea el dispositivo de enfoque para un puerto de salida para la direccion 2 de la capa 2 del NHL2. La etapa de sondeo del dispositivo de enfoque para el puerto de salida del NHL2 incluye la interrogacion espedfica de VLAN (Red de area local virtual) (como se ha descrito anteriormente). Si el puerto de salida no se encuentra en el FDB de la capa 2 (utilizando una VLAN espedfica o la VLAN nativa), la utilidad intentara encontrar que interfaz se dirige hacia el NHL2 desde los registros ARP mediante encuestado para ipNetToMediaPhysAddress 71. Es decir, la utilidad intenta aprender de que interfaz se ha aprendido la relacion entre la capa 2 y la capa 3. Una vez que la utilidad ha encontrado un puerto de salida usando la direccion de capa 2, agrega el puerto de salida al registro de ruta y utiliza el servidor de topologfa 3 para encontrar el puerto remoto conectado al puerto de salida. Este puerto remoto se registra como el puerto de entrada en el dispositivo siguiente. Si se encuentra un puerto de salida utilizando consultas FDB o consultas ARP, el indicador cambiado se establece en verdadero.

Si, al consultar el servidor de topologfa, no se encuentra ningun puerto remoto o si el nombre del puerto de salida ordena el uso de puertos de capa superior o inferior, se realiza una comprobacion para puertos de capa inferior o superior como se describe anteriormente. Si se encuentra un puerto de salida, se agrega a la ruta, el dispositivo que contiene el puerto se agrega a la ruta y el dispositivo de enfoque se establece en el dispositivo remoto.

Esta etapa de “salto siguiente” se repite hasta que se alcanza un lfmite prescrito en el numero de iteraciones o la ruta llega a su fin (es decir, no se han producido conmutaciones ni enrutamiento).

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

Las figuras 11A a 11D muestran un diagrama de flujo del funcionamiento de la utilidad ejecutada en el ordenador monitor.

Equilibrador de carga

Como se menciono 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 asignacion de la IP virtual al grupo de servidores para el equilibrador de carga. Esto permite que se identifique el servidor ffsico asignado al equilibrador de carga. La ruta se conserva hasta la ruta “rafz” (hasta el dispositivo de equilibrio de carga). A continuacion, para cada direccion IP del servidor ffsico, se ejecuta una utilidad de deteccion de ruta adicional desde el equilibrador de carga a la direccion IP del servidor ffsico, con cada ruta adicional pendiente previamente con la ruta “rafz”.

Consulta de tabla de enrutamiento

Uno de los factores que hacen que el algoritmo de ruta sea particularmente eficiente es la capacidad de generar una consulta a un dispositivo de enrutamiento de manera eficiente, es decir, generar una consulta a la que el dispositivo de enrutamiento puede responder en un corto peffodo de tiempo sin una sobrecarga significativa. La figura 5 ilustra la estructura de una tabla de rutas lineales direccionable a traves de SNMP. Para establecer una ruta a un destino determinado, ipRouteDest es el mdice requerido en la tabla de rutas. Esto se denomina 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 siguiente salto (IP del siguiente salto) e ipRouteType 54 que define el tipo de entrada de enrutamiento (invalido/directo/indirecto). El acceso a la tabla normalmente requiere el conocimiento del ipRouteMask 56: esto permitiffa localizar una direccion IP de red espedfica. Sin embargo, como se puede ver en la figura 5, el propio IpRouteMask esta incrustado en ipRouteEntry y por lo tanto no se sabe que se configure en la consulta. Lo que se requiere es encontrar una coincidencia para:

<IP de interes> & <ipRouteMask.X> == <ipRouteDest.Z> para encontrar la clave IpRouteDest 48 que representa el mdice a la tabla.

Como observado por los inventores, solo hay 33 posibilidades para el IpRouteMask (/32.../0), que es 255.255.255.255, 255.255.255.254, 255.255.255.252, 0.0.0.0. Algunos de estos producen ID de red duplicadas para la misma direccion IP, debido al numero de ceros en la direccion IP. La figura 6 muestra 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.

5

10

15

20

25

30

35

40

45

50

55

60

65

Esto genera 12 valores unicos (etiquetados 32, 31, 29, 27, 25, 24, 23, 13, 12, 10, 6, 4). Por lo tanto, ahora solo es necesario hacer 12 consultas SNMP (que se pueden presentar en un solo paquete de consulta) para encontrar la ruta. Es decir, los 12 resultados se emparejan en la tabla de ruta del dispositivo de enfoque y cuando se encuentra una coincidencia los elementos requeridos ipRoutelfIndex, ipRouteNextHop y ipRouteType se recuperan y devuelven en una respuesta al ordenador monitor 16.

La reduccion en el numero de consultas requeridas para encontrar la ruta se denomina en este documento “codificacion especulativa” y permite la realizacion de consultas en tiempo real de la tabla de rutas de una manera muy eficiente.

Cuando se examinan tablas de enrutamiento reales, no es infrecuente que la ruta encontrada para una direccion IP dada no tenga una interfaz de salida valida y solo proporcione una direccion de salto siguiente. En estos casos, la siguiente direccion de salto se utiliza para una consulta posterior de la tabla de enrutamiento para tratar de obtener una interfaz de salida para esa siguiente direccion de salto. Esta reutilizacion de la siguiente direccion de salto se repite hasta que se obtiene una interfaz de salida.

De acuerdo con este enfoque, en una primera etapa, una consulta de ruta unica de busqueda utiliza una clave especulativa para encontrar una entrada de enrutamiento para la direccion IP especificada (IPx) como se acaba de esbozar. Si el ipRouteType asociado es “directo”, IPx (e ipRoutelfIndexx) se devuelven en una respuesta al ordenador monitor como el salto siguiente. Es decir, esta directamente conectado y por lo tanto no tiene capa 3 en el salto siguiente.

Si el ipRouteType asociado no es directo, se devuelven ipRouteNextHop e ipRoutelfIndex en respuesta al equipo del monitor.

En la expansion FindRecursiveRoute, la etapa FindSingleRoute se toma para la direccion IP requerida (IPx). Si no se encuentra ninguna ruta, se devuelve un fallo. Si se encuentra una ruta, pero no hay una interfaz de salida, se devuelve ipRouteNextHop. Si se encuentra la ruta y ipRoutelfIndex es mayor que cero, se devuelven ipRouteNextHop e ipRoutelfIndex. Si se encuentra la ruta y el ipRoutelfIndex es igual a cero, se toma una etapa FindRecursiveRoute posterior para la direccion IP de ipRouteNextHop, con los mismos cuatro resultados posibles.

Mientras que la clave especulativa es una tecnica particularmente buena para la consulta eficiente de grandes conjuntos de datos, su principal aplicacion es cuando se consultan datos que estan indexados con una clave derivada para la cual ya se conoce una clave parcial. Es por eso que es particularmente util en el contexto del analisis de la tabla de rutas SNMP y la consulta de tablas ARP de SNMp. Sin embargo, tambien se puede determinar el comportamiento rapido de reenvfo de dispositivos de red mediante otras tecnicas de consulta, como el acceso a la CLI y la API XML.

Consulta de ARP

Se hara referencia a continuacion a la figura 7 para describir una tecnica eficiente para consultar una tabla ARP usando la manipulacion especulativa. La generacion de una consulta se analiza mas detalladamente mas adelante con referencia a la figura 7. Para el dispositivo que se esta consultando, se obtiene una lista de indices de interfaz (Iflndex) a partir de la topologfa de red, o bien se puede recorrer lfIndex desde el propio dispositivo. Cada iflndex para el dispositivo se combina con la direccion del NHL 3 para generar un conjunto de claves para incluir en la consulta al dispositivo. Por lo tanto, una consulta que contiene estas claves se formula y se transmite al dispositivo de enfoque. El dispositivo de enfoque produce cero o una respuesta satisfactoria. La figura 7 ilustra un formato de tabla ipNetToMediaEntry que, en principio, permitina determinar la direccion MAC para cualquier direccion IP dada. Dado que no se puede encontrar una entrada unica para una direccion IP espedfica, a menos que se sepa de que interfaz se ha aprendido la entrada ARP, se utiliza la codificacion especulativa combinando la direccion IP con todos y cada uno de los iflndex del dispositivo. Es decir, cada clave de consulta se puede crear combinando la direccion IP con un iflndex. De esta manera, el numero de consultas SNMP es el numero de interfaces en el dispositivo que es tfpicamente mucho menos que el numero de entradas ARP en el dispositivo y por lo tanto es significativamente mas eficiente.

En clave especulativa, varias claves de consulta pueden estar contenidas en un unico mensaje de consulta. Tecnologias/Protocolos adicionales

El algoritmo de identificacion de ruta cuando se utiliza anteriormente proporciona una manera eficaz de identificar una ruta particular que es probable que un paquete o mensaje particular adopten a traves de la red de dispositivos interconectados que operan de acuerdo con protocolos de red generalmente conocidos. Las situaciones surgen donde por una razon u otra, el algoritmo de identificacion de ruta cumple con un desaffo particular. Algunos de estos desaffos se analizan a continuacion.

En algunos casos, la utilidad ejecutada en el algoritmo tiene que recorrer un segmento de red MPLS (conmutacion

5

10

15

20

25

por etiquetas multiprotocol). Esto lo logra encontrando la asignacion inicial de etiquetas (en el punto en que el trafico entra en el segmento MPLS) y el seguimiento a traves de la red MPLS saltando usando los detalles de salto por salto de etiqueta haciendo emerger, empujando y reenviando hasta que el trafico tenga su etiqueta final emergida y deje el segmento MPLS.

Otro desafto es atravesar los lfmites de NAT que se pueden lograr encuestando tablas NAT del dispositivo NAT. Esto puede requerir sondeo especulativo en tiempo real para un NAT dinamico, pero puede ser posible usar el sondeo de fondo para un NAT estatico.

Para los protocolos de tunel como IPSEC/GRE/SSL, etc., la utilidad comprueba una ruta directa de un extremo del tunel a otro (tfpicamente con un salto de capa desconocida 3 que representa todos los nodos intermedios). La utilidad comprueba ademas la informacion topologica espedfica del protocolo y comprueba en las tablas/interfaces de enrutamiento la presencia de saltos de encriptado/tunel.

Otro desafto es la virtualizacion. Es importante que el algoritmo identifique los puertos ffsicos de salida de modo que se pueda acceder a un dispositivo ffsico conectado al puerto de salida desde la topologfa. Muchas redes operan en diferentes capas de virtualizacion. Los conmutadores virtuales se pueden consultar usando API adicionales y para asegurar que el servidor de topologfa tenga informacion oportuna sobre la ubicacion del host final, puede ser necesario que el servidor de topologfa se integre con plataformas de administracion de virtualizacion para obtener actualizaciones sobre la reubicacion de maquina virtual para permitir un sondeo proactivo De la ubicacion del host final en los conmutadores virtuales afectados.

La utilidad negocia las tablas de enrutamiento y reenvto virtualizadas (VRF) consultando el reenvto IP apropiado (tabla de enrutamiento) requerido para un identificador de VRF espedfico. En SNMP, por ejemplo, esto puede hacerse utilizando cadenas de comunidad VRF contextualizadas.

Claims (26)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   REIVINDICACIONES

   1. Un metodo implementado por ordenador para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo fuente (X) hasta un dispositivo final de destino (Y), comprendiendo la ruta una secuencia conectada de dispositivos, comprendiendo el metodo en un ordenador monitor 16) conectados a la red:

   identificar un primer dispositivo conectado al dispositivo fuente (X);

   transmitir una primera consulta al primer dispositivo, incluyendo la consulta un identificador de destino y solicitando la identificacion de un puerto de salida (Po) para mensajes dirigidos al destino identificado por el identificador de destino cuando se recibe la consulta en el primer dispositivo;

   recibir un mensaje de resultado que identifica el puerto de salida (Po) e identificar un segundo dispositivo conectado al primer dispositivo basado en una topologfa de red (3) accesible por el ordenador monitor (16); y dirigir una consulta siguiente al segundo dispositivo y recibir un mensaje de resultado siguiente que identifica un puerto de salida (Po) desde el segundo dispositivo;

   caracterizado por que:

   identifica desde la topologfa de red (3) un tercer dispositivo conectado al segundo dispositivo, donde la ruta se identifica para incluir el primer, segundo y tercer dispositivo;

   comprendiendo ademas el metodo:

   identificar una primera ruta a traves de la red desde el dispositivo fuente (X) al dispositivo destino (Y) utilizando un primer conjunto de consultas en una primera vez, y rutas adicionales a traves de la red desde el dispositivo fuente (X) hasta el dispositivo destino final (Y) utilizando conjuntos posteriores de consultas; e identificar repetidamente la primera y segunda ruta y determinando el uso de las rutas.
2. 2. Un metodo de acuerdo con la reivindicacion 1, donde el identificador de destino en la primera consulta es una direccion de enrutamiento (L3) del dispositivo de destino final (Y).
3. 3. Un metodo de acuerdo con la reivindicacion 1, donde el identificador de destino en la primera consulta es una direccion de conmutacion (L2) derivada de una direccion de enrutamiento para el primer dispositivo.
4. 4. Un metodo de acuerdo con cualquier reivindicacion anterior, que comprende registrar un conjunto de dispositivos y puertos identificados para estar en la ruta en un almacen accesible al ordenador monitor (16) como un registro de ruta (81).
5. 5. Un metodo de acuerdo con cualquier reivindicacion anterior, donde el registro de ruta incluye puertos de entrada (Pi) identificados desde la topologfa de red (3) para dispositivos identificados.
6. 6. Un metodo de acuerdo con cualquier reivindicacion anterior, donde la consulta se transmite desde el ordenador monitor (16) al dispositivo que se esta consultando en un mensaje que se transmite a traves de la red.
7. 7. Un metodo de acuerdo con la reivindicacion 6, donde el mensaje toma la forma de al menos un paquete dirigido al dispositivo que se esta consultando.
8. 8. Un metodo de acuerdo con cualquier reivindicacion anterior, donde la consulta incluye una pluralidad de claves para consultar el dispositivo.
9. 9. Un metodo de acuerdo con la reivindicacion 8, donde una sola consulta que contiene dicha pluralidad de claves hace que se devuelva una respuesta con la identificacion de un puerto de salida (Po).
10. 10. Un metodo de acuerdo con cualquier reivindicacion anterior, donde el primer dispositivo se identifica basandose en la topologfa de red (3).
11. 11. Un metodo de acuerdo con la reivindicacion 10, donde el primer dispositivo conectado al dispositivo fuente (X) se identifica por la localizacion en la topologfa de red (3) de un puerto de red en el que se ha visto una direccion de conmutacion del dispositivo fuente (X), y a su vez, al dispositivo que forma parte de la topologfa de red (3) a la que pertenece este puerto de red.
12. 12. Un metodo de acuerdo con cualquier reivindicacion anterior cuando se utiliza en una red de dispositivos interconectados que incluyen dispositivos de capa 2 y capa 3 (14, 12), comprendiendo el metodo,

    despues de identificar el primer dispositivo conectado al dispositivo fuente (X):

    identificar un identificador de destino de la siguiente capa 3, a lo largo de la ruta hacia el dispositivo de destino final (Y); entonces

    5

    10

    15

    20

    25

    30

    35

    40

    45

    50

    55

    60

    65

    identificar un identificador de destino de la capa 2 del siguiente identificador de destino de la capa 3.
13. 13. Un metodo de acuerdo con la reivindicacion 12, donde;

    si el primer dispositivo aloja el siguiente identificador de destino de la capa 3, enviando luego un mensaje de consulta al primer dispositivo que contiene el identificador de destino del dispositivo de destino final (Y), con el fin de determinar un nuevo identificador de destino de la capa 3 junto con un nuevo identificador de destino de la capa 2 de este nuevo identificador de destino de la siguiente capa 3 y el puerto de salida (Po) para mensajes dirigidos a este nuevo identificador de destino de la siguiente capa 3.
14. 14. Un metodo de acuerdo con la reivindicacion 12, donde si el primer dispositivo no aloja al siguiente identificador de destino de la capa 3, enviando luego un mensaje de consulta al primer dispositivo para determinar el puerto de salida (Po) para mensajes dirigidos al identificador de destino de la capa 2 del siguiente identificador de destino de la capa 3, identificar un nuevo dispositivo de salto siguiente conectado al puerto de salida (Po) basado en una topologfa de red (3) accesible por el ordenador monitor (16).
15. 15. Un metodo de acuerdo con las reivindicaciones 13 y 14, donde las etapas de las reivindicaciones 15 y 16 se repiten con cada nuevo dispositivo de salto siguiente en lugar del primer dispositivo hasta que el nuevo dispositivo de salto siguiente es el dispositivo de destino (Y).
16. 16. Un metodo de acuerdo con la reivindicacion 12, que comprende:

    enviar una consulta al dispositivo de origen (X), que contiene el identificador de destino de la capa final 3, y averiguar a partir de la respuesta el siguiente identificador de destino de la capa 3.
17. 17. Un metodo de acuerdo con la reivindicacion 16, donde si el dispositivo fuente (X) no responde a la consulta, enviar una primera consulta al primer dispositivo, que contiene el identificador de destino de la capa final 3, y verificar a partir de la respuesta el siguiente identificador de destino de la capa 3; entonces

    si el primer dispositivo no proporciona la identificacion del siguiente identificador de destino de la capa 3 a traves de la primera consulta, enviar una consulta subsiguiente al dispositivo de salto siguiente para determinar una pasarela predeterminada del primer dispositivo y utilizar el identificador de destino de la capa 3 de la pasarela predeterminada como siguiente identificador de destino de la capa 3.
18. 18. Un metodo de acuerdo con la reivindicacion 12, que comprende:

    enviar una consulta al dispositivo fuente (X), que contiene el siguiente identificador de destino de la capa 3, y averiguar a partir de la respuesta el identificador de destino de la capa 2 del siguiente identificador de destino de la capa 3.
19. 19. Un metodo de acuerdo con la reivindicacion 18, donde si la fuente (X) no responde a la consulta, enviar una consulta al primer dispositivo, que contiene el siguiente identificador de destino de la capa 3, y verificar a partir de la respuesta el identificador de destino de la capa 2 del siguiente Identificador de destino de la capa 3; entonces

    si el primer dispositivo no proporciona el identificador de destino de la capa 2 del siguiente identificador de destino de la capa 3, determinar a continuacion el identificador de destino de la capa 2 del siguiente identificador de destino de la capa 3 utilizando una tabla de correlacion (91).
20. 20. Un metodo de acuerdo con cualquiera de las reivindicaciones 12 a 19, donde cada vez que se identifica un dispositivo de salto siguiente usando la topologfa de red (3), tanto el dispositivo de salto siguiente como el puerto de entrada en el que recibiran mensajes del dispositivo anterior en la ruta, se registran como parte de la ruta junto con el dispositivo anterior y su puerto de salida (Po).
21. 21. Un metodo de acuerdo con la reivindicacion 18, donde la tabla de correlacion (91) asigna las direcciones de la capa 3 a las direcciones de la capa 2.
22. 22. Un metodo de acuerdo con cualquier reivindicacion anterior, donde cada consulta se genera para una tabla de reenvfo de trafico en el dispositivo al que se transmite la consulta, utilizando la consulta por lo menos una de un conjunto de claves que se han generado combinando el identificador de destino con una pluralidad de indices incrustados de la tabla de reenvfo de trafico.
23. 23. Un sistema informatico de monitorizacion (16) para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo fuente (X) a un dispositivo destino (Y), comprendiendo el sistema informatico:

    una interfaz (86) conectada a la red para transmitir consultas y recibir respuestas;

    un procesador (80) operable para ejecutar una herramienta de identificacion de ruta que lleva a cabo el metodo de cualquiera de las reivindicaciones 1 a 22;

    un primer medio de almacenamiento para almacenar el registro de ruta (81); y

    un segundo medio de almacenamiento que almacena la topologfa de red (3).
24. 24. Un producto de programa informatico que comprende instrucciones legibles por ordenador que cuando son ejecutadas por un procesador (80) implementan el metodo de cualquiera de las reivindicaciones 1 a 22.

    5
25. 25. Un medio legible por ordenador adaptado para almacenar el producto de programa informatico de acuerdo con la reivindicacion 24.
26. 26. Una senal transmisible adaptada para transportar el producto de programa informatico de acuerdo con la 10 reivindicacion 24.