Gestión de enlaces de datos de red en Oracle® Solaris 11.2

Salir de la Vista de impresión

Actualización: Septiembre de 2014
 
 

Detección de fallos en la agregación DLMP

La detección de fallos en la agregación DLMP es un método para detectar el fallo de los puertos agregados. Se considera que un puerto ha fallado cuando no puede enviar o recibir tráfico. El puerto puede fallar debido a los siguientes motivos:

  • Daños o cortes en el cable

  • Desactivación del puerto del conmutador

  • Fallo en la ruta de red ascendente

La agregación DLMP realiza una detección de fallos en los puertos agregados para garantizar la disponibilidad continua de la red para enviar o recibir tráfico. Cuando un puerto falla, se hace failover de los clientes asociados con ese puerto a un puerto activo. Los puertos agregados con fallos siguen sin poder utilizarse hasta que se hayan reparado. Los puertos activos restantes siguen funcionando mientras los puertos existentes se implementan según sea necesario. Después de que el puerto con errores se recupera del fallo, los clientes de otros puertos activos pueden asociarse a él.

La agregación DLMP admite la detección de fallos basada en sondeos y basada en enlaces.

Detección de fallos basada en enlaces

La detección de fallos basada en enlaces detecta el fallo cuando el cable se corta o cuando el puerto del conmutador deja de funcionar. Por lo tanto, sólo puede detectar los fallos provocados por la pérdida de conexión directa entre el enlace de datos y el conmutador de primer salto. La detección de fallos basada en enlaces se activa de forma predeterminada cuando se crea una agregación DLMP.

Detección de fallos basada en sondeos

La detección de fallos basada en sondeos detecta fallos entre un host de finalización y los destinos configurados. Esta función supera las limitaciones conocidas de la detección de fallos basada en enlaces. La detección de fallos basada en sondeos es útil cuando un enrutador predeterminado está inactivo o cuando la red se vuelve inaccesible. La agregación DLMP detecta el fallo mediante el envío y la recepción de paquetes de sondeo.

Para activar la detección de fallos basada en sondeos en la agregación DLMP, debe configurar la propiedad probe-ip.


Notas -  En una agregación DLMP, si probe-ip no está configurado, la detección de fallos basada en sondeos está desactivada y sólo se utiliza la detección de fallos basada en enlaces.

Al crear la primera agregación DLMP, el servicio svc:/network/dlmp:default se activa automáticamente. Este servicio inicia el daemon in.dlmpd, que realiza la detección de fallos basada en sondeos en las agregaciones DLMP. Este servicio está desactivado cuando no hay una agregación DLMP en el sistema. Para obtener más información, consulte Configuración de la detección de fallos basada en sondeos para la agregación DLMP.

La detección de fallos basada en sondeos se realiza mediante la combinación de dos tipos de sondeos: sondeos del protocolo de mensajes de control de Internet (ICMP) (L3) y sondeos transitivos (L2), que funcionan juntos para determinar el estado de los enlaces de datos físicos agregados.

  • Sondeo ICMP

    Puede configurar una lista separada por comas de direcciones IP de origen y un nombre de host o dirección IP de destino opcional. La dirección IP de destino debe estar en la misma subred que la dirección IP de origen especificada. Puede especificar la dirección IP de origen de cuatro formas diferentes. Para obtener más información, consulte Cómo configurar la detección de fallos basada en sondeos para DLMP.

    El sondeo ICMP utiliza las direcciones IP de origen configuradas de la propiedad probe-ip sólo si las direcciones IP están asociadas con clientes, por ejemplo, VNIC. Un puerto se asocia con un cliente, como una VNIC, sólo cuando el puerto recibe el tráfico entrante y transmite el tráfico saliente para ese cliente. En cualquier momento dado, el tráfico entrante o saliente de un cliente siempre pasa a través de un solo puerto subyacente de la agregación DLMP. Las direcciones IP configuradas de la propiedad probe-ip se utilizan para supervisar el estado de los puertos sólo si las direcciones IP están asociadas con ese puerto.

    Para cada dirección IP de origen configurada, el daemon in.dlmpd envía paquetes de ICMP de unidifusión de forma periódica dirigidos a los destinos configurados. Si las direcciones IP de destino no están configuradas, in.dlmpd utiliza la tabla de enrutamiento para las rutas de la misma subred que la dirección IP de origen especificada y utiliza el próximo salto especificado como la dirección IP de destino.

    El tráfico de sondeos ICMP se envía únicamente a través del puerto asociado con ese cliente IP. El puerto se marca como error de ICMP si no se puede acceder a ninguno de los destinos para ese puerto específico. El puerto se marcado como ICMP activo si se puede acceder a, al menos, uno de los destinos desde dicho puerto a través de un sondeo ICMP.

  • Sondeo transitivo

    El sondeo transitivo se realiza cuando no se puede determinar el estado de todos los puertos de la red mediante el sondeo ICMP. Por lo tanto, el sondeo transitivo se realiza si alguno de los puertos no está asociado con la dirección IP de origen configurada para la propiedad probe-ip. Por ejemplo, el sondeo transitivo se realiza cuando hay un puerto que no está asociado a un cliente IP o cuando el número de direcciones IP configuradas de la propiedad probe-ip es menor que el número total de puertos agregados. Los paquetes de sondeo se envían periódicamente desde los puertos que no están asociados con ningún cliente IP hacia los puertos del igual. Si un puerto puede comunicarse con cualquier puerto ICMP activo, se considera que ese puerto está activo para L2.

    Oracle Solaris incluye paquetes de protocolo de propiedad para los sondeos transitivos que se transmiten a través de la red. Para obtener más información, consulte el Appendix B, Formato de paquete de los sondeos transitivos.

La detección de fallos basada en sondeos se realiza en la zona global cuando las VNIC de una agregación se crean en la zona global y se asignan a las zonas no globales. Sin embargo, el tráfico de sondeos se puede segregar de la zona no global con la ayuda de VLAN. Por ejemplo, cuando el tráfico de sondeos se ejecuta en una VLAN en una zona global, el tráfico de la zona no global puede ejecutarse en una VLAN diferente.