| Omitir V�nculos de navegaci�n | |
| Salir de la Vista de impresi�n | |
|
Guía de administración del sistema: servicios IP |
| 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
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
Detección de reparaciones de interfaces físicas
Qué ocurre durante la conmutación por error de la interfaz
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)
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.
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.
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.
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.
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.
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. Sin embargo, si una aplicación no se vincula explícitamente con una dirección, y la única dirección que está marcada como UP en la interfaz también está marcada como deprecated; después, como última instancia, esa dirección se utiliza como dirección de origen.
Nota - En los casos de conmutación por error y recuperación tras los errores, mientras la detección de direcciones duplicadas todavía se está ejecutando, puede que las aplicaciones reciban los paquetes que utilizan direcciones descartadas como direcciones de origen. Éste es el comportamiento esperado. Normalmente, una vez que DAD se ha completado, las direcciones descartadas ya no se procesan con las aplicaciones. Sin embargo, puede producirse una excepción inusual con paquetes TCP. Después de que una conexión TCP selecciona una determinada dirección de origen, el uso de dicha dirección no puede cambiarse durante esa conexión. Esa duración puede ampliarse durante un largo período. En casos extremos como éste, existe la posibilidad de que las aplicaciones continúen utilizando direcciones descartadas, incluso después de que DAD finaliza.
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.
|