test

Guía de administración del sistema: servicios IP

Parte VI IPMP

Esta parte introduce las múltiples rutas de redes IP (IPMP) y contiene las tareas necesarias para administrar IPMP. IPMP proporciona funciones de detección de fallos y conmutación por error para las interfaces de un sistema que están conectadas al mismo vínculo.

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:

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:

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.

Nota –

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.

Nota –

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.

Nota –

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:

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:

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.

Nota –

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.

Precaución – Precaución –

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:

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:

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.

Nota –

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.

Tabla 30–1 Recursos de documentación para la reconfiguración dinámica

Descripción 

Para obtener información 

Información detallada sobre el comando cfgadm

Página del comando man cfgadm(1M)

Información específica sobre DR en el entorno de Sun Cluster 

Sun Cluster 3.1 System Administration Guide

Información específica sobre DR en el entorno de Sun Fire 

Sun Fire 880 Dynamic Reconfiguration Guide

Información introductoria sobre DR y el comando cfgadm

Capítulo 6, Dynamically Configuring Devices (Tasks) de System Administration Guide: Devices and File Systems

Tareas para administrar grupos IPMP en un sistema que admite DR 

Sustitución de una interfaz física fallida en sistemas que admiten reconfiguración dinámica

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)
Nota –

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.

Capítulo 31 Administración de IPMP (tareas)

En este capitulo se describen las tareas para administrar grupos de interfaces con múltiples rutas de redes IP (IPMP). Se abordan los siguientes temas principales:

Para obtener una descripción general de los conceptos de IPMP, consulte el Capítulo 30Introducción a IPMP (descripción general).

Configuración de IPMP (mapas de tareas)

Esta sección contiene los vínculos a las tareas que se describen en este capítulo.

Configuración y administración de grupos IPMP (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Planificar un grupo IPMP. 

Enumera toda la información auxiliar y las tareas necesarias para poder configurar un grupo IPMP. 

Cómo planificar un grupo IPMP

Configurar un grupo de interfaces IPMP con múltiples interfaces. 

Configura varias interfaces como miembros de un grupo IPMP. 

Cómo configurar un grupo IPMP con múltiples interfaces

Configurar un grupo IPMP en el que una de las interfaces es una interfaz de reserva. 

Configura una de las interfaces de un grupo de interfaces IPMP como interfaz de reserva. 

Cómo configurar una interfaz de reserva para un grupo IPMP

Configurar un grupo IPMP compuesto por una única interfaz. 

Crea un único grupo de interfaces IPMP.  

Cómo configurar un grupo IPMP de interfaz única

Mostrar el grupo IPMP al que pertenece una interfaz física. 

Explica cómo obtener el nombre de un grupo IPMP de la interfaz a partir del resultado del comando ifconfig.

Cómo mostrar la pertenencia de una interfaz a un grupo IPMP

Agregar una interfaz a un grupo IPMP. 

Configura una nueva interfaz como miembro de un grupo IPMP existente. 

Cómo agregar una interfaz a un grupo IPMP

Eliminar una interfaz de un grupo IPMP. 

Explica cómo eliminar una interfaz de un grupo IPMP. 

Cómo eliminar una interfaz de un grupo IPMP

Mover una interfaz de un grupo IPMP existente a otro grupo distinto. 

Mueve las interfaces entre los grupos IPMP. 

Cómo mover una interfaz de un grupo IPMP a otro grupo

Cambiar tres parámetros predeterminados para el daemon in.mpathd.

Personaliza el tiempo de detección de fallos y otros parámetros del daemon in.mpathd.

Cómo configurar el archivo /etc/default/mpathd

Administración de IPMP en interfaces que admiten reconfiguración dinámica (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Eliminar una interfaz que ha fallado. 

Elimina una interfaz fallida de un sistema. 

Cómo eliminar una interfaz física que ha fallado (desconexión en DR)

Reemplazar una interfaz que ha fallado. 

Reemplaza una interfaz fallida. 

Como sustituir una interfaz física que ha fallado (conexión en DR)

Recuperar una interfaz que no se ha configurado durante el inicio. 

Recupera una interfaz fallida. 

Cómo recuperar una interfaz física que no está presente al iniciar el sistema

Configuración de grupos IPMP

Esta sección describe los procedimientos para configurar los grupos IPMP. También explica cómo configurar una interfaz como interfaz de reserva.

Planificación de un grupo IPMP

Antes de configurar las interfaces de un sistema como parte de un grupo IPMP, debe realizar una planificación previa.

ProcedureCómo planificar un grupo IPMP

El procedimiento siguiente incluye las tareas de planificación de la información que se debe obtener antes de configurar el grupo IPMP. No es necesario realizar las tareas por orden.

  1. Decida qué interfaces del sistema formarán parte del grupo IPMP.

    Un grupo IPMP se compone normalmente de, como mínimo, dos interfaces físicas conectadas al mismo vinculo IP. No obstante, si lo desea, puede configurar un grupo IPMP de interfaz única. Para ver una introducción a los grupos IPMP, consulte Configuraciones de interfaces IPMP. Por ejemplo, puede configurar el mismo conmutador Ethernet o la misma subred IP en el mismo grupo IPMP. Puede configurar la cantidad de interfaces que desee en el mismo grupo IPMP.

    No puede utilizar el parámetro group del comando ifconfig con interfaces lógicas. Por ejemplo, puede utilizar el parámetro group con hme0, pero no con hme0:1 .

  2. Compruebe que cada interfaz del grupo tenga una dirección MAC exclusiva.

    Para ver instrucciones, consulte SPARC: Cómo asegurarse de que la dirección MAC de una interfaz sea única.

  3. Elija un nombre para el grupo IPMP.

    Cualquier nombre que no sea nulo será válido. También puede utilizar un nombre que identifique el vínculo IP al que están vinculadas las interfaces.

  4. Asegúrese de que se inserte y configure el mismo conjunto de módulos STREAMS en todas las interfaces del grupo IPMP.

    Todas las interfaces del mismo grupo deben tener configurados los mismos módulos STREAMS y en el mismo orden.

    1. Compruebe el orden de los módulos STREAMS en todas las interfaces del grupo IPMP eventual.

      Puede imprimir una lista de los módulos STREAMS utilizando el comando ifconfig interfaz modlist. Por ejemplo, éste es el resultado de ifconfig para una interfaz hme0:


      # ifconfig hme0 modlist
	0 arp
	1 ip
	2 hme

      Las interfaces existen normalmente como controladores de red justo debajo del módulo IP, tal como se muestra en el resultado de ifconfig hme0 modlist. No requieren ninguna configuración adicional.

      Sin embargo, determinadas tecnologías, como NCA o el Filtro IP, se insertan como módulos STREAMS entre el módulo IP y el controlador de red. Es posible que se originen problemas en el comportamiento de las interfaces del mismo grupo IPMP.

      Si un módulo STREAMS tiene estado, puede producirse un comportamiento inesperado en la conmutación por error, aunque se inserte el mismo módulo en todas las interfaces de un grupo. Sin embargo, puede utilizar módulos STREAMS sin estado, siempre y cuando los inserte en el mismo orden en todas las interfaces del grupo IPMP.

    2. Inserte los módulos de una interfaz en el orden estándar para el grupo IPMP.


      ifconfig interface modinsert module-name


      ifconfig hme0 modinsert ip

  5. Utilice el mismo formato de direcciones IP en todas las interfaces del grupo IPMP.

    Si una interfaz está configurada para IPv4, todas las interfaces del grupo deben estar configuradas para IPv4. Supongamos que tiene un grupo IPMP compuesto por interfaces de varias NIC. Si añade direcciones IPv6 a las interfaces de una tarjeta NIC, todas las interfaces del grupo IPMP se deben configurar para que admitan IPv6.

  6. Compruebe que todas las interfaces del grupo IPMP estén conectadas al mismo vínculo IP.

  7. Compruebe que el grupo IPMP no contenga interfaces con diferentes tipos de medios de red.

    Las interfaces que están agrupadas deben tener el mismo tipo de interfaz, de acuerdo con lo que se define en /usr/include/net/if_types.h. Por ejemplo, no puede combinar interfaces Ethernet y Token Ring en un grupo IPMP. Tampoco puede combinar una interfaz de bus Token con las interfaces de modalidad de transferencia asíncrona (ATM) del mismo grupo IPMP.

  8. En el caso de IPMP con interfaces ATM, configure dichas interfaces en modo de emulación de LAN.

    IPMP no se admite para las interfaces que utilicen IP clásica sobre ATM.

Configuración de grupos IPMP

Esta sección contiene las tareas de configuración para un grupo IPMP típico con un mínimo de dos interfaces físicas.

ProcedureCómo configurar un grupo IPMP con múltiples interfaces

Los siguientes pasos para configurar un grupo IPMP también se aplican al configurar redes VLAN en un grupo IPMP.

Antes de empezar

Es preciso que ya haya configurado las direcciones IPv4, y, si es necesario, las direcciones IPv6 de todas las interfaces del grupo IPMP eventual.

Precaución – Precaución –

Debe configurar sólo un grupo IPMP para cada subred o dominio de emisión L2. Para obtener más información, consulte Requisitos básicos de IPMP

  1. En el sistema cuyas interfaces se deben configurar, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Coloque cada interfaz física en un grupo IPMP.


    # ifconfig interface group group-name

    Por ejemplo, para colocar hme0 y hme1 en el grupo testgroup1, debe escribir los siguientes comandos:


    # ifconfig hme0 group testgroup1
# ifconfig hme1 group testgroup1

    Evite utilizar espacios en los nombres de grupo. La pantalla de estado de ifconfig no muestra espacios. Por tanto, no cree dos nombres de grupo similares que sólo se diferencien en un espacio. Si uno de los nombres de grupo contiene un espacio, aparecerán iguales en la pantalla de estado.

    En un entorno de doble pila, si se coloca una instancia IPv4 de una interfaz en un grupo específico, automáticamente se coloca la instancia IPv6 en el mismo grupo.

  3. (Opcional) Configure una dirección de prueba IPv4 en una o más interfaces físicas.

    Sólo debe configurar una dirección de prueba si desea utilizar la detección de fallos basada en sondeos en una interfaz específica. Las direcciones de prueba se configuran como interfaces lógicas de la interfaz física que especifica para el comando ifconfig.

    Si una interfaz del grupo va a convertirse en la interfaz de reserva, no configure ninguna dirección de prueba para la interfaz en este momento. Configure una dirección de prueba para la interfaz de reserva como parte de la tarea Cómo configurar una interfaz de reserva para un grupo IPMP.

    Utilice la siguiente sintaxis del comando ifconfig para configurar una dirección de prueba:


    # ifconfig interface addif ip-address parameters -failover deprecated up

    Por ejemplo, para la interfaz de red principal hme0 debe crear la siguiente dirección de prueba:


    # ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up

    Este comando configura los siguientes parámetros para la interfaz de red principal hme0:

    • La dirección se establece en 192.168.85.21.

    • La dirección de emisión y la máscara de red se configuran con el valor predeterminado.

    • Se establecen las opciones -failover y deprecated.

      Nota –

      Debe marcar una dirección de prueba IPv4 como deprecated para evitar que las aplicaciones utilicen la dirección de prueba.

  4. Compruebe la configuración de IPv4 para una interfaz específica.

    Puede ver el estado de una interfaz en cualquier momento escribiendo ifconfig interfaz. Para obtener mas información sobre cómo ver el estado de una interfaz, consulte Cómo obtener información sobre una interfaz específica.

    Puede obtener información sobre la configuración de la dirección de prueba para una interfaz física especificando la interfaz lógica que está asignada a la dirección de prueba.


    # ifconfig hme0:1
	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

  5. (Opcional) Si procede, configure una dirección de prueba IPv6. 


    # ifconfig interface inet6 -failover

    Las interfaces físicas con direcciones IPv6 se colocan en el mismo grupo IPMP que las direcciones IPv4 de las interfaces. Esto sucede al configurar la interfaz física con direcciones IPv4 en un grupo IPMP. Si coloca primero las interfaces físicas con direcciones IPv6 en un grupo IPMP, las interfaces físicas con direcciones IPv4 también se colocan implícitamente en el mismo grupo IPMP.

    Por ejemplo, para configurar hme0 con una dirección de prueba IPv6, debe escribir lo siguiente:


    # ifconfig hme0 inet6 -failover

    No es necesario marcar una dirección de prueba IPv6 como descartada para impedir que las aplicaciones utilicen la dirección de prueba.

  6. Compruebe la configuración de IPv6.


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

    La dirección de prueba IPv6 es la dirección local de vínculo de la interfaz.

  7. (Opcional) Conserve la configuración del grupo IPMP tras los reinicios.

    • Para IPv4, agregue la línea siguiente al archivo /etc/hostname. interfaz:


      interface-address <parameters> group group-name up \
	addif logical-interface -failover deprecated <parameters> up

      En esta instancia, la dirección IPv4 de prueba se configura sólo después de reiniciar. Si desea invocar la configuración en la sesión actual, lleve a cabo los pasos 1, 2, y, opcionalmente, 3.

    • Para IPv6, agregue la línea siguiente al archivo /etc/hostname6. interfaz:


      -failover group group-name up

      Esta dirección IPv6 de prueba se configura sólo después del reinicio. Si desea invocar la configuración en la sesión actual, lleve a cabo los pasos 1, 2, y, opcionalmente, 5.

  8. (Opcional) Agregue más interfaces al grupo IPMP repitiendo los pasos del 1 al 6.

    Puede agregar nuevas interfaces a un grupo existente en un sistema en funcionamiento. No obstante, los cambios se perderán al reiniciar.

Ejemplo 31–1 Configuración de un grupo IPMP con dos interfaces

Supongamos que desea hacer lo siguiente:

Debe escribir el comando siguiente:


# ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up

Debe marcar una dirección de prueba IPv4 como deprecated para evitar que las aplicaciones utilicen la dirección de prueba. Consulte Cómo configurar un grupo IPMP con múltiples interfaces.

Para activar el atributo de conmutación por error de la dirección, debe utilizar la opción failover sin el guión.

Todas las direcciones IP de prueba de un grupo IPMP deben utilizar el mismo prefijo de red. Las direcciones IP de prueba deben pertenecer a una única subred IP.

Ejemplo 31–2 Conservación de la configuración de un grupo IPMP IPv4 tras el reinicio

Supongamos que desea crear un grupo IPMP denominado testgroup1 con la siguiente configuración:

Debe agregar la siguiente línea al archivo /etc/hostname.hme0:


192.168.85.19 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.21 deprecated -failover netmask + broadcast + up

De modo similar, para colocar la segunda interfaz hme1 bajo el mismo grupo testgroup1 y configurar una dirección de prueba, debe agregar la línea siguiente:


192.168.85.20 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.22 deprecated -failover netmask + broadcast + up
Ejemplo 31–3 Conservación de la configuración de un grupo IPMP IPv6 tras el reinicio

Para crear un grupo de prueba para la interfaz hme0 con una dirección IPv6, debe agregar la línea siguiente al archivo /etc/hostname6.hme0:


-failover group testgroup1 up

De modo similar, para colocar la segunda interfaz hme1 en el grupo testgroup1 y configurar una dirección de prueba, debe agregar la línea siguiente al archivo /etc/hostname6.hme1:


-failover group testgroup1 up
Errores más frecuentes

Durante la configuración del grupo IPMP, in.mpathd genera una serie de mensajes para la consola del sistema o el archivo syslog. Estos mensajes son informativos e indican que la configuración de IPMP funciona correctamente.

Véase también

Si desea que el grupo IPMP tenga una configuración de reserva activa, vaya a Cómo configurar una interfaz de reserva para un grupo IPMP.

Configuración de sistemas de destino

La detección de fallos basada en sondeos implica el uso de sistemas de destino, tal como se explica en Detección de fallos basada en sondeos. Para algunos grupos IPMP, los destinos predeterminados que utiliza in.mpathd son suficientes. Sin embargo, para algunos grupos IPMP, quizá desee configurar destinos específicos para la detección de fallos basada en sondeos. La detección de fallos basada en sondeos se lleva a cabo configurando las rutas host en la tabla de enrutamiento como destinos de sondeo. Cualquier ruta host configurada en la tabla de enrutamiento aparece enumerada antes del enrutador predeterminado. Por tanto, IPMP utiliza rutas host definidas explícitamente para la selección de destino. Puede utilizar cualquiera de estos dos métodos para especificar destinos directamente: configurar manualmente las rutas host o crear una secuencia shell que se pueda convertir en una secuencia de inicio.

Considere los siguientes criterios cuando evalúe qué hosts de su red podrían constituir destinos correctos.

ProcedureCómo especificar manualmente los sistemas de destino para la detección de fallos basada en sondeos

  1. Inicie sesión con su cuenta de usuario en el sistema en el que va a configurar la detección de fallos basada en sondeos.

  2. Agregue una ruta a un host particular para utilizar como destino en la detección de fallos basada en sondeos.


    $ route add -host destination-IP gateway-IP -static

    Sustituya los valores de IP_destino e IP_portal por la dirección IPv4 del host que se utilizará como destino. Por ejemplo, escriba lo siguiente para especificar el sistema de destino 192.168.85.137, que se encuentra en la misma subred que las interfaces del grupo IPMP testgroup1.


    $ route add -host 192.168.85.137 192.168.85.137 -static

  3. Agregue rutas a los host adicionales de la red para utilizar como sistemas de destino.

ProcedureCómo especificar sistemas de destino en una secuencia de shell

  1. En el sistema en el que ha configurado un grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Cree una secuencia de shell que configure rutas estáticas para los destinos propuestos.

    Por ejemplo, puede crear una secuencia de shell denominada ipmp.targets con el siguiente contenido:


    TARGETS="192.168.85.117 192.168.85.127 192.168.85.137"

case "$1" in
        'start')
            /usr/bin/echo "Adding static routes for use as IPMP targets"
		for target in $TARGETS; do
	  /usr/sbin/route add -host $target $target
		done
                  ;;
        'stop')
              /usr/bin/echo "Removing static routes for use as IPMP targets"
		 for target in $TARGETS; do
		/usr/sbin/route delete -host $target $target
		 done
                  ;;
  esac

  3. Copie la secuencia de shell en el directorio de la secuencia de inicio. 


     # cp ipmp.targets /etc/init.d

  4. Cambie los permisos de la nueva secuencia de inicio. 


    # chmod 744 /etc/init.d/ipmp.targets

  5. Cambie la propiedad de la nueva secuencia de inicio. 


    # chown root:sys /etc/init.d/ipmp.targets

  6. Cree un vínculo para la secuencia de inicio en el directorio /etc/init.d.


    # ln /etc/init.d/ipmp.targets /etc/rc2.d/S70ipmp.targets

    El prefijo S70 del nombre de archivo S70ipmp.targets ordena la nueva secuencia correctamente con respecto a las demás secuencias de inicio.

Configuración de interfaces de reserva

Siga este procedimiento para que el grupo IPMP tenga una configuración de reserva activa. Para obtener más información sobre este tipo de configuración, consulte Configuraciones de interfaces IPMP.

ProcedureCómo configurar una interfaz de reserva para un grupo IPMP

Antes de empezar

Para obtener información sobre cómo configurar un grupo IPMP y asignar direcciones de prueba, consulte Cómo configurar un grupo IPMP con múltiples interfaces.

  1. En el sistema cuyas interfaces de reserva se deben configurar, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Configure una interfaz como reserva y asigne la dirección de prueba.


    # ifconfig interface plumb \
ip-address other-parameters deprecated -failover standby up

    Una interfaz de reserva sólo puede tener una dirección IP (la dirección de prueba). Debe configurar la opción -failover antes de configurar la opción standby up. Para <other-parameters>, utilice los parámetros que requiera su configuración, según lo descrito en la página del comando man ifconfig(1M).

    • Por ejemplo, para crear una dirección de prueba IPv4, debe escribir el siguiente comando:


      # ifconfig hme1 plumb 192.168.85.22 netmask + broadcast + deprecated -failover standby up
      hme1

      Define hme1 como interfaz típica para configurar como interfaz de reserva.

      192.168.85.22

      Asigna esta dirección de prueba a la interfaz de reserva.

      deprecated

      Indica que la dirección de prueba no se utiliza para los paquetes salientes.

      -failover

      Indica que la dirección de prueba no conmuta por error si falla la interfaz.

      standby

      Marca la interfaz como interfaz de reserva.

    • Por ejemplo, para crear una dirección de prueba IPv6, debe escribir el siguiente comando:


      # ifconfig hme1 plumb -failover standby up

  3. Compruebe los resultados de la configuración de la interfaz de reserva.


    # ifconfig hme1
hme1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,
      STANDBY,INACTIVE mtu 1500 
         index 4 inet 192.168.85.22 netmask ffffff00 broadcast 19.16.85.255
         groupname test

    El indicador INACTIVE significa que esta interfaz no se utiliza para ningún paquete saliente. Cuando se produce una conmutación por error en esta interfaz de reserva, se borra el indicador INACTIVE.

    Nota –

    Puede ver el estado de una interfaz en cualquier momento escribiendo el comando ifconfig interfaz. Para más información sobre cómo ver el estado de la interfaz, consulte Cómo obtener información sobre una interfaz específica .

  4. (Opcional) Mantenga la interfaz de reserva IPv4 después de reiniciar.

    Asigne la interfaz de reserva al mismo grupo IPMP, y configure una dirección de prueba para la interfaz de reserva.

    Por ejemplo, para configurar hme1 como interfaz de reserva, debe agregar la siguiente línea al archivo /etc/hostname.hme1:


    192.168.85.22 netmask + broadcast + deprecated group test -failover standby up

  5. (Opcional) Conserve la interfaz de reserva IPv6 tras los reinicios.

    Asigne la interfaz de reserva al mismo grupo IPMP, y configure una dirección de prueba para la interfaz de reserva.

    Por ejemplo, para configurar hme1 como interfaz de reserva, agregue la línea siguiente al archivo /etc/hostname6.hme1:


    -failover group test standby up
Ejemplo 31–4 Configuración de una interfaz de reserva para un grupo IPMP

Supongamos que desea crear una dirección de prueba con la siguiente configuración:

Debe escribir lo siguiente:


# ifconfig hme2 plumb 192.168.85.22 netmask + broadcast + \
deprecated -failover standby up

La interfaz se marca como interfaz de reserva sólo después de que la dirección se marque como dirección NOFAILOVER.

Debe eliminar el estado de reserva de una interfaz escribiendo lo siguiente:


# ifconfig interface -standby

Configuración de grupos IPMP con una única interfaz física

Cuando sólo tiene una interfaz en un grupo IPMP, no es posible conmutar tras un fallo. Sin embargo, puede activar la función de detección de fallos en dicha interfaz asignándola a un grupo IPMP. No es necesario que configure una dirección IP de prueba dedicada para establecer la detección de fallos para un grupo IPMP de interfaz única. Puede utilizar una sola dirección IP para enviar datos y detectar los fallos.

ProcedureCómo configurar un grupo IPMP de interfaz única

  1. En el sistema con el eventual grupo IPMP de interfaz única, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Para IPv4, cree el grupo IPMP de interfaz única.

    Utilice la siguiente sintaxis para asignar la interfaz única a un grupo IPMP.


    # ifconfig interface group group-name

    El ejemplo siguiente asigna la interfaz hme0 al grupo IPMP v4test:


    # ifconfig hme0 group v4test

    Tras realizar este paso, IPMP permite la detección de fallos basada en vínculos en la interfaz.

    Además, puede utilizar el subcomando -failover del comando ifconfig para habilitar la detección de fallos basada en sonda. En el ejemplo siguiente se muestra la detección de fallos basada en sonda de hme0 mediante la dirección IP asignada actualmente a hme0:


    # ifconfig hme0 -failover

    A diferencia de los grupos de interfaz múltiple, la misma dirección IP puede ser de datos y de prueba. Para que las aplicaciones puedan utilizar la dirección de prueba como dirección de datos, las direcciones de prueba nunca se deben marcar como deprecated en los grupos IPMP de interfaz única.

  3. Para IPv6, cree el grupo IPMP de interfaz única.

    Utilice la siguiente sintaxis para asignar la interfaz única a un grupo IPMP:


    # ifconfig interface inet6 group group-name

    Por ejemplo, para agregar la interfaz única hme0 en el grupo IPMP v6test, escriba lo siguiente:


    # ifconfig hme0 inet6 group v6test

    Tras realizar este paso, IPMP permite la detección de fallos basada en vínculos en la interfaz.

    Además, puede utilizar el subcomando -failover del comando ifconfig para habilitar la detección de fallos basada en sonda. En el ejemplo siguiente se muestra la detección de fallos basada en sonda de hme0 mediante la dirección IP asignada actualmente a hme0:


    # ifconfig hme0 inet6 -failover

    A diferencia de los grupos de interfaz múltiple, la misma dirección IP puede ser de datos y de prueba. Para que las aplicaciones puedan utilizar la dirección de prueba como dirección de datos, las direcciones de prueba nunca se deben marcar como deprecated en los grupos IPMP de interfaz única.

    En una configuración de interfaz física única, no puede comprobar si ha fallado el sistema de destino que se está sondeando o la interfaz. El sistema de destino se puede sondear mediante una única interfaz física. Si sólo hay un enrutador predeterminado en la subred, desactive IPMP si hay una única interfaz física en el grupo. Si existe un enrutador distinto para IPv4 e IPv6, o hay varios enrutadores predeterminados, debe sondearse más de un sistema de destino. De este modo, podrá activar IPMP de un modo seguro.

Mantenimiento de grupos IPMP

Esta sección contiene las tareas para mantener los grupos IPMP existentes y las interfaces que los componen. Las tareas presuponen que ya se ha configurado un grupo IPMP, tal como se explica en Configuración de grupos IPMP.

ProcedureCómo mostrar la pertenencia de una interfaz a un grupo IPMP

  1. En el sistema con la configuración de grupo IPMP, conviértase en superusuario o asuma un rol equivalente.

    Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice la información sobre la interfaz, incluido el grupo al que pertenece la interfaz.


    # ifconfig interface

  3. Si es preciso, visualice la información de IPv6 para la interfaz.


    # ifconfig interface inet6
Ejemplo 31–5 Visualización de grupos de interfaces físicas

Para mostrar el nombre de grupo para hme0, debe escribir lo siguiente:


# ifconfig hme0
	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 testgroup1

Para mostrar el nombre de grupo sólo para la información de IPv6, debe escribir:


# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:19fa/10 
        	groupname testgroup1

ProcedureCómo agregar una interfaz a un grupo IPMP

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Agregue la interfaz al grupo IPMP.


    # ifconfig interface group group-name

    La interfaz especificada en interfaz se convierte en miembro del grupo IPMP nombre_grupo.

Ejemplo 31–6 Adición de una interfaz a un grupo IPMP

Para agregar hme0 al grupo IPMP testgroup2, escriba el comando siguiente:


# ifconfig hme0 group testgroup2
  hme0: flags=9000843<UP ,BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER> mtu 1500 index 2
  inet 192.168.85.19 netmask ff000000 broadcast 10.255.255.255
  groupname testgroup2
  ether 8:0:20:c1:8b:c3

ProcedureCómo eliminar una interfaz de un grupo IPMP

Al ejecutar el parámetro group del comando ifconfig con una cadena nula, la interfaz se elimina de su grupo IPMP actual. Tenga cuidado al eliminar interfaces de un grupo. Si ha fallado otra interfaz del grupo IPMP, es posible que se haya producido una conmutación por error anteriormente. Por ejemplo, si hme0 ha fallado previamente, todas las direcciones serán fallidas para hme1, si hme1 forma parte del mismo grupo. La eliminación de hme1 del grupo hace que el daemon in.mpathd devuelva todas las direcciones de conmutación por error a otra interfaz del grupo. Si no hay otras interfaces en funcionamiento en el grupo, es posible que la conmutación por error no restaure todos los accesos de la red.

De un modo similar, cuando se debe desconectar una interfaz de un grupo, primero es preciso eliminar la interfaz del grupo. A continuación, asegúrese de que la interfaz tiene configuradas todas las direcciones IP originales. El daemon in.mpathd trata de restaurar la configuración original de una interfaz que se elimina del grupo. Debe asegurarse de que se restaure la configuración antes de desconectar la interfaz. Consulte Qué ocurre durante la conmutación por error de la interfaz para ver el aspecto de las interfaces antes y después de una conmutación por error.

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Elimine la interfaz del grupo IPMP.


    # ifconfig interface group ""

    Las comillas indican una cadena nula.

Ejemplo 31–7 Eliminación de una interfaz de un grupo

Para eliminar hme0 del grupo IPMP test, escriba el comando siguiente:


# ifconfig hme0 group ""
	# ifconfig hme0
	hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
    index 2 inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
	# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
    inet6 fe80::a00:20ff:feb9:19fa/10

ProcedureCómo mover una interfaz de un grupo IPMP a otro grupo

Puede colocar una interfaz en un nuevo grupo IPMP cuando la interfaz pertenece a un grupo IPMP existente. No es necesario eliminar la interfaz del grupo IPMP actual. Cuando coloca la interfaz en un nuevo grupo, se elimina automáticamente de cualquier grupo IPMP existente.

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Mueva la interfaz a un nuevo grupo IPMP.


    # ifconfig interface group group-name

    Al colocar la interfaz en un nuevo grupo se elimina automáticamente la interfaz de cualquier grupo existente.

Ejemplo 31–8 Cómo mover una interfaz a otro grupo IPMP

Para cambiar el grupo IPMP de la interfaz hme0, escriba: 


# ifconfig hme0 group cs-link

Con este comando se elimina la interfaz hme0 del grupo IPMP test y se coloca en el grupo cs-link.

Sustitución de una interfaz física fallida en sistemas que admiten reconfiguración dinámica

Esta sección contiene los procedimientos relativos a la administración de sistemas que admiten reconfiguración dinámica (DR).

Nota –

Las tareas sólo se aplican a las capas IP configuradas con el comando ifconfig. Las capas que hay delante o detrás de la capa IP, como ATM u otros servicios, requieren pasos manuales específicos si las capas no están automatizadas. Los pasos de los procedimientos siguientes permiten desconfigurar interfaces durante la desconexión previa y configurarlas tras la conexión posterior.

ProcedureCómo eliminar una interfaz física que ha fallado (desconexión en DR)

Este procedimiento muestra cómo eliminar una interfaz física de un sistema que admite DR. El procedimiento presupone la existencia de las siguientes condiciones:

Nota –

Puede omitir el paso 2 si la dirección de prueba se conecta utilizando el archivo /etc/hostname.hme0.

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Visualice la configuración de la dirección de prueba.


    # ifconfig hme0:1

hme0:1:
flags=9040842<BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 192.168.233.250 netmask ffffff00 broadcast 192.168.233.255

    Esta información es necesaria para volver a sondear la dirección de prueba cuando se reemplaza la interfaz física.

  3. Elimine la interfaz física.

    Consulte las siguientes fuentes para obtener una descripción completa sobre cómo eliminar la interfaz física:

    • Página del comando man cfgadm(1M)

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

    • Sun Enterprise 10000 DR Configuration Guide

ProcedureComo sustituir una interfaz física que ha fallado (conexión en DR)

Este procedimiento muestra cómo reemplazar una interfaz física en un sistema que admite DR.

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Reemplace la interfaz física.

    Consulte las instrucciones que se incluyen en las siguientes fuentes:

    • Página del comando man cfgadm(1M)

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

    • Sun Enterprise 10000 DR Configuration Guide o Sun Fire 880 Dynamic Reconfiguration User's Guide

Recuperación de una interfaz física que no estaba presente durante el inicio del sistema

Nota –

El siguiente procedimiento sólo se aplica a las capas IP configuradas con el comando ifconfig. Las capas que hay delante o detrás de la capa IP, como ATM u otros servicios, requieren pasos manuales específicos si las capas no están automatizadas. Los pasos específicos del siguiente procedimiento permiten desconfigurar interfaces durante la desconexión previa y configurarlas tras la conexión posterior.

La recuperación tras la reconfiguración dinámica es automática para una interfaz que forma parte de la placa de E/S de una plataforma Sun Fire™. Si la tarjeta NIC es una Sun Crypto Accelerator I - cPCI, la recuperación también es automática. Como resultado, no es necesario realizar los pasos siguientes para una interfaz que se recupera como parte de una operación de DR. Para obtener más información sobre los sistemas Sun Fire x800 y Sun Fire 15000, consulte la página del comando man cfgadm_sbd(1M) La interfaz física vuelve a la configuración especificada en el archivo /etc/hostname. interfaz. Consulte Configuración de grupos IPMP para obtener más detalles sobre cómo configurar las interfaces para que conserven la configuración tras un reinicio.

Nota –

En los sistemas Sun Fire (Exx00) antiguos, la desconexión DR sigue estando sujeta a los procedimientos manuales. Sin embargo, las conexiones en DR están automatizadas.

ProcedureCómo recuperar una interfaz física que no está presente al iniciar el sistema

Debe completar el procedimiento siguiente para recuperar una interfaz física que no estaba presente al iniciar el sistema. El ejemplo de este procedimiento está configurado del modo siguiente:

Nota –

La recuperación tras error de direcciones IP durante la recuperación de una interfaz física fallida puede tardar hasta tres minutos. Este tiempo puede variar en función del tráfico de la red. El tiempo también depende de la estabilidad de la interfaz entrante para recuperar las interfaces fallidas mediante el daemon in.mpathd.

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Recupere la información de red fallida del mensaje de error del registro de la consola.

    Consulte la página del comando man syslog(3C) El mensaje de error podría ser similar al siguiente:


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

    Este mensaje indica que las direcciones IPv4 de la interfaz fallida hme1 han fallado para la interfaz hme0.

    También podría recibir un mensaje como el siguiente:


    moving addresses from failed IPv4 interfaces:
hme1 (couldn't move, no alternative interface)

    Este mensaje indica que no se ha podido encontrar ninguna interfaz activa en el mismo grupo que la interfaz fallida hme1. Por tanto, las direcciones IPv4 de hme1 no se han podido conmutar por error.

  3. Conecte la interfaz física al sistema.

    Consulte las siguientes instrucciones para reemplazar la interfaz física:

    • Página del comando man cfgadm(1M)

    • Sun Enterprise 10000 DR Configuration Guide

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

  4. Consulte el contenido del paso 2. Si no se pueden mover las direcciones, vaya al paso 6. Si se han podido mover las direcciones, continúe con el paso 5.

  5. Desconecte las interfaces lógicas que se configuraron como parte del proceso de conmutación por error.

    1. Revise el contenido del archivo /etc/hostname. movido_de_interfaz para determinar qué interfaces lógicas se han configurado como parte del proceso de conmutación por error.

    2. Desconecte cada dirección IP de conmutación por error.


      # ifconfig moved-to-interface removeif moved-ip-address
      Nota –

      Las direcciones de conmutación por error se marcan con el parámetro failover, o no se marcan con el parámetro -failover. No es necesario desconectar las direcciones IP marcadas con -failover.

      Por ejemplo, supongamos que el contenido del archivo /etc/hostname.hme0 contiene las líneas siguientes:


      inet 10.0.0.4 -failover up group one
addif 10.0.0.5 failover up
addif 10.0.0.6 failover up

      Para desconectar cada dirección IP de conmutación tras error, escriba los comandos siguientes:


      # ifconfig hme0 removeif 10.0.0.5
# ifconfig hme0 removeif 10.0.0.6

  6. Reconfigure la información de IPv4 para la interfaz física reemplazada escribiendo el comando siguiente para cada interfaz eliminada:


    # ifconfig removed-from-NIC <parameters>

    Por ejemplo, escriba:


    # ifconfig hme1 inet plumb
# ifconfig hme1 inet 10.0.0.4 -failover up group one
# ifconfig hme1 addif 10.0.0.5 failover up
# ifconfig hme1 addif 10.0.0.6 failover up

Modificación de configuraciones IPMP

Utilice el archivo de configuración IPMP /etc/default/mpathd para configurar los siguientes parámetros del sistema para los grupos IPMP.

ProcedureCómo configurar el archivo /etc/default/mpathd

  1. En el sistema con la configuración de grupo IPMP, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Edite el archivo /etc/default/mpathd.

    Cambie el valor predeterminado de uno o más de los tres parámetros.

    1. Escriba el nuevo valor para el parámetro FAILURE_DETECTION_TIME.


      FAILURE_DETECTION_TIME=n

      donde n es el tiempo en segundos para que los sondeos ICMP detecten si se ha producido un fallo de la interfaz. El valor predeterminado es de 10 segundos.

    2. Escriba el nuevo valor para el parámetro FAILBACK.


      FAILBACK=[yes | no]

      • yes: El valor yes es el comportamiento de recuperación tras fallo predeterminado de IPMP. Cuando se detecta la reparación de una interfaz fallida, el acceso de red recupera la interfaz reparada, tal como se describe en Funciones de detección de fallos IPMP y recuperación.

      • no: El valor no indica que el tráfico de datos no se devuelve a una interfaz reparada. Cuando se detecta la reparación de una interfaz fallida, se configura el indicador INACTIVE para dicha interfaz. Este indicador significa que la interfaz no se va a utilizar para el tráfico de datos. La interfaz se puede seguir utilizando para el tráfico de sondeos.

        Por ejemplo, supongamos que un grupo IPMP se compone de dos interfaces, ce0 y ce1. A continuación, supongamos que se configura el valor FAILBACK=no en /etc/default/mpathd. Si falla ce0, su tráfico fallará para ce1, de acuerdo con el comportamiento de IPMP. No obstante, cuando IPMP detecta que se ha reparado ce0 , el tráfico no se recupera de ce1, debido al parámetro FAILBACK=no de /etc/default/mpathd. La interfaz ce0 conserva su estado INACTIVE y no se utiliza para tráfico a menos que falle la interfaz ce1. Si falla la interfaz ce1, las direcciones de ce1 se migran de nuevo a ce0, cuyo indicador INACTIVE se borra. Esta migración tiene lugar siempre y cuando ce0 sea la única interfaz INACTIVE del grupo. Si hay otras interfaces INACTIVE en el grupo, las direcciones podrían migrarse a una interfaz INACTIVE que no sea ce0.

    3. Escriba el nuevo valor para el parámetro TRACK_INTERFACES_ONLY_WITH_GROUPS .


      TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]

      • yes: El valor yes es el comportamiento predeterminado de IPMP. Este parámetro hace que IPMP omita las interfaces de red que no están configuradas en un grupo IPMP.

      • no: El valor no define la detección de fallos y la reparación para todas las interfaces de red, independientemente de si están configuradas en un grupo IPMP. Sin embargo, cuando se detecta un fallo o reparación en una interfaz que no está configurada en un grupo IPMP, no tiene lugar ninguna recuperación tras error o conmutación por error. Por tanto, el valor no sólo resulta útil para comunicar errores y no mejora directamente la disponibilidad de la red.

  3. Reinicie el daemon in.mpathd.


    # pkill -HUP in.mpathd