Capítulo 30 Introducción a IPMP (descripción general)

Las múltiples rutas de redes IP (IPMP) detectan los fallos en la interfaz física y conmutan por error el acceso a la red de forma transparente para un sistema con varias interfaces en el mismo vínculo IP. IPMP también permite repartir la carga de los paquetes para los sistemas con varias interfaces.

Este capítulo contiene la información siguiente:

• Por qué debe utilizar IPMP

• Requisitos básicos de IPMP

• Direcciones IPMP

• Componentes IPMP de Oracle Solaris

• Configuraciones de interfaces IPMP

• Funciones de detección de fallos IPMP y recuperación

• IPMP y reconfiguración dinámica

Para conocer las tareas de configuración de IPMP, consulte el Capítulo 31Administración de IPMP (tareas).

Por qué debe utilizar IPMP

IPMP ofrece una mayor fiabilidad, disponibilidad y rendimiento de la red para los sistemas con múltiples interfaces físicas. Ocasionalmente, una interfaz física o el hardware de red conectado a la interfaz podrían fallar o requerir mantenimiento. Por norma general, en ese punto, ya no es posible contactar con el sistema mediante cualquiera de las direcciones IP que están asociadas con la interfaz fallida. Asimismo, se interrumpe cualquier conexión con el sistema que utilice dichas direcciones IP.

Gracias a IPMP, puede configurar una o más interfaces físicas en un grupo de múltiples rutas IP o grupo IPMP. Después de configurar IPMP, el sistema supervisa automáticamente las interfaces del grupo IPMP para detectar posibles errores. Si falla una interfaz del grupo o se elimina para fines de mantenimiento, IPMP migra automáticamente o hace que fallen las direcciones IP de la interfaz fallida. El destinatario de estas direcciones es una interfaz en funcionamiento del grupo IPMP de la interfaz fallida. La función de conmutación tras error de IPMP mantiene la conectividad e impide la interrupción de cualquier conexión. Asimismo, IPMP mejora el rendimiento global de la red al expandir automáticamente el tráfico de la red por un conjunto de interfaces del grupo IPMP. Este proceso se denomina expansión de carga.

Componentes IPMP de Oracle Solaris

IPMP de Oracle Solaris implica el siguiente software:

• El daemon in.mpathd, que se describe detalladamente en la página del comando man in.mpathd(1M).

• El archivo de configuración /etc/default/mpathd, que también se describe en la página del comando man in.mpathd(1M).

• Opciones ifconfig para la configuración de IPMP, tal como se describe en la página del comando man ifconfig(1M).

Daemon de múltiples rutas, in.mpathd

El daemon in.mpathd detecta los fallos de la interfaz y, a continuación, implementa varios procedimientos para la conmutación y recuperación tras error. Si in.mpathd detecta un fallo o una reparación, el daemon envía un comando ioctl para llevar a cabo la conmutación o recuperación tras error. El módulo de núcleo ip, que implementa ioctl, lleva a cabo la conmutación por error de acceso de red de modo transparente y automático.

No utilice las rutas alternativas si utiliza IPMP en el mismo conjunto de tarjetas de interfaz de red. Tampoco debe utilizar IPMP mientras utiliza las rutas alternativas. Puede utilizar las rutas alternativas e IPMP de forma simultánea en diferentes conjuntos de interfaces. Para obtener mas información sobre las rutas alternativas, consulte Sun Enterprise Server Alternate Pathing 2.3.1 User Guide.

El daemon in.mpathd detecta fallos y reparaciones enviando sondeos a todas las interfaces que forman parte de un grupo IPMP. El daemon in.mpathd también detecta fallos y reparaciones supervisando el indicador RUNNING en cada interfaz del grupo. Consulte la página del comando man in.mpathd(1M) para obtener más información.

No se admite DHCP para administrar direcciones de datos IPMP. Si intenta utilizar DHCP en estas direcciones, DHCP finalmente abandonará el control de dichas direcciones. No utilice DHCP en las direcciones de datos.

Terminología y conceptos de IPMP

En esta sección se introducen los términos y conceptos que se utilizan en los capítulos sobre IPMP de esta guía.

Vínculo IP

En terminología IPMP, un vínculo IP es una utilidad de comunicación o medio a través del cual los nodos se pueden comunicar en la capa del vínculo de datos del conjunto de protocolos de Internet. Los tipos de vínculos IP podrían incluir redes Ethernet simples, Ethernet con puente, concentradores o redes de modalidad de transferencia asíncrona (ATM). Un vínculo IP puede tener uno o más números de subred IPv4 y, si es preciso, uno o más prefijos de subred IPv6. No se puede asignar el mismo número o prefijo de subred a más de un vínculo IP. En ATM LANE, un vínculo IP es una sola red de área local (LAN) emulada. Con el protocolo de resolución de direcciones (ARP), el alcance del protocolo ARP es un único vínculo IP.

Otros documentos relacionados con IP, como RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, utilizan el término vínculo en lugar de vínculo IP. La parte VI utiliza el término vínculo IP para evitar la confusión con IEEE 802. En IEEE 802, vínculo hace referencia a una única conexión entre una tarjeta de interfaz de red Ethernet (NIC) y un conmutador Ethernet.

Interfaz física

La interfaz física proporciona una conexión del sistema con un vínculo IP. Esta conexión se suele implementar como un controlador de dispositivos y una NIC. Si un sistema tiene varias interfaces conectadas al mismo vínculo, puede configurar IPMP para que lleve a cabo la conmutación por error si falla una de las interfaces. Para obtener mas información sobre las interfaces físicas, consulte Configuraciones de interfaces IPMP.

Tarjeta de interfaz de red

Una tarjeta de interfaz de red es un adaptador de red que se puede integrar en el sistema. Una NIC también puede ser una tarjeta independiente que actúe como interfaz de un sistema a un vínculo IP. Algunas NIC pueden tener varias interfaces físicas. Por ejemplo, una NIC qfe puede tener cuatro interfaces, de qfe0 a qfe3, etc.

Grupo IPMP

Un grupo de múltiples rutas IP, o grupo IPMP, se compone de una o más interfaces físicas en el mismo sistema configuradas con el mismo nombre de grupo IPMP. Todas las interfaces del grupo IPMP deben estar conectadas al mismo vínculo IP. El mismo nombre de grupo IPMP de cadena de caracteres (no nula) identifica a todas las interfaces del grupo. Puede colocar interfaces de NIC de diferentes velocidades en el mismo grupo IPMP, siempre que las NIC sean del mismo tipo. Por ejemplo, en el mismo grupo puede configurar las interfaces de NIC Ethernet de 100 megabits y las interfaces de NIC Ethernet de 1 gigabit. A modo de ejemplo, supongamos que tiene dos tarjetas NIC Ethernet de 100 megabits. Puede configurar una de las interfaces con 10 megabits y seguir colocando las dos interfaces en el mismo grupo IPMP.

No es posible colocar dos interfaces de distintos tipos de medios en un grupo IPMP. Por ejemplo, no puede colocar una interfaz ATM en el mismo grupo que una interfaz Ethernet.

Detección de fallos y conmutación por error

La detección de fallos es el proceso de detectar si una interfaz o su ruta a un dispositivo de capa de Internet han dejado de funcionar. IPMP ofrece a los sistemas la posibilidad de detectar si una interfaz ha fallado. IPMP detecta los siguientes tipos de fallos de comunicación:

• La ruta de transmisión o recepción de la interfaz han fallado.

• La conexión de la interfaz al vínculo IP está inactiva.

• El puerto del conmutador no transmite ni recibe paquetes.

• La interfaz física de un grupo IPMP no está presente en el inicio del sistema.

Tras detectar un fallo, IPMP inicia la conmutación por error. La conmutación por error es el proceso automático de conmutar el acceso de red de una interfaz fallida a una interfaz física que funcione del mismo grupo. El acceso a red incluye unidifusión, multidifusión y tráfico de emisión IPv4, así como unidifusión, multidifusión y tráfico de emisión IPv6. La conmutación por error sólo se produce si se ha configurado más de una interfaz en el grupo IPMP. El proceso de conmutación por error garantiza un acceso ininterrumpido a la red.

Detección de reparaciones y recuperación tras los errores

La detección de reparaciones es el proceso de detectar si una tarjeta NIC o la ruta de una NIC a un dispositivo de capa de Internet empieza a funcionar correctamente tras un error. Tras detectar si una NIC se ha reparado, IPMP lleva a cabo la recuperación tras los errores, el proceso de restablecer el acceso a la red para la interfaz reparada. La detección de reparaciones da por sentado que se ha activado la función de recuperación tras los errores. Consulte Detección de reparaciones de interfaces físicas para obtener más información.

Sistemas de destino

La detección de errores basada en sondeos utiliza los sistemas de destino para determinar la condición de una interfaz. Cada sistema de destino debe estar conectado al mismo vínculo IP que los miembros del grupo IPMP. El daemon in.mpathd del sistema local envía mensajes de sondeo de ICMP a cada sistema de destino. Los mensajes de sondeo ayudan a determinar el estado de cada interfaz del grupo IPMP.

Para obtener más información sobre el uso del sistema de destino en la detección de fallos basada en sondeos, consulte Detección de fallos basada en sondeos.

Expansión de la carga saliente

Con IPMP configurado, los paquetes de red salientes se reparten en varias NIC sin que ello afecte al orden de los paquetes. Este proceso se conoce como expansión de carga. Como consecuencia de la expansión de carga, se obtiene un mayor rendimiento. La expansión de carga sólo se produce cuando el tráfico de red fluye hacia varios destinos que utilizan múltiples conexiones.

Reconfiguración dinámica

La reconfiguración dinámica (DR) es la capacidad de volver a configurar un sistema mientras se ejecuta, prácticamente con ningún impacto o con ninguno en absoluto en las operaciones en curso. No todas las plataformas de Sun admiten DR. Es posible que algunas plataformas de Sun sólo admitan DR de determinados tipos de hardware. En las plataformas que admiten DR de NIC, se puede utilizar IPMP para conmutar por error de modo transparente el acceso de red y proporcionar acceso de red ininterrumpido al sistema.

Para obtener más información sobre cómo IPMP admite DR, consulte IPMP y reconfiguración dinámica.

Requisitos básicos de IPMP

IPMP se integra en Oracle Solaris y no requiere hardware especial. Cualquier interfaz que admita Oracle Solaris se puede utilizar con IPMP. Sin embargo, IPMP impone los siguientes requisitos de topología y configuración de la red:

• Todas las interfaces de un grupo IPMP deben tener direcciones MAC únicas.

  De modo predeterminado, todas las interfaces de red de sistemas basados en SPARC comparten una única dirección MAC. De este modo, debe cambiar explícitamente la configuración predeterminada para poder utilizar IPMP en sistemas basados en SPARC. Para obtener más información, consulte Cómo planificar un grupo IPMP.

• Todas las interfaces de un grupo IPMP deben tener el mismo tipo de medio. Si desea más información, consulte Grupo IPMP.

• Todas las interfaces de un grupo IPMP deben estar conectadas al mismo vínculo IP. Si desea más información, consulte Grupo IPMP.

  ---

  Nota –

  No se admiten varios grupos IPMP en el mismo dominio de emisión de capa de vínculo (L2 o capa 2). Normalmente, un dominio de emisión L2 se asigna a una subred específica. Por lo tanto, debe configurar sólo un grupo IPMP por subred.

  ---

• En función de los requisitos de detección de fallos, es posible que deba utilizar tipos específicos de interfaces de red o configurar direcciones IP adicionales en cada interfaz de red. Consulte Detección de fallos basada en vínculos y Detección de fallos basada en sondeos.

Direcciones IPMP

Puede configurar la detección de fallos IPMP en redes IPv4 y de pila doble, y redes IPv4 e IPv6. Las interfaces que se configuran con IPMP admiten dos tipos de direcciones: direcciones de datos y direcciones de prueba.

Direcciones de datos

Las direcciones de datos son direcciones IPv4 e IPv6 convencionales que se asignan a una interfaz de NIC durante el inicio o manualmente mediante el comando ifconfig. El tráfico de paquetes IPv4 estándar y, si es aplicable, el tráfico de paquetes IPv6 mediante una interfaz se considera tráfico de datos.

Direcciones de prueba

Las direcciones de prueba son direcciones específicas IPMP que utiliza el daemon in.mpathd. Para que una interfaz utilice la detección de fallos basada en sondeos y la reparación, debe estar configurada como mínimo con una dirección de prueba.

Sólo es necesario configurar direcciones de prueba si se va a utilizar la detección de fallos basada en sondeos.

El daemon in.mpathd utiliza las direcciones de prueba para el intercambio de sondeos ICMP (denominado también tráfico de sondeos) con otros destinos del vínculo IP. El tráfico de sondeos ayuda a determinar el estado de la interfaz y su NIC, incluida la información sobre si una interfaz ha fallado. Los sondeos verifican que la ruta de envío y recepción de la interfaz esté funcionando correctamente.

Cada interfaz puede configurarse con una dirección de prueba IP. Para una interfaz de una red de doble pila, puede configurar una dirección de prueba IPv4, una dirección de prueba IPv6 o tanto la dirección de prueba IPv4 como la IPv6.

Tras el fallo de una interfaz, las direcciones de prueba permanecen en la interfaz fallida de modo que in.mpathd puede seguir enviando sondeos para comprobar las posteriores reparaciones. Debe configurar de modo específico las direcciones de prueba para que las aplicaciones no las utilicen por accidente. Para más información, consulte Cómo evitar que las aplicaciones utilicen direcciones de prueba.

Para más información sobre la detección de fallos basada en sondeos, consulte Detección de fallos basada en sondeos.

Direcciones de prueba IPv4

En general, puede utilizar cualquier dirección IPv4 de la subred como dirección de prueba. Las direcciones de prueba IPv4 no necesitan ser enrutables. Dado que las direcciones IPv4 son un recurso limitado para muchos sitios, puede utilizar direcciones privadas RFC 1918 no enrutables como direcciones de prueba. Observe que el daemon in.mpathd intercambia sólo sondeos ICMP con otros hosts que se encuentran en la misma subred que la dirección de prueba. Si utiliza las direcciones de prueba RFC 1918, debe configurar otros sistemas, preferiblemente enrutadores, en el vínculo IP con direcciones en la subred RFC 1918 pertinente. De este modo, el daemon in.mpathd podrá intercambiar correctamente los sondeos con los sistemas de destino.

Los ejemplos IPMP utilizan direcciones RFC 1918 de la red 192.168.0/24 como direcciones de prueba IPv4. Para obtener más información acerca de direcciones privadas de RFC 1918, consulte RFC 1918, Address Allocation for Private Internets.

Para configurar direcciones de prueba IPv4, consulte la tarea Cómo configurar un grupo IPMP con múltiples interfaces.

Direcciones de prueba IPv6

La única dirección de prueba IPv6 válida es la dirección local de vínculo de una interfaz física. No necesita una dirección IPv6 aparte para hacer la función de dirección de prueba IPMP. La dirección local de vínculo IPv6 se basa en la dirección de control de acceso de soportes (MAC) de la interfaz. Las direcciones locales de vínculo se configuran automáticamente cuando la interfaz se activa para IPv6 durante el inicio o cuando se configura manualmente mediante ifconfig.

Para identificar la dirección local de vínculo de una interfaz, ejecute el comando ifconfig interfaz de un nodo habilitado para IPv6. Compruebe el resultado de la dirección que comienza con el prefijo fe80, el prefijo local de vínculo. El indicador NOFAILOVER del siguiente resultado de ifconfig indica que la dirección local de vínculo fe80::a00:20ff:feb9:17fa/10 de la interfaz hme0 se utiliza como dirección de prueba.

hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:17fa/10 

Para obtener más información sobre las direcciones locales de vínculo, consulte Dirección unidifusión local de vínculo.

Cuando un grupo IPMP tiene conectadas direcciones tanto IPv4 como IPv6 en todas las interfaces del grupo, no es necesario configurar direcciones de IPv4 aparte. El daemon in.mpathd puede utilizar las direcciones locales de vínculo IPv6 como direcciones de prueba.

Para crear una dirección de prueba IPv6, consulte la tarea Cómo configurar un grupo IPMP con múltiples interfaces.

Cómo evitar que las aplicaciones utilicen direcciones de prueba

Una vez configurada una dirección de prueba, debe asegurarse de que las aplicaciones no la utilicen. De lo contrario, si falla la interfaz, no se podrá acceder a la aplicación porque las direcciones de prueba no se conmutarán por error durante la operación de conmutación por error. Para asegurarse de que la IP no elija las direcciones de prueba para las aplicaciones normales, marque las direcciones de prueba como deprecated.

IPv4 no utiliza una dirección descartada como dirección de origen para las comunicaciones, a menos que una aplicación se vincule explícitamente con la dirección. El daemon in.mpathd se vincula explícitamente con dicha dirección para enviar y recibir tráfico de sondeos.

Dado que las direcciones locales de vínculo IPv6 normalmente no están presentes en un servicio de nombres, las aplicaciones DNS y NIS no utilizan direcciones locales de vínculo para la comunicación. Por tanto, no debe marcar las direcciones locales de vínculo IPv6 como deprecated.

Las direcciones de prueba IPv4 no deben colocarse en las tablas de servicios de nombres DNS ni NIS. En IPv6, las direcciones locales de vínculo no se colocan normalmente en las tablas de servicios de nombres.

Configuraciones de interfaces IPMP

Una configuración IPMP se compone normalmente de dos o más interfaces físicas en el mismo sistema que están conectadas al mismo vínculo IP. Estas interfaces físicas pueden estar en la misma NIC o no estarlo. Las interfaces se configuran como miembros del mismo grupo IPMP. Si el sistema cuenta con interfaces adicionales en un segundo vínculo IP, debe configurar dichas interfaces como otro grupo IPMP.

Una única interfaz se puede configurar en su propio grupo IPMP. El grupo IPMP de interfaz única tiene el mismo comportamiento que un grupo IPMP con múltiples interfaces. No obstante, la recuperación tras los errores y la conmutación por error no pueden tener lugar para un grupo IPMP que sólo tenga una interfaz.

Asimismo, puede configurar redes VLAN en un grupo IPMP siguiendo los mismos pasos que se deben seguir para configurar un grupo a partir de interfaces IP. Para ver los procedimientos, consulte Configuración de grupos IPMP. Los mismos requisitos que se enumeran en Requisitos básicos de IPMP se aplican para configurar redes VLAN en un grupo IPMP.

La convención que se utiliza para denominar redes VLAN puede conducir a errores al configurar redes VLAN como grupo IPMP. Para obtener más detalles acerca de nombres de VLAN, consulte Etiquetas VLAN y puntos de conexión físicos de System Administration Guide: IP Services. Considere el ejemplo de cuatro redes VLAN bge1000, bge1001, bge2000 y bge2001. La implementación de IPMP precisa que estas VLAN se agrupen del siguiente modo: bge1000 y bge1001 pertenecen a un grupo de la misma VLAN 1, mientras bge2000 y bge2001 pertenecen a otro grupo de la misma VLAN 2. Debido a los nombres de VLAN, pueden darse con frecuencia errores como mezclar VLAN que pertenecen a varios vínculos en un grupo IPMP, por ejemplo, bge1000 y bge2000.

Interfaces de reserva en un grupo IPMP

La interfaz de reserva de un grupo IPMP no se utiliza para el tráfico de datos a menos que falle otra interfaz del grupo. Cuando se produce un fallo, las direcciones de datos de la interfaz fallida se migran a la interfaz de reserva. La interfaz de reserva recibe el mismo tratamiento que las demás interfaces activas hasta que se repara la interfaz fallida. Es posible que algunas conmutaciones por error no elijan una interfaz de reserva. En lugar de ello, estas conmutaciones por error podrían elegir una interfaz activa con menos direcciones de datos configurados como UP que la interfaz de reserva.

En una interfaz de reserva debe configurar únicamente las direcciones de prueba. IPMP no permite agregar una dirección de datos a una interfaz configurada con el comando ifconfig como standby. Cualquier intento de crear este tipo de configuración será fallido. De modo similar, si configura como standby una interfaz que ya cuenta con direcciones de datos, estas direcciones conmutarán por error automáticamente a otra interfaz del grupo IPMP. Debido a estas restricciones, debe utilizar el comando ifconfig para marcar cualquier dirección de prueba como deprecated y - failover antes de configurar la interfaz como standby. Para configurar interfaces de reserva, consulte Cómo configurar una interfaz de reserva para un grupo IPMP

Configuraciones comunes de interfaces IPMP

Como se menciona en Direcciones IPMP, las interfaces de un grupo IPMP controlan el tráfico de sondeos y de datos regulares, según la configuración de las interfaces. Las opciones IPMP del comando ifconfig se utilizan para establecer la configuración.

Una interfaz activa es una interfaz física que transmite tanto tráfico de datos como tráfico de sondeos. La interfaz se configura como "activa" llevando a cabo los procedimientos de Cómo configurar un grupo IPMP con múltiples interfaces o Cómo configurar un grupo IPMP de interfaz única.

A continuación se describen los dos tipos comunes de configuraciones IPMP:

Configuración activa-activa

Un grupo IPMP de dos interfaces en el que ambas interfaces están "activas", es decir, que pueden transmitir tanto tráfico de datos como tráfico de sondeos en cualquier momento

Configuración activa-reserva

Grupo IPMP de dos interfaces en el que una interfaz se configura como "reserva".

Comprobación del estado de una interfaz

Puede comprobar el estado de una interfaz escribiendo el comando ifconfig interfaz. Para obtener información general sobre los informes de estado ifconfig, consulte Cómo obtener información sobre una interfaz específica.

Por ejemplo, puede utilizar el comando ifconfig para obtener el estado de una interfaz de reserva. Cuando la interfaz de reserva no aloja ninguna dirección de datos, tiene el indicador de estado INACTIVE. Este observador se encuentra en las líneas de estado de la interfaz en el resultado de ifconfig.

Funciones de detección de fallos IPMP y recuperación

El daemon in.mpathd controla los siguientes tipos de detección de fallos:

• Detección de fallos basada en vínculos, si la admite el controlador de la NIC

• Detección de fallos basada en sondeos, cuando se configuran las direcciones de prueba

• Detección de interfaces que no estaban presentes durante el inicio

La página del comando man in.mpathd(1M) describe detalladamente el modo en que el daemon in.mpathd controla la detección de fallos de la interfaz.

Detección de fallos basada en vínculos

La detección de fallos basada en vínculos siempre está activada, cuando la interfaz admite este tipo de detección de fallos. En la versión actual de Oracle Solaris se admiten los siguientes controladores de red de Sun:

• hme

• eri

• ce

• ge

• bge

• qfe

• dmfe

• e1000g

• ixgb

• nge

• nxge

• rge

• xge

Para determinar si la interfaz de otro proveedor admite la detección de fallos basada en vínculos, consulte la documentación del fabricante.

Estos controladores de interfaces de red supervisan el estado del vínculo de la interfaz y notifican al subsistema de red si dicho estado cambia. Cuando se notifica un cambio, el subsistema de red establece o borra el indicador RUNNING para dicha interfaz, según sea preciso. Si el daemon detecta que el indicador RUNNING de la interfaz se ha borrado, el daemon rechaza inmediatamente la interfaz.

Detección de fallos basada en sondeos

El daemon in.mpathd lleva a cabo la detección de fallos basada en sondeos en cada interfaz del grupo IPMP que cuente con una dirección de prueba. La detección de fallos basada en sondeos implica enviar y recibir los mensajes de sondeo de ICMP que utilizan direcciones de prueba. Estos mensajes pasan por la interfaz y se dirigen a uno o más sistemas de destino del mismo vínculo IP. Para ver una introducción a las direcciones de prueba, consulte Direcciones de prueba. Si desea información sobre cómo configurar las direcciones de prueba, consulte Cómo configurar un grupo IPMP con múltiples interfaces.

El daemon in.mpathd determina qué sistemas de destino se sondean dinámicamente. Los enrutadores conectados al vínculo IP se seleccionan automáticamente como destinos para el sondeo. Si no hay enrutadores en el vínculo, in.mpathd envía sondeos a los hosts vecinos del vínculo. Un paquete multidifusión que se envía a la dirección multidifusión de todos los hosts, 224.0.0.1 en IPv4 y ff02::1 en IPv6, determina qué hosts se utilizarán como sistemas de destino. Los primeros hosts que responden a los paquetes echo se eligen como destinos para los sondeos. Si in.mpathd no encuentra enrutadores ni hosts que respondan a los paquetes echo ICMP, in.mpathd no puede detectar los fallos basados en sondeos.

Puede utilizar las rutas host para configurar explícitamente una lista de sistemas de destino para utilizar con el comando in.mpathd. Para obtener más información, consulte Configuración de sistemas de destino.

Para asegurarse de que cada interfaz del grupo IPMP funcione correctamente, in.mpathd sondea todos los destinos por separado mediante todas las interfaces del grupo IPMP. Si no hay ninguna respuesta a cinco sondeos consecutivos, in.mpathd considera que la interfaz ha fallado. La velocidad de sondeo depende del tiempo de detección de fallos (FDT). El valor predeterminado del tiempo de detección de fallos es de 10 segundos. Puede ajustar el tiempo de detección de fallos en el archivo /etc/default/mpathd. Para obtener instrucciones, consulte Cómo configurar el archivo /etc/default/mpathd.

Para un tiempo de detección de reparaciones de 10 segundos, la velocidad de sondeo es de aproximadamente un sondeo cada dos segundos. El tiempo mínimo de detección de reparaciones predeterminado es el doble del tiempo de detección de fallos, es decir, 20 segundos, ya que debe recibirse la respuesta de 10 sondeos consecutivos. Los tiempos de detección de fallos y reparaciones sólo se aplican a la detección de fallos basada en sondeos.

En un grupo IPMP compuesto por redes VLAN, la detección de fallos basada en vínculos se implementa por vínculos físicos y, por lo tanto, afecta a todas las redes VLAN del vínculo en cuestión. La detección de fallos basada en sondeos se realiza por vínculos VLAN. Por ejemplo, bge0/bge1 y bge1000/bge1001 se configuran en un mismo grupo. Si el cable para bge0 está desconectado, la detección de fallos basada en vínculos no indicará que bge0 y bge1000 hayan fallado de manera inmediata. Sin embargo, si no se puede alcanzar ningún destino de sondeo de bge0, sólo se indicará que ha fallado bge0, porque bge1000 tiene sus propios destinos de sondeo en su red VLAN.

Fallos de grupo

Un fallo de grupo tiene lugar cuando todas las interfaces de un grupo IPMP fallan al mismo tiempo. El daemon in.mpathd no lleva a cabo conmutaciones por error para un fallo de grupo. Asimismo, no se puede realizar ninguna conmutación por error si todos los sistemas de destino fallan de forma simultánea. En este caso, in.mpathd vacía todos los sistemas de destino actuales y descubre nuevos sistemas de destino.

Detección de reparaciones de interfaces físicas

Para que el daemon in.mpathd considere que se ha reparado una interfaz, el indicador RUNNING debe estar configurado para la interfaz. Si se utiliza la detección de fallos basada en sondeos, el daemon in.mpathd debe recibir respuestas a 10 paquetes de sondeos consecutivos de la interfaz antes de que ésta se considere como reparada. Cuando una interfaz se considera reparada, cualquier dirección que conmutaba por error a otra interfaz, se recuperará tras el error a la interfaz reparada. Si la interfaz estaba configurada como "activa" antes de que fallara, tras la reparación podrá seguir enviando y recibiendo tráfico.

Qué ocurre durante la conmutación por error de la interfaz

Los dos ejemplos siguientes muestran una configuración típica y cómo dicha configuración cambia automáticamente cuando falla una interfaz. Cuando falla la interfaz hme0, observe que todas las direcciones de datos pasan de hme0 a hme1.

Ejemplo 30–1 Configuración de la interfaz antes de un fallo

hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> 
     mtu 1500 index 2
     inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme0:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.21 netmask ffffff00 broadcast 192.168.85.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
8     inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.22 netmask ffffff00 broadcast 192.168.85.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:19fa/10
     groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:1bfc/10
     groupname test

Ejemplo 30–2 Configuración de la interfaz después de un fallo

hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4,
      NOFAILOVER,FAILED> mtu 0 index 2
      inet 0.0.0.0 netmask 0 
      groupname test
hme0:1: flags=19040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER,FAILED> mtu 1500 index 2 
      inet 192.168.85.21 netmask ffffff00 broadcast 10.0.0.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
      groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER> mtu 1500 
      index 2 inet 192.168.85.22 netmask ffffff00 broadcast 10.0.0.255
hme1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
      inet 192.168.85.19 netmask ffffff00 broadcast 192.168.18.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER,FAILED> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:19fa/10 
      groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:1bfc/10 
      groupname test

Puede ver que el indicador FAILED aparece en hme0 para indicar que la interfaz ha fallado. Observe también que se ha creado hme1:2. hme1:2 era originalmente hme0. La dirección 192.168.85.19 se convierte en accesible mediante hme1.

Los miembros multidifusión asociados con 192.168.85.19 pueden seguir recibiendo paquetes, pero ahora los reciben mediante hme1. Cuando se produce el fallo de la dirección 192.168.85.19 de hme0 a hme1, se crea la dirección ficticia 0.0.0.0 en hme0. La dirección ficticia se crea para que se pueda seguir accediendo a hme0. hme0:1 no puede existir sin hme0. La dirección de prueba se elimina cuando tiene lugar una recuperación tras los errores.

De modo similar, se produce la conmutación por error de la dirección IPv6 de hme0 a hme1. En IPv6, los miembros de multidifusión se asocian con índices de interfaz. Los miembros de multidifusión también se conmutan por error de hme0 a hme1. También se mueven todas las direcciones configuradas por in.ndpd. Esta acción no se muestra en los ejemplos.

El daemon in.mpathd sigue realizando el sondeo a través de la interfaz fallida hme0. Cuando el daemon recibe 10 respuestas consecutivas para un tiempo de detección de reparaciones predeterminado de 20 segundos, determina que la interfaz se ha reparado. Dado que el indicador RUNNING también se establece en hme0, el daemon invoca la recuperación tras los errores. Después de la recuperación tras los errores, se restablece la configuración original.

Para ver una descripción de todos los mensajes de error registrados en la consola durante los fallos y las reparaciones, consulte la página del comando man in.mpathd(1M).

IPMP y reconfiguración dinámica

La función de reconfiguración dinámica (DR) permite volver a configurar el hardware del sistema, como las interfaces, mientras el sistema está en ejecución. En esta sección se explica cómo DR interopera con IPMP.

En un sistema que admite la DR de NIC, IPMP se puede utilizar para mantener la conectividad y evitar la interrupción de las conexiones existentes. Puede conectar, desconectar o volver a conectar tarjetas NIC de forma segura en un sistema que admita DR y utilice IPMP. Esto es posible porque IPMP se integra en la estructura del Gestor de coordinación de reconfiguración (RCM). RCM administra la reconfiguración dinámica de los componentes del sistema.

Normalmente se utiliza el comando cfgadm para llevar a cabo las operaciones de DR. Sin embargo, algunas plataformas proporcionan otros métodos. Consulte la documentación de su plataforma para obtener más información. Encontrará información específica sobre DR en los siguientes recursos.

Conexión de NIC

Puede agregar interfaces a un grupo IPMP en cualquier momento utilizando el comando ifconfig, tal como se describe en Cómo configurar un grupo IPMP con múltiples interfaces. De este modo, cualquier interfaz de los componentes del sistema que conecte tras el inicio del sistema se podrá sondear y agregar a un grupo IPMP existente. Si es preciso, puede configurar las interfaces que acaba de agregar en su propio grupo IPMP.

Estas interfaces y las direcciones de datos que se configuran en ellas están inmediatamente disponibles para el grupo IPMP. Sin embargo, para que el sistema configure y utilice las interfaces automáticamente tras un reinicio, debe crear un archivo /etc/hostname.interfaz para cada interfaz nueva. Para obtener más información, consulte Cómo configurar una interfaz física tras la instalación del sistema.

Si ya existe un archivo /etc/hostname.interfaz cuando se conecta la interfaz, RCM configura automáticamente la interfaz de acuerdo con el contenido de este archivo. De este modo, la interfaz recibe la misma configuración que habría recibido tras el inicio del sistema.

Desconexión de NIC

Todas las solicitudes para desconectar los componentes del sistema que contengan NIC se comprueban antes para garantizar el mantenimiento de la conectividad. Por ejemplo, de modo predeterminado no puede desconectar una NIC que no se encuentre en un grupo IPMP. Tampoco puede desconectar una NIC que contenga las únicas interfaces en funcionamiento de un grupo IPMP. Sin embargo, si debe eliminar el componente del sistema, puede modificar este comportamiento con la opción -f de cfgadm, tal como se explica en la página del comando man cfgadm(1M).

Si las comprobaciones son correctas, las direcciones de datos asociadas con la NIC desconectada conmutarán por error a una NIC en funcionamiento del mismo grupo, como si la NIC que se desconecta hubiera fallado. Cuando se desconecta la NIC, todas las direcciones de prueba de las interfaces NIC se desconfiguran. A continuación, la NIC se desconecta del sistema. Si falla alguno de estos pasos, o falla la DR de otro hardware del mismo componente del sistema, se restablece el estado original de la configuración anterior. Recibirá un mensaje de estado sobre este evento. De lo contrario, la solicitud de desconexión se completará correctamente. Ya podrá eliminar el componente del sistema. Las conexiones existentes no se interrumpen.

Reconexión de NIC

RCM registra la información de configuración asociada con cualquier NIC que se desconecte de un sistema en ejecución. Como consecuencia, RCM trata la reconexión de una NIC que se ha desconectado previamente del mismo modo que lo haría con la conexión de una nueva NIC. Por tanto, RCM sólo realiza conexiones.

Sin embargo, las NIC reconectadas cuentan con un archivo /etc/hostname. interfaz. En ese caso, RCM configura automáticamente la interfaz de acuerdo con el contenido del archivo /etc/hostname. interfaz. Asimismo, RCM informa al daemon in.mpathd de cada dirección de datos que se alojó originalmente en la interfaz reconectada. Cuando la interfaz reconectada funciona correctamente, todas sus direcciones de datos se recuperan tras los errores en la interfaz reconectada como si se hubiera reparado.

Si la NIC que se reconecta no tiene ningún archivo /etc/hostname. interfaz, no hay ninguna información de configuración disponible. RCM no tiene información sobre cómo configurar la interfaz. Una consecuencia de esta situación es que las direcciones que se habían conmutado por error a otra interfaz no se recuperarán tras los errores.

NIC que no estaban presentes durante el inicio del sistema

Las tarjetas NIC que no están presentes durante el inicio del sistema representan un caso especial de detección de fallos. Durante el inicio, las secuencias de inicio supervisan las interfaces con archivos /etc/hostname.interfaz que no se pueden sondear. Todas las direcciones de datos que haya en dicho archivo /etc/hostname. interfaz se alojan de manera automática en otra interfaz del grupo IPMP.

En tal caso, recibirá mensajes de error similares a los siguientes:

moving addresses from failed IPv4 interfaces: hme0 (moved to hme1)
moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)

Si no existe ninguna dirección alternativa, recibirá mensajes de error similares a los siguientes:

moving addresses from failed IPv4 interfaces: hme0 (couldn't move; 
   no alternative interface) 
 moving addresses from failed IPv6 interfaces: hme0 (couldn't move; 
   no alternative interface) 

En este caso de detección de fallos, sólo se mueven a una interfaz alternativa las direcciones de datos que se especifican en el archivo /etc/hostname. interfaz de la interfaz que falta. Cualquier dirección que se obtenga por otros medios, como RARP o DHCP, no se obtendrá ni se moverá.

Si se reconecta con DR una interfaz con el mismo nombre que otra interfaz que no estaba presente durante el inicio del sistema, RCM sondea la interfaz automáticamente. A continuación, RCM configura la interfaz de acuerdo con el contenido del archivo /etc/hostname.interfaz de la interfaz. Finalmente, RCM recupera tras los errores las direcciones de datos, como si la interfaz se hubiera reparado. Por tanto, la configuración de red final es idéntica a la configuración que se habría realizado si el sistema se hubiera iniciado con la interfaz presente.