Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Oracle Administración Solaris: Servicios de red Oracle Solaris 11 Information Library (Español) |
Parte I Servicios de red (temas)
1. Servicio de red (descripción general)
2. Gestión de servidores de antememoria web
3. Servicios relacionados con el tiempo
Parte II Acceso a los sistemas de archivos de red (temas)
4. Gestión de sistemas de archivos de red (descripción general)
5. Administración de sistema de archivos de red (tareas)
6. Acceso a los sistemas de archivos de red (referencia)
8. Planificación y habilitación del SLP (tareas)
9. Administración del SLP (tareas)
Configuración de propiedades del SLP
Archivo de configuración del SLP: elementos básicos
Líneas de comentario y notaciones
Cómo cambiar la configuración del SLP
Modificación de frecuencia de detección y anuncios del DA
Limitación de UA y SA a DA configurados estáticamente
Cómo limitar UA y SA a DA configurados estáticamente
Configuración de detección de DA para redes de acceso telefónico
Cómo configurar la detección de DA para redes de acceso telefónico
Configuración del latido del DA para particiones frecuentes
Cómo configurar latidos del DA para particiones frecuentes
Liberación de la congestión de la red
Adaptación de diferentes medios de red, topologías o configuraciones
Reducción de reregistros de SA
Cómo reducir reregistros de SA
Configuración de la propiedad Time-to-Live de multidifusión
Cómo configurar la propiedad Time-to-Live de multidifusión
Configuración del tamaño de paquete
Cómo configurar el tamaño de paquete
Configuración de enrutamiento de sólo difusión
Cómo configurar el enrutamiento de sólo difusión
Modificación de tiempos de espera en solicitudes de detección de SLP
Cambio de tiempos de espera predeterminados
Cómo cambiar tiempos de espera predeterminados
Configuración del límite de espera aleatoria
Cómo configurar el límite de espera aleatoria
Consideraciones al configurar ámbitos
¿Por qué implementar un DA de SLP?
Colocación de varios DA para el equilibrio de carga
SLP y función de hosts múltiples
Configuración de la función de hosts múltiples para SLP
Cuándo realizar la configuración para múltiples interfaces de red no enrutadas
Configuración de múltiples interfaces de red no enrutadas (mapa de tareas)
Configuración de la propiedad net.slp.interfaces
Cómo configurar la propiedad net.slp.interfaces
Anuncios de proxy y hosts múltiples
Asignación de nombre de ámbito y colocación de DA
Consideraciones al configurar múltiples interfaces de red no enrutadas
10. Incorporación de servicios antiguos
Parte IV Servicios de correo (temas)
12. Servicios de correo (descripción general)
13. Servicios de correo (tareas)
14. Servicios de correo (referencia)
Parte V Redes en serie (temas)
15. Solaris PPP 4.0 (descripción general)
16. Planificación del enlace de PPP (tareas)
17. Configuración de un enlace de PPP por marcación telefónica (tareas)
18. Configuración de un enlace de PPP de línea arrendada (tareas)
19. Configuración de autenticación PPP (tareas)
20. Configuración de un túnel PPPoE (tareas)
21. Resolución de problemas comunes de PPP (tareas)
22. Solaris PPP 4.0 (referencia)
23. Migración de Solaris PPP asíncrono a Solaris PPP 4.0 (tareas)
24. UUCP (descripción general)
25. Administración del UUCP (tareas)
Parte VI Trabajo con sistemas remotos (temas)
27. Trabajo con sistemas remotos (descripción general)
28. Administración del servidor FTP (tareas)
29. Acceso a sistemas remotos (tareas)
Parte VII Supervisión de servicios de red (temas)
Un servidor de hosts múltiples actúa como un host en varias subredes IP. El servidor puede, a veces, tener más de una tarjeta de interfaz de red y puede actuar como enrutador. Los paquetes IP, incluidos los paquetes de multidifusión, se enrutan entre las interfaces. En algunas situaciones, el enrutamiento entre interfaces está deshabilitado. En las secciones siguientes, se describe cómo configurar el SLP para esas situaciones.
Sin configuración, el slpd escucha la multidifusión y la unidifusión UDP/TCP en la interfaz de red predeterminada. Si el enrutamiento de unidifusión y multidifusión está habilitado entre las interfaces de un equipo de hosts múltiples, no se necesita ninguna configuración adicional. Esto se debe a que los paquetes de multidifusión que llegan a otra interfaz se enrutan correctamente a la interfaz predeterminada. Como resultado, las solicitudes de multidifusión para DA u otros anuncios de servicios llegan a slpd. Si el enrutamiento no está activado por algún motivo, es necesario realizar la configuración.
Si existe una de las condiciones siguientes, quizá deba configurar equipos de hosts múltiples.
El enrutamiento de unidifusión está habilitado entre las interfaces y el enrutamiento de multidifusión está deshabilitado.
El enrutamiento de unidifusión y el enrutamiento de multidifusión están deshabilitados entre las interfaces.
Cuando el enrutamiento de multidifusión está deshabilitado entre interfaces, normalmente, se debe a que la multidifusión no ha sido implementada en la red. En tal situación, la difusión se usa, por lo general, para la detección de servicios que no se basa en DA y para la detección de DA en las subredes individuales. La difusión se configura estableciendo la propiedad net.slp.isBroadcastOnly en True.
Tabla 9-5 Configuración de múltiples interfaces de red no enrutadas
|
Si la propiedad net.slp.interfaces está establecida, slpd escucha solicitudes del SLP de unidifusión y multidifusión/difusión en las interfaces que aparecen en la propiedad, en lugar de la interfaz predeterminada.
Por lo general, establece la propiedad net.slp.interfaces junto con la habilitación de la difusión estableciendo la propiedad net.slp.isBroadcastOnly, porque la multidifusión no se ha implementado en la red. Sin embargo, si la multidifusión se ha implementado, pero no se enruta en este host múltiple particular, una solicitud de multidifusión puede llegar a slpd de más de una interfaz. Esta situación se puede producir cuando el enrutamiento de paquetes es manejado por otro host múltiple o enrutador que conecta las subredes que son servidas por las interfaces.
Cuando tal situación se produce, el servidor de SA o el UA que envía la solicitud recibe dos respuestas de slpd en el host múltiple. Las respuestas se filtran por las bibliotecas del cliente, y el cliente no las ve. Sin embargo, las respuestas están visibles en el rastreo de snoop.
Nota -
Si el enrutamiento de unidifusión está desactivado, es posible que no se pueda acceder a los servicios anunciados por clientes de SA en hosts múltiples desde todas las subredes. Si no se puede acceder a los servicios, los clientes de SA pueden realizar lo siguiente:
Anunciar una URL de servicio para cada subred.
Garantizar que las solicitudes de una subred particular se respondan con una URL accesible.
La biblioteca del cliente de SA no hace nada para garantizar que las direcciones URL accesibles se anuncien. El programa de servicio, que puede o no manejar un host múltiple sin ningún enrutamiento, es responsable de asegurar que las direcciones URL accesibles sean anunciadas.
Antes de desplegar un servicio en un host múltiple con enrutamiento de unidifusión deshabilitado, use snoop para determinar si el servicio maneja las solicitudes de varias subredes correctamente. Además, si tiene previsto implementar un DA en el host múltiple, consulte Asignación de nombre de ámbito y colocación de DA.
Utilice el siguiente procedimiento para cambiar la propiedad net.slp.interfaces en el archivo slp.conf.
Para obtener más información, consulte Cómo obtener derechos administrativos de Administración de Oracle Solaris: servicios de seguridad.
# svcadm disable network/slp
net.slp.interfaces=value
Lista de direcciones IPv4 o nombres de host de las tarjetas de interfaz de red en las que el DA o SA deben escuchar mensajes TCP, UDP de unidifusión y multidifusión en el puerto 427
Por ejemplo, un servidor con tres tarjetas de red y enrutamiento de multidifusión desactivado está conectado a tres subredes. Las direcciones IP de las tres interfaces de red son 192.147.142.42, 192.147.143.42 y 192.147.144.42. La máscara de subred es 255.255.255.0. El siguiente valor de propiedad hace que slpd escuche en las tres interfaces mensajes de unidifusión y multidifusión/difusión:
net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42
# svcadm enable network/slp
Si un host con varias interfaces anuncia servicios mediante slpd y registro de proxy, las direcciones URL de servicio anunciadas por slpd deben contener direcciones o nombres de host accesibles. Si el enrutamiento de unidifusión está habilitado entre las interfaces, los hosts en todas las subredes pueden acceder a los hosts de otras subredes. Los registros de proxy también se pueden realizar para un servicio en cualquier subred. Sin embargo, si el enrutamiento de unidifusión está deshabilitado, los clientes de servicio en una subred no pueden acceder a servicios en otra subred por medio del host múltiple. Es posible, no obstante, que dichos clientes puedan acceder a los servicios mediante otro enrutador.
Por ejemplo, suponga que el host con el nombre de host predeterminado bigguy tiene tres tarjetas de interfaz en tres subredes enrutadas diferentes. Los nombres de host en estas subredes son bigguy, con dirección IP 192.147.142.42, bigguy1, con dirección IP 192.147.143.42 y bigguy2, con dirección IP 192.147.144.42. Ahora, suponga que una impresora antigua, oldprinter, está conectada a la subred 143 y que la dirección URL service:printing:lpr://oldprinter/queue1 está configurada con net.slp.interfaces para escuchar en todas las interfaces. La URL oldprinter tiene anuncios de proxy en todas las interfaces. Los equipos de las subredes 142 y 144 reciben la dirección URL en respuesta a solicitudes de servicio, pero no pueden acceder al servicio oldprinter.
La solución a este problema es realizar los anuncios de proxy con slpd ejecutándose en un equipo que está conectado sólo a la subred 143, en lugar de en el host múltiple. Sólo los hosts de la subred 143 pueden obtener el anuncio en respuesta a una solicitud de servicio.
La colocación de DA y la asignación de nombres de ámbito en una red con un host múltiple se deben realizar cuidadosamente para garantizar que los clientes obtengan servicios accesibles. Sea especialmente cauteloso cuando el enrutamiento esté deshabilitado y la propiedad net.slp.interfaces esté configurada. De nuevo, si el enrutamiento de unidifusión está habilitado entre las interfaces en un equipo de hosts múltiples, no es necesaria ninguna configuración especial de DA ni ámbito. Los anuncios se almacenan en la antememoria con los servicios de identificación de DA a los que se puede acceder desde cualquiera de las subredes. Sin embargo, si el enrutamiento de unidifusión está deshabilitado, la colocación incorrecta de DA puede generar problemas.
Para ver los problemas que pueden ocurrir en el ejemplo anterior, considere qué sucedería si bigguy ejecuta un DA y los clientes en todas las subredes tienen los mismos ámbitos. Los SA en la subred 143 registran sus anuncios de servicios con el DA. Los UA en la subred 144 pueden obtener esos anuncios de servicios, aunque no se pueda acceder a los hosts de la subred 143.
Una solución a este problema es ejecutar un DA en cada subred y no en el host múltiple. En esta situación, la propiedad net.slp.interfaces en los hosts múltiples debe configurarse con una dirección o un nombre de host de interfaz único, o debe dejarse sin configurar, con lo que se fuerza el uso de la interfaz predeterminada. La desventaja de esta solución es que los hosts múltiples son, a menudo, grandes equipos que podrían manejar mejor la carga computacional de un DA.
Otro solución es ejecutar un DA en el host múltiple, pero configurar ámbitos para que los SA y UA en cada subred tengan un ámbito diferente. Por ejemplo, en la situación anterior, los UA y SA en la subred 142 pueden tener un ámbito que se denomina scope142. Los UA y SA en la subred 143 pueden tener otro ámbito que se denomina scope143, y los UA y SA en la subred 144 pueden tener un tercer ámbito que se denomina scope144. Puede configurar la propiedad net.slp.interfaces en bigguy con las tres interfaces, de modo que el DA atienda tres ámbitos en las tres subredes.
La configuración de la propiedad net.slp.interfaces permite que un DA en el host múltiple una anuncios de servicios entre las subredes. Dicha configuración es útil si el enrutamiento de multidifusión está desactivado en la red, pero el enrutamiento de unidifusión entre interfaces en un host múltiple está habilitado. Debido a que la unidifusión se enruta entre las interfaces, los hosts en una subred diferente de la subred en la que el servicio se encuentra pueden ponerse en contacto con el servicio cuando reciben la URL del servicio. Sin el DA, los servidores de SA en una subred en particular reciben sólo difusiones que se realizaron en la misma subred, por lo que no pueden buscar servicios fuera de su subred.
La situación más común que requiere la configuración de la propiedad net.slp.interfaces se produce cuando la multidifusión no está implementada en la red y la difusión se utiliza en su lugar. Otras situaciones exigen una cuidadosa consideración y planificación para evitar respuestas duplicadas innecesarias o servicios inaccesibles.