EN ESTA PÁGINA
Uso de solicitudes dinámicas RADIUS para la administración de acceso de suscriptores
Configuración de la compatibilidad con solicitudes dinámicas iniciadas por RADIUS
Descripción general del cambio de autorización (CoA) iniciado por RADIUS
Descripción general de los inicios de sesión de suscriptores y errores de activación del servicio
Códigos de causa de error (atributo RADIUS 101) para solicitudes dinámicas
Comprobación de estadísticas de solicitud dinámica de RADIUS
Gestión dinámica de servicios con RADIUS
Uso de solicitudes dinámicas RADIUS para la administración de acceso de suscriptores
Las solicitudes dinámicas de RADIUS proporcionan una forma eficaz de administrar de forma centralizada las sesiones de suscriptores. La compatibilidad con solicitudes dinámicas RADIUS del marco de servicio AAA permite a los servidores RADIUS iniciar operaciones relacionadas con el usuario, como una operación de terminación, mediante el envío de mensajes de solicitud no solicitados al enrutador. Sin la función de solicitud dinámica RADIUS, la única forma de desconectar a un usuario RADIUS es desde el enrutador, lo que puede ser engorroso y llevar mucho tiempo en redes grandes.
En un entorno RADIUS cliente-servidor típico, el enrutador funciona como el cliente e inicia las solicitudes enviadas al servidor RADIUS remoto. Sin embargo, cuando se utilizan solicitudes dinámicas RADIUS, los roles se invierten. Por ejemplo, durante una operación de desconexión, el servidor RADIUS remoto actúa como cliente e inicia la solicitud (la acción de desconexión): el enrutador funciona como el servidor en la relación.
Puede crear un perfil de acceso para configurar el enrutador de modo que admita solicitudes dinámicas RADIUS. Esta configuración permite que el enrutador reciba y actúe sobre los siguientes tipos de mensajes de servidores RADIUS remotos:
Mensajes de acceso-aceptación: activa dinámicamente servicios basados en atributos de los mensajes de acceso-aceptación de RADIUS recibidos cuando un suscriptor inicia sesión.
Mensajes de cambio de autorización (CoA): modifique dinámicamente las sesiones activas según los atributos de los mensajes de CoA. Los mensajes de CoA pueden incluir solicitudes de creación de servicios, solicitudes de eliminación, atributos RADIUS y VSA de Juniper Networks.
Desconectar mensajes: permite finalizar inmediatamente sesiones específicas de suscriptor.
De forma predeterminada, el enrutador supervisa el puerto UDP 3799 en busca de solicitudes de CoA de los servidores RADIUS. También puede configurar un puerto no predeterminado para los servidores RADIUS. Debe utilizar el puerto predeterminado para todos los servidores RADIUS o configurar el mismo puerto no predeterminado para todos los servidores RADIUS. Esta regla se aplica tanto en el nivel de acceso global como en el de perfil de acceso.
Cualquier otra configuración produce un error en la comprobación de confirmación. No se admiten varios números de puerto, es decir, diferentes números de puerto para distintos servidores.
Ventajas de las solicitudes dinámicas de Radius
Permite una administración central simplificada de las sesiones del suscriptor mediante el envío de cambios no solicitados a las sesiones del suscriptor, incluidos los cambios en los atributos, la activación del servicio, la desactivación del servicio y la terminación de la sesión.
Ver también
Configuración de la compatibilidad con solicitudes dinámicas iniciadas por RADIUS
El enrutador utiliza la lista de servidores de autenticación RADIUS especificados para las operaciones de autenticación y de solicitud dinámica. De forma predeterminada, el enrutador supervisa el puerto UDP 3799 en busca de solicitudes dinámicas, también conocidas como solicitudes de cambio de autorización (CoA).
Para configurar la compatibilidad con solicitudes dinámicas de RADIUS:
Especifique la dirección IP del servidor RADIUS.
[edit access profile isp-bos-metro-fiber-basic radius] user@host# set authentication-server 192.168.1.3
Para configurar el enrutador para que admita solicitudes dinámicas de más de un servidor RADIUS:
Especifique las direcciones IP de varios servidores RADIUS.
[edit access profile isp-bos-metro-fiber-basic radius] user@host# set authentication-server 192.168.1.3 192.168.10.15
Al configurar puertos de solicitud dinámicos, debe realizar una de las siguientes acciones:
Utilice el puerto predeterminado para todos los servidores RADIUS, tanto en el nivel de acceso global como en todos los perfiles de acceso.
Configure el mismo puerto no predeterminado para todos los servidores tanto en el nivel de acceso global como en todos los perfiles de acceso.
Cualquier otra configuración produce un error en la comprobación de confirmación. No se admiten varios números de puerto, es decir, diferentes números de puerto para distintos servidores.
Para especificar un puerto de solicitud dinámico global:
[edit access] user@host# set radius-server server-address dynamic-request-port port-number
Para especificar el puerto de solicitud dinámico para un perfil de acceso específico:
[edit access] user@host# set profile profile-name radius-server server-address dynamic-request-port port-number
Considere los siguientes escenarios:
La siguiente configuración utiliza el puerto predeterminado tanto para un servidor globalmente como para un servidor diferente en el perfil de acceso. Esta es una configuración válida.
[edit access] user@host# set radius-server 192.0.2.1 user@host# set profile ap1 radius-server 192.0.2.3
La siguiente configuración especifica el puerto no predeterminado 50201 tanto para un servidor globalmente como para un servidor diferente en el perfil de acceso. Esta es una configuración válida.
[edit access] user@host# set radius-server 192.0.2.1 dynamic-request-port 50201 user@host# set profile ap1 radius-server 192.0.2.3 dynamic-request-port 50201
La siguiente configuración especifica el puerto 50201 globalmente para un servidor y el puerto 51133 para el mismo servidor en el perfil de acceso ap1. Se trata de una configuración no válida y se produce un error en la comprobación de confirmación, ya que no se admiten varios puertos no predeterminados.
[edit access] user@host# set radius-server 192.0.2.1 dynamic-request-port 50201 user@host# set profile ap1 radius-server 192.0.2.1 dynamic-request-port 51133
La siguiente configuración utiliza el puerto predeterminado 3799 para un servidor globalmente y el puerto 51133 para otro servidor globalmente. Se trata de una configuración no válida y se produce un error en la comprobación de confirmación, ya que para todos los servidores debe configurar el puerto predeterminado o el mismo puerto no predeterminado.
[edit access] user@host# set radius-server 192.0.2.1 user@host# set radius-server 192.0.2.3 dynamic-request-port 51133
Ver también
Descripción general del cambio de autorización (CoA) iniciado por RADIUS
AAA Service Framework utiliza mensajes CoA para modificar dinámicamente las sesiones de suscriptores activos. Por ejemplo, los atributos RADIUS en los mensajes CoA pueden indicar al marco que cree, modifique o finalice un servicio de suscriptor. También puede usar mensajes CoA para establecer o modificar umbrales de uso para los servicios de suscriptor actuales.
- Mensajes de CoA
- Requisitos para el cambio de autorización
- Intercambio de mensajes
- Transacciones masivas de CoA
- Ventajas del cambio de autorización iniciado por Radius
Mensajes de CoA
El soporte dinámico de solicitudes permite que el enrutador reciba y procese mensajes CoA no solicitados de servidores RADIUS externos. Los mensajes CoA iniciados por RADIUS utilizan los siguientes códigos en los mensajes de solicitud y respuesta:
CoA-Solicitud (43)
CoA-ACK (44)
CoA-NAK (45)
Requisitos para el cambio de autorización
Para completar el cambio de autorización para un usuario, especifique atributos de identificación y atributos de sesión. Los atributos de identificación identifican al suscriptor. Los atributos de sesión especifican la operación (activación o desactivación) que se debe realizar en la sesión del suscriptor e incluyen también los atributos de cliente para la sesión (por ejemplo, atributos QoS). El marco de servicio AAA controla la solicitud real.
La Tabla 1 muestra los atributos de identificación para las operaciones de CoA.
Atributo |
Descripción |
|---|---|
Nombre de usuario [atributo RADIUS 1] |
Nombre de usuario del suscriptor. |
Acct-Session-ID [atributo RADIUS 44] |
Sesión específica del suscriptor. |
Usar el atributo Acct-Session-ID para identificar la sesión del suscriptor es más explícito que usar el atributo User-Name. Cuando se utiliza el nombre de usuario como identificador, la operación CoA se aplica a la primera sesión que inició sesión con el nombre de usuario especificado. Sin embargo, dado que un suscriptor puede tener varias sesiones asociadas con el mismo nombre de usuario, es posible que la primera sesión no sea la sesión correcta para la operación de CoA.
Cuando se utiliza el atributo Acct-Session-ID, identifica la sesión específica del suscriptor, evitando ese posible error. Aunque el atributo Acct-Session-ID puede incluir un especificador de interfaz además del ID de sesión, cuando el atributo está en el formato de descripción, solo se usa el ID de sesión para la coincidencia de suscriptores. Por ejemplo, si el suscriptor tiene un ID de sesión de suscriptor de , entonces el suscriptor coincide cuando el atributo Acct-Session-ID es 54785 (formato decimal), o jnpr demux0.1073759682:54785 (formato de descripción), o incluso any value:54785 (formato de 54785descripción).
La Tabla 2 muestra los atributos de sesión para las operaciones de CoA. Cualquier atributo de cliente adicional que incluya dependerá de sus requisitos de sesión particulares.
Atributo |
Descripción |
|---|---|
Servicio de activación [Juniper Networks VSA 26-65] |
Servicio a activar para el suscriptor. |
Servicio de desactivación [Juniper Networks VSA 26-66] |
Servicio a desactivar para el suscriptor. |
Volumen de servicio [Juniper Networks VSA 26-67] |
Cantidad de tráfico, en MB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. |
Tiempo de espera del servicio [Juniper Networks VSA 26-68] |
Número de segundos que el servicio puede estar activo; El servicio se desactiva cuando expira el tiempo de espera. |
Gigawords de volumen de servicio [VSA 26-179 de Juniper Networks] |
Cantidad de tráfico, en unidades de 4GB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. |
Servicio de actualización [Juniper Networks VSA 26-180] |
Nuevos valores de servicio y cuotas de tiempo para el servicio existente. |
Intercambio de mensajes
El servidor RADIUS y AAA Service Framework en el enrutador intercambian mensajes mediante UDP. El mensaje CoA-Request enviado por el servidor RADIUS tiene el mismo formato que el paquete Disconnect-Request que se envía para una operación de desconexión.
La respuesta es un mensaje CoA-ACK o CoA-NAK:
Si AAA Service Framework cambia correctamente la autorización, la respuesta es un paquete con formato RADIUS con un mensaje CoA-ACK y el filtro de datos se aplica a la sesión.
Si AAA Service Framework no se realiza correctamente, la solicitud está mal formada o faltan atributos, la respuesta es un paquete con formato RADIUS con un mensaje CoA-NAK.
AAA Service Framework procesa una solicitud dinámica a la vez por suscriptor. Si el marco recibe una segunda solicitud dinámica (ya sea otro CoA o una solicitud de desconexión) mientras procesa una solicitud anterior para el mismo suscriptor, el marco responde con un mensaje CoA-NAK. A partir de Junos OS versión 15.1R5, los mensajes de reintento de solicitud de CoA se ignoran y no se envía ningún CoA-NAK en respuesta a ellos.
Transacciones masivas de CoA
A partir de Junos OS versión 17.2R1, se admiten solicitudes masivas de CoA para mejorar la eficiencia de procesamiento de los servicios de suscriptor basados en RADIUS en el BNG. La funcionalidad de CoA masivo permite la acumulación de una serie de solicitudes de CoA y las compromete todas juntas, de forma masiva y automáticamente.
Todos los servicios en una solicitud masiva de CoA deben ser para la misma sesión de suscriptor.
Las transacciones masivas de CoA son particularmente valiosas para los servicios empresariales. Los servicios de abonado basados en RADIUS utilizan los VSA, Activate-Service (26-65) y Deactivate-Service (26-66) de Juniper Networks. Los VSA se proporcionan en mensajes RADIUS-Accept durante el inicio de sesión o en solicitudes de CoA después del inicio de sesión.
Para los servicios convencionales y dinámicos basados en perfiles de servicio, pueden caber fácilmente hasta 12 activaciones de servicio dentro de cualquiera de los mensajes RADIUS. Sin embargo, los servicios basados en scripts operativos utilizados por las empresas suelen tener requisitos de escalado que superan la capacidad de cualquiera de los mensajes. Esto significa que especificar y activar todos los servicios necesarios en una sesión de suscriptor determinada puede requerir el uso de un mensaje de aceptación y acceso y múltiples solicitudes de CoA.
Cada mensaje de solicitud de CoA es independiente de las solicitudes de CoA anteriores y futuras en la misma sesión de suscriptor. Todas las activaciones y desactivaciones de servicio en un mensaje se procesan antes de que se ofrezca una respuesta de CoA. La solicitud CoA proporciona una forma de modificar incrementalmente una sesión de suscriptor sin afectar a los servicios existentes que ya están presentes.
Para los servicios basados en scripts operativos, las sesiones de servicio se crean de forma colaborativa mediante los procesos authd y essmd, de modo que la última operación inicia una confirmación para aplicar todas las interfaces lógicas empresariales estáticas resultantes de la solicitud CoA. Dado que el tiempo de confirmación suele ser la mayor parte de la aplicación de un servicio empresarial estático, es ventajoso empaquetar tantas activaciones o desactivaciones de servicio como caban dentro de un mensaje RADIUS para usar la ventana de confirmación de forma eficaz. Hasta que se complete la operación de confirmación, el BNG no puede aceptar una solicitud de CoA posterior para aplicar servicios empresariales adicionales para la misma sesión de suscriptor.
La CoA masiva mejora la eficiencia del procesamiento de confirmaciones mediante el uso de una única acción de confirmación para todos los servicios de la transacción masiva. La transacción masiva tiene el efecto de administrar una serie de solicitudes como una sola metasolicitud. Difiere el procesamiento de confirmación hasta que se reciba la solicitud final de CoA en la transacción masiva.
La CoA masiva requiere que cada solicitud individual contenga una única instancia de la VSA de ID de transacción masiva de CoA de Juniper Networks (26–194). Este VSA identifica las solicitudes como pertenecientes a la misma transacción masiva; 26–194 deben tener el mismo valor en todas las solicitudes de CoA de la serie masiva. Cada transacción masiva sucesiva en la sesión debe tener un identificador diferente; por ejemplo, tres transacciones masivas sucesivas pueden tener identificadores de 1, 2 y 1, pero no pueden tener identificadores sucesivos de 1, 1 y 2. En la práctica, el valor Bulk-CoA-Transaction-Id normalmente se incrementa para varias transacciones masivas, pero esto no es obligatorio. Un valor de ID utilizado en una sesión de suscriptor determinada también se puede usar en diferentes sesiones de suscriptor.
Cada solicitud de CoA dentro de una transacción masiva tiene su propio identificador único, proporcionado por una sola instancia del VSA de identificador de CoA masivo (26–195) en cada CoA. Una serie creciente de valores para el ID es típica, pero no se aplica. Los valores se pueden reutilizar dentro de una sesión determinada y entre sesiones. La última solicitud de CoA de la serie se identifica teniendo un valor de 0xFFFFFFFF para el identificador de CoA masivo.
Ventajas del cambio de autorización iniciado por Radius
Permite que los cambios en los valores de atributo se inserten dinámicamente en las sesiones de suscriptor, así como la activación y desactivación dinámica de los servicios de suscriptor.
Ver también
Descripción general de la desconexión iniciada por RADIUS
En esta sección se describe la compatibilidad de AAA Service Framework con las solicitudes dinámicas de desconexión iniciadas por RADIUS. AAA Service Framework usa mensajes de desconexión para terminar dinámicamente las sesiones de suscriptor activas.
- Desconectar mensajes
- Requisitos para Desconectar
- Intercambio de mensajes
- Ventajas de las desconexiones iniciadas por Radius
Desconectar mensajes
Para controlar de forma centralizada la desconexión de los suscriptores de acceso remoto, la función de solicitud dinámica RADIUS del enrutador recibe y procesa mensajes no solicitados de los servidores RADIUS.
La característica de solicitud dinámica utiliza el formato existente de mensajes de solicitud y respuesta de desconexión RADIUS. La desconexión iniciada por RADIUS utiliza los siguientes códigos en sus mensajes de solicitud y respuesta de RADIUS:
Solicitud de desconexión (40)
Desconexión-ACK (41)
Desconexión-NAK (42)
Requisitos para Desconectar
Para que AAA Service Framework desconecte a un usuario, el mensaje Disconnect-Request debe contener un atributo con un identificador de sesión de contabilidad. El mensaje Disconnect-Request puede contener un atributo Acct-Session-Id (44) o un atributo Acct-Multi-Session-Id (50) para el ID de sesión, o ambos. Si los atributos Acct-Session-Id y Acct-Multi-Session-Id están presentes en la solicitud, el enrutador utiliza ambos atributos. Si el atributo Nombre de usuario (1) también está presente en la solicitud, el nombre de usuario y el ID de sesión de contabilidad se utilizan para realizar la desconexión. El marco de servicio AAA controla la solicitud real.
Intercambio de mensajes
El servidor RADIUS y AAA Service Framework intercambian mensajes mediante UDP. El mensaje Disconnect-Request enviado por el servidor RADIUS tiene el mismo formato que el paquete CoA-Request que se envía para una operación de cambio de autorización.
La respuesta de desconexión es un mensaje Disconnect-ACK o Disconnect-NAK:
Si AAA Service Framework desconecta correctamente al usuario, la respuesta es un paquete con formato RADIUS con un mensaje Disconnect-ACK.
Si AAA Service Framework no puede desconectar al usuario, la solicitud está mal formada o faltan atributos en la solicitud, la respuesta es un paquete con formato RADIUS con un mensaje Disconnect-NAK.
AAA Service Framework procesa una solicitud dinámica a la vez por suscriptor. Si el framework recibe una segunda solicitud dinámica mientras procesa una solicitud anterior (ya sea un CoA u otra Disconnect-Request) para el mismo suscriptor, el framework responde con un mensaje Disconnect-NAK.
Ventajas de las desconexiones iniciadas por Radius
Permite que un servidor RADIUS termine dinámicamente las sesiones de suscriptor. Esta función de administración centralizada de suscriptores simplifica el manejo de un gran número de suscriptores, ya que de lo contrario la terminación del operador requeriría una acción en el enrutador.
Ver también
Umbrales de uso para los servicios de suscriptor
A partir de Junos OS versión 14.1, la administración de suscriptores permite administrar servicios de suscriptores estableciendo umbrales de uso cuando un servicio se activa dinámicamente o cuando un servicio existente se modifica mediante una acción de RADIUS CoA. El servicio se desactiva cuando se alcanza el umbral especificado.
La administración de suscriptores admite dos tipos de umbrales de uso: volumen de tráfico y tiempo. Los VSA de Juniper Networks se utilizan para establecer los umbrales de uso. Los VSA se transmiten en mensajes de aceptación de acceso RADIUS para servicios activados dinámicamente o en mensajes de solicitud de CoA iniciados por RADIUS para servicios existentes. El umbral de volumen establece la cantidad máxima del tráfico total de entrada y salida que puede usar el servicio antes de que se desactive el servicio. Un umbral de tiempo establece el tiempo máximo que el servicio puede estar activo. La Tabla 3 muestra los VSA utilizados para los umbrales de volumen y tiempo.
Número de atributo |
Nombre del atributo |
Descripción |
Valor |
|---|---|---|---|
26-67 |
Volumen de servicio |
Cantidad de tráfico de entrada y salida, en MB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. Etiquetado VSA, que admite 8 etiquetas (1-8). El enrutador sondea el tráfico en intervalos de 10 minutos. |
|
26-68 |
Tiempo de espera del servicio |
Número de segundos que el servicio puede estar activo; El servicio se desactiva cuando expira el tiempo de espera. Etiquetado VSA, que admite 8 etiquetas (1-8). |
|
26-179 |
Servicio-Volumen-Gigawords |
Cantidad de tráfico de entrada y salida, en unidades de 4GB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. Etiquetado VSA, que admite 8 etiquetas (1-8). El enrutador sondea el tráfico en intervalos de 10 minutos. |
|
26-180 |
Servicio de actualización |
Nuevos valores de servicio y cuotas de tiempo para un servicio existente. Etiquetado VSA, que admite 8 etiquetas (1-8). |
cuerda: service-name |
Ver también
Descripción general de los inicios de sesión de suscriptores y errores de activación del servicio
Cuando un suscriptor intenta iniciar sesión y es autenticado por RADIUS, el mensaje de aceptación de acceso puede incluir servicios en el VSA de activación del servicio RADIUS (26-65) que se activarán para una familia de red en particular. Según la configuración y el tipo de servicio, si no se activa un servicio, se puede denegar el inicio de sesión del suscriptor.
Puede utilizar la service activation instrucción en el nivel de jerarquía ] para configurar el comportamiento posterior a un error de [edit access profile profile-name radius optionsactivación.
Utilice las siguientes opciones para configurar este comportamiento por separado para dos tipos de servicios:
dynamic-profile: este tipo de servicio se configura en el perfil dinámico aplicado por el perfil de acceso del suscriptor.extensible-service: este tipo de servicio se configura en un script de operación del Administrador de servicios de suscriptor extensible (ESSM). Estos servicios suelen configurar nuevas interfaces para los suscriptores empresariales.
Utilice las siguientes opciones para especificar si se requiere u opcional la activación correcta de estos servicios para el acceso de inicio de sesión del suscriptor:
required-at-login—Es necesario realizar la activación. Si se produce un error por cualquier motivo, se produce un error en la solicitud de activación de la familia de red para esa familia de redes. Si no hay ninguna otra familia de red activa para el suscriptor, la aplicación cliente cierra la sesión del suscriptor. Este es el comportamiento predeterminado para el tipo dedynamic-profileservicio.optional-at-login: la activación es opcional. Los errores debidos a errores de configuración no impiden la activación de la familia de direcciones; Permite el acceso de los suscriptores. Si se produce un error por cualquier otro motivo, se produce un error en la activación de la familia de redes. Si no hay ninguna otra familia de red activa para el suscriptor, la aplicación cliente cierra la sesión del suscriptor. Este es el comportamiento predeterminado para el tipo deextensible-serviceservicio.
Los fallos asociados con la activación de las políticas seguras de suscriptores (para reflejar el tráfico a un dispositivo de mediación) no tienen ningún efecto en el acceso de los suscriptores sujetos a la política.
Esta configuración no se aplica a los servicios activados mediante solicitudes RADIUS CoA, mensajes JSRC Push-Profile-Request (PPR) o políticas seguras de suscriptor.
Para el tipo de servicio, los errores de dynamic-profile configuración incluyen lo siguiente:
Errores de análisis del perfil dinámico y sus atributos.
Faltan variables de usuario obligatorias.
Referencias a perfiles dinámicos que no existen.
Errores de comprobación semántica en el perfil dinámico.
Para el tipo de servicio, los errores de extensible-service configuración incluyen lo siguiente:
Errores de análisis del script de operación.
Cometer errores.
Para activar un servicio, authd envía una solicitud de activación de los servicios adecuados a la infraestructura de gestión de suscriptores (SMI). Por ejemplo, si la solicitud es para la familia IPv4, solicita la activación solo de los servicios IPv4. A su vez, el SMI envía solicitudes a los demonios del servidor asociados con el servicio, como cosd o filtrado. Los resultados devueltos por los demonios determinan si la activación del servicio se realiza correctamente o se produce un error.
Cuando todos los demonios del servidor informan de que se han realizado correctamente, SMI informa del éxito a authd y se activa el servicio.
Si algún demonio de servidor informa de un error de configuración y ningún demonio informa de un error de no configuración, SMI informa de un error de configuración a authd. El servicio no está activado, pero dependiendo de la configuración, la activación de la familia de red puede realizarse correctamente.
Si algún demonio de servidor informa de un error de no configuración, SMI informa de un error de autenticación y el servicio no está activado.
Proceso de activación de la familia de servicios y redes
Cuando un suscriptor inicia sesión, authd tiene que activar la familia de direcciones correspondiente después de autenticar al suscriptor. La aplicación cliente, como DHCP o PPP, puede solicitar la activación de una única familia de red, IPv4 o IPv6, o puede solicitar secuencialmente que se activen ambas familias. La activación correcta de la familia de red está relacionada con la activación de los servicios asociados. Los pasos siguientes describen el proceso cuando authd está configurado para usar RADIUS para la autenticación:
Un suscriptor intenta iniciar sesión.
La aplicación cliente solicita autenticación de authd.
authd envía un mensaje de solicitud de acceso al servidor RADIUS.
El servidor RADIUS envía un mensaje de aceptación de acceso a authd que incluye el VSA del servicio de activación de RADIUS (26-65).
Authd almacena en caché los atributos de activación del servicio y envía una concesión a la aplicación cliente.
La aplicación cliente envía la primera solicitud Network-Family-Activate, ya sea para la familia de direcciones IPv4 o IPv6. Esta solicitud a veces se denomina solicitud de activación del cliente.
authd revisa los atributos de activación del servicio almacenado en caché y envía una solicitud de activación para los servicios adecuados a la infraestructura de administración de suscriptores (SMI). Por ejemplo, si la solicitud es para la familia IPv4, solicita la activación solo de los servicios IPv4. A su vez, el SMI envía solicitudes a los demonios del servidor asociados con el servicio, como cosd o filtrado.
Lo que authd haga a continuación depende de si se produce un error en la solicitud de activación del servicio y de si el servicio es opcional o obligatorio.
Cuando se produce un error en la activación del servicio debido a un error de configuración y el servicio es opcional:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía una ACK en respuesta a la solicitud de activación familiar y la familia se activa.
El inicio de sesión del suscriptor continúa.
Cuando se produce un error en la activación del servicio debido a un error de configuración y se requiere el servicio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía un NACK en respuesta a la activación de la familia, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando se produce un error en la activación del servicio debido a un error que no está relacionado con la configuración y el servicio es opcional o obligatorio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía un NACK en respuesta a la activación de la familia, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando la activación del servicio se realiza correctamente:
AUTHD activa el servicio.
authd envía una ACK en respuesta a la solicitud de activación familiar y la familia se activa.
El inicio de sesión del suscriptor continúa.
A menos que se requiera la activación del servicio y se produzca un error, lo que provoca un error en la activación familiar en la primera solicitud, la aplicación cliente puede enviar una segunda solicitud, pero solo para la familia que no se solicitó la primera vez. Si la primera solicitud fue para IPv4, la segunda solicitud solo puede ser para IPv6. Si la primera solicitud fue para IPv6, la segunda solicitud solo puede ser para IPv4.
AUTHD revisa los atributos de activación de servicio almacenados en caché y solicita la activación de los servicios asociados con la familia de direcciones solicitadas.
Lo que authd haga a continuación depende de si se produce un error en la solicitud de activación del servicio y de si el servicio es opcional o obligatorio.
Cuando se produce un error en la activación del servicio debido a un error de configuración y el servicio es opcional:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía una ACK en respuesta a la solicitud de activación familiar y la familia se activa.
El inicio de sesión del suscriptor continúa.
Cuando se produce un error en la activación del servicio debido a un error de configuración y se requiere el servicio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía un NACK en respuesta a la activación de la familia. Dado que esta es la segunda solicitud de activación familiar, el resultado de la primera activación familiar determina lo que sucede a continuación:
Si la primera activación familiar se realizó correctamente y ese suscriptor inició sesión, el error de la segunda solicitud no detiene el inicio de sesión del suscriptor actual. Este evento tampoco hace que authd cierre la sesión del suscriptor anterior (primera solicitud).
Si la primera activación familiar no se realizó correctamente, el error de la segunda solicitud hace que la aplicación cliente finalice el inicio de sesión del suscriptor actual.
Cuando se produce un error en la activación del servicio debido a un error que no está relacionado con la configuración y el servicio es opcional o obligatorio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencias del servicio con errores.
authd envía un NACK en respuesta a la activación de la familia, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando la activación del servicio se realiza correctamente:
AUTHD activa el servicio.
authd envía una ACK en respuesta a la solicitud de activación familiar y la familia se activa.
El inicio de sesión del suscriptor continúa.
Configuración de cómo los errores de activación del servicio afectan al inicio de sesión del suscriptor
Puede configurar cómo un error de activación de servicios opcionales durante el inicio de sesión del suscriptor afecta el resultado del inicio de sesión. Estos servicios opcionales son aquellos a los que hace referencia el VSA (26-65) del servicio de activación de RADIUS (26-65) que aparece en el mensaje de aceptación de acceso de RADIUS durante el inicio de sesión inicial del suscriptor.
Puede configurar estos dos tipos de activación de servicio para que sean obligatorios u opcionales.
dynamic-profile: Estos servicios se configuran en el perfil dinámico que aplica el perfil de acceso del abonado para proporcionar acceso y servicios de abonado para aplicaciones de banda ancha. De forma predeterminada, se requiere la activación del servicio para iniciar sesión correctamente. Un error de configuración durante la activación del servicio impide que se active la familia de red y provoca un error en el inicio de sesión del suscriptor.extensible-service: estos servicios se aplican mediante scripts de operación manejados por el demonio Administrador de servicios de suscriptor extensible (ESSM) (essmd) para suscriptores empresariales. De forma predeterminada, la activación del servicio es opcional para el inicio de sesión correcto del suscriptor.
La service-activation configuración de la instrucción sólo afecta a los errores de activación debidos a errores de configuración en el perfil dinámico o en el script de operación ESSM. Los fallos debidos a errores no relacionados con la configuración siempre provocan la denegación de acceso para el suscriptor y la finalización del intento de inicio de sesión.
Para configurar el comportamiento de los servicios de perfiles dinámicos, siga uno de estos procedimientos:
Especifique que la activación del servicio es opcional.
[edit access profile profile-name radius options service-activation] user@host# set dynamic-profile optional-at-login
Especifique que es necesaria la activación del servicio (valor predeterminado).
[edit access profile profile-name radius options service-activation] user@host# set dynamic-profile required-at-login
Para configurar el comportamiento de los servicios ESSM, siga uno de estos procedimientos:
Especifique que es necesaria la activación del servicio.
[edit access profile profile-name radius options service-activation] user@host# set extensible-service required-at-login
Especifique que la activación del servicio es opcional (valor predeterminado).
[edit access profile profile-name radius options service-activation] user@host# set extensible-service optional-at-login
Ver también
Códigos de causa de error (atributo RADIUS 101) para solicitudes dinámicas
Cuando una operación de CoA o desconexión iniciada por RADIUS no se realiza correctamente, el enrutador incluye un atributo de causa de error (atributo RADIUS 101) en el mensaje CoA-NAK o Disconnect-NAK que envía de vuelta al servidor RADIUS. Si el error detectado no se asigna a uno de los atributos de causa de error admitidos, el enrutador envía el mensaje sin un atributo de causa de error. En la tabla 4 se describen los códigos de causa de error.
Código |
Valor |
Descripción |
|---|---|---|
401 |
Atributo no compatible |
La solicitud contiene un atributo que no es compatible (por ejemplo, un atributo de terceros). |
402 |
Falta el atributo |
Falta un atributo crítico (por ejemplo, el atributo de identificación de sesión) en una solicitud. |
404 |
Solicitud no válida |
Algún otro aspecto de la solicitud no es válido, como si uno o más atributos no tienen el formato correcto. |
503 |
No se encontró el contexto de la sesión |
El contexto de sesión identificado en la solicitud no existe en el enrutador. |
504 |
El contexto de la sesión no se puede quitar |
El suscriptor identificado por los atributos de la solicitud es propiedad de un componente que no es compatible. |
506 |
Recursos no disponibles |
No se pudo cumplir una solicitud debido a la falta de recursos NAS disponibles (como la memoria). |
Ver también
Comprobación de estadísticas de solicitud dinámica de RADIUS
Propósito
Muestra estadísticas e información de solicitudes dinámicas de RADIUS.
Acción
Para mostrar estadísticas de solicitudes dinámicas de RADIUS:
user@host>show network-access aaa statistics dynamic-requests
Ver también
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.