ES2709977T3 - Bucles de ejecución - Google Patents

Abstract

Un método para identificar una ruta desde un dispositivo de origen (X) a un dispositivo terminal en una red de dispositivos interconectados, que comprende: identificar como dispositivo de enfoque un primer dispositivo conectado al dispositivo fuente (X); transmitir una primera consulta de identificación de ruta al primer dispositivo, incluyendo la consulta un identificador de destino y solicitar la identificación de un puerto de salida para los mensajes dirigidos al destino identificado por el identificador de destino cuando la consulta se recibe en el primer dispositivo; y recibir un mensaje de resultado que identifica el puerto de salida e identifica como dispositivo de enfoque un segundo dispositivo conectado al primer dispositivo basado en una topología de red a la que puede acceder el ordenador del monitor (16); dirigir una consulta de identificación de ruta adicional al segundo dispositivo y recibiendo un mensaje de resultado siguiente que identifica un puerto de salida desde el segundo dispositivo; y identificar desde la topología de la red un tercer dispositivo conectado al segundo dispositivo, donde la ruta se identifica para incluir el primer, segundo y tercer dispositivos; donde la formulación de la primera y otras consultas se lleva a cabo mediante un programa informático de bucle de acuerdo con las siguientes etapas: recibir en una unidad de ejecución en un ordenador de monitor (16) que tiene una ruta de consulta a los dispositivos interconectados un conjunto de variables de estado que definen un estado de entrada, donde una de las variables de estado del conjunto define una secuencia ordenada de opciones de bucle (C, S, R, A, c, r); registrar el estado de entrada en una unidad de almacenamiento; en la unidad de ejecución (16), ejecutar una primera opción de bucle en la secuencia ordenada de opciones de bucle (C, S, R, A, c, r) en el estado de entrada, utilizando como parámetros al menos una de las otras variables de estado en el conjunto de variables de estado, donde la ejecución de la primera opción de bucle comprende cancelar la primera opción de bucle de la secuencia ordenada, realizar etapas de procesamiento utilizando al menos una de las otras variables de estado y determinar si alguna de estas variables de estado se ha alterado como resultado de las etapas de procesamiento, donde: si ninguna de las variables de estado ha cambiado, ingresar la siguiente iteración de bucle con un estado de entrada en el cual la primera opción de bucle se cancela desde la secuencia ordenada de opciones de bucle, revelando una nueva opción de primer bucle que se ejecutará con las variables no alteradas, y si al menos una de las variables de estado ha cambiado, restablecer la opción de primer bucle cancelado en la secuencia ordenada para proporcionar una secuencia ordenada original de opciones de bucle e ingresar una iteración de bucle siguiente con un estado de entrada definido por la(s) variable(s) de estado alterado y la secuencia original ordenada de opciones de bucle, por lo que cada iteración de bucle siguiente recibe un nuevo estado de entrada, de las variables de estado alteradas, donde una de las variables de estado es el dispositivo de enfoque para recibir la consulta de identificación de ruta generada por la opción de bucle ejecutada en el ordenador de monitor; otra de las variables de estado es una dirección de red de enrutamiento como identificador de destino y otra de las variables de estado es una dirección de conmutación como identificador de destino, y una de las opciones determina si la dirección de enrutamiento del estado de entrada está en el dispositivo de enfoque del estado de entrada y, si no, utiliza una tabla de asignación para traducir la dirección de enrutamiento para proporcionar una nueva dirección de conmutación como una variable de estado alterada.

Description

DESCRIPCION

Bucles de ejecucion

La presente invencion se refiere a la ejecucion de bucles de programa de ordenador, particularmente, pero no exclusivamente en el contexto de la identificacion de una ruta en una red de dispositivos interconectados.

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 informatizadas 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.

Un ejemplo de este tipo se muestra en el documento US 2014/036729 A1. 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, enrutadores, 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 en un modelo complejo de la topologfa 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: Tecnolog^a 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

Tecnolog^as de superposicion de red (por ejemplo, MPLS, 802, 1q VLAN), etc.

Tecnolog^as 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.

Sumario

En el nuevo enfoque aqu 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.

Los inventores han desarrollado un proceso de ejecucion de bucle para permitir la implementacion eficiente de un proceso de identificacion de ruta. Sin embargo, el proceso de ejecucion del bucle tiene una aplicabilidad mas amplia.

Es aplicable a la resolucion de problemas donde el problema tiene varias etapas y cada etapa puede resolverse mediante una gama de tecnicas donde las tecnicas estan ordenadas en terminos de precision/conveniencia y no se sabe a priori que tecnica debe ser aplicada en cada etapa.

Segun un aspecto de la presente invencion, se proporciona un metodo para ejecutar un programa informatico de bucle que comprende: recibir en una unidad de ejecucion un conjunto de variables de estado que definen un estado de entrada, donde una de las variables de estado define una secuencia de opciones de bucle; registrar el estado de entrada en una unidad de almacenamiento; en la unidad de ejecucion, ejecutar una primera opcion de bucle en la secuencia ordenada de opciones de bucle en el estado de entrada, usando como parametros al menos una de las otras variables de estado en el conjunto de variables de estado, donde ejecutar la primera opcion de bucle comprende cancelar la primera opcion de bucle de la secuencia ordenada, realizar etapas de procesamiento utilizando al menos una variable de estado y determinar si alguna de las variables de estado se ha alterado como resultado de las etapas de procesamiento, donde: si ninguna de las variables de estado se ha alterado, se ingresa una siguiente iteracion de bucle con un estado de entrada donde la primera opcion de bucle se cancela desde la secuencia ordenada, revelando una nueva opcion de primer bucle, y; si al menos una de las variables de estado ha cambiado, restablece la opcion de primer bucle cancelado en la secuencia ordenada e ingresa a la siguiente iteracion del bucle con un estado de entrada definido por la(s) variable(s) de estado alterada(s) y la secuencia ordenada original, por lo que cada bucle siguiente de la iteracion recibe un nuevo estado de entrada.

El metodo es particularmente util en un metodo implementado por ordenador para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo de origen a un dispositivo de destino, comprendiendo la ruta una secuencia de dispositivos conectados, comprendiendo el metodo en un monitor de ordenador 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 solicitar la identificacion de un puerto de salida para los mensajes dirigidos a un destino identificado por el identificador de destino cuando la consulta se recibe en el primer dispositivo; recibir un mensaje de resultado que identifica el puerto de salida e identifica el segundo dispositivo conectado al primer dispositivo en funcion de una topologfa de red a la que puede acceder el monitor de ordenador; y dirigir una proxima consulta al segundo dispositivo y recibir un mensaje de resultado siguiente que identifica un puerto de salida del segundo dispositivo; e identificar desde la topologfa de la red un tercer dispositivo conectado al segundo dispositivo, y asf sucesivamente, donde la ruta se identifica para incluir el primer, el segundo y los dispositivos posteriores.

Cuando se usa el metodo de ejecucion de bucle, la formulacion de los mensajes de consulta a los dispositivos puede realizarse mediante la misma opcion repetida o diferentes opciones, ejecutadas en iteraciones de bucle sucesivas. El proceso de identificacion de rutas utiliza un nuevo enfoque 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" - expeditamente 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 puede ser de valor si no se conoce que dispositivo e interfaz estan conectados a esa 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.

Asf, 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 enrutador, 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 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 inmediata 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 (indicado en el presente documento como “salto”). 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, SLA (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").

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.

De acuerdo con otro aspecto de la presente invencion, se proporciona un sistema informatico para ejecutar un programa informatico de bucle, comprendiendo el sistema informatico un procesador operable para ejecutar un metodo de ejecucion de bucle y medios de almacenamiento para registrar el estado de entrada.

El sistema se puede utilizar como un sistema informatico de supervision para identificar en una red de dispositivos interconectados una ruta a traves de la red desde un dispositivo de origen a un dispositivo de destino, comprendiendo el sistema informatico: una interfaz conectada a la red para transmitir consultas y recibir respuestas; un segundo medio de almacenamiento para almacenar un registro de ruta; y un tercer medio de almacenamiento para almacenar una topologfa de red.

Un aspecto adicional de la presente invencion proporciona un producto de programa informatico que comprende instrucciones legibles por computadora que, cuando se ejecutan por un procesador, implementan el metodo como se define aquf

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 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 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 enrutador 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 anteriores;

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 enrutadores y conmutadores. El nucleo de la red incluye una pluralidad de dispositivos de red. Con respecto 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 tfpicamente 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 donde el paquete debera ser enviado. Como ya se ha explicado anteriormente, segun el modelo OSI, los identificadores para los 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 aqrn. 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 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 donde 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 aqrn 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 etapas 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 y el dispositivo terminal (es decir, el ultimo destino del paquete) el algoritmo adopta sucesivas opciones en un bucle para evaluar cada dispositivo de enfoque. De acuerdo con dos de las opciones (“S” y “R”) 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 (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.

Otras opciones se pueden implementar en el bucle como sea necesario, como se describe a continuacion.

Como parte del proceso de preparacion (definido posteriormente), se localizan el dispositivo de fuente y el dispositivo terminal. Esto puede no ser directo y tecnicas para conseguir esto se describen posteriormente.

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).

A continuacion, se hara referencia a la figura 12 para describir el proceso de iteracion en bucle. La entrada en el bucle principal se indica en la parte superior de la figura 12 mediante la flecha de entrada 4. La flecha de entrada 4 indica el estado al final de los procesos de preparacion que se describiran mas adelante. El estado de entrada comprende:

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

Estos elementos se describiran en mas detalle y se establecen por los procesos de preparacion que se describiran mas adelante. Estos se denominan a continuacion como "variables de estado". La variable de estado titulada "opciones" tiene una secuencia ordenada de opciones de bucle. En el presente ejemplo, la secuencia ordenada comprende CSRAcr.

La variable de estado, titulada "VLAN" es el identificador de la red de area local virtual (numero) de la VLAN con la cual el paquete hipotetico esta etiquetado actualmente en este punto en la ruta.

En la etapa L01 del bucle, la primera opcion (cabeza de lista) se selecciona y se ejecuta. Estas opciones se describen mas adelante. Despues de la ejecucion de la opcion, el proceso vuelve a regresar al punto L02 y se crea un nuevo estado (L03), siguiendo las etapas de procesamiento implementadas por la cabeza de la opcion de la lista. Se determina (L04) de si este estado se ha producido antes, y si no, el estado se almacena (L05). Si el estado se ha producido antes, se genera un informe de "bucle descubierto" y el lfmite del bucle se establece en cero, lo que tendra por efecto la ruptura del bucle.

En la etapa L07, se disminuye el lfmite de bucle. Si el lfmite de bucle es menor que 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 establece una condicion de "terminacion es igual a verdadero". En la etapa L08, se realiza una comprobacion de la condicion de terminacion, y si la condicion de terminacion es verdadera, termina el bucle principal. De lo contrario, vuelve al punto de entrada de bucle principal usando el nuevo estado que fue creado en la etapa L03.

Observese que, en la ejecucion de cada opcion en una iteracion del bucle, la primera etapa en la ejecucion de la opcion es eliminar esa opcion de la secuencia ordenada en la variable de estado de opciones.

Al final de las etapas de procesamiento de la opcion, puede ser que esa opcion se restablezca de nuevo en la secuencia, o puede haber sido eliminada de forma permanente, dependiendo de la opcion y de los resultados de las etapas de procesamiento.

Observese tambien que, en la ejecucion de las etapas de procesamiento de una opcion, las otras variables de estado (dispositivo de enfoque, n HL3, NHL2, VLAN) pueden alterarse de forma individual o en total. La alteracion de cualesquiera variables de estado resulta en un nuevo estado, que puede constituir un nuevo estado de entrada para una siguiente iteracion del bucle.

Ahora se hara referencia a la figura 13 para describir la segunda parte del proceso de bucle principal. En la etapa L09 se determina si se ha alcanzado o no el dispositivo terminal esperado. Si lo ha hecho, en la etapa L10 se determina si el terminal tiene un conmutador de acceso conectado al IP del servidor. Si no lo es, entonces el proceso termina despues de que se indica un descubrimiento de ruta completa con exito y devuelve una ruta completa. Si el dispositivo terminal es un conmutador de acceso conectado a la IP del servidor, se anade la conexion del puerto de acceso y la IP del servidor a la ruta, y entonces el proceso pasa a completar el descubrimiento de la ruta con exito y devuelve una ruta completa antes de terminar deteniendose.

Si en la etapa L09 se determina que el dispositivo terminal esperado no se ha alcanzado, entonces en la etapa L14, se pregunto si NHL3 es la IP del servidor o no. Si no lo es, entonces se determina que el descubrimiento de la ruta completa no ha tenido exito, y una ruta parcial se devuelve antes de la detencion. Si NHL fue la IP del servidor, esto indica que el proceso en el segmento L2 final, por lo que el proceso puede saltar hasta el destino mediante el incremento del contador de segmentos de salto y estableciendo el dispositivo de enfoque en NHL3.

La figura 14 ilustra la Opcion C. En la primera etapa C1, la opcion se elimina de la secuencia en la variable de opciones. En la etapa C2, se realiza una comprobacion para una unica interfaz de red cuya direccion coincide con el destino (IP del servidor). Si es asf, esto indica que el algoritmo ha llegado a la porcion de red de conmutacion final, y NHL3 se establece en la IP del servidor. En la etapa C3, el dispositivo de enfoque se consulta para encontrar la entrada ARP para la IP del servidor, y NHL2 se establece en el 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 mediante SNMP a la tabla ARP en el dispositivo de enfoque, o si no se encuentra, se consulta el sistema de gestion de la red ARP en cache. Estas consultas son de acuerdo con tecnicas mas plenamente descritas mas adelante.

En la etapa C2, si la comprobacion para la interfaz unica para la IP del servidor de destino falla, no existe ninguna interfaz unica identificada. Las variables de estado no se actualizan en absoluto. En este caso, todo lo que hemos hecho es la opcion "C" evaluada (y descartada) y parecio que es improductiva.

La figura 15 ilustra opcion S. Segun la etapa S101, la opcion S se elimina de la secuencia ordenada. En la etapa S102, se realiza una consulta al sistema de gestion de red o mediante consultas SNMP al dispositivo de enfoque para encontrar si el dispositivo de enfoque aloja NHL3. Si NHL3 esta en el dispositivo de enfoque, el proceso vuelve al punto de retorno del bucle principal (S104). Si la direccion de enrutamiento NHL3 no esta en el dispositivo de enfoque, se determina si se establece el NHL2 de la direccion de conmutacion, y el dispositivo de enfoque se consulta en la tabla de asignacion (ARP) para el NHL2 dado el NHL3. Las consultas se realizan como se describe mas completamente mas adelante. En la etapa S106 se determina si se establece o no el indicio de VLAN indirecto. Indicios de VLAN se discutiran mas adelante. Si no, se determina una lista de las VLAN en el dispositivo de enfoque, ya sea desde el dispositivo de enfoque o desde el sistema de gestion de red. Una VLAN se selecciona de la lista y una busqueda de la entrada de la base de datos de reenvfo se realiza utilizando el dispositivo de enfoque, NHL2 y VLAN. La busqueda de la entrada de base de datos de reenvfo que se ilustra en la etapa S109 se muestra en un diagrama de flujo en la figura X. Volviendo a la etapa S106, si el indicio de VLAN se establece a continuacion, el proceso pasa directamente a la etapa 110, que es una busqueda de la entrada FDB como en la etapa S109 usando el indicio de VLAN que la VLAN ha consultado dentro de la FDB. En la etapa S112 (tambien S111), se determina si hay o no hay una entrada encontrada en la base de datos de reenvfo. Si la hay, el proceso pasa a la segunda parte de la opcion S que se muestra en la figura 16 (flecha de entrada 5). Si despues de la etapa S111, no se encuentra ninguna entrada FDB, se entra en un bucle de VLAN hasta que se determina si existe una entrada FDB o que el proceso debe 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 describe, anteriormente, si se encuentra una entrada de base de datos de reenvfo, esto indica el puerto de salida para la ruta S115. Esto se puede utilizar para obtener el siguiente dispositivo conectado desde la topologfa de la red, como se muestra en la etapa S117, y se describe mas completamente mas adelante. La etapa S116 es la etapa de obtener un indicio de VLAN que se muestra en la figura 21 y se describira mas adelante.

La etapa S117 se muestra en la figura 22, que es un diagrama de flujo que ilustra el proceso para la obtencion del puerto conectado y, por lo tanto, el dispositivo conectado posterior del sistema de gestion de red basado en el puerto de salida regresa desde la base de datos de reenvfo: Si en la etapa S118 se encuentra el puerto conectado, el puerto conectado y dispositivo conectado se anaden a la ruta identificada (etapa S119) y en la etapa S120 el dispositivo de enfoque se cambia al dispositivo conectado. En la etapa S121, las opciones de bucle se restablecen a CSRAcr. A continuacion, el procesador vuelve al bucle principal en la etapa S122. Volviendo a la etapa S118, si no se encuentra el puerto conectado, el proceso salta adelante a NHL3, incrementando un contador de segmento de salto 89 (figura 8) y cambiando el dispositivo de enfoque a NHL3. El contador de segmento de salto se implementa en el ordenador de administracion de hardware, firmware o software y permite a los segmentos de la ruta que se distingan por ser saltados cuando esta claro que el siguiente dispositivo conectado no puede determinarse facilmente a partir de las etapas de proceso anteriores. En la etapa S124, se determina si el dispositivo de enfoque no es el destino (IP del servidor). Si no es asf, las opciones de bucle se restablecen a CSRAcr en la etapa S125. Si el dispositivo de enfoque es el servidor de destino, en la etapa 126 se determina si el destino esta en un conmutador de acceso conocido, y si es asf, NHL 3 se establece en la direccion del conmutador de acceso al servidor. Despues de configurar las opciones de bucle en la etapa S125, en la etapa S128 el dispositivo de enfoque realiza una consulta para NHL2 utilizando la direccion NHL3 que fue creada en la etapa S127, mediante la consulta de la tabla ARP del dispositivo de enfoque o un NMS.

Debe tenerse en cuenta que la opcion S incluye la etapa de eliminarlo de las opciones disponibles en la etapa S101, y luego restablecerse de nuevo en las opciones disponibles en la etapa S121 y la etapa S125 en base a los resultados de las etapas de procesamiento.

Ahora se hara referencia a la figura 17 para describir las opciones R y r. Cada una de esas opciones comienza con la eliminacion de esa opcion de la secuencia ordenada en la opcion variable de la etapa R1, r1. En la etapa R2, r2, un proceso es instigado a buscar la ruta a la IP de destino (IP del servidor) utilizando un proceso de busqueda de rutas iterativo que se ilustra en la figura P. En la opcion R, el proceso opera donde no hay ruta por defecto permitida (ruta por defecto permitida es igual a falso). En la opcion R, el proceso permite una ruta por defecto (la ruta por defecto permitida es igual a verdadero). Si no se encuentra ninguna ruta, etapa R3, el procesador vuelve al bucle principal. Si se encuentra una ruta, a continuacion, se envfa una consulta al dispositivo de enfoque mediante un NHL3 candidato, que se ha determinado a partir de la tabla de enrutamiento desde la que se encontro la ruta. Esta consulta es la tabla ARP del dispositivo para determinar un NHL2 candidato que corresponde al NHL3 candidato. Si no se encuentra ningun NHL2 candidato, el proceso se mueve al punto de entrada 7 para la segunda parte de la opcion R/r. Si un NHL2 candidato se encuentra a partir de la consulta ARP, a continuacion, se realiza una comprobacion en la etapa R8 para determinar si el NHL2 candidato es el mismo que el NHL2 que se registra como la variable de estado en el estado de la entrada para el proceso R/r. Si son iguales, entonces el proceso pasa al punto de entrada 6. Si no lo son, siguiendo la etapa R8, si el NHL2 candidato no es el mismo que el estado de entrada NHL2, a continuacion, NHL3 se establece en siguiente salto de IP de la ruta candidata, y ⁿ HL2 se establece en el NHL2 candidato. En la etapa R10 se determina si las consultas de la tabla de enrutamiento en R2 y r2 tambien proporcionan un puerto de salida. Si es asf, el proceso prosigue al punto de entrada 6. Si no es asf, las opciones se restablecen a CSRAcr en la etapa R11. La figura 18 ilustra el punto de entrada 6 en la parte superior de la figura. En la siguiente etapa R12, se determina si la tabla de enrutamiento proporciona un puerto de salida. Si no, el proceso vuelve al bucle principal. En la etapa R13, el proceso de obtener un indicio de VLAN se realiza de acuerdo con la figura 21 y se describira posteriormente.

A continuacion, el proceso de obtener el puerto conectado se realiza como se ilustra en la figura 22. En la etapa R15, se determina si se encuentra o no el puerto conectado. Si lo es, 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 restablecen en CSRAcr. Si no se encuentra un puerto conectado, no se hace nada en esta etapa. El proceso pasa a la etapa R20, donde se determina si NHL3 se ha actualizado. Si no es asf, el proceso vuelve al bucle principal. Si es asf, el dispositivo de enfoque anterior se consulta para el candidato NHL2, dado el candidato NHL3 de la tabla de enrutamiento. Si, despues de esta etapa, la NHL2 se ha resuelto, el proceso vuelve al bucle principal. Si no es asf, el nuevo dispositivo de enfoque se consulta para el candidato NHL 2 dado el candidato NHL3.

Se hara referencia a la opcion c con referencia a la figura 19. En la primera etapa c1, c se elimina de las opciones en la variable de estado. En la etapa C2 se realiza una comprobacion para una unica interfaz, cuya direccion de red coincide con la direccion de red NHL3. Si no se encuentra una interfaz unica, el proceso vuelve al bucle principal. Si se encuentra una interfaz unica, y es un nombre de interfaz de salida, se realiza el proceso de indicio de VLAN que se describira con referencia a la figura 21. Despues de la etapa c4, se obtiene el puerto conectado empleando el proceso de obtener el puerto conectado que se muestra en la figura 22.

En la etapa C7, se determina si se encuentra un puerto emparejado. Si es asf, el puerto de salida, el puerto emparejado y el dispositivo emparejado se anaden a la ruta y el dispositivo de enfoque se fija en el dispositivo emparejado. Las opciones disponibles se restablecen a CSRAcr en C8. Si ningun puerto emparejado se encuentra en la etapa C7, el proceso vuelve al bucle principal.

Ahora se hara referencia a la figura 20 para describir la Opcion A. En la etapa A1, la opcion A se retira de la secuencia de opcion en la variable de estado. En la etapa A2, se encuentra la entrada ARP SNMP para asignacion de NHL3 a NHL2. Si no se encuentra ninguna asignacion, el proceso vuelve al bucle principal.

Si se encuentra una asignacion, el proceso utiliza SNMP para encontrar el iflndex de la interfaz desde la que se aprendio la relacion. En la etapa a 5, se determina si una interfaz unica se ha encontrado o no. Si no es asf, el proceso vuelve al bucle principal. Si es asf, el proceso pasa a la etapa A6, donde se determina si hay un nombre de interfaz de salida disponible. Si lo hay, el proceso de indicio de VLAN es instigado como se describira con referencia a la figura 21. Luego, en A8, se instiga el proceso de obtener el puerto conectado, como se ilustra en la figura 22. Si como resultado del proceso de obtener el puerto conectado se encuentra un puerto emparejado, se anade el puerto de salida a la ruta, el puerto emparejado y el dispositivo emparejado se anaden a la ruta y el dispositivo de enfoque se fija en el dispositivo emparejado. Ademas, las opciones disponibles se restablecen a CSRAcr. Si no se encuentra ningun puerto emparejado, el proceso vuelve al bucle principal.

Ahora se hara referencia a la figura 21 para explicar el proceso de indicio de VLAN. Este proceso se utilizo en la Opcion A en la etapa A7, en la Opcion C en la etapa c5 , en la Opcion R/r en la etapa R13 y en la Opcion S en la etapa S116. Ademas, se utiliza en uno de los procesos de preparacion que aun no ha sido abordado. El proceso comienza en la etapa VL1 con un nombre de puerto de acceso. En la etapa VL2 se determina si el nombre esta en la forma de "VL un numero", y si el numero se extrae y se almacena como un indicio de VLAN en la etapa VL3. Si no es asf, entonces en el sistema de gestion de la red se solicita una lista de todas las VLAN en la interfaz. La etapa VL5 comprueba cualesquiera VLAN en conflicto. Si no hay ninguna, entonces la unica VLAN se almacena como un indicio de VLAN en la etapa VL6. Si hay VLAN en conflicto, cualquier indicio de VLAN que ya ha sido almacenado se deja sin cambios.

Los indicios de VLAN abordan un problema que puede surgir en determinadas redes que utilizan una tecnica de conmutacion llamada STP (protocolo de arbol de extension) que se utiliza para evitar tener bucles logicos en porciones conmutadas (capa 2) de la red (para evitar el bucle de trafico alrededor de manera infinita). El protocolo se utiliza para decidir a donde un dispositivo de conmutacion debe enviar un paquete dado.

Es decir, si el dispositivo se esta conmutando, el conmutador mirara al encabezado de la capa 2 (MAC/Ethernet) y mirara a la direccion de la capa 2 de destino (NHL2) y luego consultara una base de datos interna (la FDB - base de datos de reenvfo) para determinar desde cual de sus puertos se debe enviar el paquete. Muchas empresas utilizan una extension de STP llamada PVSTP (protocolo de arbol de expansion por VLAN), por lo que cada paquete esta marcado con un identificador de VLAN tambien. Entonces el conmutador mantiene f Db separadas - una por cada VLAN.

Esto se hace en parte por eficiencia y en parte para permitir topologfas virtuales mas complejas. Asf, es perfectamente posible (y no es raro) que dos paquetes con la misma capa 2 de destino abandonen por diferentes puertos, ya que estan etiquetados como que estan en diferentes VLAN, a pesar de que su destino sea el mismo dispositivo/puerto.

La consecuencia de esto es que el proceso no puede simplemente arrastrar todos los FDB por VLAN hasta que se encuentra una coincidencia. Es importante saber a priori que VLAN del paquete se etiqueta como un miembro. Este etiquetado de la VLAN puede producirse en diferentes lugares de la red, por ejemplo, en el puerto de acceso de origen - es decir, cuando el dispositivo de origen esta conectado ffsicamente, o en otro lugar en la red - no es raro que una etiqueta de VLAN sea sustituida por otra (esto se llama enrutamiento entre VLAN).

Por ejemplo, dado un paquete que llega al dispositivo D de la red (en la ruta A->B->C->D) D solo puede ser consultado por la interfaz de salida correcta si se conoce la VLAN del paquete desde A estuviera en el punto cuando alcanza D. Podna ser, por ejemplo, que A coloque el paquete en la VLAN 100, B pase (usando la VLAN 100), entonces C cambie de 100 a 200 y luego D lo conmute usando la VLAN 200.

Por esta razon, es necesario 'llevar' un indicio de VLAN en toda la red desde nuestro dispositivo de origen a nuestro dispositivo de destino como parte del paquete hipotetico que rastreamos. Asf, en su caso el indicio de VLAN se usa, anula, restablece o actualiza.

Como ya se ha mencionado, la figura 23 ilustra el proceso de findRoutelterative que se utiliza en las opciones R y r. El proceso consiste en un bucle de ruta de hallazgo que comienza en la etapa F1 y termina en una verificacion del lfmite de la ruta F2. El proceso findRoutelterative determina entonces si se ha encontrado una ruta y permite un mdice de salida que se encuentra perteneciente a la ruta.

Antes de embarcarse en el bucle principal, hay tres procesos de preparacion que se implementan para establecer el estado de entrada para la primera iteracion del bucle. Un primer proceso de preparacion se muestra en la figura 24, que establece como punto inicial el conmutador de acceso o dispositivo de red identificado por el dispositivo de origen (indicado en la figura 24 como el lado del cliente). Del mismo modo, un conmutador de acceso o dispositivo de red se almacena como un punto de detencion, en base al dispositivo de destino, que se refiere en la figura 24 como el lado del servidor. En la Figura 24, la IP del cliente y la IP del servidor son el origen y destino respectivamente.

La figura 25 es un proceso de preparacion para el establecimiento de las direcciones NHL3 y NHL2 de estado de entrada inicial.

La figura 26 ilustra un tercer proceso de preparacion que establece el dispositivo de enfoque para el estado de la entrada inicial.

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

Un algoritmo alternativo para identificar una ruta de acceso se describe ahora. Sera evidente que las explicaciones detalladas en partes de la siguiente descripcion se aplican a las partes equivalentes del proceso de iteracion de bucle que se acaba de describir.

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 determinate 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

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.

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. 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 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 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 la etapa 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 la etapa S1 se anade al registro de ruta S1A. En la etapa 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 la etapa 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 la etapa S5 se determina si NHL2 es conocido. En caso afirmativo, el bucle pasa a la etapa S5A. En caso negativo, el proceso lleva a cabo la etapa 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 la etapa 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 la etapa 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). Las etapas S6A, S7 y S7A pueden denominarse un salto L2. En este punto, consultese la figura 2b. En la etapa 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 la etapa 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 la etapa 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". En la etapa 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 la etapa 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 a la etapa S5, pero usando NHL3 y NHL2 puestos en la etapa 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 enrutador 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 dedr, 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 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). 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, St P 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 la etapa 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 IP 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 MAC (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. Esto se encuentra en el proceso de la figura 23 (con el subproceso de la figura 27), y la figura 28, mas de una consulta puede ser generada de forma autonoma por el proceso de ejecucion del bucle para lograr un resultado. El principio de una utilidad "por salto" se describe mas claramente con referencia al algoritmo alternativo mencionado anteriormente. 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 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. La etapa 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 son indicativas 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 291 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 a la etapa 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. La etapa 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 la etapa de establecer en que VLAN esta participando el dispositivo segun la topologfa 3 y como se ha registrado en el dispositivo. Estas VLAN se usan para ayudar a hallar entradas de tabla de envfo para VLAN espedficas (las FDB 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 topolog^a 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 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. La etapa 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.

Esta etapa de "Salto siguiente" se repite hasta que se llega a un ffmite 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 permitina localizar una direccion IP de red espedfica. Sin embargo, como se puede ver en la figura 5, IpRouteMask propiamente dicho esta embebido en ipRouteEntr 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

255.255.255.255, 255.255.255.254, 255.255.255.252,... 0.0.0.0. Un numero de estos produce ID 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 = 000010100010110000000001 11010101.

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 las etapas 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 aqrn "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 enfoque, en una primera etapa 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 la etapa Z10 no da lugar a una direccion IP, el proceso pasa a la etapa 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 a la etapa Z7 y realiza las etapas 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 a la etapa 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 la etapa 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 una etapa 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 envm 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 ipNetToMediaEntr y 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 iflndex. 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 ello es significativamente mas eficiente.

En manipulacion especulativa, multiples claves de consulta pueden contenerse en un solo mensaje de consulta. 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 multiprotocolo (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 entremedios). 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 API 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 cadenas comunitarias contextualizadas VRF.

Claims (22)

REIVINDICACIONES

1. Un metodo para identificar una ruta desde un dispositivo de origen (X) a un dispositivo terminal en una red de dispositivos interconectados, que comprende:

identificar como dispositivo de enfoque un primer dispositivo conectado al dispositivo fuente (X);

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

recibir un mensaje de resultado que identifica el puerto de salida e identifica como dispositivo de enfoque un segundo dispositivo conectado al primer dispositivo basado en una topologfa de red a la que puede acceder el ordenador del monitor (16);

dirigir una consulta de identificacion de ruta adicional al segundo dispositivo y recibiendo un mensaje de resultado siguiente que identifica un puerto de salida desde el segundo dispositivo; y

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

donde la formulacion de la primera y otras consultas se lleva a cabo mediante un programa informatico de bucle de acuerdo con las siguientes etapas:

recibir en una unidad de ejecucion en un ordenador de monitor (16) que tiene una ruta de consulta a los dispositivos interconectados un conjunto de variables de estado que definen un estado de entrada, donde una de las variables de estado del conjunto define una secuencia ordenada de opciones de bucle (C, S, R, A, c, r);

registrar el estado de entrada en una unidad de almacenamiento;

en la unidad de ejecucion (16), ejecutar una primera opcion de bucle en la secuencia ordenada de opciones de bucle (C, S, R, A, c, r) en el estado de entrada, utilizando como parametros al menos una de las otras variables de estado en el conjunto de variables de estado, donde la ejecucion de la primera opcion de bucle comprende cancelar la primera opcion de bucle de la secuencia ordenada, realizar etapas de procesamiento utilizando al menos una de las otras variables de estado y determinar si alguna de estas variables de estado se ha alterado como resultado de las etapas de procesamiento, donde:

si ninguna de las variables de estado ha cambiado, ingresar la siguiente iteracion de bucle con un estado de entrada en el cual la primera opcion de bucle se cancela desde la secuencia ordenada de opciones de bucle, revelando una nueva opcion de primer bucle que se ejecutara con las variables no alteradas, y si al menos una de las variables de estado ha cambiado, restablecer la opcion de primer bucle cancelado en la secuencia ordenada para proporcionar una secuencia ordenada original de opciones de bucle e ingresar una iteracion de bucle siguiente con un estado de entrada definido por la(s) variable(s) de estado alterado y la secuencia original ordenada de opciones de bucle,

por lo que cada iteracion de bucle siguiente recibe un nuevo estado de entrada, de las variables de estado alteradas, donde una de las variables de estado es el dispositivo de enfoque para recibir la consulta de identificacion de ruta generada por la opcion de bucle ejecutada en el ordenador de monitor; otra de las variables de estado es una direccion de red de enrutamiento como identificador de destino y otra de las variables de estado es una direccion de conmutacion como identificador de destino, y una de las opciones determina si la direccion de enrutamiento del estado de entrada esta en el dispositivo de enfoque del estado de entrada y, si no, utiliza una tabla de asignacion para traducir la direccion de enrutamiento para proporcionar una nueva direccion de conmutacion como una variable de estado alterada.

2. El metodo de la reivindicacion 1, donde las variables de estado incluyen un identificador de red de area local virtual que es relevante para la ruta en la ubicacion identificada por el dispositivo de enfoque.

3. El metodo de la reivindicacion 1 o 2, donde las opciones incluyen: una opcion que determina si hay una interfaz unica en el dispositivo de enfoque que coincida con la direccion de la red de enrutamiento en el estado de entrada, o cada nuevo estado de entrada, e identifica un puerto de salida del dispositivo de enfoque desde la interfaz unica, y una opcion que ubica en una tabla de asignacion una entrada de asignacion entre la direccion de enrutamiento y la direccion de conmutacion en el estado de entrada (o nuevo estado de entrada), utiliza la entrada de asignacion para determinar desde que interfaz fue derivada la entrada de asignacion, y por lo tanto deriva un puerto de salida.

4. El metodo de cualquier reivindicacion anterior, donde la direccion de enrutamiento (L3) se establece en la direccion de enrutamiento (L3) del dispositivo terminal (Y).

5. El metodo de cualquier reivindicacion anterior, donde la direccion de conmutacion (L2) se usa para acceder a una base de datos de reenvfo para localizar un puerto de salida.

6. El metodo de cualquier reivindicacion anterior, donde la opcion determina la ruta mediante la consulta iterativa de una tabla de enrutamiento (92) en el dispositivo de enfoque para generar una direccion de enrutamiento candidata.

7. El metodo de la reivindicacion 6, que comprende usar una tabla de mapeo (91) para traducir la direccion de enrutamiento candidata (L3) a una direccion de conmutacion candidata (L2), y comparar la direccion de conmutacion candidata (L2) con la direccion de conmutacion (L2) en el estado de entrada (o el nuevo estado de entrada).

8. El metodo de la reivindicacion 1, que comprende procesos de preparacion que incluyen al menos uno de un primer proceso de preparacion que almacena los puntos de inicio y parada identificando ubicaciones de red para cada uno de los dispositivos fuente (X) y dispositivo terminal (Y); un segundo proceso de preparacion que establece una direccion de enrutamiento (L3) y una direccion de conmutacion (L2) para el estado de entrada de una primera iteracion de bucle; y un tercer proceso de preparacion que establece un dispositivo de enfoque para el estado de entrada de una primera iteracion de bucle como el dispositivo de origen (X) o un conmutador de acceso para el dispositivo de origen (X).

9. El metodo de la reivindicacion 8, que comprende: obtener una sugerencia para ayudar a identificar una red de area local virtual donde esta conectado el dispositivo de enfoque.

10. El metodo de la reivindicacion 9, donde obtener una sugerencia comprende determinar un puerto de acceso para la salida de mensajes del dispositivo fuente (X), identificar el nombre del puerto de acceso y extraer un numero del nombre del puerto de acceso para almacenar como el indicio.

11. El metodo de la reivindicacion 9, donde obtener una sugerencia comprende determinar un puerto de acceso para la salida de mensajes del dispositivo de origen (X), identificar asignaciones explfcitas de VLAN para el puerto (a traves de SNMP o desde un NMS) y si la asignacion de VLAN es unica, almacenar el numero de VLAN unico como el indicio.

12. El metodo de las reivindicaciones 3 o 5, donde el puerto de salida y el indicio de VLAN se utilizan para ubicar el siguiente dispositivo conectado desde la topologfa de la red.

13. Un metodo segun la reivindicacion 1, que comprende registrar un conjunto de dispositivos y puertos identificados para estar en la ruta en una tienda a la que puede acceder el ordenador monitor (16) como un registro de ruta.

14. Un metodo segun la reivindicacion 13, donde el registro de ruta incluye puertos de entrada identificados desde la topologfa de red para dispositivos identificados.

15. Un metodo segun la reivindicacion 1, donde la consulta de identificacion de ruta se transmite desde el ordenador monitor (16) al dispositivo de enfoque que se consulta en un mensaje que se transmite a traves de la red.

16. Un metodo segun la reivindicacion 1, donde la consulta de identificacion de ruta incluye una pluralidad de claves para consultar el dispositivo.

17. Un metodo segun la reivindicacion 1, que comprende identificar una primera ruta a traves de la red desde el dispositivo de origen (X) hasta el dispositivo de 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) al dispositivo de destino final (Y) utilizando conjuntos de consultas posteriores.

18. Un metodo segun la reivindicacion 1, cuando se usa en una red de dispositivos interconectados que incluyen dispositivos de capa 2 y de capa 3, comprendiendo el metodo, despues de identificar el primer dispositivo conectado al dispositivo fuente (X):

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

identificar de un identificador de destino de capa 2 del siguiente identificador de destino de capa 3.

19. Un metodo segun la reivindicacion 1, donde cada consulta de identificacion de ruta se genera para una tabla de reenvfo de trafico en el dispositivo al que se transmite la consulta de identificacion de ruta, utilizando la consulta al menos una de un conjunto de claves que se han generado al combinar el identificador de destino con una pluralidad de indices incrustados de la tabla de reenvfo de trafico.

20. Un sistema informatico para ejecutar un programa informatico de bucle, comprendiendo el sistema informatico un procesador que puede ejecutarse para ejecutar un metodo de ejecucion de bucle de acuerdo con cualquiera de las reivindicaciones 1 a 19; y medios de almacenamiento para registrar el estado de entrada.

21. Un sistema informatico segun la reivindicacion 20, que comprende, ademas:

una interfaz (84) conectada a una red de dispositivos interconectados para transmitir consultas y recibir respuestas a un dispositivo de enfoque;

un segundo medio de almacenamiento para almacenar un registro de trayectoria; y

un tercer medio de almacenamiento que almacena una topologfa de red.

22. Un programa informatico que comprende un codigo que, cuando se ejecuta mediante un procesador, realiza las etapas del metodo de cualquiera de las reivindicaciones 1 a 19.