Autoconfiguración de dispositivos de red con lógica de configuración

1. Introducción

A pesar del enorme desarrollo de los servicios y funcionalidades de red

Los años, la configuración y despliegue de elementos de red como enrutadores
Y conmutadores sigue siendo una tarea mayormente manual. Un conocimiento intrincado de
cada uno Dispositivos y servicios "y las dependencias entre la configuración
Los parámetros necesarios del ingeniero de red para ejecutar con éxito
Incluso casos de uso básicos. La adición de un nuevo dispositivo o el despliegue de un nuevo
Servicio a una infraestructura existente requiere manipulación repetitiva pero cuidadosa
De múltiples parámetros de configuración en muchos elementos, e incluso una
El trabajo puede generar efectos secundarios impredecibles que se descubren por ensayo y
error.
La aplicación del paradigma de sistemas autónomos [19] a las redes informáticas
Ofrece un medio prometedor para liberar la carga del conocimiento y tedioso
Manipulaciones actualmente necesarias de los ingenieros. Por definición, los dispositivos auto
gestionados Puede modular automáticamente su comportamiento en reacción a la
configuración Incoherencias o cambios en la topología o las políticas de gestión de la red.
En este artículo, describimos un método de descubrir y generar automáticamente

La configuración de un dispositivo de red. Cada configuración está representada en

La forma de una jerarquía de pares de parámetro-valor que se asimila a una etiqueta
D. Gaiti et al. (Eds.): AN 2006, LNCS 4195, pp. 36-49, 2006.
C IFIP Federación Internacional para el Tratamiento de la Información 2006
Autoconfiguración de dispositivos de red con lógica de configuración 37

árbol. Las dependencias entre estos parámetros se expresan entonces como auto-reglas
En un formalismo especial llamado Configuración lógica (CL) [22].
A partir de la fórmula CL que define cada regla, mostramos cómo una acción puede ser
automáticamente asociado; Esta acción consiste en una serie de operaciones de configuración
Cuyo resultado final garantiza que se cumpla la norma. Un motor de validación de CL puede
Comprobar si un determinado conjunto de auto-reglas se respetan en una red
Y desencadenar las acciones apropiadas asociadas con las reglas que son violadas.
El sistema utiliza una prueba de satisfacción booleana estándar para generar una
Planifica correctamente la instancia de valores de parámetros y elige entre conflictos
comportamiento; En caso de que sea posible más de un plan, la elección final puede
Luego se pasará a un administrador de políticas de nivel superior. Este método puede usarse
Para la integración de funcionalidades de auto-configuración y auto-sanación en cualquier
Donde las configuraciones de los dispositivos están representadas por árboles. Lo ilustraremos
Por un simple ejemplo en Virtual LANs en el que se conecta un nuevo switch y
Descubre su configuración de forma plug-and-play basada en los datos obtenidos
Desde otros dispositivos de la red.
El resto del documento está estructurado de la siguiente manera. La sección 2 presenta el
trabajo relacionado.

La sección 3 presenta el caso de uso de VLAN que ilustra nuestro método y elicita
Una serie de auto-reglas de configuración de VLAN. La sección 4 presenta la estructura de
árbol Se utiliza para describir las configuraciones y formalice las reglas de configuración usando
Lógica de configuración. La Sección 5 extiende el escenario VLAN original para permitir
Autoconfiguración y muestra cómo las reglas VLAN violadas activan las operaciones de
configuración.
Finalmente, la sección 6 concluye e indica posibles trabajos futuros.

2. Trabajo relacionado

El enfoque autonómico de la gestión de redes ha sido la fuente de numerosos

En los últimos años. Empresas como Cisco y Motorola son
Desarrollando conceptos similares llamados respectivamente redes programables [2] y
Redes cognitivas; La idea también se ha desarrollado en [16].
El proyecto SELFCON [5] desarrolló un entorno de autoconfiguración basado en
El Directorio habilitado para redes (DEN) [21] principios, donde los dispositivos de registro
En un servidor de directorio centralizado que les notifique de cambios en la configuración
Políticas o estado de la red. Del mismo modo, el entorno AUTONOMIA [15] proporciona
Una arquitectura autónoma para el control y la gestión automatizados de
Aplicaciones. En [20], un conjunto de protocolos compatibles con TCP / IP se describe
Que se podrían implementar en "routers inteligentes" autónomos basados en agentes que
Tomar las decisiones sobre qué protocolo en la suite se debe utilizar para optimizar
Algunos objetivos definidos por el usuario. Todos estos proyectos describen una
infraestructura en términos de
Conceptos de alto nivel y no se concentran en la representación, validación y
Generación de configuraciones y reglas, sino que proporcionan un ambiente
En el que estas operaciones pueden tener lugar. El enfoque de agente se extiende en [11]
Desde una perspectiva de calidad de servicio y actualmente está en desarrollo.
En [12], los parámetros de una red óptica se reconfiguran automáticamente
Basado en el tráfico de enlaces mediante técnicas de regresión. Sin embargo, la gama de
valores de estos parámetros es fijo y conocido de antemano y la reconfiguración
Sólo tiene como objetivo encontrar un ajuste óptimo de los valores existentes: la propia red
Se supone que funciona correctamente en cualquier momento. Nuestro trabajo no intenta
Estructuralmente modificar una configuración mediante la adición y eliminación de
parámetros. Además,
En nuestra situación, el rango legal de valores cambia de vez en cuando y
Nuestro método intenta descubrir que van desde las reglas de configuración.
El sistema de software GulfStream [10] proporciona un descubrimiento de topología dinámica
Y detección de fallos para clústeres de conmutadores en VLANs múltiples; El enfoque es
No se basa en el examen de la configuración de otros interruptores, sino
Sobre la difusión de mensajes Beacon y heartbeat entre pares VLAN
Y es algo restringido a esta situación particular.
Nuestro enfoque también difiere de sistemas de configuración bien establecidos como
Cfengine [7] en que sólo las propiedades deseadas de la configuración se expresan
De forma declarativa, pero ninguna acción o script debe ser especificado por el usuario. los
Método que presentamos determina automáticamente las acciones apropiadas
Configuración para cumplir con las reglas deseadas.
Por último, se ha publicado mucho trabajo sobre autoconfiguración aplicada a
sensor de redes inalámbricas. En este contexto, la palabra "configuración" generalmente
Se refiere al arreglo topológico de los diferentes elementos que forman el sensor
Malla, y no los parámetros lógicos que regulan el comportamiento de un dispositivo en
sí mismo. Por lo tanto, sólo está ligeramente relacionado con el presente trabajo.

3 Restricciones y reglas en los servicios de red

En esta sección, desarrollamos un ejemplo de configuración basado en el área local virtual

Nertworks y el Protocolo Virtual de Trunking. Expresamos auto-reglas de configuración
Para que una configuración de este tipo sea funcional. Este ejemplo más adelante
Se utiliza para mostrar cómo podemos encontrar la configuración apropiada de un
Autoconfiguración y auto-sanación contexto.

3.1 Redes de área local virtuales y el protocolo de trunking virtual

Los conmutadores permiten dividir una red en segmentos lógicos a través del uso
De redes de área local virtuales (VLAN). Esta segmentación es independiente de la
Localización física de los usuarios en la red. Los puertos de un conmutador
A la misma VLAN pueden comunicarse en la capa 2 mientras que los puertos no asignados
A la misma VLAN requieren comunicación de capa 3. Todos los conmutadores que
Share La comunicación intra-VLAN de la capa 2 necesita ser conectada por un tronco. IEEE
802.1Q [4] y VTP [1] son dos protocolos populares para troncales VLAN.
En principio, para que una VLAN exista en un conmutador, debe crearse manualmente
El ingeniero de red en dicho conmutador. El Virtual Trunking Protocol (VTP)
[1] ha sido desarrollado en dispositivos Cisco para centralizar la creación y eliminación
De VLAN en una red en un servidor VTP. Este servidor se encarga de crear,
Borrar y actualizar el estado de las VLAN existentes a los otros conmutadores que comparten
El mismo dominio VTP.

3.2 Restricciones en las configuraciones de VLAN

Nuestro ejemplo de configuración implica VTP. Considere una red de conmutadores tales
Como el que se muestra en la Figura 1, donde varias VLAN están disponibles. Expresamos un
número de auto-reglas VTP que deben ser verdaderas en esta red.

fig. 1. Un cluster simple de switches en la misma VLAN. Los enlaces son troncales VLAN.

En primer lugar, para tener una configuración VTP activa, la red necesita un Servidor VTP
único; Todos los demás conmutadores deben ser clientes VTP. Esto requiere una primera
Conjunto de dos auto-reglas:

VTP Self-Rule 1. El VTP debe estar activado en todos los interruptores.

VTP Self-Rule 2. Hay un servidor VTP único.

Imponemos que todos los switches estén en el mismo dominio VTP, y que si dos switches
Están conectados por un tronco, entonces este tronco debe estar encapsulado en el mismo
modo. En ambas interfaces. Esto nos da dos restricciones más que deberían ser verdaderas en
todas veces:
VTP Self-Rule 3. Todos los conmutadores deben estar en el mismo dominio VTP.

VTP Self-Rule 4. Las interfaces en ambos extremos de un tronco deben ser definidas como
Tales y encapsulados en el mismo modo.

4 Configuraciones y reglas

En esta sección, ofrecemos un breve resumen de la lógica de configuración (CL), una lógica
Formalismo sobre estructuras de árbol desarrolladas para expresar propiedades de
configuraciones. Mostramos cómo las Reglas de Auto-VTP descritas en la sección anterior
pueden Ser reescrito en CL para convertirse en Formal VTP Self-Rules.

4.1 Representación de las configuraciones

Como se explica en [13], la configuración de dispositivos de red como enrutadores y

Interruptores se puede representar como un árbol donde cada nodo es un par compuesto de
un Nombre y un valor. Este árbol representa la jerarquía de parámetros inherente a

fig. 2. Una parte de la configuración del conmutador-1 en la red de la Figura 1. La configuración

del switch-2 y del switch-3 difiere en el modo VTP y en la información del tronco.

La configuración de tales dispositivos. Como ejemplo, la Figura 2 muestra una representación

en árbol De la configuración del conmutador 1 en la red de la figura 1. Construir un árbol desde
un documento XML es trivial; Por lo tanto, la representación De las configuraciones como los
árboles se asemeja a la naturaleza XML de un protocolo como Netconf [9] que utiliza este
formato para buscar y modificar la configuración de un dispositivo.

4.2 Una lógica para configuraciones

La lógica de la configuración [22] fue desarrollada para expresar propiedades en la

configuración Árboles. Las fórmulas CL usan las tradicionales conectivas booleanas del
predicado
Lógica: ∧ ("y"), ∨ ("o"), ¬ ("no"), → ("implica"), a la que dos cuantificadores especiales
Se agregan. El cuantificador universal, identificado por [], indica una ruta en
El árbol e impone que una fórmula sea verdadera para todos los nodos al final de ese camino.
Del mismo modo, el cuantificador existencial, identificado por? ?, Indica una ruta en el árbol
E impone que una fórmula sea verdadera para algún nodo al final de ese camino.
Para mejorar la legibilidad de las reglas CL, podemos usar predicados. Los predicados son
Expresadas de la misma manera que las normas, con la excepción de que los
Corresponden a nodos ya cuantificados. Por ejemplo, para crear un
Predicado que devuelve true si un switch es un cliente VTP, se puede hacerlo escribiendo:

Es VTP Cliente (s): -

{S; Vtp modo = x } X = cliente

Este predicado indica que bajo el nodo S pasado como un argumento, existe
Un nodo cuyo nombre es "modo vtp" y cuyo valor es x, y donde x es igual a
"cliente". En otras palabras, este predicado es verdadero siempre que S tenga un niño
etiquetado "Vtp mode = client", lo que significa que el dispositivo es de hecho un cliente VTP.
Del mismo modo, los predicados IsVTPServer e IsTrunk respectivamente indican que
El dispositivo es un servidor VTP y que una interfaz específica está conectada a un tronco.
Se definen como los siguientes:

IsVTPServer (S): -
S; Vtp modo = x? X = servidor
IsTrunk (I): -
{YO ; Modo switchport = x } X = tronco

El predicado siguiente afirma que dos conmutadores están en el mismo dominio VTP. Esta
Se realiza comprobando que para dos nodos S y T que representan la raíz de la
Árbol de configuración de dos dispositivos, también aparecerá todo dominio VTP
Bajo T.
SwitchesInSameVTPDominio (S, T): -

[S; Dominio vtp = x]

\ Delta T; Vtp domain = y? X = y

Finalmente, este último predicado verifica que la encapsulación en un tronco de VLAN es

Ya sea IEEE 802.11Q o ISL, y que ambos extremos utilizan protocolos de coincidencia:

SameEncapsulation (I1, I2): -

[I1; Switchport encapsulation = x1]
\ Delta I2; Switchport encapsulation = x2?
(X1 = dot1q ∧ x2 = dot1q) ∨ (x1 = isl ∧ x2 = isl)
Para más detalles acerca de CL, el lector se dirige a [22, 23, 14].

4.3 Reglas Expresadas en la Lógica de Configuración

Equipado con los predicados anteriores, las auto-reglas VTP mencionadas en la sección
3 ahora se puede expresar en la lógica de la configuración. La primera regla comprueba si
El VTP está activado en todos los interruptores.

Auto-Regla VTP Formal 1 (VTPActivated)

[Device = s1]
IsVTPServer (s1) ∨ ISVTPClient (s1)

Esto se hace indicando que para cada dispositivo s1, s1 es un servidor VTP, o s1
Es un cliente VTP. Tenga en cuenta que esta regla utiliza los predicados definidos
anteriormente para simplificar
Su expresión; Sin embargo, los predicados no son necesarios, y su definición
Simplemente podría haber sido copiado en la regla.
La segunda regla asegura que hay una, y sólo un servidor en la
red. Primero se indica que existe un dispositivo s1 que es un servidor VTP, y
Entonces que cada dispositivo s2 diferente de s1 es un cliente VTP. Observar que este
Regla subsume la anterior, que todavía se ha incluido para ilustrar más adelante
conceptos.

Formal VTP Auto-Regla 2 (UniqueServer)

? Device = s1?
(IsVTPServer (s1) ∧
[Device = s2]
S1? = S2 → IsVTPClient (s2))

La tercera regla comprueba que todos los conmutadores de la red tengan el mismo VTP
Dominio.

Formal VTP Auto-Regla 3 (SameVTPDomain)

[Device = s1]
[Device = s2]
SwitchesInSameVTPDomain (s1, s2)

Lo hace afirmando que para cada par de dispositivos s1 y s2, el predicado

"SwitchesInSameVTPDomain" definido anteriormente es verdadero.
Finalmente, la cuarta regla comprueba que si dos interfaces están conectadas,
Dos interfaces deben definirse como troncos y tienen el mismo protocolo de encapsulación.

Formal VTP Auto-Regla 4 (TrunkActive)

[Device = s1]
[Device = s2]
[S1; Interface = i1]
S2; Interface = i2?
(InterfacesConnected (i1, i2) → (IsTrunk (i1)
∧ IsTrunk (i2) ∧ SameEncapsulation (i1, i2)))

La relación "InterfacesConnected" no es un predicado definido en CL, sino más bien

Un sistema primitivo que la red puede decirnos acerca de. Devuelve true si los dos
Las interfaces están conectadas por un enlace. Esto requiere el conocimiento de la topología
de La red y depende de la arquitectura del componente autonómico, como
Se discutirá en la siguiente sección.

5 Un escenario de autoconfiguración

En esta sección, mostramos cómo usar la lógica de configuración para activar la configuración
Cambios en los dispositivos. La figura 3 presenta una posible arquitectura utilizando este
método. Muestra cómo una herramienta existente llamada ValidMaker [8] que descarga y
carga Árboles de configuración del archivo de configuración almacenado en enrutadores y
conmutadores, Se pueden utilizar de forma gratuita para proporcionar un comportamiento
autónomo a los dispositivos. Un CL El motor de validación se implementa dentro de
ValidMaker. Por lo tanto, se puede cargar Configuraciones, definir auto-reglas en estas
configuraciones y verificar automáticamente ellos. Si una o varias reglas resultan ser falsas, un
generador de configuración adicional Puede ajustar los árboles de configuración y generar las
nuevas configuraciones Que luego se puede volver a colocar en los dispositivos.
Para ello, revisamos el escenario original de VLAN descrito en la sección 3 de
Un punto de vista autonómico de la red. En lugar de validar las reglas de configuración
Estático, completamente formado de interruptores, suponemos que un interruptor está
conectado a El clúster con una configuración en blanco, como se muestra en la figura 4. Más
La interfaz fe04 del conmutador-4 está conectada a la interfaz fe06 del conmutador-3. los
El árbol de configuración inicial de switch-4 es un árbol con un solo nodo raíz etiquetado
"Device = switch-4".
Basándonos en este caso de uso, describimos un método que permite Descubrirá
automáticamente su configuración.

fig. 3. Una posible arquitectura de autoconfiguración con componentes disponibles en el

mercado

fig. 4. Caso de uso autonómico. El interruptor 4 está conectado al interruptor 3 e intenta

descubrir Su configuración.

5.1 Restricciones activas

Las reglas de red mostradas en la sección 3.2 se han interpretado hasta ahora en
Una forma estática: su validación nos permitió determinar si una configuración
Satisfecho o no. Sin embargo, es posible ir más lejos y automáticamente
Asociar con cada regla una acción, convirtiéndola así en una "auto-regla". Esta acción,
En línea con la semántica de los operadores utilizados en la regla, se genera tal
Que la ejecución cambia la configuración de una manera que cumple la regla que
Fue originalmente falsa.
Como ejemplo, considere una regla de la forma? P = x? Φ (x). Tal regla impone
La existencia de un nodo p = x en la configuración del dispositivo. Si se viola,
Esto significa que no existe tal tupla p = x; Para hacer esta regla verdad, el nodo
Debe añadirse a la configuración. Esta adición de un nuevo nodo
A una operación de configuración equivalente a escribir un comando (o una secuencia de
Comandos) a la CLI del dispositivo. Además, el valor x de este parámetro
Debe ser tal que φ (x) sea verdadera.
Para que tal procedimiento sea posible, las fórmulas que intenta
Expresarse en una lógica en la que la existencia de un modelo es un problema decidible.
De lo contrario, no siempre es posible encontrar y construir una configuración que satisfaga
Una fórmula dada. Por lo tanto, la elección de CL como formalismo lógico de
Las reglas formales no son arbitrarias: se ha demostrado en [23] que bajo razonable
Condiciones, CL es una lógica decidible. Utilizar una lógica más rica como XPath o TQL
Llevaría a la indecidibilidad, como se ha demostrado en [6].
Por lo tanto, al descender recursivamente a través de los subformulas anidados de CL, es
Posible crear una serie de operaciones de configuración y restricciones
En sus parámetros que hacen que toda autonomía sea verdadera. Con este fin, definimos un
Llamado PlanT que recursivamente crea los planes para cada regla dada una
Árbol de configuración global T. La notación especial ⊕ (p = x; p = x) indica que
Un nodo de parámetro p y valor x debe ser agregado al árbol en la punta de la
Rama p = x. Este procedimiento se define en la Tabla 1

Tabla 1. El procedimiento de generación de planes recursivos

PlanT (φ) = 1 si T | = φ
PlanT (¬φ) = ¬PlanT (φ)
PlanT (φ ∧ ψ) = PlanT (φ) ∧ PlanT (ψ)
PlanT (φ ∨ ψ) = PlanT (φ) ∨ PlanT (ψ)
PlanT (? P = x; p = x? Φ (x)) = ⊕ (p = x; p = x) ∧ PlanT (φ)
PlanT ([p = x; p = x] φ (x)) =
x
PlanT (φ)

Como ejemplo, considere la configuración inicial del switch-4 cuando se añade

A la configuración del clúster original de conmutadores que se muestra en la Figura 2.
Es claro que la Auto-Regla VTP Formal 1, que impone la presencia de cualquiera
Servidor o cliente en cada switch, se viola para el switch-4. El recursivo
La aplicación del Plan en esta fórmula produce la siguiente acción:

⊕ (dispositivo = switch-4; modo vtp = servidor) ∨

⊕ (dispositivo = switch-4; modo vtp = cliente) (1)
Que ordena que se determine el rol VTP del conmutador. Este papel es
Especificado por la adición de cualquiera de los nodos vtp mode = server o vtp mode = client
Bajo la raíz del árbol de configuración de switch-4. De forma similar, se viola la Auto-Regla VTP
Formal 2. Implica que sólo haya una Servidor en la red y que todos los demás sean clientes, y
produce los siguientes acción:

⊕ (dispositivo = switch-4; modo vtp = cliente) (2)

En otras palabras, la única acción posible es la definición de switch-4 como cliente.

La auto-regla 3 de VTP formal también es violada. Esta regla impone que todos los
En el mismo dominio. La aplicación de Plan en esta regla produce esta acción:
⊕ (dispositivo = switch-4; dominio vtp = contabilidad) (3)
Por último, las acciones producidas por la Auto-Regla VTP Formal 4 son las siguientes:
⊕ (dispositivo = conmutador-3; interfaz = fe06)
∧ ⊕ (dispositivo = conmutador-4; interfaz = fe04)
∧ ⊕ (dispositivo = conmutador-3, interfaz = fe06; modo switchport = tronco)
∧ ⊕ (dispositivo = conmutador-4, interfaz = fe04; modo switchport = tronco)
∧
(⊕ (dispositivo = switch-3, interfaz = fe06; switchport encapsulation = dot1q) ∧
⊕ |! (Device = switch-4, interface = fe04; switchport encapsulation = dot1q)) ∨
(⊕ (dispositivo = conmutador-3, interfaz = fe06; encapsulación switchport = isl) ∧
⊕ (dispositivo = conmutador-4, interfaz = fe04; switchport encapsulation = isl))
)
(4)

Este último conjunto de acciones es interesante, ya que impone la adición de nodos no

Sólo en el switch 4 recién conectado, sino también en el switch-3 que es
Ya forma parte de la VLAN de trabajo. La razón es que conectar el interruptor-3 a
Switch-4 implica configurar un tronco, una operación que requiere configuración
Modificaciones en ambos extremos del alambre.
Por lo tanto, el curso real de las acciones dependerá de la arquitectura elegida:
Si el módulo de autoconfiguración representado en la Figura 3 está descentralizado en
, Cada switch debe ignorar las acciones que modifican otros dispositivos,
Suponiendo que los dispositivos en cuestión tomarán las medidas adecuadas para
Situación de su lado. Si el módulo de autoconfiguración está centralizado para
Algunos dispositivos, los cambios pueden ser enviados por la comunicación del dispositivo
Administrador a múltiples conmutadores a la vez.
El plan global que debe ser ejecutado para hacer verdaderas las reglas es la conjunción
De las ecuaciones (1) - (4).

5.2 Generación de la configuración

Se puede ver que el plan anterior no es determinista. Por ejemplo, si un

\ Vskip1.000000 \ Φ ∨ ψ es falso, hay dos formas diferentes de hacerla verdad:
Haciendo φ verdadero, o haciendo ψ verdadero. En tal caso, ambas soluciones son
Explorado y propagado hasta la pila de recursión. Esto sucede con las acciones
Producido por la Auto-Regla VTP Formal 1 que define el switch como cliente
O como servidor. De la misma manera, las acciones producidas por la AutoRule Formal de VTP
4 impone que la encapsulación del tronco en el switch-3 y el switch-4 sea
Tanto dot1q como isl, pero ya que ninguno de ellos ya está configurado y
No se aplica ninguna restricción adicional, la elección es gratuita.
Además, se ha generado un plan separado para cada uno de ellos violado; sin embargo,
Es muy posible que estos planes sean mutuamente contradictorios y que no

Existe una solución global. Por último, hay que asegurarse de que la ejecución de los
Sólo hace que las reglas violadas sean verdaderas, pero a su vez no produce efectos
secundarios que
Podría falsificar otras reglas que eran anteriormente verdaderas.
Para ello, se realizan dos pasos adicionales antes de comprometer cualquier configuración
Al dispositivo. Primero, se debe encontrar una asignación satisfactoria del plan global.
Esto puede obtenerse fácilmente aplicando una satisfacibilidad booleana estándar (SAT)
Solver como zChaff [17] o SATO [24]. Esta asignación designa las acciones
Que son elegidos de entre las muchas alternativas sugeridas por el plan para
Hacer las fórmulas verdaderas.
Una vez que se ha encontrado esta asignación, el plan se ejecuta provisionalmente
Configuración, y todo el conjunto de auto-reglas es entonces revalidado contra este
Configuración modificada. Si una de las reglas es violada, la asignación satisfactoria
Se descarta y el procedimiento retrocede para encontrar una nueva asignación. Esto es
Caso de que se elijan las siguientes operaciones como la acción a ejecutar en el
Configuración (para mayor claridad, se omitieron las acciones en el switch-3):

⊕ (dispositivo = conmutador-4; modo vtp = servidor)

⊕ (dispositivo = switch-4; modo vtp = cliente)
⊕ (dispositivo = switch-4; dominio vtp = contabilidad)
⊕ (dispositivo = conmutador-4; interfaz = fe04)
⊕ (dispositivo = conmutador-4, interfaz = fe04; modo switchport = tronco)
⊕ (dispositivo = switch-4, interfaz = fe04; switchport encapsulation = dot1q)
La configuración resultante de las operaciones anteriores viola Formal VTP
Auto-Regla 2, ya que asigna switch-4 a la función de cliente y servidor en la
Mismo tiempo. Vuelve a la Auto-Regla VTP Formal 2 por otra razón, como un servidor
Ya existe en la red.

Sin embargo, una segunda posible asignación de verdad al plan global es la siguiente:

⊕ (dispositivo = switch-4; modo vtp = cliente)

⊕ (dispositivo = switch-4; dominio vtp = contabilidad)
⊕ (dispositivo = conmutador-4; interfaz = fe04)
⊕ (dispositivo = conmutador-4, interfaz = fe04; modo switchport = tronco)
⊕ (dispositivo = switch-4, interfaz = fe04; switchport encapsulation = dot1q)

La configuración resultante de estas operaciones valida todas las auto-reglas formales VTP
Por lo tanto, es admisible. En tal caso, la configuración tentativa es
Cometido como la configuración de ejecución del conmutador. La configuración resultante
Árbol obtenido de estos pasos de configuración autonómica se muestra en la Figura 5.
Se puede observar que este método también puede funcionar en un contexto de auto-
curación donde
Una red de trabajo es perturbada; El método de generación de planes recursivos
Aquí asegura que las configuraciones de los dispositivos pueden ser pero volver a un estado
Donde cumplen todas las reglas que deben aplicarse en la red.

fig. 5. La configuración del switch-4 después de la generación automática de la configuración

Tabla 2. Tiempo de validación de cada auto-regla VTP formal en una red formada por un
número variable de conmutadores

5.3 Complejidad del Método y Resultados Experimentales

Ahora evaluamos la complejidad global del método. Aunque la satisfacción booleana

Fabilidad es un problema NP-completo, no es el cuello de botella del procedimiento, como
La fórmula booleana global que se genera nunca tiene más de unas pocas docenas,
Posiblemente un centenar, operaciones de configuración. Por lo tanto, el tamaño de los
booleanos Ejemplo a ser procesado es insignificante según las normas SAT, y puede
Fracciones de un segundo por solucionadores SAT acostumbrados a problemas que superan el
millón De las variables. Cada operación de configuración en sí misma consiste únicamente en
la adición de Nodo en el árbol de configuración de un dispositivo y también se puede
considerar instantáneo. Por lo tanto, el núcleo de la complejidad de este método reside en la
validación De fórmulas CL en múltiples encarnaciones de configuraciones para muchos
dispositivos. Para que este método sea manejable, la validación de las fórmulas CL debe
Ser rápido y sencillo. Se ha demostrado en [14] que el modelo CL de verificación de un
La fórmula es polinomial en el tamaño del árbol.
Damos en la Tabla 2 los tiempos de validación para una red compuesta de 10 a 80
Interruptores. Estas configuraciones fueron generadas por un script parametrizable y
Y luego cargarse en ValidMaker. Todos los resultados se han obtenido en un Pentium IV
De 2,4 GHz con 512 Mb de RAM con Windows XP Professional; son
Consistente con el resultado de polinomialidad ya demostrado.
Como se puede ver a partir de estos resultados, los tiempos de validación son razonables y
No exceso de 25 milisegundos por dispositivo para la red más grande de 80 conmutadores.
Uno Debe comparar estas cifras con el tiempo necesario para inyectar realmente un nuevo
Configuración en un switch y reiniciarlo para que sea efectivo, lo cual es al menos un pocos
segundos. Además, debe observarse que los experimentos de validación mostrados Aquí
implican la validación de toda la red, y no sólo de los pocos dispositivos Que podría estar
preocupado cuando un nuevo interruptor está conectado; Esto es especialmente cierto Para
VTP Auto-Regla 4.

6 Conclusión y trabajo futuro

En este trabajo, hemos mostrado cómo auto-configurar un dispositivo de red mediante la

validación Restricciones en la configuración de otros dispositivos expresados como árboles de
Parámetros y valores. Mostramos cómo un nuevo switch conectado a una VLAN
Puede descubrir su configuración mediante la selección de un plan adecuado que intente
Restricciones de configuración existentes. También mostraron por resultados experimentales
con La herramienta de configuración de ValidMaker que la validación de auto-reglas es un
tractable Operación que impone tiempo insignificante para ejecutar.
En este momento, las instancias SAT que forman los planes posibles se tratan
Separadamente de la validación CL en un solver independiente incrustado en el
Generador de configuración. Una extensión natural de este trabajo es enriquecer este
Modelo, tratando con los efectos secundarios de la aplicación de una autogobierno y apoyo
Supresión y modificación de nodos, por ejemplo integrando componentes CL en Un solver SAT
existente en el contexto de SAT modulo teorías [18].
Reconocimiento Agradecemos el apoyo financiero de las Ciencias
Consejo de Investigación de Ingeniería de Canadá en esta investigación.