ES2713078T3

ES2713078T3 - Sistema y método para implementar y gestionar redes virtuales

Info

Publication number: ES2713078T3
Application number: ES12819833T
Authority: ES
Inventors: Dan Mihai Dumitriu; Romain F V Lenglet; Candia Giuseppe De; Jacob L Mandelson
Original assignee: Mido Holdings Ltd
Current assignee: Mido Holdings Ltd
Priority date: 2011-08-04
Filing date: 2012-08-06
Publication date: 2019-05-17
Anticipated expiration: 2032-08-06
Also published as: EP2740242A4; US20180227195A1; WO2013020126A1; US11070447B2; JP6080313B2; US9900224B2; JP2014529926A; EP2740242B1; EP2740242A1; EP2740242B8; TW201322686A; US20140195666A1; TWI583151B

Abstract

Un sistema informático que comprende: una pluralidad de nodos (54, 73, 80, 210, 221, 222) interconectados mediante una red subyacente (53, 79, 202), en el que cada nodo incluye una o más interfaces de red (55, 74, 75, 81), estando conectada la una o más interfaces de cada nodo a la red subyacente, una pluralidad de dispositivos virtuales (211, 212, 213, 214) que se simulan en al menos uno de la pluralidad de nodos, teniendo cada dispositivo virtual una pluralidad de puertos virtuales, en el que cada puerto virtual corresponde a uno de un puerto orientado hacia el exterior o un puerto orientado hacia el interior, correspondiendo cada puerto orientado hacia el exterior a una de las interfaces de red de los nodos de la red subyacente, teniendo cada puerto orientado hacia el interior un enlace virtual con otro puerto orientado hacia el interior de los dispositivos de red virtuales y una base de datos compartida (61, 86) que almacena una pluralidad de reglas de flujo y una topología de red virtual que incluye una configuración de los puertos virtuales y los dispositivos virtuales, incluyendo la configuración, para cada uno de los puertos virtuales, una identificación del puerto virtual como una de un puerto orientado hacia el exterior o un puerto orientado hacia el interior, siendo la base de datos compartida accesible por la pluralidad de nodos, estando caracterizado el sistema informático por que comprende además un motor de decisión (78, 84, 165) operable para: simular un recorrido de un paquete de red de la topología de red virtual desde un puerto orientado hacia el exterior de entrada de un primer dispositivo virtual hasta un puerto orientado hacia el exterior de salida de un último dispositivo virtual, en el que el puerto orientado hacia el exterior de salida del último dispositivo virtual corresponde a una interfaz de red en la que el paquete de red se emitirá desde la red subyacente, determinar un patrón de cabecera de paquete identificando cada campo de la cabecera de protocolo del paquete que se lee durante la simulación del recorrido, en el que el patrón de cabecera de protocolo de paquete incluye un comodín para cualquier campo de la cabecera de protocolo del paquete que no se lee durante la simulación del recorrido, determinar una modificación de cabecera de protocolo que va a aplicarse al paquete de red basándose en una configuración de cada dispositivo virtual recorrido por el paquete durante la simulación del recorrido, comunicar el patrón de cabecera de protocolo de paquete y la modificación de cabecera de protocolo determinada a la base de datos compartida, almacenar el patrón de cabecera de protocolo de paquete y la modificación de cabecera de protocolo determinada como una regla de flujo en la base de datos compartida; tras recibir un paquete posterior, seleccionar una regla de flujo desde la base de datos compartida haciendo coincidir una cabecera del paquete posterior con el patrón de cabecera de protocolo de paquete almacenado, y aplicar la modificación de cabecera de protocolo determinada de la regla de flujo seleccionada a paquetes posteriores que coinciden con el patrón de cabecera de protocolo de paquete de manera que el paquete se entrega al segundo nodo de la red subyacente y se emite desde la segunda interfaz de red, estando determinada la simulación del recorrido de la topología de red virtual en parte consultando la base de datos compartida usando un campo de la cabecera de protocolo del paquete de red.

Description

DESCRIPCION

Sistema y metodo para implementar y gestionar redes virtuales

Antecedentes y sumario

La presente divulgacion se refiere a la conexion en red, y mas particularmente sistemas y metodos que implementan y gestionan redes virtuales.

La aparicion de informatica basada en la nube ha creado nuevas demandas de proveedores de servicio. A los proveedores de servicio les gustana dotar a cada cliente de una red virtual, con la capacidad de anadir anfitriones y de cambiar la topologfa desacoplada de la red ffsica. La virtualizacion de la red permite que los proveedores de servicio creen topologfas de red configurables por el cliente que pueden cambiarse alterando enrutadores virtuales y conmutadores virtuales sin ningun cambio de hardware. Los enrutadores virtuales permiten tambien la segregacion de datos de clientes por seguridad y precios basados en uso. Un hardware dedicado puede proporcionar algunas de estas caractensticas pero puede ser caro. Permanece la necesidad de una herramienta que permita que una red virtual se superponga sobre una red existente y que permita cambiar esa topologfa de la red virtual independientemente de la red subyacente.

El documento US 7.991.859 B1 representa la tecnica anterior mas proxima y tecnicas para proporcionar redes informaticas virtuales gestionadas cuya topologfa de red logica configurada puede tener uno o mas dispositivos de conexion en redes virtuales, tales como mediante un servicio de red configurable accesible por red, con funcionalidad de conexion en red correspondiente proporcionada para comunicaciones entre multiples nodos informaticos de una red informatica virtual emulando la funcionalidad que se proporcionana por los dispositivos de conexion en red si estuvieran presentes ffsicamente.

El documento EP 2139178 A1 se refiere a un metodo de determinar una trayectoria de ruta en una red superpuesta entre homologos, y un nodo de red y un producto de programa informatico para ejecutar dicho metodo. La red superpuesta entre homologos comprende una pluralidad de nodos. Se identifica un hardware ffsico en el que funciona un primer nodo de dicha pluralidad de nodos.

El objeto de la invencion se soluciona mediante las reivindicaciones independientes. En las reivindicaciones dependientes se mencionan realizaciones adicionales.

En el presente documento se dan a conocer un sistema y un metodo que facilitan el enrutamiento de paquetes usando una red virtual superpuesta en una red ffsica. En diversas realizaciones, la presente divulgacion preve la interconexion flexible de elementos de red en multiples capas del modelo OSI, incluyendo, L2 (Capa-2, es decir Capa de enlace), L3 (Capa-3, es decir Capa de red) y L4 (Capa-4, es decir Capa de transporte). Los elementos de red pueden estar interconectados con conmutadores L2 virtuales y enrutadores L3. Los paquetes de las redes L2 virtuales pueden transportarse por la red L3 existente usando tunelizacion, sin requerir ningun cambio a la red L3. Pueden usarse diversos metodos de tunelizacion, tal como GRE, Ethernet sobre IP, VXLan, MPLS sobre lP o CAPWAP. Los paquetes de protocolo de Internet (IP) enrutados por el enrutador L3 virtual pueden transportarse por la red L3 existente, sin requerir ningun cambio a la red L3 existente.

En una realizacion, para los elementos a los que se conectan, los conmutadores L2 virtuales y enrutadores L3 virtuales se tratan de conmutadores L2 ffsicos y enrutadores L3 ffsicos, aunque no pueden implementarse usando elementos de red L2 y L3 ffsicos. Puede haber un numero arbitrario de elementos de red virtuales (conmutadores o enrutadores), conectados virtualmente cada uno a un numero arbitrario de elementos de red. En una configuracion, cada conmutador L2 virtual esta conectado a un enrutador L3 virtual, que puede conectarse a un numero arbitrario de otros enrutadores L3.

Los conmutadores L2 virtuales y los enrutadores L3 virtuales del sistema pueden conectarse a un gran numero de elementos de red, independientemente de la separacion geografica. El sistema puede conectar elementos que son o bien ffsicos o bien virtuales, conectando, por ejemplo, maquinas virtuales emuladas en ordenadores servidores a enrutadores ffsicos que estan conectados a Internet.

Se proporcionan un metodo y un sistema para crear y gestionar redes virtuales que comprenden una pluralidad de enrutadores y conmutadores virtuales. El metodo y el sistema tambien pueden proporcionar servicios de cortafuegos L3/L4, servicios de traduccion de direccion de red de origen y/o destino, y equilibrio de carga tal como se describe en mas detalle a continuacion. En el presente documento se da a conocer un metodo para enrutar un paquete desde un primer nodo hasta un segundo nodo que comprende recibir un paquete en un primer nodo de una red subyacente; acceder a una tabla de enrutamiento virtual para determinar un siguiente salto para el paquete en una topologfa de red virtual, donde el siguiente salto es o bien un puerto (logico) orientado hacia el interior o bien un puerto (materializado) orientado hacia el exterior, y continuar accediendo a tablas de enrutamiento virtuales posteriores en serie hasta que se determine que el siguiente salto sea un puerto orientado hacia el exterior en un segundo nodo de la red; y enviar el paquete por la red subyacente al puerto orientado hacia el exterior del segundo nodo. La etapa de acceder a una tabla de enrutamiento virtual para determinar un siguiente salto para el paquete tambien puede incluir ejecutar una busqueda en cada tabla de enrutamiento virtual, donde la tabla de busqueda contiene los datos del siguiente salto para el paquete. En una realizacion, el primer nodo de la red esta configurado para acceder a una red externa, y el segundo nodo de la red esta configurado para hospedar una maquina virtual. El metodo tambien puede incluir aplicar una modificacion de preenrutamiento y/o una modificacion de posenrutamiento al paquete para al menos un salto en la red virtual. En una realizacion, el siguiente salto para un paquete se determina a partir de la direccion de origen y/o la direccion de destino. Ademas, los procesos de preenrutamiento y posenrutamiento pueden utilizar la direccion de origen, el puerto de origen, la direccion de destino y/o el puerto de destino para determinar la traduccion o la modificacion deseada del paquete. El metodo tambien puede comprender almacenar al menos una tabla de enrutamiento virtual en un estado distribuido en una pluralidad de nodos en la red subyacente. En diversas realizaciones, la red subyacente puede incluir una red Ethernet, una red de IP privada, una red de IP publica u otras redes capaces de proporcionar conectividad entre los nodos.

Tambien se da a conocer un metodo para enrutar paquetes que comprende las etapas de recibir un paquete de un flujo en un primer nodo; acceder a una tabla de flujo y determinar que el paquete no coincide con una regla de flujo existente; comunicar el paquete a un motor de decision; acceder a una topologfa de red virtual almacenada en una base de datos compartida accesible por una pluralidad de nodos; crear una regla de flujo para el paquete; y comunicar la regla de flujo a la tabla de flujo. La etapa de crear una regla de flujo puede comprender ademas determinar una secuencia de enrutamiento para el paquete en la red basandose en una topologfa virtual establecida por un titular de red.

Tambien se da a conocer un metodo de seguimiento de conexiones con estado para borrar una entrada de flujo que comprende las etapas de recibir un paquete FIN con un numero de secuencia en un nodo perimetral con un conmutador configurable de flujo; identificar una regla de flujo correspondiente al paquete en el conmutador configurable de flujo; identificar la regla de flujo para su borrado y comunicar la regla de flujo identificada a un estado distribuido en una base de datos compartida; y comunicar el paquete basandose en la regla de flujo correspondiente. En realizaciones, el sistema proporciona medios para simular una maquina de estado de conexion TCP y guardar su estado en la base de datos compartida.

En realizaciones, el flujo puede ser un flujo entrante o un flujo saliente de una conexion TCP. El metodo puede incluir ademas borrar el flujo identificado tras recibir un paquete de ACK correspondiente al paquete FIN. En una realizacion, el metodo comprende tambien identificar un flujo de sentido opuesto almacenado en el estado distribuido que corresponde al flujo identificado; identificar el flujo de sentido opuesto para su borrado; y borrar el flujo identificado y el flujo de sentido opuesto tras recibir un paquete de ACK correspondiente al paquete FIN.

En otra realizacion, un metodo para realizar la traduccion de direccion de red de destino comprende las etapas de recibir un primer paquete en un primer nodo, teniendo el primer paquete una direccion de destino; crear una primera regla de flujo correspondiente al primer paquete, donde la primera regla de flujo comprende una agregacion de las modificaciones hechas a un paquete que recorre una pluralidad de dispositivos virtuales en la topologfa de red virtual; aplicar la primera regla de flujo al primer paquete; recibir un segundo paquete en un segundo nodo en respuesta al primer paquete, teniendo el segundo paquete una direccion de origen; crear una segunda regla de flujo correspondiente al segundo paquete; y acceder el primer flujo desde un estado distribuido y aplicar la traduccion de direccion de red de destino a la direccion de origen del segundo paquete. El metodo tambien puede comprender esperar hasta que la primera regla de flujo se almacene en el estado distribuido antes de reenviar el primer paquete de manera que el segundo paquete no se recibe hasta que se almacena la primera regla de flujo en el estado distribuido. En una realizacion, el primer paquete y el segundo paquete corresponden a una conexion TCP. En otra realizacion, el metodo comprende ademas aplicar un algoritmo de equilibrio de carga para equilibrar cargas en los recursos de red subyacente.

Breve descripcion de los dibujos

La figura 1 ilustra una realizacion de un metodo para invalidar un flujo;

la figura 2 ilustra una realizacion de un metodo para aprendizaje de MAC;

la figura 3 ilustra una realizacion de un metodo para desaprendizaje de MAC;

la figura 4 ilustra una realizacion de un metodo para seguimiento de conexion;

la figura 5 ilustra una vista ffsica de un sistema para la gestion de VPN;

la figura 6 ilustra una vista ffsica de otro sistema para la gestion de VPN.

La figura 7 ilustra un ejemplo de un ordenador servidor usado por el sistema para enrutar paquetes hasta y desde una red general tal como Internet hasta un tejido IP de un proveedor de servicios.

La figura 8 ilustra una red ffsica de ejemplo.

La figura 9 ilustra una red virtual de ejemplo que puede superponerse en la red ffsica de la figura 8.

La figura 10 ilustra un proceso que se ejecuta en un conector de borde para enrutar paquetes en una topologfa virtual compuesta de enrutadores virtuales.

La figura 11 ilustra un proceso que se ejecuta en un conector de borde para conmutar y enrutar paquetes en una topologfa virtual compuesta de enrutadores virtuales y conmutadores virtuales.

La figura 12 es una continuacion del proceso de la figura 11.

La figura 13 ilustra una realizacion de una red virtual.

La figura 14 ilustra la red virtual de la figura 13 superpuesta en una red ffsica.

Descripcion detallada

Haciendo referencia generalmente a las figuras 1 a 14, las realizaciones del sistema y el metodo dados a conocer se refieren a sistemas informaticos que implementan y gestionan redes virtuales y pueden proporcionar soluciones de red definidas por software. El sistema y el metodo dados a conocer proporcionan una capa de abstraccion de software para virtualizar una red para mejorar la efectividad de sistemas informaticos en la nube al tiempo que se reduce la complejidad de redes ffsicas y los costes de mantenimiento asociados.

En diversas realizaciones, se da a conocer un metodo informatico que incluye recibir un paquete que llega a una primera interfaz de red de un primer nodo de una red subyacente. La primera interfaz de red puede implementarse en hardware o software en el primer nodo. Un motor de decision puede invocarse para determinar como se gestionara el paquete. En un aspecto, el paquete y una identificacion de la interfaz de red en la que el paquete llego a la red se comunican al motor de decision para procesarse. El motor de decision puede simular como recorrera el paquete la topologfa de red virtual que incluye cada uno de una pluralidad de dispositivos de red virtuales encontrados por el paquete. Ademas de simular como se pasa un paquete desde un dispositivo al siguiente a traves de la red virtual, el motor de decision tambien puede simular como afecta a cada uno de los dispositivos virtuales el paquete, tal como modificando las cabeceras de protocolo de paquete. Basandose en los resultados de simulacion, el sistema puede procesar el paquete aplicando cada una de las modificaciones determinadas o una agregacion de las modificaciones de modo que el paquete puede emitirse desde una interfaz de red en uno de los nodos de la red, donde la interfaz de red espedfica en la que emitir el paquete se determino durante la simulacion por el motor de decision.

En cada etapa a traves de la topologfa de red virtual, el motor de decision determina como puede gestionarse el paquete por dispositivos sucesivos. En un ejemplo, el motor de decision puede determinar que un paquete debe soltarse o ignorarse. Soltar un paquete puede producirse cuando se asocia un paquete dado con una comunicacion o flujo que el sistema ya no esta procesando. En otros ejemplos, un paquete puede soltarse puesto que un dispositivo virtual carece de instrucciones suficientes para gestionar un paquete del tipo recibido. Alternativamente, un dispositivo puede ser incapaz de enrutar de manera satisfactoria un paquete dado al destino especificado. Puede proporcionarse un mensaje de error u otra respuesta para alertar al remitente del paquete de que el paquete no llego a su destino.

Para muchos paquetes, el motor de decision determinara que el paquete debe emitirse desde un puerto virtual correspondiente a una segunda interfaz de red. La segunda interfaz de red puede estar en el primer nodo o en un segundo o un nodo diferente de la red subyacente dependiendo del destino del paquete y el mapeo de puerto a anfitrion virtual. Cuando el paquete va a entregarse a una segunda interfaz de red en un segundo nodo, el motor de decision determina como va a procesarse el paquete y luego se entrega el paquete por la red subyacente al segundo nodo que va a emitirse por la segunda interfaz de red.

En multiples realizaciones, las cabeceras de protocolo de los paquetes pueden modificarse antes de la entrega a la segunda interfaz de red. La modificacion de las cabeceras de protocolo puede proporcionar la traduccion de direccion de red, tunelizacion, VPN u otras caractensticas tal como se comenta mas a fondo a continuacion.

En una realizacion, el metodo incluye mantener un mapa de identificadores de nodo para direcciones de nodo para nodos en la red subyacente. Pueden usarse identificadores de nodo para distinguir nodos individuales para fines de enrutar paquetes en la red subyacente. Para entregar un paquete desde un primer nodo hasta un segundo nodo, el paquete puede reenviarse como la carga util de un paquete de protocolo de tunelizacion (tal como Ethernet+IP+GRE). En realizaciones, el paquete de protocolo de tunelizacion tiene una clave de tunel que codifica un identificador global de una segunda interfaz de red. Un identificador global puede ser unico dentro de la red de manera que cada interfaz de red puede identificarse de manera unica. En cambio, un identificador local puede usarse dentro de un nodo, o dentro de un subconjunto de la red para identificar de manera unica un puerto o una interfaz dentro de un subconjunto de la red. Cuando el paquete de protocolo de tunelizacion se recibe en el segundo nodo, la carga util que contiene el paquete original se extrae junto con la clave de tunel. Entonces, la clave de tunel puede decodificarse para determinar el segundo identificador de interfaz de red virtual y el paquete emitido desde la segunda interfaz de red. De esta manera, el sistema puede utilizar el motor de decision para determinar como ha de gestionarse un paquete cuando recorre el sistema y tambien para transportar de manera eficiente el paquete una vez que se hace la determinacion.

En otras realizaciones, el motor de decision determina que debe emitirse un paquete desde un conjunto de interfaces de red. Puede ser necesario emitir desde un conjunto de interfaces de red en aplicaciones de multidifusion o difusion. Las interfaces de red desde las que debe emitirse el paquete pueden ser locales para un solo nodo de la red, o pueden dispersarse por dos o mas nodos. En cualquier caso, el sistema determino que el paquete debe emitirse desde un conjunto de interfaces de red correspondiente a un identificador de conjunto de interfaz. Entonces el paquete se procesa entregando el paquete a cada interfaz de red en el conjunto que es local para el primer nodo. El paquete tambien se reenvfa, con modificaciones, desde el primer nodo hasta el segundo nodo, a lo largo de un tunel. El paquete puede reenviarse como la carga util de un paquete de protocolo de tunelizacion usando una clave de tunel que codifica el identificador de conjunto de interfaz. Cuando se recibe el paquete de tunelizacion en el segundo nodo, la clave de tunel puede decodificarse para determinar el identificador de conjunto de interfaz, y el paquete emitido en interfaces de red cualesquiera incluidas en ese conjunto que son locales para el segundo nodo. El conjunto de interfaces de red asociado con unos identificadores de conjunto de interfaz dados pueden almacenarse en la base de datos compartida accesible por cada nodo del sistema. Por tanto si un nodo recibe un identificador de conjunto de interfaz desconocido, el nodo puede acceder a la base de datos compartida para determinar que interfaces de red estan incluidas en el conjunto identificado. Ademas, un nodo puede almacenar o copiar en memoria cache el mapeo de interfaces de red a identificadores de conjunto de interfaz localmente en el nodo. Sin embargo, cuando el identificador de conjunto de interfaz cambia, los datos copiados en memoria cache localmente se invalidan y el nodo puede acceder a la base de datos compartida para recuperar el mapeo actual o actualizado de interfaces a conjuntos de interfaz. En realizaciones, una interfaz de red virtual puede pertenecer a mas de un conjunto de interfaz.

En la aplicacion en la que la red subyacente soporta multidifusion (tal como multidifusion de IP), cada identificador de conjunto de interfaz puede mapearse a una direccion de multidifusion, y cada nodo de la red subyacente puede mantener una suscripcion de multidifusion para cada uno de los identificadores de conjunto de interfaz a los que pertenece al menos una de las interfaces de red virtual mapeadas a ese nodo. Entonces, pueden multidifundirse paquetes como la carga util de un paquete de protocolo de tunelizacion a un segundo o mas nodos. Entonces, cada nodo emite el paquete desde cualquier interfaz de red correspondiente a las interfaces en el conjunto que son locales a ese nodo. En diversas realizaciones, los identificadores de conjunto de interfaz estan mapeados de manera unica a direcciones de multidifusion.

Si la red subyacente no soporta la multidifusion, el motor de decision determina el conjunto de nodos de red subyacente que tienen interfaces de red locales que pertenecen al conjunto de interfaces de red al que va a enviarse el paquete. Entonces, el paquete se reenvfa desde el primer nodo hasta cada nodo en el conjunto de nodos de red subyacente en un paquete de protocolo de tunelizacion tal como se describio anteriormente. Entonces, cada nodo emitio el paquete a las interfaces de red correspondientes asociadas con el conjunto identificado.

El motor de decision determina como gestionar un paquete dado basandose en una simulacion de ese paquete que recorre la topologfa de red virtual. En muchas aplicaciones, estan asociados multiples paquetes como un flujo y cada paquete en el flujo, donde va a procesarse de la misma manera cada paquete en el flujo, por ejemplo, todos los paquetes de una direccion de una conexion TCP. En realizaciones, tras recibir el primer paquete de flujo, el sistema invoca el motor de decision para determinar como va a gestionarse el paquete de ese flujo. Entonces, el motor de decision puede almacenar las acciones o reglas para gestionar paquetes posteriores de ese flujo. Las acciones o reglas almacenadas pueden almacenarse en la base de datos compartida de manera que las reglas estan disponibles para todos los nodos del sistema para gestionar paquetes de un flujo dado. Alternativamente, las reglas pueden almacenarse localmente.

En realizaciones, la salida del motor de decision incluye un patron de cabecera de protocolo de paquete que puede usarse para hacer coincidir otros paquetes para los que la salida del motor de decision sera la misma que para el primer paquete. Dicho de otro modo, el patron de cabecera de protocolo de paquete puede usarse para identificar paquetes que se trataran de manera identica aplicando las acciones o reglas determinadas para el primer paquete. En realizaciones, la salida del motor de decision es el resultado de la simulacion realizada para determinar como ha de procesarse el paquete. Se almacenan el patron de cabecera de protocolo de paquete y el resultado de la simulacion para el primer paquete. Tras recibir un segundo paquete, las cabeceras del segundo paquete se comparan con el patron de cabecera de protocolo de paquete al tiempo que se ignoran campos que cambian en una base por paquete tal como numero de secuencia TCP. Si el segundo paquete coincide con el patron, entonces el segundo paquete se considera que forma parte del mismo flujo y el resultado almacenado anteriormente de la simulacion para el primer paquete se recupera y se aplica al segundo paquete. El resultado almacenado de la simulacion puede recuperarse desde la base de datos compartida, una memoria cache local o cualquier otra memoria adecuada para contener las reglas que van a aplicarse a paquetes del flujo. En realizaciones, el motor de decision puede aplicar al flujo las reglas a los paquetes segundos y posteriores en un flujo. En otras realizaciones, sin embargo, la simulacion asociada con el primer paquete para determinar las reglas para el flujo, y la aplicacion de esas reglas a paquetes pueden dividirse para mejorar la velocidad o eficiencia del sistema.

La copia en memoria cache o el almacenamiento de resultados de simulacion espedficos puede determinarse por el sistema. Por ejemplo, el motor de decision puede sugerir que resultados de simulacion deben copiarse en memoria cache. En este contexto, una sugerencia puede incluir una recomendacion de que se almacena un resultado espedfico sujeto a otra consideracion tal como eficiencia o capacidad de almacenamiento disponible. En un ejemplo, el sistema puede elegir no almacenar los resultados de simulacion para un flujo usado con poca frecuencia. Tambien puede informarse al motor de decision sobre que desenlaces o resultados de simulacion estan copiados en memoria cache realmente o que resultados se han invalidado o expulsado de los resultados copiados en memoria cache. Un resultado copiado en memoria cache puede invalidarse por una variedad de motivos. En un ejemplo, un desenlace puede expulsarse para liberar espacio de almacenamiento para flujos nuevos o usados con mas frecuencia. El rendimiento del sistema puede mermar a medida que aumenta el numero de reglas de flujo almacenadas, por tanto en algunas realizaciones, el numero de reglas de flujo almacenadas puede limitarse para aumentar la eficiencia y la velocidad de funcionamiento.

Con el tiempo, puede cambiar la configuracion de la topologfa de red virtual y/o los dispositivos virtuales. Esto puede provocar que resultados de simulacion realizados anteriormente ya no reflejen las reglas apropiadas que van a aplicarse a paquetes posteriores para uno o mas flujos establecidos anteriormente. Por tanto, el sistema puede comunicar entre la base de datos compartida, el motor de decision y otros componentes para detectar y responder a cambios en los resultados de simulacion copiados en memoria cache. En un ejemplo, el motor de decision puede pedir en cualquier momento que se elimine una entrada copiada en memoria cache espedfica basandose en un cambio en la configuracion tal como se refleja en el estado global almacenado en la base de datos compartida. Cuando se elimina una entrada copiada en memoria cache, tras la recepcion del siguiente paquete correspondiente al flujo eliminado, el motor de decision se invocara y la simulacion se recalculara para determinar como han de procesarse paquetes de ese flujo. Entonces, el resultado de simulacion revisado puede almacenarse y aplicarse a paquetes posteriores que coinciden con el patron de cabecera de protocolo de paquete asociado con el flujo.

El sistema puede determinar el patron de cabecera de protocolo de paquete para un flujo dado durante la simulacion de un paquete. En realizaciones, un paquete incluye una cabecera de protocolo que tiene una pluralidad de campos y el patron se determina identificando cada uno de los campos que se leen durante la simulacion por el motor de decision. De esta manera, se identifica cada campo lefdo a medida que se recorre la topologfa de red virtual, incluyendo un campo lefdo por la pluralidad de dispositivos de red virtuales. Cada campo que se lee puede incluirse como parte del patron. En cambio, los campos que no se leen y por tanto no afectan a la gestion del paquete pueden designarse como comodines.

En todavfa otra realizacion, se recibe un primer paquete en un segundo nodo de la red subyacente y el segundo nodo genera un patron de cabecera de protocolo que puede usarse para identificar otros paquetes que tienen la misma clave de tunel que el primer paquete. Entonces, el segundo nodo usa el patron de cabecera de protocolo para identificar un segundo paquete que coincide con el patron de cabecera de protocolo de paquete y emite los segundos (y posteriores) paquetes desde las mismas interfaces de red locales desde las que se emitio el primer paquete. De esta manera, el segundo nodo simplifica el proceso de determinar en que puertos emitir el segundo paquete y mejora la eficiencia del sistema. En realizaciones, un conmutador programable de flujo en el nodo puede depender del patron de cabecera de protocolo en combinacion con una clave de tunel, o puede depender solo de la clave de tunel para identificar paquetes posteriores que se trataran de manera similar a un primer paquete.

En otra realizacion, al tiempo que se determina la simulacion para un primer paquete, el motor de decision puede pedir que un sistema de base genere uno o mas paquetes adicionales desde una interfaz de red o conjunto de interfaces de red. En realizaciones, pueden requerirse paquetes adicionales para determinar el comportamiento de puertos de la red. Al pedir paquetes adicionales, el motor de decision puede obtener informacion adicional en partes de la red para ayudar en el proceso de simulacion. Cada uno de los paquetes adicionales puede procesarse sustancialmente tal como se describe en el presente documento, o puede dotarse de un tratamiento diferente segun sea necesario para que el motor de decision desarrolle la informacion necesaria sobre la red.

En otra realizacion, un metodo informatico incluye mantener una base de datos compartida accesible desde una red subyacente que tiene una pluralidad de nodos. La base de datos compartida almacena una topologfa de red virtual y configuraciones de dispositivo virtual para una pluralidad de dispositivos de red virtuales. Un paquete de red llega a una primera interfaz de red de un primer nodo de la red subyacente. El metodo incluye ademas determinar una accion para procesar el paquete de red basandose en una simulacion del recorrido del paquete de la topologfa de red virtual incluyendo la pluralidad de dispositivos de red virtuales. En realizaciones, la accion es una regla de flujo operable en un conmutador programable de flujo operable para procesar paquetes recibidos en el nodo de la red subyacente.

La simulacion del recorrido del paquete de la topologfa de red virtual puede realizarse por un motor de decision, tal como el motor de decision comentado anteriormente. El motor de decision puede ser operable en cada uno de la pluralidad de nodos para realizar la simulacion para paquetes recibidos en cada nodo. Alternativamente, el motor de decision puede operar en un nodo independiente en comunicacion con cada uno de los nodos que recibe paquetes para los que se requiere una simulacion.

La topologfa de red virtual incluye una pluralidad de puertos virtuales correspondientes a la pluralidad de dispositivos de red virtuales. Cada dispositivo de red virtual tiene uno o mas puertos virtuales. Unos puertos virtuales pueden ser o bien un puerto orientado hacia el exterior asociado con una interfaz de red de un nodo de la red subyacente, o un puerto orientado hacia el interior asociado con un enlace virtual entre dispositivos de red virtuales. Un enlace virtual representa la conexion logica de un puerto virtual a otro puerto virtual y tambien puede denominarse cable virtual.

La base de datos compartida almacena la topolog^a de red virtual y configuraciones de dispositivo virtual que incluyen la configuracion de los puertos virtuales. En realizaciones, la base de datos compartida puede incluir una o mas de una configuracion para cada uno de la pluralidad de puertos virtuales que incluyen una identificacion del puerto virtual como una de un puerto orientado hacia el exterior o un puerto orientado hacia el interior, una configuracion para cada uno de la pluralidad de dispositivos de red virtuales asociados con la pluralidad de puertos virtuales, un mapeo de identificadores de interfaz de red a identificadores de los nodos de red subyacente, un mapeo bidireccional de puertos exteriores a interfaces de red de nodos de red subyacente correspondientes, y un mapeo de cada puerto orientado hacia el interior de cada dispositivo al puerto orientado hacia el interior homologo de otro dispositivo conectado mediante un enlace virtual. Tal como se usa en el presente documento, un puerto orientado hacia el interior homologo es el puerto virtual conectado a un puerto virtual dado por una conexion logica. Un puerto orientado hacia el interior tiene un solo igual, por tanto cada puerto virtual interior es el igual del puerto virtual interior al que esta conectado.

La configuracion de puertos virtuales puede configurarse dependiendo de la configuracion deseada del sistema, y un usuario de sistema puede definir los puertos virtuales. Un paquete que entra en/sale de un puerto virtual exterior esta entrando a/saliendo de la red virtual. En cambio, un paquete que entra en/sale de un puerto virtual interior permanece en la red. De esta manera, un puerto virtual puede caracterizarse como exterior o interior dependiendo de si el paquete entra a/sale de la red virtual cuando pasa a traves del puerto.

En una realizacion, el motor de decision opera localmente en un primer nodo y se comunica con la base de datos compartida que contiene la topologfa de red virtual y las configuraciones de dispositivo. La base de datos compartida puede contener una copia maestra o autoritativa de la topologfa e informacion de configuracion de dispositivo. Para mejorar la eficiencia, al menos una parte de la topologfa de red virtual y la informacion de configuracion de dispositivo virtual pueden copiarse en memoria cache localmente en nodos individuales. Los datos copiados en memoria cache pueden actualizarse cuando se modifica la base de datos compartida. En una realizacion, solo aquellas partes de la topologfa o configuracion de dispositivo usadas por un nodo dado se copian en memoria cache en el nodo. Tras la simulacion de una llegada de un paquete a un dispositivo virtual, el sistema puede cargar la configuracion del dispositivo virtual desde la base de datos compartida hasta el nodo que realiza la simulacion y puede copiar en memoria cache la configuracion de dispositivo para un futuro uso en el nodo.

Realizaciones del metodo informatico incluyen tambien mapear la primera interfaz de red del primer nodo a un puerto virtual correspondiente y recuperar la configuracion del puerto virtual y el dispositivo asociado con el puerto virtual desde la base de datos compartida. La accion para procesar el paquete de red se determina entonces basandose en una simulacion del dispositivo asociado con el puerto virtual. La accion determinada puede incluir uno o mas de modificar un estado interno de un dispositivo de red, soltar el paquete, modificar las cabeceras de protocolo del paquete, emitir el paquete desde uno o mas puertos virtuales de un dispositivo de red, y emitir un paquete diferente desde uno o mas puertos virtuales del dispositivo de red. En realizaciones, emitir el paquete desde uno o mas puertos virtuales del dispositivo de red puede incluir emitir el paquete desde un puerto orientado hacia el exterior o un puerto orientado hacia el interior.

Al determinar como procesar un paquete, el motor de decision puede recorrer multiples dispositivos virtuales conectados por puertos virtuales orientados hacia el interior. En una realizacion, el motor de decision determina un puerto orientado hacia el interior homologo para un segundo puerto virtual y recupera la configuracion del puerto orientado hacia el interior homologo y el dispositivo de red en el que se ubica el puerto orientado hacia el interior homologo. Entonces, el motor de decision puede simular el funcionamiento del dispositivo de red asociado con el puerto orientado hacia el interior homologo para determinar como ha de procesarse el paquete. De esta manera, el motor de decision puede simular una ruta a traves de la topologfa de red virtual incluyendo cualquier numero de dispositivos de red virtuales con el fin de determinar como ha de procesarse un paquete o flujo dado.

Si la accion determinada es emitir un paquete desde uno o mas puertos virtuales orientados hacia el exterior, el sistema mapea cada puerto virtual orientado hacia el exterior a una interfaz de red correspondiente y un nodo de la red subyacente y luego emitir el paquete desde cada una de las interfaces de red correspondientes.

Los procesos de simulacion descritos en el presente documento se repiten hasta que el motor de decision ha simulado el ultimo dispositivo virtual recorrido por el paquete. El motor de decision proporciona una accion o resultado de simulacion que va a aplicarse al paquete y a paquetes posteriores que coinciden con un patron de cabecera de protocolo de paquete. La accion o resultado de simulacion incluye una modificacion agregada del paquete para modificar la cabecera de protocolo del paquete para que coincida la configuracion de las cabeceras ya que el paquete se emitira por el ultimo dispositivo virtual, basandose en todas las modificaciones aplicadas a lo largo del recorrido de la topologfa de red virtual. De esta manera, el motor de decision determina a traves de la simulacion la modificacion necesaria al paquete de modo que el paquete puede modificarse y enrutarse de manera eficiente a traves de la red.

Tal como se comento anteriormente, el paquete incluye una cabecera de protocolo que tiene una pluralidad de campos. El sistema determina un patron de cabecera de protocolo de paquete usado para identificar paquetes para los que una regla de flujo o accion determinada se aplicara basandose en el resultado de simulacion. En una realizacion, el sistema determina el patron de cabecera de protocolo de paquete identificando cada uno del campo de la cabecera de protocolo que se leyo durante la simulacion de la topolog^a de red virtual y los dispositivos de red virtuales. De esta manera, los campos de la cabecera de protocolo de los que se depende para atravesar la red se identifican de modo que la regla de flujo determinada puede aplicarse a paquetes que deben procesarse de la misma manera. Aquellos campos de la cabecera de protocolo de los que no se depende pueden tratarse como comodines o, de otro modo, excluirse de la consideracion en el proceso de hacer coincidir la cabecera de protocolo de paquetes posteriores con el patron determinado. El patron de cabecera de protocolo de paquete y el resultado de simulacion correspondiente pueden almacenarse en el nodo. En una realizacion, el patron y el resultado de simulacion correspondiente se almacenan como regla de flujo para su uso en un conmutador configurable de flujo configurado para procesar paquetes posteriores que llegan al nodo. Cuando un paquete llega a un nodo para el que no se ha creado una regla de flujo, el sistema puede invocar el motor de decision para realizar una simulacion para el paquete.

El resultado de simulacion producido por el motor de decision es dependiente de la topologfa de red virtual y las configuraciones de dispositivo virtual, al menos para aquellos dispositivos virtuales recorridos durante la simulacion. Cuando la topologfa o configuraciones de dispositivo cambian, el resultado de simulacion determinado anteriormente y las acciones correspondientes que van a aplicarse a un paquete pueden no ser ya correctos. Para dar cabida a tales cambios, el sistema esta configurado para invalidar un patron de cabecera de protocolo de paquete almacenado y el resultado de simulacion almacenado correspondiente tras un cambio en la topologfa de red virtual o configuraciones de dispositivo virtual. En una realizacion, el sistema invalida todos los patrones almacenados y los resultados de simulacion tras detectar un cambio. En otras realizaciones, solo se invalidan aquellos resultados almacenados que dependen del dispositivo virtual cambiado. En un ejemplo, el conjunto recorrido de dispositivos virtuales recorridos durante la simulacion se determina durante la simulacion por el motor de decision. El conjunto recorrido de dispositivos virtuales se asocia entonces con la cabecera de protocolo de paquete y/o el resultado de simulacion. Cuando se detecta un cambio en la configuracion de un dispositivo virtual, pueden invalidarse los resultados de simulacion almacenados asociados con cualquier conjunto recorrido que contiene el dispositivo virtual cambiado. De esta manera, el sistema determino de manera eficiente que reglas de flujo deben invalidarse basandose en un cambio de dispositivo virtual dado. Un metodo de determinar un conjunto recorrido de dispositivos virtuales y unos flujos de invalidacion basandose en un cambio en una configuracion de dispositivo virtual se ilustran adicionalmente en la figura 1. En otras realizaciones, pueden invalidarse o expulsarse flujos cuando la memoria cache es un recurso de espacio limitado. Por ejemplo, el sistema puede seguir localmente (en el primer nodo) todos los motores de decision que estan copiados en memoria cache por el sistema subyacente, seguir una vez de “ultima coincidencia” de una decision que es la ultima vez que un paquete coincidio con un patron de decision y que las acciones de decision se aplicaron al paquete. Entonces, el sistema puede consultar la vez de “ultima coincidencia” de todas las decisiones y expulsar aquellas decisiones que no se han usado en el tiempo mas largo. La consulta de la vez de ultima coincidencia puede realizarse a una frecuencia especificada o puede realizarse segun sea necesario para mantener el tamano de la memoria cache de decisiones almacenadas por debajo de un tamano especificado. El sistema tambien puede eliminar decisiones aleatorias que se crearon “recientemente”. La eliminacion de decisiones aleatorias creadas recientemente puede ser eficiente cuando una mayona de decisiones recientes son para flujos de paquete de corta duracion (en comparacion con decisiones supervivientes mas antiguas que tienen un porcentaje comparativamente mas alto de flujos de larga duracion). Los procesos para invalidar flujos pueden usarse individualmente o en combinacion para gestionar la memoria cache de datos almacenados en el nodo dentro de parametros deseados. El sistema puede ajustar tambien la tasa de invalidaciones o expulsiones basandose en la tasa de nuevas invocaciones del motor de decision, que se correlacionan con la adicion de nuevas decisiones a la memoria cache almacenada.

El sistema tambien esta configurado para hacer converger con trafico correcto, de manera eficiente y con alteracion minima, las decisiones copiadas en memoria cache para que concuerden con respecto a configuraciones de dispositivo virtual actualizadas. La convergencia de decisiones copiadas en memoria cache, que puede caracterizarse como invalidaciones o expulsiones basadas en exactitud de flujos anteriormente almacenados. Tal como se usa en el presente documento, una decision que concuerda, con respecto a una configuracion de red virtual inicial mas algun cambio, es una a la que puede volver a llegarse mediante una nueva invocacion del motor de decision con el mismo paquete de entrada e interfaz de entrada. En cambio, una decision que no concuerda es una decision que no realizara el motor de decision dadas las mismas entradas debido a la nueva configuracion de los dispositivos de red virtuales. En una realizacion, para un tiempo T hay un periodo P limitado dentro del cual todas las decisiones que se copiaron en memoria cache antes del tiempo T concuerdan con el estado de la configuracion de red virtual en o despues del tiempo T. Para hacer converger las decisiones, el sistema indexa las decisiones copiadas en memoria cache de manera local mediante los dispositivos que se simularon para esa decision (estos representan los dispositivos virtuales que recorrio el paquete) y el tiempo en el que se realizo/almaceno en memoria cache la decision. El sistema recibe entonces actualizaciones locales de la configuracion de dispositivo virtual para una actualizacion de configuracion de un primer dispositivo virtual recibida en el tiempo T, espera un tiempo especificado de modo que el numero de decisiones realizadas y almacenadas en memoria cache antes del tiempo T ya se ha reducido mediante expulsiones basadas en espacio, y luego interseca el conjunto de decisiones realizadas/almacenadas en memoria cache antes del tiempo T con el conjunto de decisiones que requirieron simular el primer dispositivo virtual. Las decisiones en el conjunto resultante deben validarse entonces volviendo a invocar el motor de decision con las mismas entradas (y la configuracion actual). Para cualquier decision que haya cambiado, se invalida la decision antigua y se instala/almacena en memoria cache el nuevo resultado de simulacion basado en la configuracion actual actualizada para su uso con paquetes posteriores que coinciden con el flujo.

En otro aspecto, el metodo y sistema informatico dados a conocer en el presente documento incluyen simular uno o mas puentes de aprendizaje de MAC, en los que los puertos exteriores de cada puente se mapean a interfaces de uno o mas nodos de la red subyacente y en los que cada puerto orientado hacia el interior del puente esta conectado a un puerto orientado hacia el interior de un enrutador virtual. El metodo informatico incluye mantener una copia autoritativa de la tabla de aprendizaje de MAC del puente en la base de datos compartida. La tabla de aprendizaje de MAC tambien puede conocerse como base de datos de filtrado dinamico, mapa de direcciones MAC al puerto a traves del cual puede alcanzarse la MAC, en la que una MAC solo puede alcanzarse a traves de uno de los puertos de un puente en un momento cualquiera en una red correctamente configurada. El metodo incluye ademas mantener una copia en memoria cache de la tabla de aprendizaje de MAC del puente en cada nodo que tiene una interfaz que mapea a uno de los puertos orientados hacia el exterior del puente, y en cada nodo que simulo un recorrido del paquete de ese puente. La copia en memoria cache de la tabla de aprendizaje de MAC puede actualizarse cuando cambia la copia autoritativa.

En una realizacion, la invocacion del motor de decision da como resultado la simulacion de una trama de Ethernet que lleva a un primer puerto de un puente de Ethernet, y el sistema carga el estado del puente de Ethernet si ninguna invocacion previa del motor de decision lo ha cargado. Una trama de Ethernet entrante puede tener una direccion MAC de destino de unidifusion. En realizaciones, un metodo incluye ademas detectar que la MAC de destino es una direccion de unidifusion, y determinar si hay una entrada para esa MAC en la tabla de aprendizaje de MAC. Si la tabla de aprendizaje de MAC incluye una entrada que mapea la MAC a un segundo puerto del puente, el sistema determina que el puente simulado emitira tal trama a partir del segundo puerto. Si la tabla de aprendizaje de MAC no incluye una entrada para esa MAC, el sistema determina que el puente simulado emitira la trama a partir de todos sus puertos, excepto aquel en el que llego.

En otra realizacion, la trama de Ethernet entrante tiene una MAC de multidifusion o radiodifusion que indica que la trama debe emitirse desde multiples puertos. Realizaciones del metodo informatico pueden incluir ademas detectar que la MAC de destino es una direccion de multidifusion o radiodifusion y determinar que el puente simulado emitira tal trama a partir de todos sus puertos excepto aquel en el que llego. En aun otra realizacion, la trama de Ethernet entrante tiene una direccion MAC de origen de unidifusion. Si la tabla de aprendizaje de MAC no tiene ninguna entrada para esta MAC, el sistema anade una entrada que mapea esta MAC al puerto de llegada. Entonces, el sistema inicia un recuento de referencia de tal entrada de tabla de aprendizaje de MAC, local para el nodo en el que se produjo la invocacion, en el que el recuento se basa en el numero de decisiones copiadas en memoria cache que dieron como resultado una trama con la misma direccion MAC de origen que llega al mismo puerto. El recuento de referencia de tales decisiones copiadas en memoria cache puede resultar util puesto que el motor de decision no ve todos los paquetes con la misma MAC de origen que llegan al puerto. Por tanto, cuando el numero de tales decisiones copiadas en memoria cache alcanza cero, puede hacerse que caduque (o establecerse para que caduque) la entrada de tabla de aprendizaje de MAC para esta MAC de origen y puerto de llegada. En cada nodo que tiene una copia en memoria cache de la tabla de aprendizaje de MAC del puente (puesto que tiene una interfaz mapeada a un puerto orientado hacia el exterior del puente, o puesto que recientemente simulo el puente) el sistema aprende la actualizacion de la tabla y expulsa cualquier decision copiada en memoria cache que se baso en la ausencia de una entrada para esa MAC en la tabla de aprendizaje de MAC, puesto que esos flujos/paquetes ahora pueden suministrarse al puerto de entrada, en lugar de inundarse en todos los puertos del puente.

En otras realizaciones, la tabla de aprendizaje de MAC puede tener ya una entrada para la direccion MAC y el puerto mapeado es el mismo que el puerto de llegada de la trama entrante actual. Entonces, el sistema puede detectar que existe la entrada de tabla de aprendizaje de MAC y no necesita modificarse. El sistema puede incrementar el recuento de referencia local si esta invocacion del motor de decision da como resultado una decision copiada en memoria cache. Alternativamente, la tabla de aprendizaje de MAC puede tener ya una entrada para la direccion MAC, pero el puerto mapeado puede ser diferente del puerto de llegada de la trama entrante actual. Entonces, el sistema retira la entrada anterior de la tabla de aprendizaje de MAC, y anade una nueva entrada a la tabla de aprendizaje de MAC que asocia la direccion MAC con el puerto de llegada de la trama. En el nodo que es propietario de la interfaz que corresponde al puerto mapeado de la entrada anterior, el sistema toma conocimiento de la retirada de la entrada y expulsa cualquier decision que realiza el recuento de referencia de esa entrada dado que ahora se basan en informacion incorrecta. En cada nodo que tiene una copia en memoria cache de la tabla de aprendizaje de MAC del puente (puesto que tiene una interfaz que corresponde a un puerto orientado hacia el exterior del puente, o puesto que recientemente simulo el puente) aprende las actualizaciones de la tabla y expulsa cualquier decision copiada en memoria cache que se basara en la entrada de tabla de aprendizaje de MAC anterior para esa MAC dado que ahora se basan en informacion incorrecta. Para ilustrar adicionalmente, en la figura 2 se ilustra un metodo para aprendizaje de MAC y en la figura 3 se ilustra un metodo para desaprendizaje de MAC.

En otra realizacion, se proporciona un metodo para reducir paquetes inundados en puentes de Ethernet cuando se conocen por adelantado las direcciones MAC que pueden alcanzarse desde cada uno de los puertos de un puente. Por ejemplo, en el caso de una VM invitada adherida a una de las interfaces de red de un nodo que se mapea a uno de los puertos orientados hacia el exterior de un puente virtual, las direcciones MAC pueden conocerse por adelantado de manera que la tabla de aprendizaje de MAC puede poblarse previamente con las entradas de puerto de MAC conocidas.

En otro aspecto, el metodo informatico reduce los paquetes inundados en una red IP interceptando y respondiendo a peticiones de ARP. El metodo incluye aumentar el estado de un puente con una memoria cache de ARP almacenada en la base de datos compartida. La memoria cache de ARP incluye un mapa de direccion IP de unidifusion a direccion MAC de unidifusion. Como con la tabla de aprendizaje de MAC, la memoria cache de ARP del puente puede poblarse previamente con entradas correspondientes a cualquier enrutador que esta conectado al puente a traves de puertos orientados hacia el interior. Cada entrada puede determinarse examinando uno de los puertos orientados hacia el interior del puente, recuperando la configuracion del puerto homologo, y extrayendo la direccion IP y MAC del puerto homologo. El metodo tambien puede incluir poblar previamente la memoria cache de ARP del puente con cualquier otra entrada que se conoce por adelantado, tal como en un entorno de gestion en la nube en el que a maquinas virtuales invitadas se les asignan direcciones IP y MAC por usuarios o de manera automatica por el sistema. El metodo tambien puede incluir reconocer paquetes de IP y extraer la direccion IP de origen y la direccion MAC de origen de la trama de Ethernet de encapsulamiento y por tanto deducir la correspondencia lP-MAC y anadir la entrada apropiada a la memoria cache de ARP.

En aun otra realizacion, un metodo para simular uno o mas enrutadores IPv4 en el que los puertos orientados hacia el exterior de cada enrutador se mapean a interfaces de uno o mas nodos de la red subyacente, y cada puerto orientado hacia el interior de un enrutador esta conectado a un puerto orientado hacia el interior o bien de otro enrutador virtual o bien de un puente virtual. El metodo incluye mantener una copia autoritativa de la memoria cache de ARP del enrutador (mapa de direccion IP de unidifusion a direccion MAC de unidifusion) en la base de datos compartida, cargar previamente la memoria cache de ARP con los pares de direcciones (IPv4, MAC) de los puertos homologos de todos los puertos orientados hacia el interior del enrutador, mantener una copia autoritativa de la tabla de reenvfo del enrutador (conjunto de reglas/rutas que determinan que puerto de enrutador debe emitir un paquete basandose en escoger la regla con el prefijo de destino de IPv4 coincidente mas preciso y un prefijo de origen coincidente) en la base de datos compartida, mantener una copia en memoria cache de la memoria cache de ARP del enrutador y tabla de reenvfo en cada nodo que tiene una interfaz que mapea a uno de los puertos orientados hacia el exterior del enrutador, y en cada nodo que recientemente simulo un recorrido del paquete de ese enrutador. Un enrutador se ha simulado recientemente en un nodo si ese nodo tiene al menos una decision de motor copiada en memoria cache que requiere simular el enrutador. El metodo tambien puede incluir actualizar la copia en memoria cache de la memoria cache de ARP y la tabla de reenvfo cuando cambia la copia autoritativa en la base de datos compartida. Tras la simulacion de la llegada de un paquete en un enrutador de IPv4, el estado del enrutador puede cargarse en este nodo si no se ha cargado ya ninguna invocacion de motor de decision anterior.

El motor de decision tambien puede simular un paquete de IPv4 que llega a un primer puerto de un enrutador de IPv4. La direccion de destino del paquete de IPv4 entrante puede ser igual a uno de los puertos del enrutador. Entonces, el sistema detectara que el paquete va dirigido a uno de los puertos del enrutador, determinara que el enrutador soltara el paquete si no se reconoce o no se gestiona su protocolo, detectara si el paquete es una peticion de ping (eco de ICMP) y en ese caso generara un paquete de respuesta de ping desde el puerto del enrutador hasta la direccion de origen de IPv4 del primer paquete, e invocara la logica de simulacion del motor de decision para determinar la trayectoria que seguira la respuesta de ping desde el puerto a traves de la red virtual. Si la logica de simulacion determina que la respuesta de ping saldra de la red virtual en un puerto orientado hacia el exterior espedfico (de cualquier dispositivo), entonces el sistema mapeara ese puerto a su interfaz correspondiente y nodo de red subyacente y pedira que el sistema de llamada emita el paquete de respuesta de ping desde esa interfaz. Alternativamente, la direccion de destino del paquete de IPv4 entrante puede no ser una de las direcciones de los puertos del enrutador, en cuyo caso el sistema consulta la tabla de reenvfo del enrutador para determinar la ruta mas coincidente dadas las direcciones de IPv4 de origen y destino del paquete. Cuando no se encuentra ninguna ruta coincidente, el sistema determina que tras recibir el primer paquete el enrutador en cuestion soltara el paquete y respondera con un error de ICMP, tal como ruta no alcanzable, e invoca la logica de simulacion del motor de decision para determinar la trayectoria que seguira el error de ICMP desde el puerto hasta la red virtual. Si la logica de simulacion determina que el error de ICMP saldra de la red virtual en un puerto orientado hacia el exterior espedfico, entonces el sistema mapea ese puerto a su interfaz correspondiente y nodo de red subyacente y pide que el sistema de llamada emita el paquete de error de ICMP desde esa interfaz. De una manera similar, puede generarse un paquete de error de ICMP cuando la ruta coincidente especifica que el destino esta prohibido de manera administrativa.

Cuando la simulacion determina que la ruta mas coincidente especifica que el paquete se reenvfe a traves de puerto de enrutador (por ejemplo, puerto de siguiente salto), el sistema puede cambiar la direccion Ethernet de origen del paquete por la MAC del puerto de siguiente salto. Si la pasarela de siguiente salto de la ruta es nula (lo que significa que la direccion de destino esta en la misma subred L3 que el puerto de siguiente salto), el sistema consulta la memoria cache de ARP local para determinar la MAC correspondiente al destino de IPv4 del paquete y cambia la direccion Ethernet de destino del paquete por la MAC. Si la pasarela de siguiente salto de la ruta no es nula (lo que significa que el paquete debe reenviarse para pasar a traves de al menos un enrutador mas antes de alcanzar su destino), el sistema consulta la memoria cache de ARP local para determinar la MAC correspondiente a la direccion IPv4 de la pasarela y cambia la direccion Ethernet de destino del paquete por esa MAC. El sistema puede determinar ademas que tras recibir el primer paquete (que puede haberse modificado tras la simulacion de dispositivos virtuales anteriormente recorridos), el enrutador en cuestion modificara adicionalmente el paquete tal como se describe y lo emitira a partir del puerto de siguiente salto.

Cuando la memoria cache de ARP no contiene una entrada para la direccion IPv4 consultada (tal como cuando el puerto de siguiente salto es un puerto orientado hacia el exterior), el sistema puede implementar un metodo que incluye generar un paquete de peticion de ARP para la direccion IPv4 deseada, y anadir un par (IPv4, MAC nula), indicado con un momento de ultimo envfo establecido al momento actual, a la base de datos compartida para indicar cuando se envio la ultima peticion de ARP para esa IPv4. El metodo puede incluir ademas mapear el puerto de siguiente salto orientado hacia el exterior a su interfaz correspondiente y nodo de red subyacente, pedir que el sistema de llamada emita una peticion de ARP desde esa interfaz, y repetir periodicamente la peticion de que se emita el paquete de peticion de ARP desde esa interfaz. En realizaciones, la peticion de ARP se suministrara por el sistema de base como cualquier otro paquete que entro en la red virtual, y por tanto posiblemente a lo largo de un tunel hasta un nodo diferente. El metodo puede continuar hasta que se agota un tiempo asignado, y luego generar un mensaje de error de ruta ICMP inalcanzable en respuesta al primer paquete. Alternativamente, el metodo continua hasta que se recibe una actualizacion para la copia local de la memoria cache de ARP que incluye una entrada (IPv4, MAC) para la direccion IPv4 deseada, y luego incluye cambiar la direccion Ethernet de destino del paquete por la MAC de esa entrada, y determinar que el enrutador simulado modificara el paquete tal como se describe y lo emitira desde el puerto de siguiente salto. En realizaciones, la respuesta de ARP se recibira en un nodo diferente del que procesa el primer paquete si la peticion de ARP se emitio a partir de un puerto que se mapea a una interfaz en un nodo diferente. De esta manera, el motor de decision puede aprender la entrada de ARP a traves de la memoria cache de ARP en vez de recibiendo directamente la respuesta de ARP. Cuando se agota un tiempo asignado y no se encuentra la entrada de memoria cache de ARP, el sistema puede responder con un error de ruta de ICMP inalcanzable tal como se describio anteriormente.

En otra realizacion, una invocacion del motor de decision da como resultado la simulacion de un paquete de peticion de ARP que llega a un primer puerto de un enrutador IPv4 y en la que la direccion de protocolo objetivo del ARP (“TPA”) es la direccion IPv4 del puerto de llegada/primer puerto. Entonces, el sistema puede generar un paquete de respuesta de ARP con una direccion de hardware de origen (“SHA") establecida a la direccion MAC del puerto de llegada, invocar la logica de simulacion del motor de decision para determinar la trayectoria que seguira la respuesta de ARP desde el puerto de llegada del primer paquete a traves de la red virtual. La respuesta de ARP puede emitirse de una manera similar a las respuestas anteriormente comentadas. Alternativamente, la simulacion de motor de decision puede determinar que el enrutador simulado soltara el paquete de peticion de ARP.

En otra realizacion, una invocacion del motor de decision da como resultado la simulacion de un paquete de respuesta de ARP que llega a un primer puerto de un enrutador IPv4. El sistema puede detectar si la respuesta de ARP es en respuesta a una peticion de ARP que se genero por el enrutador. En una realizacion, el sistema comprueba que hay una entrada (IPv4, MAC) en la memoria cache de ARP, indicada con un momento de ultimo envfo reciente, aunque la propia MAC sea nula. Si no hay ninguna entrada, el sistema determina que el enrutador soltara una peticion de ARP no solicitada de este tipo con el fin de bloquear ataques de denegacion de servicio. Alternativamente, el sistema extrae la direccion de hardware de origen, una direccion MAC, y la direccion de protocolo de origen, una direccion IPv4, a partir de la respuesta de ARP y actualiza la memoria cache de ARP. La memoria cache de ARP puede actualizarse localmente y en la base de datos compartida con la entrada (IPv4, MAC).

En otro aspecto, el sistema informatico dado a conocer en el presente documento esta configurado para realizar un metodo que incluye simular filtros de entrada y salida de un dispositivo virtual, en el que los filtros incluyen reglas de filtrado individuales que estan organizadas en listas que pueden hacer referencia unas a otras mediante reglas de salto. El metodo tambien puede incluir especificar una condicion que puede leer y aplicar logica a cualquiera de o todos los campos de las cabeceras de protocolo de red L2-L4 de un paquete, y especificar una accion que debe ejecutarse (por ejemplo soltar, aceptar para procesamiento adicional) cuando un paquete coincide con la condicion.

En una realizacion, el metodo comprende ademas mantener las reglas de filtrado para el filtro de entrada/salida de cada dispositivo en la base de datos compartida, mantener una copia local de las reglas de filtrado de un dispositivo en cualquier nodo que ha simulado recientemente el dispositivo, actualizar la copia local de las reglas de filtrado de un dispositivo cuando la copia autoritativa de las reglas cambia en la base de datos compartida, y/o volver a validar decisiones de reenvfo de flujo copiadas en memoria cache de manera local que requirieron simulacion de un dispositivo, cuando se modifican los filtros de ese dispositivo. El metodo tambien puede incluir simular reglas de filtrado que coinciden en cuanto al estado de conexion segun el flujo, en el que el estado de conexion segun el flujo se sigue independientemente por cada dispositivo simulado, y en el que el conjunto de valores de estado de conexion depende del protocolo de transporte (L4) del paquete. En una realizacion, el sistema esta configurado para realizar un metodo que incluye tener espacio dedicado en la base de datos central para almacenar el estado de conexion segun el dispositivo y el flujo, tras comenzar la simulacion de un dispositivo, consultar la base de datos central usando la firma de flujo del paquete para recuperar el estado de conexion. En una realizacion, la firma de flujo se calcula adjuntando estos campos en este orden: el ID de dispositivo del dispositivo simulado, el campo de origen (por ejemplo, IP) de la cabecera L3 del paquete, el campo de destino L3, el tipo de protocolo L4 (por ejemplo TCP), el campo de origen de la cabecera L4, el campo de destino de cabecera L4. Si no se encuentra ningun estado de conexion en la base de datos central, entonces el paquete constituye un nuevo flujo cuyo estado de conexion es de manera implfcita el valor “inicio” del conjunto de estados para el protocolo de red de este paquete. El metodo tambien puede exponer el valor de estado de conexion para su coincidencia mediante las reglas de filtrado de este dispositivo. Antes de terminar la simulacion del dispositivo, y si la simulacion determina que el dispositivo reenviara el paquete, se establece el estado de conexion para la firma de flujo de este paquete y la firma de flujo de retorno de este paquete segun las reglas de transicion para el conjunto de valores de estado de conexion para el protocolo de red de este paquete. En una realizacion similar a la anterior, la firma de flujo de retorno del paquete se calculara adjuntando estos valores en este orden: el ID de dispositivo del dispositivo simulado, el campo de destino de la cabecera L3 del paquete, campo de origen L3, tipo de protocolo L4, campo de destino de cabecera L4, y campo de origen de cabecera L4. La firma de flujo directo y la firma de flujo de retorno tambien pueden definirse usando campos adicionales que pueden ser utiles en una aplicacion dada. Cuando la decision copiada en memoria cache para el flujo directo caduca, el sistema puede planificar la retirada tanto del estado de conexion asociado con ese flujo como del flujo de retorno. Para ilustrar adicionalmente, en la figura 4 se ilustra una realizacion de un metodo para seguir conexiones.

En una realizacion, el metodo incluye ademas simular reglas de filtrado que coinciden con el estado de conexion del flujo del paquete, en el que el estado de conexion segun el flujo se comparte entre todos los dispositivos simulados, y en el que el conjunto de estados de conexion depende del protocolo de transporte (L4) del paquete. De esta manera, el estado de conexion se considera una propiedad del flujo, independiente de la trayectoria seguida a traves de la red de dispositivos. El resultado es que todos los dispositivos simulados en una unica llamada al motor de decision estaran de acuerdo en cuanto a los estados de conexion del flujo de retorno y del flujo del paquete; y dos dispositivos cualesquiera simulados en dos llamadas diferentes al motor de decision estaran de acuerdo en cuanto a esos estados de conexion si al menos uno de lo siguiente es cierto: el flujo de retorno entra en la red virtual en el mismo dispositivo desde el que se emite el flujo directo; los paquetes de flujo de retorno tienen direcciones L3 publicas, es decir globalmente unicas. En realizaciones, la base de datos compartida incluye espacio dedicado para almacenar el estado de conexion segun el flujo. Tras comenzarse la simulacion del recorrido del paquete de la red virtual, puede consultarse la base de datos compartida usando la firma de flujo del paquete. La firma de flujo puede depender del ID de dispositivo del primer dispositivo simulado si al menos uno del origen/destino L3 no es publico, es decir globalmente unico. La firma de flujo tambien puede depender del campo de origen (por ejemplo, IP) de la cabecera L3 del paquete, campo de destino L3, tipo de protocolo L4 (por ejemplo TCP), campo de origen de la cabecera L4, y campo de destino de cabecera L4. Si no se encuentra ningun estado de conexion en la base de datos central, entonces el paquete constituye un nuevo flujo cuyo estado de conexion es de manera implfcita el valor de inicio del conjunto de estados para este el protocolo de red de este paquete. Entonces puede exponerse el valor de estado de conexion para su coincidencia por las reglas de filtrado de cualquier dispositivo simulado. Antes de terminar la simulacion del recorrido del paquete de la red virtual, y si la simulacion determina que el paquete se emitira finalmente desde algun puerto virtual, se establece el estado de conexion para la firma de flujo de este paquete y la firma de flujo de retorno de este paquete segun las reglas de transicion para el conjunto de valores de estado de conexion para el protocolo de red de este paquete. El estado de conexion se escribe en la base de datos compartida antes de tunelar/reenviar el paquete (y por tanto antes de devolver la decision) con el fin de evitar una condicion de carrera en la que se simula un paquete procedente del flujo de retorno y desencadena una consulta del estado de conexion antes de haberse completado la escritura del estado de conexion en la base de datos compartida. La firma de flujo de retorno del paquete puede calcularse de una manera similar. Tal como se indico anteriormente, cuando caduca la decision copiada en memoria cache para el flujo directo, se planifica la retirada tanto del estado de conexion asociado con ese flujo como del flujo de retorno.

En otro aspecto, el metodo incluye reducir el tiempo de simulacion evitando consultar o escribir un estado de conexion cuando este estado no se usara por la simulacion del paquete o por la simulacion de un paquete de retorno, retrasar la consulta del estado de conexion para el flujo del paquete hasta que una regla de filtrado en algun dispositivo simulado necesite leer tal estado, determinar si la trayectoria probable para el paquete de retorno incluira simular una regla de filtrado que necesite leer el estado de conexion del flujo de retorno, y en caso negativo omitir la escritura del estado de conexion de flujo tanto directo como de retorno en la base de datos compartida. En realizaciones, el estado de conexion se mantiene en la base de datos compartida de modo que si cualquier paquete del mismo flujo llega a una interfaz de un segundo nodo en un momento posterior, el motor de decision del segundo nodo llegara a la misma decision sobre como tratar ese flujo (en ausencia de cambios en la configuracion de red virtual). Esto es necesario para conservar la integridad de un flujo cuando sus paquetes llegan a las interfaces de mas de un nodo de la red subyacente debido a decisiones de enrutamiento externas. Esas decisiones de enrutamiento pueden estar relacionadas o no con la inalcanzabilidad percibida o real de la interfaz de un nodo.

En todavfa otras realizaciones, el sistema esta configurado para realizar una simulacion de traduccion de direccion de red (es decir L3) y de transporte (es decir L4) para un dispositivo virtual. De manera similar el sistema esta configurado para simular traducciones inversas de las direcciones de red y protocolo de un dispositivo virtual. Estos procesos pueden denominase de manera colectiva “NAT”. En diversas realizaciones, las reglas de NAT individuales pueden seguir o preceder o estar intercaladas con reglas de filtrado, especificar una condicion que puede leerse y aplicar logica a cualquiera de o todos campos de las cabeceras de protocolo de red L2-L4 de un paquete, especificar como deben traducirse o traducirse de manera inversa los campos L3 y L4 cuando un paquete coincide con la condicion, y/o especificar una accion que va a ejecutarse cuando se ha producido la traduccion (por ejemplo aceptar para procesamiento adicional por parte del dispositivo, continuar procesando en el conjunto de reglas). El metodo puede incluir ademas mantener las reglas de traduccion para el filtro de entrada/salida de cada dispositivo en la base de datos compartida, mantener una copia local de las reglas de traduccion de un dispositivo en cualquier nodo que ha simulado recientemente el dispositivo, y actualizar la copia local de las reglas de traduccion de un dispositivo cuando la copia autoritativa de las reglas cambia en la base de datos compartida. Durante la simulacion del dispositivo, si el procesamiento de paquete alcanza la regla de NAT, el metodo incluye determinar si el paquete (posiblemente ya modificado mediante dispositivos o reglas anteriores) satisface la condicion de la regla y, en caso afirmativo, modificar el paquete segun la traduccion o traduccion inversa especificada por la regla. Decisiones de reenvfo de flujo copiadas en memoria cache de manera local que requieren simulacion de un dispositivo pueden entonces validarse de nuevo cuando se modifican las traducciones de ese dispositivo.

En otro aspecto, el sistema implementa un dispositivo virtual ffsicamente distribuido que soporta NAT de destino con estado, en el que algunas reglas de NAT permiten una eleccion de objetivo de traduccion para direcciones de destino L3 y L4 y especifican una polftica para realizar la eleccion entre objetivos de traduccion. En realizaciones, el sistema puede almacenar la eleccion de traduccion para cada flujo directo en la base de datos compartida, usando como claves las firmas de flujo tanto directo como de retorno. La firma de flujo directo puede estar compuesta por estos valores en este orden: el ID del dispositivo virtual, la direccion de origen L3 del paquete, direccion de destino L3, numero de protocolo L4, direccion de origen L4 y direccion de destino L4. La firma de flujo de retorno puede estar compuesta por estos valores en este orden: el ID del dispositivo virtual, la direccion L3 elegida por la traduccion, la direccion de origen L3 del paquete, numero de protocolo L4, la direccion L4 elegida por la traduccion, la direccion de origen L4 del paquete. La traduccion almacenada puede codificar las direcciones de destino L3 y L4 originales del paquete asf como las direcciones de destino L3 y L4 elegidas para la traduccion. El metodo incluye ademas durante la simulacion de un dispositivo, si el procesamiento de paquete alcanza una regla de NAT de este tipo (que permite una eleccion de direcciones de destino) y satisface la condicion de la regla, componer una clave tal como se describio anteriormente para la firma de flujo directo y consultar la base de datos compartida para determinar si ya se ha almacenado una traduccion (y por tanto ya se ha realizado la eleccion de direcciones traducidas) mediante una ejecucion de motor de decision anterior (en el nodo de red subyacente local o alguno remoto). Si se encuentra una traduccion almacenada de este tipo en la base de datos compartida, entonces se modifican las direcciones de destino L3 y L4 del paquete para dar las direcciones L3 y L4 elegidas, y luego se continua la simulacion. Si no se encuentra una traduccion almacenada de este tipo en la base de datos compartida, entonces se realiza una eleccion segun la polftica especificada, se modifican las direcciones de destino L3 y L4 del paquete segun esa eleccion, se almacena la eleccion de traduccion en la base de datos compartida tal como se describio anteriormente, y luego se continua la simulacion. Durante la simulacion de un dispositivo, si el procesamiento de paquete alcanza una regla de traduccion inversa que especifica invertir una eleccion, y el paquete satisface la condicion de la regla, entonces se supone que el paquete es un paquete de retorno de un flujo directo traducido, se compone la clave que corresponde a la firma de flujo de retorno, y se consulta la base de datos compartida para determinar si se ha almacenado una traduccion para ese flujo de retorno. La firma de flujo de retorno puede estar compuesta por estos valores en este orden: el iD del dispositivo virtual, la direccion de origen L3 del paquete, direccion de destino L3, numero de protocolo L4, direccion de destino L4 y direccion de origen L4. Si se encuentra una traduccion almacenada de este tipo en la base de datos, entonces se aplica en sentido inverso a este paquete modificando las direcciones de origen L3 y L4 del paquete para dar las direcciones L3 y L4 originales de la traduccion almacenada, y luego se continua la simulacion. Si no se encuentra una traduccion almacenada de este tipo en la base de datos compartida, entonces la suposicion de que el paquete es un paquete de retorno de un flujo directo traducido es incorrecta, por tanto no se necesita aplicar ninguna traduccion inversa, y por tanto se continua la simulacion como si no se hubiera satisfecho la condicion de la regla inversa. De esta manera, el sistema y metodo permiten almacenar las traducciones en una base de datos compartida y abordar condiciones de carrera de manera que el dispositivo virtual se comporta correctamente y no puede distinguirse de un dispositivo de hardware que funciona correctamente, pero con una disponibilidad aumentada del dispositivo virtual en comparacion con el dispositivo de hardware.

En otro aspecto, algunas reglas de NAT permiten una eleccion de objetivos de traduccion para las direcciones de origen L3 y L4 y especifican una polftica para realizar esa eleccion. En realizaciones, el sistema puede almacenar la eleccion de traduccion para cada flujo directo en la base de datos compartida, usando como claves las firmas de flujo tanto directo como de retorno. La traduccion almacenada codifica las direcciones de origen L3 y L4 originales del paquete asf como las direcciones de origen L3 y L4 elegidas para la traduccion. Durante la simulacion de un dispositivo, si el procesamiento de paquete alcanza una regla de NAT de este tipo (que permite una eleccion de direcciones de origen) y satisface la condicion de la regla, se compone una clave tal como se describio anteriormente para la firma de flujo directo y se consulta la base de datos compartida para determinar si ya se ha almacenado una traduccion (y por tanto ya se ha realizado la eleccion de direcciones traducidas) mediante una ejecucion de motor de decision anterior (en el nodo de red subyacente local o alguno remoto). Si se encuentra una traduccion almacenada de este tipo en la base de datos compartida, entonces las direcciones de origen L3 y L4 del paquete se modifican para dar las direcciones L3 y L4 elegidas, y luego se continua la simulacion. Si no se encuentra una traduccion almacenada de este tipo en la base de datos compartida, entonces se realiza una eleccion segun la polftica especificada, se construye la firma de flujo de retorno segun esa eleccion y se consulta la base de datos para garantizar que no hay ninguna traduccion almacenada mediante esa clave, se repite la eleccion y comprobacion de base de datos hasta que la base de datos no devuelve ninguna coincidencia para la clave, despues se modifican los campos de origen L3 y L4 del paquete segun la eleccion final, se almacena la eleccion de traduccion en la base de datos compartida tal como se describio anteriormente, y luego se continua la simulacion. La comprobacion para detectar la clave de flujo de retorno en la base de datos puede usarse para determinar la exactitud y para evitar ambiguedad en el enrutamiento de flujos de retorno. Durante la simulacion de un dispositivo, si el procesamiento de paquete alcanza una regla de traduccion inversa que especifica invertir una eleccion, y el paquete satisface la condicion de la regla, entonces se supone que el paquete es un paquete de retorno de un flujo directo traducido, se compone una clave que corresponde a la firma de flujo de retorno, y se consulta la base de datos compartida para determinar si se ha almacenado una traduccion para ese flujo de retorno. Si se encuentra una traduccion almacenada de este tipo en la base de datos, entonces se aplica la traduccion almacenada en sentido inverso a este paquete modificando las direcciones de destino L3 y L4 del paquete para dar las direcciones L3 y L4 originales de la traduccion almacenada, y luego se continua la simulacion. Si no se encuentra una traduccion almacenada en la base de datos compartida, entonces la suposicion de que el paquete es un paquete de retorno de un flujo directo traducido es incorrecta, por tanto no se necesita aplicar ninguna traduccion inversa, y por tanto la simulacion puede continuarse como si no se hubiera satisfecho la condicion de la regla inversa.

En aun otro aspecto, el numero de intentos que intentos que seleccionan traducciones de direccion L3 y L4 que ya estan en la base de datos puede reducirse segmentando los intervalos de direcciones L3 y L4 en bloques que pueden reservarse mediante nodos individuales. Cuando se eligen las direcciones L3 y L4 para la traduccion, un nodo comprueba localmente si hay combinaciones de direcciones sin usar en su propio bloque, de lo contrario reserva un nuevo bloque. Con frecuencia, esto da como resultado una comunicacion de ida y vuelta en la base de datos. Si el nodo no puede reservar un nuevo bloque y no tiene ninguna combinacion de direcciones L3 y L4 sin usar disponible para una nueva traduccion, entonces intenta usar una combinacion de direcciones L3 y L4 aleatoria dentro de las limitaciones especificadas por la regla.

En realizaciones, los protocolos de enrutamiento funcionan a nivel global ya que estan disenados y estudiados en cuanto a sus efectos globales sobre el establecimiento y mantenimiento de conectividad y estabilidad de red. Sin embargo, cualquier enrutador individual solo necesita mantener una discusion de protocolo de enrutador con sus homologos inmediatos. Una organizacion puede hacer funcionar sesiones de protocolo de enrutamiento con sus redes vecinas por una variedad de motivos. Como ejemplos, puede aconsejar a vecinos sobre la mejor trayectoria para entrar en su red para bloques de direcciones espedficos, y puede ajustar sus propias decisiones de reenvfo basandose en condiciones de red externa. Estas sesiones de enrutamiento son inherentemente con estado, tanto puesto que la discusion puede realizarse a lo largo de una conexion (tal como TCP) en contraposicion a un protocolo sin conexion (tal como UDP) como puesto que el objetivo es intercambiar el estado que luego usan los enrutadores para decidir si reenviar paquetes. En realizaciones, el sistema usa un modelo de aplicacion para implementar protocolos de enrutamiento. En un modelo de aplicacion, se proporciona aislamiento l2 para el conjunto de redes virtuales que se ejecutan en la capa base. En el caso de los protocolos de enrutamiento, el modelo de aplicacion puede ser beneficioso puesto que el protocolo de enrutamiento es una parte espedfica de logica y una en la que el propio dispositivo virtual es el origen y destino de trafico. En una realizacion, en lugar de poner un enrutador L3 completo en una aplicacion, solo se pone en una aplicacion el protocolo de enrutamiento entre un puerto virtual y algun homologo externo. De esta manera, el sistema es mas tolerante a fallos ya que aunque la aplicacion puede ser un unico punto de fallo, no importa, los protocolos de enrutamiento tienen esto en cuenta permitiendo multiples sesiones entre homologos a lo largo de multiples puertos.

El sistema puede estar configurado ademas para soportar protocolos de enrutamiento (por ejemplo BGP, iBGP, OSPF) en enrutadores IPv4 virtuales implementando un metodo que incluye almacenar parametros de configuracion para un protocolo de enrutamiento deseado y sesion por homologos como parte de la configuracion del puerto virtual a traves del cual el enrutador establecera la sesion con su homologo. Esta informacion puede almacenarse en la base de datos compartida. El metodo tambien puede incluir almacenar las rutas notificadas deseadas con la configuracion de sesion de protocolo de enrutamiento en la base de datos compartida, cuando un nodo de red subyacente tiene una interfaz publica que se mapea a un puerto virtual con configuracion para una sesion de protocolo de enrutamiento, el nodo lanza localmente un programa residente de protocolo de enrutamiento en un contenedor (por ejemplo en una VM). El contenedor obtiene una interfaz “privada” en el anfitrion, y los nodos establecen decisiones de reenvfo que permiten que paquetes procedentes de esa sesion de protocolo de enrutamiento, y opcionalmente algunos otros flujos tales como ARP e ICMP, fluyan entre el contenedor y el homologo evitando el motor de decision. El metodo tambien puede incluir configuracion de sesion de protocolo de enrutamiento en un puerto que implica que los paquetes del homologo llegaran a la interfaz de nodo subyacente correspondiente. De manera similar, paquetes de sesion procedentes del puerto de enrutador virtual hacia el homologo deben emitirse a traves de la interfaz de nodo subyacente correspondiente. Sin embargo, el trafico de red desde el homologo hasta la red virtual tambien llegara a la misma interfaz, y el trafico desde la red virtual que la tabla de reenvfo del enrutador virtual indica que debe pasar a traves del homologo debe emitirse por la misma interfaz. El primer paquete de cada flujo regular (flujo de protocolo no de enrutamiento) dara como resultado una llamada al motor de decision. En vez de eso, los paquetes de los flujos de protocolo de enrutamiento evitan el motor de decision. Los que llegan a la interfaz publica se emiten directamente desde la interfaz privada y viceversa. El nodo tambien sondea el contenedor tanto para forzar las rutas notificadas del puerto virtual para esa sesion de protocolo de enrutamiento como para ver las rutas aprendidas por el programa residente de protocolo de enrutamiento que se ejecuta en el contenedor (es decir, las rutas notificadas por el homologo). El nodo procesa (por ejemplo agrega) las rutas notificadas por el homologo y las anade a la tabla de reenvfo del enrutador virtual tras establecer su puerto de salida al ID del puerto virtual que tiene la configuracion de sesion de protocolo de enrutamiento. Si el contenedor o sesion presenta un fallo, el nodo retira todas de tales rutas que puede haber anadido el mismo a la tabla de reenvfo. El resultado es que el homologo percibe el puerto del enrutador como si enviara y recibiera tanto trafico regular (anfitrion final) como trafico de sesion de protocolo de enrutamiento. Dado que el trafico de sesion de protocolo de enrutamiento se configura segun el puerto, un enrutador IPv4 virtual puede tener mas de un puerto con una sesion de protocolo de enrutamiento configurada con uno o mas homologos. Mapeando esos puertos virtuales a interfaces en diferentes nodos de red subyacente, el enrutador virtual no es un unico punto de fallo como un enrutador ffsico. Esto mejora adicionalmente la tolerancia a fallos del sistema en comparacion con sistemas anteriormente disponibles.

En aun otro aspecto, el sistema proporciona metodos para implementar o imitar una red privada virtual (“VPN”). En una realizacion, se proporciona un metodo para enlazar un dispositivo virtual a una red remota en una parte diferente de Internet que permite que el dispositivo virtual intercambie paquetes con la red remota como si estuviera ffsicamente conectado, y su enlace fuera seguro y privado. De esta manera, los elementos ajenos no pueden ver el trafico de enlace ni inyectar trafico en el enlace. El metodo puede incluir permitir configuraciones de puertos de dispositivo L2 y L3 virtual indicadas con un identificador de un objeto de configuracion de VPN, almacenadas en la base de datos compartida. Pueden asignarse configuraciones de VPN a nodos de red subyacente espedficos, o nodos de red subyacente pueden competir por conseguir un enganche en una configuracion de VPN en la que la adquisicion de un enganche en una configuracion VPN indica que el propietario del enganche es responsable de gestionar el enlace de VPN correspondiente. En este ultimo caso, el fallo de un nodo da como resultado la perdida del enganche por ese nodo y por tanto la desconexion del enlace de VPN en ese nodo si el nodo todavfa sigue activo. Por tanto, la adquisicion del enlace de VPN por otro nodo es posible. Una configuracion de VPN puede incluir un identificador de puerto privado. El puerto privado identifica un puerto virtual en el dispositivo que debe enlazarse a la red remota. El nodo de red subyacente al que se asigna la VPN localmente crea una interfaz de red logica y la mapea al identificador de puerto privado. Despues lanza un programa residente de gestion de VPN (por ejemplo OpenVPN) dentro de un contenedor y enlaza el contenedor con la interfaz recien creada. Por tanto, el trafico emitido por el nodo a traves de esa interfaz (es decir, emitido por la red virtual desde el puerto privado) llega al programa residente de gestion de VPN que a su vez lo cifra y lo reenvfa al sitio remoto. Cuando la configuracion de VPN especifica que el programa residente de gestion de VPN dentro del contenedor debe reenviar trafico cifrado al sitio remoto a traves de la propia conexion en red del nodo de red subyacente, el programa residente de gestion de VPN en el contenedor debe actuar por tanto como cliente de VPN (puesto que el nodo de red subyacente puede no tener una direccion IPv4 publica). Por tanto, la configuracion de VPN especifica la direccion iP publica del programa residente de gestion de VPN remoto a la que debe conectarse el programa residente local. En otro aspecto, todos los nodos de red subyacente pueden no tener acceso directo a Internet y por tanto el trafico de VPN cifrado debe volver a entrar en la red virtual para tunelarse hasta un dispositivo virtual que tiene un enlace ascendente conectado a Internet (por ejemplo, un enrutador de borde L3 con un puerto habilitado para BGP). En una realizacion, la configuracion de VPN especifica un puerto publico, que identifica un puerto virtual en un dispositivo virtual que puede reenviar paquetes (directa o indirectamente) a Internet. La configuracion de VPN tambien especifica si el programa residente de VPN local debe actuar como servidor en una direccion IPv4 y puerto TCP (o UDP) espedficos, o cliente que se conecta a una direccion IPv4 y puerto TCP o UDP remotos. El nodo al que se asigna la VPN crea una interfaz de red logica local, la mapea al puerto virtual publico, y la conecta al contenedor de programa residente de gestion de VPN. El programa residente de VPN esta configurado para enviar su trafico cifrado/tunelado desde esa interfaz, y recibira trafico cifrado desde el sitio remoto de esa interfaz.

En aun otro aspecto, el sistema proporciona capacidades de DHCP en la red virtual y puede configurar anfitriones (ffsicos o virtuales) que tienen acceso a la red virtual. De esta manera, no se necesita ningun servidor de DHCP individual, ni tampoco se necesita simular uno en un dominio L2 individual. La configuracion de DHCP puede extraerse a partir de dominios L2 y definirse simplemente como un recurso que puede asociarse con un puerto virtual. Cuando un mensaje de peticion o descubrimiento de DHCP llega a un puerto virtual (es decir llega a una interfaz correspondiente al puerto exterior de un dispositivo virtual), el motor de decision de simulacion de red del sistema comprueba la configuracion del puerto para ver si hay una configuracion de DHCP asociada. Si es asf, el motor de decision usa la configuracion de DHCP asociada para construir respuestas (ofertas y respuestas de DHCP, respectivamente) a esos mensajes y le indica al nodo que emita esos paquetes desde la interfaz en la que llego la peticion. Alternativamente, el motor de decision simula el recorrido del paquete de la red como para cualquier otro paquete de red que llega a un puerto virtual. Con respecto a esto, DHC^pes otro protocolo transportado por UDP, que a su vez es un L4 que se ejecuta en IP. Este enfoque permite disenar recursos de DHCP independientemente de la topologfa de red, y mas espedficamente, independientemente de dominios L2. Por tanto, los recursos de DHCP pueden compartirse a traves de conjuntos arbitrarios de puertos segun las necesidades del usuario. En realizaciones, el sistema almacena recursos de DHCP en la base de datos compartida.

En una realizacion, se proporciona un recurso de DHCP. El recurso de DHCP incluye configuraciones de DHCP definidas por un conjunto de opciones con valores correspondientes. El recurso de DHCP tambien incluye un conjunto de direcciones IP dinamicas, y posiblemente un conjunto de asignaciones estaticas de direcciones MAC a direcciones IPv4. Los componentes del recurso de DHCP pueden agruparse y asociarse con cualquier puerto exterior de dispositivo virtual. El sistema puede usar un recurso de DHCP en un metodo que incluye almacenar las definiciones de recurso de DHCP en la base de datos compartida, almacenar el mapeo de puerto virtual exterior a recurso de DHCP en la base de datos compartida, usar el motor de decision para identificar paquetes de DHCP que llegan a un puerto virtual, y determinar si el puerto virtual se mapea a un recurso de DHCP. Si el puerto virtual no se mapea a un recurso de DHCP, se usan los metodos anteriormente descritos para decidir como debe gestionarse el paquete. Si el puerto virtual se mapea a un recurso de DHCP, se usa la definicion de recurso de DHCP para construir la respuesta logica al paquete segun el protocolo de DHCP y segun la direccion MAC del remitente. Cuando el remitente esta pidiendo una direccion IPv4, el sistema comprueba adicionalmente si existe una asignacion estatica para la direccion MAC del remitente y devuelve esa direccion IPv4 como la direccion IP ofrecida. Cuando el remitente esta pidiendo una direccion IPv4 y el recurso de DHCP no contiene ninguna asignacion de direccion IPv4 estatica, el sistema comprueba si el recurso define un conjunto de direcciones IPv4 asignadas de manera dinamica. Si es asf, y si hay direcciones no reservadas en el conjunto, se reserva una de las direcciones en nombre del cliente (identificada por direccion MAC), y se construye el mensaje de respuesta de DHCP que debe emitirse a traves del puerto exterior que recibio la peticion. Las reservas de direcciones IPv4 a partir de un conjunto asignable de manera dinamica definido en un recurso de DHCP pueden almacenarse en la base de datos compartida para prevenir colisiones o reutilizacion. La reserva incluye un alquiler que puede renovarse mediante una peticion del cliente. Cuando se renueva un alquiler, el tiempo de caducidad del alquiler puede actualizarse por el motor de decision para mantener el alquiler durante un periodo de tiempo definido.

En otra realizacion, el sistema implementa transferencia de estado representacional (tambien denominada REST API). La REST API puede usarse por el sistema y titulares del sistema para inspeccionar, monitorizar y modificar la red virtual, incluyendo la topologfa de red virtual. En realizaciones, la REST API proporciona control de acceso basado en funciones y es consciente de quien es propietario de cada parte de la topologfa virtual. La REST API tambien puede ser consciente de las funciones y capacidades de uno o mas titulares. En un ejemplo, un titular puede crear su propio enrutador y conmutador virtual, y gestionar todos los aspectos usando la REST API. En algunos casos, tales como en nubes lasS, puede haber un titular, tal como un titular de proveedor de servicios, que tiene un conjunto de direcciones IP globales que puede alquilar a otros titulares. En tales sistemas, el titular de proveedor de servicios puede crear un puerto orientado hacia el interior y dar a otro titular la capacidad de enlazarse con ese puerto tal como se describio anteriormente.

Para fines de ilustracion, en las figuras 13 y 14 se representan realizaciones de sistemas configurados para implementar uno o mas de los metodos dados a conocer en el presente documento. Haciendo referencia a la figura 5, se ilustra una vista ffsica de un sistema que esta configurado para usarse con una aplicacion de VPN. Un sitio remoto 50 que tiene un servidor de VPN 51 se comunica por Internet 52 con una red subyacente 53. En una realizacion, el servidor de VPN 51 puede ser un servidor de OpenVPN. La red subyacente puede ser una red de IP privada. Un anfitrion 54 puede ser un nodo conectado a la red subyacente e incluye una interfaz de red 55. La interfaz de red 55 esta conectada a un puerto de tunel 56. El puerto de tunel 56 puede usar tunelizacion de GRE u otros metodos de tunelizacion tal como se comento anteriormente. La interfaz de red 55 tambien puede comunicarse con un cliente de VPN 57 en un contenedor a traves de un tunel cifrado 62. El cliente de VPN puede ser un cliente de OpenVPN. El cliente de VPN 57 en el contenedor se comunica con un conmutador programable de flujo 58 a traves de trafico de red virtual 59. El conmutador controlable de flujo 58 tambien se comunica con un motor de decision 60 que se comunica con una base de datos compartida 61. Aplicando uno o mas de los metodos dados a conocer en el presente documento, el sistema proporciona un programa residente de gestion de VPN que usa la red del anfitrion para alcanzar el servidor de VPN en el sitio remoto.

Haciendo referencia a la figura 6, se ilustra una vista ffsica de otra realizacion de un sistema para su uso con una aplicacion de VPN. Un sitio remoto 70 que tiene un servidor de VPN 71 se comunica por Internet 72 con una interfaz de red 74 de un primer anfitrion 73. El primer anfitrion 73 incluye un motor de decision 78 que se comunica con un conmutador programable de flujo 76. El conmutador programable de flujo 76 se comunica con una interfaz de red 75 a traves de un puerto de tunel 77. Una interfaz de red del primer anfitrion 73 esta conectada a una red subyacente 79. La red subyacente tambien esta conectada a una interfaz de red 81 de un segundo anfitrion 80. En una realizacion, la red subyacente 79 es una red privada que esta aislada del Internet publico. El segundo anfitrion 80 incluye ademas un conmutador configurable de flujo 83 que se comunica con la interfaz de red 81 a traves de un puerto de tunel 82. El conmutador programable de flujo 83 tambien se comunica con un motor de decision 84 y un cliente de VPN 85 en un contenedor. El motor de decision 84 tambien se comunica con la base de datos compartida 86 de manera que la base de datos compartida proporciona informacion de estado distribuido para el sistema. Aplicando uno o mas de los metodos dados a conocer en el presente documento, el sistema proporciona un programa residente de gestion de VPN en un entorno informatico en la nube usando el enlace ascendente de la red virtual para alcanzar el servidor de VPN en el sitio remoto.

En todavfa otras realizaciones, en el presente documento se dan a conocer sistemas y metodos para facilitar el enrutamiento de paquetes usando una red virtual superpuesta en una red subyacente. En realizaciones, la red subyacente es una red ffsica, sin embargo, en otras realizaciones, la red subyacente puede ser una red virtual o logica. Por motivos de claridad, la red subyacente puede describirse en cuanto a una red ffsica, sin embargo, una o mas redes virtuales pueden disponerse en capas unas sobre otras, proporcionando cada una la red subyacente para la siguiente red virtual superpuesta.

Un sistema de la presente divulgacion puede incluir una red que interconecta una pluralidad de nodos. Los nodos de la red pueden corresponder a componentes ffsicos tales como servidores, enrutadores u otros dispositivos informaticos en comunicacion con la red. Cada dispositivo puede soportar uno o mas nodos. En otra realizacion, los nodos pueden representar dispositivos logicos o virtuales. La red puede ser una red privada mantenida por un proveedor de servicios, en la que el proveedor de servicios vende, alquila o proporciona de otro modo capacidades de red a una pluralidad de titulares. La red puede tener uno o mas nodos, tales como nodos perimetrales, que proporcionan conectividad a una red publica. En un ejemplo, la red incluye una pluralidad de nodos orientados hacia Internet que proporcionan multiples trayectorias de comunicacion de entrada/salida entre Internet y la red. Los nodos orientados hacia Internet pueden ser enrutadores conectados a Internet. En otro ejemplo, la red incluye una pluralidad de nodos configurados para albergar maquinas virtuales de titular. Los nodos que albergan maquinas virtuales de titular pueden ser servidores anfitriones u otros dispositivos con los recursos necesarios para hacer funcionar una o mas maquinas virtuales de titular. En algunas implementaciones, un nodo puede albergar multiples maquinas virtuales de un unico titular. En otra realizacion, un nodo puede albergar multiples maquinas virtuales propiedad de diferentes titulares. En aun otra realizacion, un nodo puede funcionar tanto para albergar una maquina virtual de titular como para proporcionar conectividad a Internet a la red.

En diversas realizaciones, se da a conocer un metodo para enrutar un paquete desde un primer nodo hasta un segundo nodo. El metodo incluye recibir un paquete en un primer nodo de la red. El metodo incluye ademas invocar un motor de decision para simular como recorrera el paquete una red virtual. La simulacion puede incluir acceder a una tabla de enrutamiento virtual para determinar un siguiente salto para el paquete, en la que el siguiente salto es o bien un puerto orientado hacia el interior (tambien denominado puerto logico) o bien un puerto orientado hacia el exterior (tambien denominado puerto materializado), y continuar accediendo a tablas de enrutamiento virtuales posteriores en serie hasta que se determina que el siguiente salto es un puerto orientado hacia el exterior en un segundo nodo de la red. Tras haber determinado el motor de decision como procesar el paquete, el paquete puede enviarse por la red subyacente al puerto orientado hacia el exterior del segundo nodo. En realizaciones, la red subyacente puede ser una red de Ethernet, una red de IP privada o publica, u otra red que proporciona conectividad entre la pluralidad de nodos.

En una realizacion, cada nodo de la red contiene un conector de borde. Cada conector de borde contiene una implementacion de un conmutador configurable de flujo y motor de decision que se ejecutan en el mismo nodo o anfitrion ffsico. En una realizacion, un conmutador configurable de flujo puede comprender software tal como Open vSwitch. El motor de decision puede simular uno o mas conmutadores L2 virtuales y enrutadores L3 virtuales. Un conector de borde puede tener interfaces ffsicas, interfaces virtuales o ambas. Las interfaces virtuales son interfaces tales como, por ejemplo, interfaces de escucha o interfaces virtuales a nivel de nucleo. Las interfaces ffsicas son, por ejemplo, una tarjeta de interfaz de red ffsica (NIC).

Un conmutador configurable de flujo es un componente de software que aplica una lista de acciones a todos los paquetes que coinciden con una regla de flujo. Asociada con una lista de acciones hay una coincidencia de flujo que especifica que paquetes coinciden con el flujo. En algunas realizaciones, la coincidencia de flujo puede especificarse mediante un patron de cabecera de protocolo de paquete. La coincidencia de flujo puede basarse en una o mas porciones de los datos de paquete, incluyendo, por ejemplo, los puertos de origen y destino, direcciones de origen y destino, direccion MAC. La coincidencia de flujo tambien puede basarse en combinaciones de datos de paquete o subconjuntos de datos de paquete, tales como una porcion de las direcciones de origen o destino. Una regla de flujo puede comprender al menos una coincidencia de flujo y una lista de acciones, y puede denominarse “flujo”. Dos flujos (uno entrante, uno saliente) forman una conexion. Generalmente, dos flujos, un flujo entrante y un flujo saliente, forman una conexion para comunicaciones entre un cliente fuera de la red y una maquina virtual del titular u otro servicio proporcionado dentro de la red. Cada flujo representado por una o mas reglas de flujo puede almacenarse en un estado distribuido mantenido en una base de datos compartida. En una realizacion, cada flujo se almacena en un estado distribuido mantenido en un nodo de la red accesible por todos los demas nodos que requieren acceso al estado distribuido. Los flujos almacenados pueden indexarse mediante su coincidencia de flujo o mediante otros criterios asociados con las reglas de flujo.

En una realizacion, puede mantenerse una tabla de flujo que copia en memoria cache las decisiones de enrutamiento realizadas para el primer paquete en una direccion de una conexion. La tabla de flujo se mantiene dentro del conmutador configurable de flujo. La red puede tener multiples puntos de acceso posibles a la red externa, y las conexiones no necesitan usar la misma ruta virtual entrante como saliente. Permitir diferentes rutas entrantes y salientes puede mejorar la tolerancia a fallos del sistema en caso de interrupciones en determinadas porciones de la red. Permitir diferentes rutas entrantes y salientes tambien puede permitir un uso mejorado de recursos de red equilibrando cargas entre diferentes trayectorias en la red.

La red tambien puede comprender elementos de reenvfo que enrutan y conmutan paquetes entre los nodos de la ^{red. Los elementos de reenvfo pueden ser conmutadores}l2, ^{enrutadores L3 o combinaciones de conmutadores L2}y enrutadores L3. Los elementos de reenvfo pueden ser o bien ffsicos o bien virtuales, y la red puede incluir combinaciones de elementos de reenvfo ffsicos y virtuales. Un elemento de reenvfo ffsico es un componente de hardware, mientras que un elemento de reenvfo virtual puede implementarse en software. En una realizacion, un elemento de reenvfo virtual se implementa usando tablas. Por ejemplo, el motor de decision puede usarse para simular el enrutamiento y la conmutacion de paquetes segun una topologfa virtual establecida para la red.

En la red, pueden conectarse enrutadores virtuales a otros enrutadores virtuales para construir una topologfa de red virtual que puede ilustrarse mediante un grafico de red virtual. Cada enrutador virtual puede tener una pluralidad de puertos virtuales, en el que cada puerto virtual es o bien un puerto orientado hacia el interior (logico) o bien un puerto orientado hacia el exterior (materializado). Por ejemplo, cada enrutador virtual puede incluir una tabla de enrutamiento virtual, y los puertos orientados hacia el interior pueden identificarse realizando una consulta en la tabla de enrutamiento virtual para determinar el siguiente salto para un paquete que esta enrutandose por el enrutador virtual. Cada consulta puede conducir a un puerto orientado hacia el interior homologo de otro enrutador virtual o un puerto orientado hacia el exterior, permitiendo que el motor de decision simule el recorrido de una topologfa virtual que tiene multiples enrutadores virtuales. En una realizacion, un puerto orientado hacia el exterior puede corresponder a un puerto en un conmutador configurable de flujo, tal como un puerto de tunel. En algunas realizaciones, un puerto orientado hacia el exterior puede corresponder a la ubicacion de un nodo que proporciona conectividad a Internet. En otra realizacion, un puerto orientado hacia el exterior puede corresponder a la ubicacion de una maquina virtual que funciona dentro de la red. Para puertos orientados tanto hacia el interior como hacia el exterior, la configuracion estatica del puerto virtual en el arbol de configuracion compartido contiene explfcitamente el tipo de puerto (es decir, orientado hacia el interior o hacia el exterior) y, en el caso de puertos orientados hacia el interior, el identificador universalmente unico (“port_uuid”) del otro extremo del enlace virtual (es decir el puerto orientado hacia el interior homologo). Adicionalmente, los enrutadores virtuales pueden tener sus propias direcciones IP. Adicionalmente, cada enrutador virtual puede soportar protocolos tales como protocolo de pasarela de frontera (“BGP”) y/o protocolo de pasarela interna (“ iGP”).

En otra realizacion, los conectores de borde pueden tener puertos de tunel que no son puertos de los enrutadores virtuales. El puerto de tunel puede usarse para conectar un conector de borde a otro conector de borde a traves de la red. Por ejemplo, el conmutador configurable de flujo de un conector de borde puede conectarse al conmutador configurable de flujo de otro conector de borde mediante un puerto de tunel. En una realizacion, un paquete puede llegar a un conector de borde destinado a una maquina virtual en otro conector de borde. Cuando un paquete esta destinado a un puerto orientado hacia el exterior en otro conector de borde, se envfa a ese conector de borde a traves de un tunel. Puede mantenerse una tabla en un estado distribuido que mapea puertos a conectores de borde y una tabla que mapea conectores de borde a tuneles. Por tanto un conector de borde puede determinar a traves de que tunel enviar un paquete basandose en un puerto seleccionado (no local). En otra realizacion, el mapeo de puertos orientados hacia el exterior a conectores de borde y de conectores de borde a tuneles puede mantenerse en un nodo independiente, y los conectores de borde pueden comunicarse con el nodo independiente para determinar el tunel apropiado para un paquete.

En una realizacion, los conectores de borde en cada nodo tienen acceso a un estado distribuido, que puede almacenarse en una base de datos compartida. El estado distribuido se mantiene y comparte por los conectores de borde. El estado distribuido puede contener, por ejemplo, el arbol de configuracion y otros datos referentes a la topologfa de red virtual y/o ffsica. En una realizacion, puede implementarse un estado distribuido usando Zookeeper y memcache. En otra realizacion, parte del estado distribuido es un arbol de configuracion, pero se contemplan otras estructuras tales como tablas de eleccion arbitraria y arboles n-arios. Los conectores de borde pueden acceder al arbol de configuracion y a otros datos compartidos segun se necesite, tal como mediante el motor de decision.

El termino “cliente” se usa en el presente documento para indicar un cliente de red externa, tal como un navegador web, que esta intentando alcanzar un servidor albergado dentro del sistema, por ejemplo, para acceder a los servicios de una maquina virtual. El termino “titular” se usa para indicar un cliente del proveedor de servicios. Un titular puede tener una o mas maquinas virtuales u otros servicios que funcionan en maquinas ffsicas dentro del sistema, y puede querer establecer dinamicamente reglas de equilibrio de carga o traduccion de direccion de red (“NAT”) entre estas maquinas virtuales y los clientes.

Haciendo ahora referencia a la figura 7, se ilustra un servidor 101 con dos tarjetas de interfaz de red, NIC A 111 y NIC B 112. Para fines de ilustracion, algunos nodos pueden designarse como nodos perimetrales orientados hacia clientes de Internet, y que proporcionan conectividad a Internet a la red. Otros nodos pueden designarse como nodos anfitriones configurados para albergar maquinas virtuales de titular u otros servicios dentro de la red. Para fines de ilustracion, los nodos perimetrales y nodos anfitriones pueden mostrarse con arquitecturas simetricas, sin embargo, en diversas realizaciones, puede usarse una variedad de arquitecturas para los diversos nodos en el sistema. Aunque se ilustra en cuanto a nodos perimetrales orientados hacia Internet y nodos que albergan maquinas virtuales, el sistema tambien puede contener nodos intermedios incluyendo dispositivos de almacenamiento de datos y servidores de soporte deseados para facilitar el funcionamiento de la red. Tal como se muestra en la figura 7, NIC A 111 tiene una conexion a Internet 151 y NIC B 112 tiene una conexion al tejido de proveedor interno 152 (la red subyacente). El tejido de proveedor interno 152 puede ser una red de IP privada u otra red que proporciona conectividad lP entre los nodos.

El sistema incluye un componente de software que implementa muchas de las caractensticas de la red virtual superpuesta en la red ffsica. Para ilustrar el funcionamiento de los componentes de software, las acciones tras la recepcion de un paquete se describen para operaciones seleccionadas.

En una realizacion, se recibe un paquete SYN para establecer una conexion TCP. El paquete SYN se recibe desde Internet 151 en NIC A 111. Se reciben paquetes por el conector de borde en el conmutador configurable de flujo 161 para su conmutacion. El conmutador configurable de flujo 161 intenta identificar una regla de flujo haciendo coincidir datos asociados con el paquete con las reglas de flujo almacenadas en la tabla de flujo 162. Los datos coincidentes pueden incluir, por ejemplo, puertos de origen y destino, direcciones de red, direcciones MAC u otros datos asociados con el paquete. El paquete SYN es normalmente el primer paquete en un flujo y por tanto el conmutador configurable de flujo 161 no encuentra una entrada correspondiente al primer paquete en la tabla de flujo 162. Tras no encontrar una entrada correspondiente en la tabla de flujo, el conmutador configurable de flujo 161 realiza una llamada de funcion a un motor de decision 165 y comunica el paquete al motor de decision. El paquete puede llegar a un puerto del conmutador configurable de flujo, y el conmutador configurable de flujo puede comunicar el ID de puerto entrante al motor de decision con el paquete. Aunque la funcion del conmutador programable de flujo y el motor de decision se describen por separado por motivos de claridad, resultara evidente que los componentes de software pueden integrarse segun se desee. Alternativamente, cada componente puede dividirse o combinarse con otros componentes siempre que se mantengan las funciones del componente. En una realizacion, el motor de decision se comunica con el conmutador configurable de flujo 161 a traves del protocolo OpenFlow y traduce el ID de puerto entrante del conmutador configurable de flujo en un ID de puerto virtual (“vport”). Alternativamente, este mapeo puede basarse en direccion MAC o credenciales 802.1x en lugar del ID de puerto entrante. El resto del enrutamiento del paquete puede depender de su informacion L3. El motor de decision 165 tiene la logica para simular la ruta del paquete a traves de la topologfa de red virtual. En una realizacion, solo el primer paquete de una conexion provocara una llamada al motor de decision, puesto que, una vez creado el flujo en la tabla de flujo 162 ese flujo puede aplicarse a paquetes posteriores del mismo flujo.

Para crear una regla de flujo asociada con un nuevo flujo, en una realizacion el motor de decision construye una lista de acciones que indica como procesar y reenviar el paquete y la inserta como una regla de flujo en la tabla de flujo. En paquetes posteriores que coinciden con los criterios para ese flujo se aplica la lista de acciones, que puede incluir enrutar el paquete a un puerto dado. Si el paquete estaba destinado a otro conector de borde que se ejecuta en otro servidor, puede enrutarse al otro conector de borde a traves de un puerto de tunel. Los puertos de tunel pueden conectar conectores de borde o nodos en la red subyacente y se usan para reenviar paquetes entre conectores de borde. En vez de eso, cuando un paquete esta destinado a un puerto virtual en otro conector de borde, se envfa a ese conector de borde a traves de un tunel. El protocolo de tunel es, en una realizacion, GRE+IP. Este protocolo de tunelizacion permite que un conmutador configurable de flujo 161 en un servidor 101 se comunique a traves del tejido de proveedor interno 152 con otro conmutador configurable de flujo (no representado) en otro servidor (no representado). La figura 8 ilustra la interconexion ffsica de una pluralidad de conectores de borde 203, 204, 205 en una pluralidad de anfitriones respectivos 210, 221, 222 conectados mediante el tejido de red L3 interno del proveedor 202. Con el fin de ilustrar, las maquinas virtuales 211 y 212 funcionan en el anfitrion 221, mientras que las maquinas virtuales 213 y 214 funcionan en el anfitrion 222. Una consola de gestion 206 tambien puede estar conectada al tejido de red interno 202, que forma la red subyacente. La figura 9 ilustra la topologfa virtual que esta superpuesta en esta red ffsica. El protocolo de tunelizacion permite que el tejido enrute los paquetes entre conmutadores configurables de flujo sin modificacion del hardware en el tejido de proveedor 152. Puesto que los paquetes reales se desplazan por lP (L3) en contraposicion a Ethernet (L2), la red puede ajustarse a escala y puede no estar limitada por limitaciones de distancia aplicables a comunicaciones por Ethernet. Los puntos finales de los tuneles son puertos en los conmutadores configurables de flujo de los conectores de borde, pero los puertos de tunel se tratan de manera diferente a puertos orientados hacia el exterior. La porcion de lP de la cabecera de paquete de tunel permite que el paquete obtenga el anfitrion correcto, y luego la porcion de GRE de la cabecera sirve para llevar el paquete al puerto de tunel correcto. Aun otra clave en la cabecera sirve para identificar el puerto orientado hacia el exterior de destino, de modo que el conector de borde de recepcion puede enrutar el paquete al puerto local correcto.

Haciendo ahora referencia a la figura 8, se ilustra una red que comprende tres conectores de borde 203, 204 y 205, en la que cada conector de borde reside en un anfitrion. Continuando con el ejemplo anterior, se supone que un paquete se recibio en el conector de borde 203 en una tarjeta de interfaz de red ffsica (NIC) desde Internet 151 a traves del enrutador conectado a Internet 201 y que el paquete esta destinado a la maquina virtual 211. Se recuerda que el paquete es el primer paquete de un flujo, de modo que no hay ninguna regla de flujo correspondiente al paquete en la tabla de flujo. Puesto que no hay ninguna entrada de flujo correspondiente en la tabla de flujo, se invoca el motor de decision. El motor de decision determina un puerto virtual (vport) basandose en el puerto en el que se recibio el paquete por el conmutador configurable de flujo, y posiblemente en la direccion MAC y credenciales 802.1x. El vport en este caso es un puerto orientado hacia el exterior (materializado) correspondiente a una NIC y un puerto en el conmutador configurable de flujo. El motor de decision usa el vport para determinar a que enrutador virtual o conmutador virtual esta conectado el puerto. Tal como se comento anteriormente, un enrutador virtual puede implementarse mediante una tabla accesible para el motor de decision y mantenida en un estado distribuido. Una vez que el motor de decision determina que enrutador virtual esta conectado al puerto orientado hacia el exterior, el motor de decision selecciona una ruta coincidente identificando la direccion IP de destino en la tabla de enrutadores virtuales correspondiente. En una realizacion, el motor de decision puede seleccionar una ruta a partir de varias rutas, o varias rutas de igual coste, usando un algoritmo de equilibrio de carga.

En otra realizacion, cuando el motor de decision accede a una tabla de enrutadores virtuales para consultar una direccion IP, pueden aplicarse procesos de preenrutamiento y posenrutamiento. El proceso de preenrutamiento puede alterar el paquete, incluyendo las direcciones IP de origen y destino y puertos de origen y destino, para realizar la traduccion de direccion de red (“NAT”). El metodo de enrutamiento puede comprender extraer las direcciones IP de origen y destino, consultar las direcciones IP en una tabla de enrutamiento virtual correspondiente a un enrutador virtual, seleccionar un destino (si se encuentra mas de una ruta) y reenviar el paquete al puerto correspondiente a la entrada de ruta. El reenvfo del paquete depende de si el siguiente salto de la ruta coincidente es un puerto orientado hacia el interior (logico) o un puerto orientado hacia el exterior (materializado). Dado que pueden implementarse enrutadores virtuales como tablas, el enrutamiento entre dos enrutadores virtuales comprende una consulta en tablas de enrutadores virtuales sucesivas. En una realizacion, se mantiene una tabla de enrutamiento global para cada enrutador L3 virtual. La tabla de enrutamiento global puede almacenarse en un estado distribuido en la base de datos compartida. Alternativamente, la tabla de enrutamiento global puede almacenarse en un conector de borde seleccionado. En otra realizacion, la tabla de enrutamiento global se mantiene en cada conector de borde y los conectores de borde actuan conjuntamente para mantener y actualizar la tabla de enrutamiento global en cada uno de los otros conectores de borde en la red.

Haciendo ahora referencia a la figura 9, se ilustra una topologfa virtual que puede superponerse en una red subyacente, tal como la red ffsica de la figura 8. En un ejemplo, un paquete puede llegar a un puerto orientado hacia el exterior asociado con el enrutador L3 virtual 301 y su direccion IP de destino es la direccion IP de la VM 211. El motor de decision puede usar el vport en el que llego el paquete para determinar a que enrutador virtual esta conectado el vport, en este caso el enrutador L3 virtual 301. En una realizacion, el enrutador L3 virtual 301 puede ser un enrutador de proveedor, creado y administrado por el proveedor de servicios que hace funcionar la red. El motor de decision puede usar entonces la direccion IP asociada con el paquete para determinar un puerto de salida para el paquete. Si el puerto de salida es un puerto orientado hacia el exterior local, entonces se establece un flujo en el conmutador configurable de flujo y se enruta el paquete hasta el puerto orientado hacia el exterior local. Si el puerto orientado hacia el exterior no es local, el paquete se enruta fuera de un puerto de tunel segun una tabla de vport a anfitrion y una tabla de anfitrion a puerto de tunel. Si el puerto es un puerto orientado hacia el interior de otro enrutador o conmutador, entonces se repite el mismo proceso de consulta hasta que se identifica un puerto orientado hacia el exterior. Para continuar con la figura 9, la consulta en la tabla del enrutador virtual 301 puede devolver un puerto orientado hacia el interior correspondiente al enrutador virtual 302. Tras, o en combinacion con, la consulta, pueden aplicarse procesos de posenrutamiento al paquete segun se desee. Cuando la consulta devuelve un puerto orientado hacia el interior correspondiente a otro enrutador virtual, en este caso el enrutador L3 virtual 302, el motor de decision puede repetir el mismo proceso para el enrutador virtual 302. El enrutador virtual 302 puede ser, por ejemplo, un enrutador virtual creado por un titular para enrutar trafico entre las maquinas virtuales del titular, las maquinas virtuales 211 y 212. Las maquinas virtuales del titular pueden estar en el mismo anfitrion, o pueden estar ubicadas en anfitriones diferentes dentro de la red. Un titular puede alquilar recursos de red del proveedor de servicios para hacer funcionar cualquier numero de maquinas virtuales u otros servicios dentro de la capacidad de la red sujeta a reglas establecidas por el proveedor de servicios. El motor de decision realiza una simulacion que puede incluir cualquier preenrutamiento asociado con el enrutador L3 virtual 302, consultar la direccion IP en la tabla de enrutamiento virtual para determinar un siguiente salto, y cualquier posenrutamiento. En este ejemplo, el siguiente salto es la maquina virtual 211, que esta albergada en un conector de borde diferente del conector de borde 203. La tabla de enrutadores virtuales para el enrutador virtual 302 proporciona un vport correspondiente a la VM 211 segun se configura por el titular o el proveedor de servicios. En una realizacion, el proveedor de servicios puede mover maquinas virtuales de titular entre diferentes nodos en la red para gestionar el uso de equipos o mantener operaciones durante el mantenimiento o la reparacion de componentes ffsicos en la red. Entonces, el motor de decision consulta la ubicacion ffsica del vport de salida en un diccionario de ubicaciones de puerto mantenido en el estado distribuido. Puesto que todos los paquetes reenviados por los conmutadores son paquetes ^{L2, hay un espacio en los paquetes L2 para direcciones}MaC. ^{Sin embargo, puesto que hay puertos de tunel entre}dos conmutadores configurables de flujo, las direcciones MAC pueden no ser necesarias para determinadas aplicaciones. Mas espedficamente, en determinadas realizaciones, no hay necesidad de reenviar las direcciones MAC reales puesto que el conector de borde de salida puede construir la direccion MAC basandose en su propia informacion local, usando ARP para determinar la MAC de siguiente salto. En vez de eso, se codifica el vport del destino (en este caso la VM 211) en el espacio para la direccion MAC. Despues se envuelve el paquete en GRE+IP con la direccion IP del nodo perimetral como destino. Ahora el paquete esta listo para enrutarse a traves de la red L3. Haciendo referencia a la figura 7, una lista de acciones que contiene cualquier pre y posenrutamiento y el destino de enrutamiento puede instalarse en la tabla de flujo 162 para hacer coincidir todos los paquetes futuros de este flujo y el paquete puede enviarse hacia fuera a traves del protocolo de tunelizacion y a traves del enrutador de sistema operativo 113 y luego a la NIC B 112. Tras salir de la NIC B 112, el paquete se enruta por el tejido de proveedor interno 152 como se enrutana cualquier otro paquete de lP, con la direccion IP de destino del conector de borde 204.

Cuando se recibe el paquete por el conector de borde 204, se recibe en un tunel correspondiente a un puerto de tunel del conmutador configurable de flujo. Puesto que el paquete se recibe en un puerto de tunel, el conector de borde puede tratar este paquete de manera diferente a un paquete que entra en un puerto orientado hacia el exterior. El paquete es de nuevo el primer paquete recibido en este flujo y el conector de borde 204 invocara el motor de decision. En una realizacion, la clave de tunel codifica el id de vport de destino. El motor de decision puede usar el id de vport para determinar una direccion MAC y el numero de puerto local de la maquina virtual 211. En algunos casos, el motor de decision puede iniciar una peticion de ARP para determinar la direccion MAC de la VM 211. Alternativamente, la direccion MAC puede copiarse en memoria cache en una tabla de ARP. Se mantiene una tabla de ARP (de lP a MAC) por cada puerto de un enrutador virtual. La tabla de ARP puede compartirse en estado distribuido almacenado en una base de datos compartida. Tras haber determinado el motor de decision el vport de la VM 211, el sistema puede instalar un flujo en la tabla de flujo para enrutar futuros paquetes de este flujo. Entonces puede enrutarse el paquete al puerto del conmutador configurable de flujo correspondiente a la VM 211. Aunque la VM 211 es una maquina virtual local que se ejecuta en el anfitrion 221, que tambien alberga el conector de borde 205, el motor de decision todavfa puede usar la direccion IP de destino para encontrar la direccion MAC de destino. De esta manera, el sistema extrae si la VM es local o un puerto convencional a otro enrutador o conmutador demostrando adicionalmente la flexibilidad del sistema.

Una vez que se han establecido los flujos, los paquetes entrantes posteriores en la misma conexion coincidiran con los flujos en la tabla de flujos de los conectores de borde 203 y 204 y se modificaran y reenviaran por los conmutadores configurables de flujo en esas maquinas sin invocar un motor de decision. Este proceso establece el flujo entrante de una conexion a traves del sistema al destino deseado.

Cuando la VM 211 responde en la misma conexion, el primer paquete que envfa desencadenara el sistema para establecer un flujo correspondiente en el sentido opuesto. Cuando se establece un nuevo flujo, el motor de decision puede acceder al estado distribuido para determinar si se establecio anteriormente un flujo en el sentido opuesto. Este estado distribuido facilita la implementacion de otros procesos, tales como NAT y tambien permite que el sistema limpie conexiones terminadas tal como se describe adicionalmente a continuacion. En otras realizaciones, maquinas virtuales albergadas en componentes ffsicos diferentes pueden conectarse al mismo enrutador virtual.

Haciendo ahora referencia a la figura 10, se ilustra un resumen de alto nivel de un proceso que se ejecuta en un conector de borde que realiza una realizacion de metodo descrita anteriormente. En una realizacion, un conector de borde se ejecuta en una maquina ffsica con al menos una CPU que recibe paquetes de una red externa, tal como Internet, en el que los paquetes van dirigidos a una direccion IP asociada con un titular del sistema. Las direcciones IP de titular pueden asignarse a maquinas virtuales de titular que se ejecutan en uno o mas anfitriones dentro del sistema. En una realizacion, la direccion IP asociada con una maquina virtual de titular puede permanecer constante aunque el titular o proveedor de servicios reubique la maquina virtual a un anfitrion diferente dentro del sistema. En una realizacion, el sistema permite que multiples titulares compartan el enlace ascendente de un proveedor de servicios, permitiendo enrutar multiples direcciones IP en un enlace ascendente a diferentes conectores de borde y diferentes maquinas virtuales de titular. Cuando el conector de borde recibe un paquete en la etapa 410, extrae una pluralidad de datos en la etapa 412, incluyendo, pero sin limitarse a, direcciones de origen y destino y puertos de origen y destino. Tras extraer los datos, el conector de borde consulta la pluralidad de datos en una tabla de flujo (etapa 414) y determina si ya se ha establecido el flujo (etapa 416). Un ejemplo de un flujo sena un sentido de una conexion TCP, combinandose un flujo entrante y saliente para formar una unica conexion TCP. Si el flujo ya existe, se aplica la lista de acciones de flujo al paquete y se reenvfa el paquete al puerto del conmutador configurable de flujo indicado por la lista de acciones de flujo en la etapa 418.

Si el flujo no existe, este es el primer paquete en el flujo recibido por el nodo, y el conector de borde debe determinar en la etapa 417 a que puerto virtual llego el paquete, basandose, por ejemplo, en la direccion MAC, direcciones de origen y destino, o puertos de origen y destino. Una vez que el conector de borde determina el ID de puerto virtual, el conector de borde puede determinar a que elemento de reenvfo virtual esta conectado ese puerto. En la realizacion de la figura 10, el elemento de reenvfo virtual es un enrutador virtual, pero pueden usarse otros elementos de reenvfo virtuales, tales como conmutadores virtuales, segun sea necesario en el sistema tal como se comenta a continuacion. Una vez que el conector de borde determina el VFE, el conector de borde realiza otra consulta en la etapa 420. La consulta se realiza consultando la direccion IP de destino en una serie de elementos de reenvfo virtuales. Los elementos de reenvfo virtuales pueden comprender cualquier combinacion de enrutadores virtuales y conmutadores virtuales que incluyen tablas de enrutamiento virtuales para determinar la trayectoria apropiada para el paquete que esta reenviandose. En la realizacion mostrada, en la etapa 420, el motor de decision determina el destino del paquete en un primer elemento de reenvfo virtual. El primer elemento de reenvfo virtual puede ser un enrutador virtual, en cuyo caso el destino devuelto puede ser o bien un puerto orientado hacia el exterior o bien un puerto orientado hacia el interior. Tal como se indico anteriormente, un puerto orientado hacia el interior esta emparejado con otro puerto orientado hacia el interior de un segundo enrutador virtual, y el segundo enrutador virtual tiene otra tabla de enrutamiento. Si se devuelve un puerto orientado hacia el interior, el motor de decision consulta la direccion de destino en la tabla de enrutamiento del segundo enrutador virtual en la etapa 420 y continua hasta que se devuelve un puerto orientado hacia el exterior. En una realizacion, cada titular puede tener un unico enrutador virtual configurado para enrutar todos los paquetes gestionados por ese titular. En otras realizaciones, algunos titulares pueden tener una pluralidad de enrutadores virtuales, conmutadores virtuales u otros elementos de reenvfo virtuales que definen la porcion del titular de la topologfa de red virtual. El motor de decision tambien construye una serie de acciones que van a realizarse en el paquete a partir de cada tabla de enrutamiento virtual. Cada etapa de enrutamiento tambien puede tener procesos preenrutamiento o posenrutamiento que se anaden a la lista de acciones y se incorporan en la regla de flujo que va a aplicarse a los paquetes que coinciden con el flujo.

Una vez que se ha devuelto un puerto orientado hacia el exterior (etapa 424), el conector de borde determina si el puerto orientado hacia el exterior es local (etapa 426). Si el puerto es local, se anade una accion a la lista de acciones (etapa 430) para enrutar el paquete al puerto orientado hacia el exterior local. En diversas realizaciones, el puerto orientado hacia el exterior local puede ser una tarjeta de interfaz de red o maquina virtual. Despues se anade la regla de flujo a la tabla de flujo (etapa 430) y se aplica al paquete (etapa 418). Si el puerto orientado hacia el exterior no es local, entonces el puerto esta en un conector de borde diferente. En una realizacion, los conectores de borde pueden conectarse mediante puertos de tunel, tales como puertos de tunel GRE_IP. En la etapa 432, el conector de borde accede a una tabla de puerto virtual a tunel para intentar mapear el puerto orientado hacia el exterior a un puerto de tunel. Si no hay ninguna entrada correspondiente en el mapeo de tabla de puerto virtual a tunel, se anade una accion para soltar el paquete y enviar un paquete de ICMP a la lista de acciones (etapa 434), se anade la regla de flujo a la tabla de flujo (etapa 430) y se aplica la regla de flujo al paquete (etapa 418).

Si el puerto orientado hacia el exterior esta en la tabla de puerto orientado hacia el exterior a tunel, entonces se anade una accion para emitir el paquete a ese tunel a la lista de acciones (etapa 436), se anade el flujo a la tabla de flujo (etapa 430), y se aplica la lista de acciones al paquete (etapa 418).

En una realizacion, el sistema instala la lista de acciones y regla de flujo en la trayectoria de datos de conmutador configurable de flujo, y el conmutador configurable de flujo aplica la lista de acciones a cualquier paquete posterior que coincide con la regla de flujo, tal como se muestra en la etapa 416. Tal como se describio anteriormente, parte de la lista de acciones incluye a que puerto del conmutador configurable de flujo debe enviarse el paquete. El conector de borde consulta el puerto en una tabla de puerto a IP de anfitrion, y envfa el paquete a la direccion IP. Despues almacena la lista de acciones en una tabla de flujo. En todos los paquetes posteriores que tienen una pluralidad de datos coincidentes se aplicara el mismo conjunto de acciones, dando como resultado que se enruten a la misma direccion IP.

Durante el proceso de identificar la direccion de destino en los enrutadores virtuales, el flujo puede ser no enrutable, incluirse en un agujero negro o coincidir con una ruta de rechazo, punto en el cual se suelta el paquete, o se devuelven paquetes de ICMP. En esta realizacion, puede crease un flujo para soltar todos los paquetes que coinciden con la regla del flujo. De esta manera, el sistema puede configurarse para gestionar paquetes no enrutables o examinar selectivamente datos no deseados segun reglas establecidas por el proveedor de servicios o titular.

En aun otra realizacion, un conector de borde que alberga VM de titular puede tener multiples direcciones IP y multiples NIC conectadas a la red de tejido interno. En tal caso, los conectores de borde orientados a Internet pueden seleccionar una de multiples trayectorias al conector de borde que alberga VM. Ademas, un conector de borde que alberga VM con multiples direcciones IP puede tener un unico ID para identificar el conector de borde, y el motor de decision que enruta flujos puede seleccionar una de las direcciones IP del conector de borde que alberga VM, por ejemplo usando un algoritmo de equilibrio de carga o de manera aleatoria.

Otra realizacion del sistema puede usar identificadores para los nodos perimetrales distintos de direcciones IP. Por ejemplo, el tejido de red puede basarse en circuito, tal como conmutacion de etiquetas multiprotocolo (“MPLS”) u otro controlador de OpenFlow personalizado con circuitos dedicados entre conectores de borde. En esta realizacion, los circuitos pueden sustituir a los tuneles de GRE entre conmutadores configurables de flujo en nodos perimetrales. En otra realizacion, el sistema proporciona etapas de preenrutamiento y posenrutamiento antes y despues de la etapa de enrutamiento. El preenrutamiento y posenrutamiento pueden usarse para implementar la traduccion de direccion de red (NAT), equilibrado de carga u otras caractensticas L3/L4. En una realizacion, la etapa de preenrutamiento puede cambiar el destino del flujo (como, por ejemplo, en la traduccion de direccion de red) y el enrutamiento saliente puede cambiar el origen del flujo (de nuevo, como ejemplo, la traduccion de direccion de red). Para coordinar los mapeos realizados por los flujos directo e inverso que componen una unica conexion, tal como en una conexion TCP, pueden almacenarse traducciones de conexion en el estado distribuido con un gran tiempo asignado. Estas traducciones tambien pueden limpiarse de manera proactiva cuando el seguimiento de conexion detecta una conexion cerrada de manera limpia.

En una realizacion del presente sistema, se implementa NAT usando transformaciones de preenrutamiento y posenrutamiento. En la configuracion de flujo, la etapa de preenrutamiento de NAT determina si se establecio anteriormente un flujo en el sentido opuesto (entrante frente a saliente) en el estado distribuido y, si es asf, el mapa anteriormente creado se invierte para el nuevo flujo. Puesto que las reglas de flujo se almacenan en el sistema de estado distribuido accesible por todos los nodos, tras la creacion de un nuevo flujo en un nodo diferente, es posible determinar si se creo anteriormente un flujo de sentido opuesto. Si el flujo de sentido opuesto no esta en el estado distribuido, el motor de decision crea una nueva traduccion y almacena su mapa de traduccion en el estado distribuido asociado con el nuevo flujo. Para el flujo entrante, o alternativamente el primer flujo establecido, puede aplicarse la traduccion de direccion a la direccion de destino antes de la etapa de enrutamiento y la etapa de enrutamiento puede enrutar basandose en la direccion IP traducida. En el flujo saliente, o alternativamente el segundo flujo en la conexion, puede realizarse NAT tras el enrutamiento, para traducir la direccion de origen para que sea la direccion IP externa no privada. La informacion de traduccion puede almacenarse en el estado distribuido asociado con la regla de flujo antes de reenviar el paquete inicial del flujo de manera que la informacion de traduccion es accesible cuando se recibe el paquete inicial del flujo inverso en el conector de borde correspondiente. En otra realizacion, la traduccion de direccion de red de destino (DNAT) puede usarse para traducir de una direccion IP publicamente disponible a una direccion de red privada para exponer servicios albergados en una red privada a Internet general. En algunas realizaciones, puede proporcionarse una zona desmilitarizada (DMZ) entre Internet general y la red privada. En un proceso de DNAT, la direccion de destino puede traducirse durante una etapa de preenrutamiento para el flujo entrante, y en el flujo saliente correspondiente, la direccion de origen puede traducirse durante una etapa de posenrutamiento. En una implementacion, la direccion de destino puede ser uno de varios servidores posibles, y el servidor de destino puede seleccionarse mediante un algoritmo de equilibrado de carga, tal como un algoritmo aleatorio o un algoritmo de rotacion.

En la traduccion de direccion de red de origen (SNAT) multiples clientes en la LAN privada pueden compartir la misma direccion IP publica. Una direccion de origen asociada con conexiones salientes, tales como conexiones desde maquinas virtuales de titular hasta una red externa, puede traducirse a la misma direccion IP en el flujo saliente. En el flujo entrante correspondiente, una direccion IP de destino de paquete puede traducirse a la direccion IP privada correspondiente basandose, por ejemplo, en el numero de puerto y la direccion IP de origen.

En otra realizacion, el sistema puede configurarse para proporcionar simulacion de ARP para redes de area local privadas. El sistema puede permitir que anfitriones de red individuales tales como un invitado de maquina virtual se conecten a un puerto de enrutador virtual sin consumir direcciones de pasarela/radiodifusion suplantando a otros anfitriones individuales cuando el anfitrion implementa ARP para los mismos. En un diseno basado en Ethernet tradicional, esto consumina al menos un intervalo de /30 direcciones, incluyendo la direccion del invitado, la direccion de pasarela, y la direccion de radiodifusion, mas una direccion sin usar.

Como metodo de reducir el numero de direcciones IP consumidas, cada puerto del enrutador puede configurarse con una direccion MAC y un prefijo de red (nw_prefix) y un indicador que indica si hay un anfitrion individual conectado al puerto. La direccion de pasarela usada puede ser la primera direccion en el intervalo de nw_prefix. Si el indicador de anfitrion individual no esta establecido, el enrutador puede gestionar trafico hacia y desde el puerto segun sus reglas de funcionamiento convencionales. Si el indicador de anfitrion individual esta establecido, la porcion de direccion del nw_prefix especifica la direccion del anfitrion de red individual de ese puerto. Los puertos aguas abajo del enrutador pueden configurarse de manera que comprenden nw_prefixes no solapantes con el indicador de anfitrion individual no establecido y puertos con el indicador de anfitrion individual establecido, que pueden compartir intervalos de direccion identicos especificados por sus nw_prefixes. En muchas realizaciones, los intervalos de direccion usados por los puertos de anfitrion individual y no de anfitrion individual no se solaparan.

Si se envfa un paquete de lP entre puertos con el indicador de anfitrion individual establecido, el enrutador puede reenviar el paquete de lP sin comprobar o reducir el tiempo de vida (“TTL”), emulando un conmutador L2. Si se recibe una peticion de ARP desde un puerto con el indicador de anfitrion individual establecido para la direccion asociada con otro puerto de anfitrion individual, el enrutador responde al ARP, suplantando al objetivo. El resultado es que un anfitrion individual que desea enviar trafico a un anfitrion fuera de lo que considera su segmento local implementara ARP para la direccion de pasarela, y el comportamiento normal del enrutador devolvera la MAC de su puerto y entonces el anfitrion enviara sus paquetes de IP. Un anfitrion individual que desea enviar trafico a un anfitrion que considera parte de su segmento local implementara ARP para ese anfitrion directamente. El enrutador respondera a ese ARP si tiene un puerto de anfitrion individual para esa direccion, en cuyo caso el anfitrion enviara entonces sus paquetes de IP. El comportamiento de anfitriones que no estan en un puerto con indicador de anfitrion individual puede permanecer inalterado.

En otra realizacion del sistema, puede usarse el seguimiento de conexiones con estado para realizar el seguimiento del ciclo de vida de conexiones, de manera que datos asociados con esas conexiones pueden limpiarse tras determinados acontecimientos, tales como terminacion de la conexion. Los datos que van a limpiarse pueden incluir diversos datos de estado de conexion datos, incluyendo datos almacenados en el estado distribuido, tales como mapeos de NAT y LB con estado, cuando la conexion se apaga de manera limpia. Si una conexion no se apaga de manera limpia, por ejemplo si uno u otro lado presenta un fallo grave o se desconecta, entonces el estado de conexion puede caducarse tras un tiempo asignado configurable grande. Las conexiones pueden ser conexiones TCP, y estan compuestas por dos flujos, un flujo directo y un flujo de retorno. En el caso de TCP, el sistema puede simular la maquina de estado de conexion TCP con el fin de determinar el estado de conexion.

En aun otra realizacion, el sistema proporciona el flujo de retorno de una conexion que va a gestionarse por un nodo diferente del flujo directo de la conexion. Una conexion de este tipo puede denominarse flujo dividido, caracterizado porque el flujo directo e inverso se gestiona por un motor de decision diferente. En una realizacion, el sistema soporta flujos divididos haciendo que el motor de decision que ve los flujos directo e inverso comunique el cierre de sus lados respectivos. Por ejemplo, el motor de decision que gestiona la FIN del flujo directo puede notificar al motor de decision que gestiona el flujo de retorno que instale una accion que coincida con el ACK de la FIN, o viceversa. Los motores de decision actuan conjuntamente de manera que pueden identificar cuando ambos lados de una conexion se han cerrado y pueden limpiar los datos asociados con la conexion cerrada. Esta comunicacion entre los motores de decision puede producirse a traves del estado compartido en el sistema de estado distribuido. Adicionalmente, el sistema de estado distribuido puede identificar determinadas condiciones, tales como el cierre de ambos lados de una conexion, y puede comunicar notificaciones al motor de decision que gestiona cada uno de los flujos de la comunicacion.

En otra realizacion, cuando un nodo perimetral o conector de borde gestiona la configuracion de un flujo, o bien directo o bien inverso, que forma parte de una conexion que debe seguirse (basandose en si es una conexion TCP, y si se necesita un seguimiento con estado, por ejemplo si la conexion esta sometiendose a NAT), el conector de borde anadira una accion que comprueba el bit de FIN de TCP y emite el paquete FIN. Tras recibir un paquete FIN, el motor de decision que gestiona el flujo inverso puede instalar una accion que comprueba el ACK de la FIN. Cuando el sistema observa el ACK de la FIN, se considera que la conexion esta semiabierta, de manera que no se espera ningun dato salvo los ACK. Si se reciben datos mediante una conexion semiabierta, el sistema puede generar un error que indica que el sistema experimento una condicion inesperada.

Cuando un motor de decision recibe un nuevo flujo, instalara una regla que comprueba los indicadores RST y FIN de TCP. Si el sistema recibe un paquete RST, modifica la regla de flujo para que la conexion tenga un tiempo asignado corto, ya que la conexion va a terminarse una vez que el homologo reciba el paquete RST. Si el sistema recibe un paquete FIN, inserta en la lista de acciones del flujo de retorno una accion que hace coincidir el numero de secuencia de reconocimiento que es el numero de secuencia del paquete FIN. Si el sistema obtiene un paquete que reconoce una FIN, marca ese lado de la conexion como cerrado. Si ambos lados estan cerrados, modifica la regla de flujo para que la conexion tenga un tiempo asignado corto. En algunos casos, el ACK de la FIN puede soltarse, en cuyo caso el lado que se cierra retransmitira el paquete FIN con el mismo numero de secuencia. Cuando las reglas de flujo caducan, el sistema identifica que se cierra la conexion y puede limpiar datos de estado adicionales tales como seguimiento de NAT.

En otra realizacion del sistema y metodo dados a conocer en el presente documento, se proporciona un conmutador virtual como elemento de reenvfo virtual adicional. El sistema puede transmitir paquetes L2 entre los puertos de los conectores de borde que forman parte de cada conmutador ^l2 virtual. De esta manera el sistema puede simular el funcionamiento de un conmutador L2 ffsico que transmite paquetes entre NIC conectadas al conmutador ffsico. El sistema tambien puede transmitir paquetes l3 de paquete tal como se describio anteriormente usando enrutadores virtuales. Cuando se configura un flujo, se identifica el UUID de vport entrante a partir del mapeo de una direccion MAC o puerto de entrada. Basandose en este UUID de vport, se determina el dispositivo virtual al que pertenece el vport. Basandose en el tipo de dispositivo virtual (conmutador o enrutador), el paquete o bien se enruta (tal como se describio anteriormente) o bien se conmuta. Es decir, si el paquete es un paquete L3, se gestiona segun el proceso de enrutador virtual descrito anteriormente. Alternativamente, el paquete es un paquete L2 y se procesa mediante un conmutador virtual, tal como se ilustra en las figuras 5 y 6. El proceso ilustrado en las figuras 5 y 6 es sustancialmente similar al proceso ilustrado en la figura 10. Tras haberse determinado el VFE en la etapa 417, el conector de borde determina si el VFE es un enrutador virtual o un conmutador virtual. Si el VFE es un enrutador virtual, el procesamiento continua tal como se describe con respecto a la figura 10. Si el VFE es un conmutador virtual, el procesamiento continua en el punto A (520), conectado al punto A (520) en la figura 12. Tal como se ilustra en la figura 12, si el VFE es un conmutador virtual, entonces el conector de borde determina si la direccion MAC de destino es una direccion de radiodifusion o una direccion MAC de unidifusion (etapa 610). Si la direccion MAC es una direccion de radiodifusion, entonces se envfa el paquete a cada puerto conectado al conmutador virtual (etapa 620). Basandose en cada paquete, esta etapa puede ser identica al proceso de la figura 10 comenzando con la etapa 426. Para cada puerto orientado hacia el exterior que es un miembro del VFE, el paquete se envfa o bien al vport local o bien al puerto de tunel correspondiente a ese puerto orientado hacia el exterior.

Si el paquete no es un paquete de radiodifusion (por ejemplo un paquete de unidifusion), entonces se determina la MAC de destino, por ejemplo, consultando la MAC de destino en una tabla de MAC a vport (etapa 630). Si no hay una entrada correspondiente (sometido a prueba en la etapa 640), entonces se anade una accion de soltar a la lista de acciones (etapa 650). Entonces el procesamiento continua en el punto B en la figura 11, en el que se anade la regla a la tabla de flujo (430) y se aplica la accion al paquete (418).

Si hay un vport correspondiente en la tabla de MAC a vport de la etapa 640, entonces el procesamiento continua en el punto C en la figura 11, el procesamiento continua en la etapa 426, tal como se describio anteriormente.

Haciendo ahora referencia a las figuras 7 y 8, se ilustra otra realizacion del sistema y metodo dados a conocer en el presente documento. Tal como se muestra en la figura 13, una topologfa de red virtual incluye un enrutador virtual de proveedor 900 que tiene multiples conexiones 901 a una red externa, tal como Internet general 902. En esta configuracion la red virtual esta dotada de multiples trayectorias de comunicacion a la red externa permitiendo flexibilidad y redundancia en el sistema. El enrutador virtual de proveedor 900 puede tener una pluralidad de puertos orientados hacia el exterior correspondientes a una pluralidad de nodos perimetrales, en el que un nodo perimetral es un componente ffsico que proporciona acceso a la red externa. En una realizacion, un nodo perimetral puede ser un servidor o enrutador orientado hacia Internet. La topologfa de red virtual tambien puede comprender una pluralidad de enrutadores virtuales de titular. En una configuracion, cada enrutador virtual de titular puede estar asociado con un centro de datos virtual de titular. Tal como se muestra en la figura 13, un centro de datos virtual de primer titular 903 puede incluir un enrutador virtual de primer titular 904 en comunicacion con una pluralidad de maquinas virtuales de primer titular 905. Las maquinas virtuales de primer titular 905 tambien pueden comunicarse con un conmutador virtual de titular 906, que puede ser un conmutador de Ethernet virtual tal como se ilustra. Las maquinas virtuales de primer titular 905 pueden residir en uno o mas de un servidor o nodo anfitrion en la red.

Tal como tambien se muestra en la figura 13, la topologfa de red virtual puede tener un centro de datos virtual de segundo titular 907, que incluye un enrutador virtual de segundo titular 910 en comunicacion con el enrutador virtual de proveedor 900 y una pluralidad de maquinas virtuales de segundo titular 909. La pluralidad de maquinas virtuales de segundo titular 909 tambien pueden comunicarse con un conmutador virtual de segundo titular 908, que puede ser un conmutador de Ethernet virtual tal como se ilustra.

Los enrutadores virtuales tambien pueden realizar funciones adicionales tales como equilibrado de carga, DHCP y/o traduccion de direccion de red segun desee cada titular. Aunque solo se ilustra un enrutador virtual para cada titular, en otras realizaciones, un titular puede emplear una pluralidad de enrutadores virtuales creando una topolog^a de red virtual espedfica de titular. Una topologfa de red virtual espedfica de titular puede proporcionar organizacion de maquinas virtuales de titular en disposiciones deseadas o proporcionar aislamiento entre maquinas virtuales controladas por el mismo titular, tal como cuando un titular esta usando la red para albergar multiples procesos empresariales o funciones diferenciadas.

En otra realizacion, un enrutador virtual de titular puede proporcionar acceso seguro a una oficina de titular remota u otra ubicacion. Tal como se ilustra, el enrutador virtual de segundo titular 910 proporciona una conexion al enrutador de VPN de segundo titular 911 y la red de oficina de segundo titular 912 en la oficina de segundo titular 913. De esta manera, cada titular puede definir la configuracion de su centro de datos virtual. Por tanto, un proveedor de servicios que usa el sistema y metodo dados a conocer en el presente documento puede proporcionar muchas soluciones personalizables por el titular en una red ffsica.

Haciendo ahora referencia a la figura 14, la topologfa de red virtual ilustrada en la figura 13 se muestra superpuesta en una red ffsica. La red ffsica puede comprender una pluralidad de nodos perimetrales 920 configurados para acceder a una red externa, tal como Internet 902. La red ffsica tambien puede incluir una pluralidad de nodos anfitriones 921 configurados para albergar maquinas virtuales. La red 922 puede interconectar la pluralidad de nodos perimetrales 920 y la pluralidad de nodos anfitriones 921 y estar adaptada para transportar paquetes de datos a traves del sistema. En una realizacion, la red puede ser una red de IP privada. Los nodos perimetrales 920 y los nodos anfitriones 921 pueden tener arquitecturas simetricas. En una realizacion, los nodos perimetrales 920 y los nodos anfitriones 921 son servidores de uso general configurados para funcionar en un sistema informatico en la nube. En otra realizacion, los nodos perimetrales 920 son enrutadores orientados hacia Internet dedicados. En aun otra realizacion, un servidor u otro dispositivo informatico puede funcionar como nodo perimetral y como nodo anfitrion en la misma red. El sistema tambien incluye un sistema de estado distribuido en comunicacion con cada uno de los nodos perimetrales y cada uno de los nodos anfitriones a traves de la red. El sistema de estado distribuido puede almacenar datos asociados con la topologfa de red virtual y puede almacenarse en una base de datos compartida. El sistema puede incluir un componente de software que funciona en cada uno de los nodos y que implementa la topologfa de red virtual que incluye el enrutador virtual de proveedor y cada uno de los enrutadores virtuales de titular. A medida que se configuran nuevas rutas, el componente de software que funciona en cada uno de los nodos puede comunicarse con el sistema de estado distribuido de manera que el estado distribuido mantiene un mapeo exhaustivo de la topologfa de red virtual y reglas de flujo para el sistema. En otros ejemplos, el sistema de estado distribuido puede subdividirse de manera que se mantienen multiples estados distribuidos para porciones seleccionadas de la red virtual.

Tal como se ilustra en la figura 14, la topologfa de red virtual esta superpuesta en la red ffsica. El enrutador virtual de proveedor puede tener un puerto orientado hacia el exterior asociado con cada uno de los nodos perimetrales 920. Los puertos orientados hacia el exterior del enrutador virtual de proveedor 900 pueden mapearse a uno o mas puntos de acceso para proveedores de servicio de Internet y proporcionar multiples conexiones entre el sistema y una red externa, tal como Internet. El enrutador virtual de proveedor 900 tambien puede tener puertos interiores que definen enlaces virtuales a puertos orientados hacia el interior homologos correspondientes de enrutadores virtuales de titular. Tal como se ilustra, puede seleccionarse el rendimiento de cada enlace virtual en el sistema. Por ejemplo, el proveedor de servicios puede proporcionar un enlace virtual de 50 Mbps al enrutador virtual de primer titular 904, pero proporcionar un enlace virtual de 10 Mbps al enrutador virtual de segundo titular 910. Como los enlaces virtuales son configurables, si el segundo titular desea adquirir un mayor rendimiento para su centro de datos virtual, el proveedor de servicios puede modificar el rendimiento disponible sin modificar el hardware.

En la realizacion ilustrada, cada nodo anfitrion 920 alberga una maquina virtual asociada con el primer titular y una maquina virtual asociada con el segundo titular. Usando la topologfa de red virtual, el proveedor de servicios puede reasignar maquinas virtuales de titular entre nodos anfitriones disponibles sin reconfigurar el hardware de la red ffsica. La topologfa de red virtual almacenada en el sistema de estado distribuido permite reconfigurar dinamicamente el sistema.

En otra realizacion, cada uno de la pluralidad de enrutadores virtuales de titular puede configurarse para exponer al menos una direccion IP publica y puede configurarse para acceder a una red externa a traves de uno o mas de la pluralidad de nodos perimetrales. Permitiendo que cada centro de datos virtual de titular acceda a la red externa a traves de una pluralidad de nodos perimetrales, es menos probable que el fallo de un unico nodo perimetral interrumpa la disponibilidad de los servicios del titular que funcionan en la red.

Tal como se usan en el presente documento, los terminos “cache”, “copiar en memoria cache” u otras variaciones se refieren a todas las formas de almacenamiento de datos temporal independientemente de si los datos se almacenan en memoria expffcitamente designada como cache.

Claims

REIVINDICACIONES

Un sistema informatico que comprende:

una pluralidad de nodos (54, 73, 80, 210, 221, 222) interconectados mediante una red subyacente (53, 79, 202), en el que cada nodo incluye una o mas interfaces de red (55, 74, 75, 81), estando conectada la una o mas interfaces de cada nodo a la red subyacente,

una pluralidad de dispositivos virtuales (211, 212, 213, 214) que se simulan en al menos uno de la pluralidad de nodos, teniendo cada dispositivo virtual una pluralidad de puertos virtuales, en el que cada puerto virtual corresponde a uno de un puerto orientado hacia el exterior o un puerto orientado hacia el interior, correspondiendo cada puerto orientado hacia el exterior a una de las interfaces de red de los nodos de la red subyacente, teniendo cada puerto orientado hacia el interior un enlace virtual con otro puerto orientado hacia el interior de los dispositivos de red virtuales y

una base de datos compartida (61, 86) que almacena una pluralidad de reglas de flujo y una topologfa de red virtual que incluye una configuracion de los puertos virtuales y los dispositivos virtuales, incluyendo la configuracion, para cada uno de los puertos virtuales, una identificacion del puerto virtual como una de un puerto orientado hacia el exterior o un puerto orientado hacia el interior, siendo la base de datos compartida accesible por la pluralidad de nodos,

estando caracterizado el sistema informatico por que comprende ademas

un motor de decision (78, 84, 165) operable para:

simular un recorrido de un paquete de red de la topologfa de red virtual desde un puerto orientado hacia el exterior de entrada de un primer dispositivo virtual hasta un puerto orientado hacia el exterior de salida de un ultimo dispositivo virtual, en el que el puerto orientado hacia el exterior de salida del ultimo dispositivo virtual corresponde a una interfaz de red en la que el paquete de red se emitira desde la red subyacente, determinar un patron de cabecera de paquete identificando cada campo de la cabecera de protocolo del paquete que se lee durante la simulacion del recorrido, en el que el patron de cabecera de protocolo de paquete incluye un comodm para cualquier campo de la cabecera de protocolo del paquete que no se lee durante la simulacion del recorrido,

determinar una modificacion de cabecera de protocolo que va a aplicarse al paquete de red basandose en una configuracion de cada dispositivo virtual recorrido por el paquete durante la simulacion del recorrido, comunicar el patron de cabecera de protocolo de paquete y la modificacion de cabecera de protocolo determinada a la base de datos compartida,

almacenar el patron de cabecera de protocolo de paquete y la modificacion de cabecera de protocolo determinada como una regla de flujo en la base de datos compartida;

tras recibir un paquete posterior, seleccionar una regla de flujo desde la base de datos compartida haciendo coincidir una cabecera del paquete posterior con el patron de cabecera de protocolo de paquete almacenado, y

aplicar la modificacion de cabecera de protocolo determinada de la regla de flujo seleccionada a paquetes posteriores que coinciden con el patron de cabecera de protocolo de paquete de manera que el paquete se entrega al segundo nodo de la red subyacente y se emite desde la segunda interfaz de red,

estando determinada la simulacion del recorrido de la topologfa de red virtual en parte consultando la base de datos compartida usando un campo de la cabecera de protocolo del paquete de red.

El sistema informatico segun la reivindicacion 1, en el que el motor de decision es operable adicionalmente para simular un puente de aprendizaje de MAC que tiene una tabla de aprendizaje de MAC y actualizar la tabla de aprendizaje de MAC del puente de aprendizaje de MAC en la base de datos compartida.

El sistema informatico segun la reivindicacion 1 o 2, en el que el motor de decision es operable adicionalmente para identificar paquetes de IP que estan encapsulados en una trama de Ethernet de encapsulamiento y extraer una direccion IP de origen y una direccion MAC de origen de la trama de Ethernet de encapsulamiento, y actualizar una memoria cache de ARP de un puente virtual para asociar la direccion IP y la direccion MAC identificadas.

El sistema informatico segun una de las reivindicaciones 1 a 3, en el que el motor de decision esta configurado adicionalmente para simular al menos uno de un filtro de entrada y un filtro de salida de al menos un dispositivo virtual, en el que cada filtro esta adaptado para someter a prueba los paquetes para una condicion especificada e incluye reglas de filtrado que van a aplicarse a paquetes que coinciden con la condicion especificada.

El sistema informatico segun una de las reivindicaciones 1 a 4, en el que el motor de decision esta configurado adicionalmente para simular la aplicacion de una traduccion de direccion de red a paquetes recibidos por al menos uno de los dispositivos virtuales y almacenar la traduccion de direccion de red para paquetes de tanto un flujo directo como un flujo inverso en la base de datos compartida.

El sistema informatico segun una de las reivindicaciones 1 a 5, en el que el motor de decision esta configurado ademas para asignar dinamicamente una direccion IP desde un recurso de DHCP hasta una direccion MAC de un remitente en respuesta a una peticion de dicho remitente recibida en un puerto orientado hacia el exterior y almacenar la direccion IP asignada en la base de datos compartida.

Un metodo informatico que comprende:

recibir un paquete de red que llega en una primera interfaz de red de un primer nodo de una red subyacente (53, 79, 202), comprendiendo la red subyacente una pluralidad de nodos interconectados (54, 73, 80, 210, 221,222);

comunicar al menos el paquete y un identificador de la primera interfaz de red a un motor de decision; determinar como debe procesarse el paquete basandose en una simulacion por el motor de decision (78, 84, 165) de un recorrido de una topologfa de red virtual que incluye una pluralidad de dispositivos de red virtuales, en el que el motor de decision se comunica con una base de datos compartida (61, 86) accesible desde la pluralidad de nodos interconectados, almacenando la base de datos compartida una pluralidad de reglas de flujo y la topologfa de red virtual y configuraciones de dispositivo virtual para la pluralidad de dispositivos de red virtuales, teniendo cada dispositivo virtual una pluralidad de puertos virtuales, en el que cada puerto virtual corresponde a uno de un puerto orientado hacia el exterior o un puerto orientado hacia el interior,

estando caracterizado el metodo informatico por que

cada puerto orientado hacia el exterior corresponde a una de las interfaces de red de los nodos de la red subyacente,

por que cada puerto orientado hacia el interior tiene un enlace virtual con otro puerto orientado hacia el interior de los dispositivos de red virtuales;

por que la determinacion de como debe procesarse el paquete incluye determinar que el paquete debe emitirse desde una segunda interfaz de red de un segundo nodo de la red subyacente, y determinar como las cabeceras de protocolo de los paquetes deben modificarse antes de la entrega al segundo nodo de la red subyacente,

y por que el metodo informatico comprende ademas:

crear un patron de cabecera de protocolo de paquete identificando cada campo de la cabecera de paquete que se lee durante la simulacion del recorrido, en el que el patron de cabecera de protocolo de paquete incluye un comodm para cualquier campo de la cabecera de protocolo del paquete que no se lee durante la simulacion del recorrido,

determinar una modificacion de cabecera de protocolo que va a aplicarse al paquete de red basandose en una configuracion de cada dispositivo virtual recorrido por el paquete durante la simulacion del recorrido, y comunicar el patron de cabecera de protocolo de paquete y la modificacion de cabecera de protocolo determinada a la base de datos compartida,

almacenar el patron de cabecera de protocolo de paquete y la modificacion de cabecera de protocolo determinada como una regla de flujo en la base de datos compartida; y

procesar el paquete basandose en la simulacion, en el que procesar el paquete incluye entregar el paquete al segundo nodo de la red subyacente y emitir el paquete desde la segunda interfaz de red;

tras recibir paquete posterior, seleccionar una regla de flujo desde la base de datos compartida haciendo coincidir una cabecera del paquete posterior con el patron de cabecera de protocolo de paquete almacenado, y

aplicar la modificacion de cabecera de protocolo determinada de la regla de flujo seleccionada al paquete posterior que coincide con el patron de cabecera de protocolo de paquete de manera que el paquete se entrega al segundo nodo de la red subyacente y se emite desde la segunda interfaz de red.

8. El metodo informatico segun la reivindicacion 7, en el que cada nodo de la red subyacente esta configurado para hacer funcionar el motor de decision para realizar la simulacion para determinar como debe procesarse un paquete que llega al nodo.

9. El metodo informatico segun la reivindicacion 7 u 8, en el que la determinacion de como debe procesarse el paquete incluye determinar un patron de cabecera de protocolo de paquete a partir de un resultado de la simulacion por el motor de decision para el paquete, comprendiendo ademas el metodo:

almacenar el patron de cabecera de protocolo de paquete y el resultado de la simulacion para el paquete, recibir un segundo paquete en el primer nodo de la red subyacente,

comparar el segundo paquete con el patron de cabecera de protocolo de paquete,

si el segundo paquete coincide con el patron de cabecera de protocolo de paquete, determinar como debe procesarse el segundo paquete recuperando el resultado almacenado de la simulacion para el paquete, y procesar el segundo paquete basandose en el resultado recuperado de la simulacion por el motor de decision para el paquete.

10. El metodo informatico segun una de las reivindicaciones 7 a 9

en el que la determinacion de como debe procesarse el paquete incluye determinar que el paquete debe emitirse desde una segunda interfaz de red del primer nodo de la red subyacente, y

en el que el procesamiento del paquete incluye emitir el paquete desde la segunda interfaz de red.