Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Guía de administración del sistema: servicios IP |
Parte I Introducción a la administración del sistema: servicios IP
1. Conjunto de protocolos TCP/IP de Oracle Solaris (descripción general)
Parte II Administración de TCP/IP
2. Planificación de la red TCP/IP (tareas)
3. Introducción a IPv6 (descripción general)
4. Planificación de una red IPv6 (tareas)
5. Configuración de servicios de red TCP/IP y direcciones IPv4 (tareas)
6. Administración de interfaces de red (tareas)
7. Configuración de una red IPv6 (tareas).
8. Administración de redes TCP/IP (tareas)
9. Resolución de problemas de red (Tareas)
10. Descripción detallada de TCP/IP e IPv4 (referencia)
11. IPv6 en profundidad (referencia)
12. Acerca de DHCP (descripción general)
13. Planificación del servicio DHCP (tareas)
14. Configuración del servicio DHCP (tareas)
15. Administración de DHCP (tareas)
16. Configuración y administración del cliente DHCP
17. Solución de problemas de DHCP (referencia)
18. Comandos y archivos DHCP (referencia)
19. Arquitectura de seguridad IP (descripción general)
20. Configuración de IPsec (tareas)
21. Arquitectura de seguridad IP (referencia)
22. Intercambio de claves de Internet (descripción general)
23. Configuración de IKE (tareas)
24. Intercambio de claves de Internet (referencia)
25. Filtro IP en Oracle Solaris (descripción general)
27. IP para móviles (Descripción general)
28. Administración de IP móvil (tareas)
29. Archivos y comandos de IP para móviles (referencia)
30. Introducción a IPMP (descripción general)
Componentes IPMP de Oracle Solaris
Daemon de múltiples rutas, in.mpathd
Terminología y conceptos de IPMP
Detección de fallos y conmutación por error
Detección de reparaciones y recuperación tras los errores
Expansión de la carga saliente
Cómo evitar que las aplicaciones utilicen direcciones de prueba
Configuraciones de interfaces IPMP
Interfaces de reserva en un grupo IPMP
Configuraciones comunes de interfaces IPMP
Comprobación del estado de una interfaz
Funciones de detección de fallos IPMP y recuperación
Detección de fallos basada en vínculos
Detección de fallos basada en sondeos
IPMP y reconfiguración dinámica
NIC que no estaban presentes durante el inicio del sistema
31. Administración de IPMP (tareas)
Parte VII Calidad de servicio IP (IPQoS)
32. Introducción a IPQoS (Descripción general)
33. Planificación para una red con IPQoS (Tareas)
34. Creación del archivo de configuración IPQoS (Tareas)
35. Inicio y mantenimiento de IPQoS (Tareas)
36. Uso de control de flujo y recopilación de estadísticas (Tareas)
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.
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.
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.
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.
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.
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).