EN ESTA PÁGINA
Descripción general de los perfiles dinámicos para interfaces de suscriptor PPP
Actualizaciones de estado de conexión de origen RADIUS a dispositivos CPE
Prevención de la validación de números mágicos de PPP durante los intercambios de keepalive de PPP
Cómo configurar las actualizaciones de estado de conexión de origen RADIUS para dispositivos CPE
Adjuntar perfiles dinámicos a interfaces de suscriptor PPP estáticas
Configuración de la autenticación dinámica para suscriptores PPP
Verificar y administrar la configuración de PPP para la administración de suscriptores
Descripción general de las redes de acceso de suscriptores PPP
Descripción general de los perfiles dinámicos para interfaces de suscriptor PPP
El soporte PPP de administración de suscriptores le permite crear y adjuntar perfiles dinámicos para interfaces de suscriptor PPP. Cuando el suscriptor PPP inicia sesión, el enrutador crea una instancia del perfil dinámico especificado y, luego, aplica los atributos definidos en el perfil a la interfaz.
Los perfiles dinámicos se utilizan para interfaces PPP estáticas y dinámicas. En el caso de las interfaces PPP estáticas, la CLI se utiliza para asociar perfiles dinámicos, los cuales especifican opciones PPP. En el caso de las interfaces PPP dinámicas, el perfil dinámico crea la interfaz, incluidas las opciones PPP.
Las interfaces creadas dinámicamente solo se admiten en interfaces PPPoE.
A diferencia del soporte PPP tradicional, la administración de suscriptores no permite la autenticación PPP bidireccional: la autenticación la realiza únicamente el enrutador, nunca el par remoto. El proceso AAA del enrutador administra la autenticación y la asignación de direcciones para la administración de suscriptores. Cuando configure las opciones de PPP para un perfil dinámico, puede configurar la autenticación del protocolo de autenticación por desafío mutuo (CHAP) o la autenticación del protocolo de autenticación por contraseña (PAP), y puede controlar el orden en que el enrutador negocia los protocolos CHAP y PAP. Además, para la autenticación CHAP, puede modificar la longitud predeterminada del mensaje de desafío CHAP. Otras opciones PPP, que son comúnmente utilizadas u obligatorias para una configuración de interfaz PPP tradicional, no son compatibles con los perfiles dinámicos de administración de suscriptores.
Comprender cómo el enrutador procesa las solicitudes de mantenimiento rápido de PPP iniciadas por el suscriptor
En enrutadores de la serie MX con concentradores de puerto modulares o tarjetas de interfaz modular (MPC/MIC), el motor de reenvío de paquetes de una MPC/MIC procesa y responde a los paquetes de solicitud de eco del protocolo de control de vínculo (LCP) que el suscriptor PPP (cliente) inicia y envía al enrutador. Los paquetes de solicitud de eco de LCP y los paquetes de respuesta de eco de LCP son parte del mecanismo de keepalive de PPP que ayuda a determinar si un vínculo funciona correctamente.
Anteriormente, el motor de enrutamiento manejaba los paquetes de solicitud de eco LCP y los paquetes de respuesta de eco LCP en un enrutador de la serie MX. El mecanismo por el cual los paquetes de solicitud de eco LCP son procesados por el motor de reenvío de paquetes en lugar de por el motor de enrutamiento se conoce como keepalives rápidos PPP.
- Beneficios de las Señales de Mantenimiento Rápido PPP
- Cómo funciona el procesamiento rápido de keepalive de PPP
- Visualización de estadísticas para PPP Fast Keepalive
- Efecto de cambiar la configuración de la clase de reenvío
- Ignorar una discordancia de números mágicos
Beneficios de las Señales de Mantenimiento Rápido PPP
Las señales de mantenimiento rápido PPP reducen el tiempo requerido para los intercambios de mantenimiento al permitir que el motor de reenvío de paquetes reciba paquetes LCP Echo-Request del suscriptor PPP y responda con paquetes LCP Echo-Respond, sin tener que enviar los paquetes LCP al motor de enrutamiento para su procesamiento.
Las señales de mantenimiento rápido PPP proporcionan un mayor ancho de banda en el enrutador para admitir un mayor número de suscriptores con un rendimiento mejorado al liberar al motor de enrutamiento de tener que procesar los paquetes de solicitud de eco y respuesta de eco de LCP.
Las señales de mantenimiento rápido de PPP utilizan números mágicos negociados para identificar posibles circuitos cerrados de tráfico al enrutador o problemas de red. También puede deshabilitar la validación si es necesario para evitar la terminación no deseada de la sesión PPP, por ejemplo, cuando los pares remotos de PPP utilizan números arbitrarios en lugar del número negociado.
Cómo funciona el procesamiento rápido de keepalive de PPP
No necesita ninguna configuración especial en un enrutador de la serie MX con MPC/MIC para habilitar el procesamiento de solicitudes de mantenimiento rápido de PPP en el motor de reenvío de paquetes. La función está habilitada de forma predeterminada y no se puede deshabilitar.
La siguiente secuencia describe cómo un enrutador de la serie MX procesa los paquetes de solicitud de eco de LCP y los paquetes de respuesta de eco de LCP en el motor de reenvío de paquetes en la MPC/MIC:
El motor de enrutamiento notifica al motor de reenvío de paquetes cuando la transmisión de solicitudes de keepalive está habilitada en una interfaz lógica PPP. La notificación incluye los números mágicos del servidor y del cliente remoto.
El motor de reenvío de paquetes recibe el paquete LCP Echo-Request iniciado por el suscriptor PPP (cliente).
El motor de reenvío de paquetes valida el número mágico par en el paquete LCP Echo-Request y transmite el paquete LCP Echo-Reply correspondiente que contiene el número mágico negociado por el enrutador.
Si el motor de reenvío de paquetes detecta una condición de bucle en el vínculo, envía el paquete de solicitud de eco LCP al motor de enrutamiento para su posterior procesamiento.
El motor de enrutamiento continúa procesando paquetes de solicitud de eco LCP hasta que se borra la condición de bucle.
La transmisión de solicitudes de keepalive desde el motor de reenvío de paquetes en el enrutador no está habilitada actualmente.
Visualización de estadísticas para PPP Fast Keepalive
Cuando un enrutador de la serie MX con MPC/MIC utiliza keepalive rápido PPP para un vínculo PPP, el Keepalive statistics campo de la salida del show interfaces pp0.logical statistics comando operativo no incluye estadísticas del número de paquetes de keepalive recibidos o enviados, ni de la cantidad de tiempo transcurrido desde que el enrutador recibió o envió el último paquete de keepalive.
Efecto de cambiar la configuración de la clase de reenvío
Para cambiar la asignación de cola predeterminada (clase de reenvío) para el tráfico saliente generado por el motor de enrutamiento, puede incluir la forwarding-class class-name instrucción en el [edit class-of-service host-outbound-traffic] nivel de jerarquía.
Para PPP paquetes de solicitud de eco LCP rápida (en línea) y replicación de eco LCP transmitidos entre un enrutador de la serie MX con MPC/MIC y un cliente PPP, el cambio de la configuración de clase de reenvío surte efecto inmediatamente para las nuevas sesiones de suscriptor PPP sobre Ethernet (PPPoE), PPP sobre ATM (PPPoA) y L2TP network server (LNS) creadas después del cambio de configuración, y para PPPoE, PPPoA existentes, y las sesiones de suscriptor de LNS establecidas antes del cambio de configuración.
Ignorar una discordancia de números mágicos
Cuando el motor de reenvío de paquetes valida el número mágico par en el paquete LCP Echo-Request recibido, comprueba si el número mágico es inesperado. El número recibido debe coincidir con el número del par remoto acordado durante la negociación del LCP. El número del par remoto debe ser distinto del número del par local; Cuando son iguales, la expectativa es que exista una condición de circuito cerrado (el tráfico vuelve al par local) o algún otro problema de red.
Cuando la comprobación de validación determina que hay una discrepancia, lo que significa que el número del par remoto recibido es distinto del número negociado, el motor de reenvío de paquetes envía los paquetes de respuesta de eco con errores al motor de enrutamiento. Si no se recibe una respuesta de eco con un número mágico válido dentro de un intervalo determinado, PPP considera que se trata de una falla de mantenimiento y desactiva la sesión PPP.
Es posible que algunos equipos de clientes no negocien su número mágico local y, en su lugar, inserten un valor arbitrario como el número mágico que envía al enrutador en los paquetes keepalive. Este número se identifica como una discrepancia y la sesión finalmente se descarta. A partir de la versión 18.1R1 de Junos OS, este resultado se puede evitar configurando el enrutador para que no realice una comprobación de validación de números mágicos. Dado que nunca se identifica la discordancia, el enrutador sigue intercambiando paquetes PPP keepalive con el par remoto. Para configurar este comportamiento, incluya la ignore-magic-number-mismatch instrucción en un perfil de grupo L2TP, en el perfil dinámico para conexiones dinámicas de suscriptor PPP terminadas en el enrutador o en el perfil dinámico para suscriptores PPP con túnel dinámico en LNS.
Ver también
Actualizaciones de estado de conexión de origen RADIUS a dispositivos CPE
A partir de la versión 20.2R1 de Junos OS, puede utilizar mensajes de origen de RADIUS para transmitir información que el BNG reenvía de forma transparente a un dispositivo CPE, como una puerta de enlace doméstica. Por ejemplo, esta información puede ser el ancho de banda ascendente o algún otro parámetro de velocidad de conexión que necesite el dispositivo CPE. Esta capacidad es útil cuando desea aplicar dinámicamente la administración del tráfico lo más cerca posible de los suscriptores.
Normalmente, puede utilizar el atributo estándar RADIUS Reply-Message (18) para transmitir esta información al dispositivo CPE durante la autenticación PPP. Sin embargo, si ya está usando ese atributo para otra cosa, también puede usar el VSA de mensajes de estado de conexión de Juniper Networks (26-4874-218). Este VSA es una extensión lógica del atributo Reply-Message (18) y tiene el mismo formato y semántica.
PPP utiliza una extensión específica del proveedor de Juniper Networks a LCP para enviar el contenido del VSA de mensaje de estado de conexión a la puerta de enlace doméstica del par. PPP incluye esta información en la opción Connection-Status-Message de un mensaje LCP Connection-Update-Request.
RADIUS puede enviar el VSA Connection-Status-Message a authd de las siguientes maneras:
-
En el mensaje de aceptación de acceso de RADIUS durante la negociación y autorización de una sesión PPP
-
En una solicitud de CoA de RADIUS en cualquier momento para una sesión PPP activa
Puede utilizar ambos métodos para cualquier sesión determinada para suscriptores empresariales o residenciales. El mensaje Access-Accept proporciona los parámetros de conexión iniciales. La capacidad CoA le permite actualizar los parámetros de velocidad de conexión según sea necesario a lo largo de la vida de una sesión. La información que se incluye en el VSA de mensaje de estado de conexión suelen ser tasas de tráfico aplicadas por la configuración local, como un perfil de servicio dinámico o el mensaje de puerto ascendente de ANCP correspondiente.
Si no incluye la lcp-connection-update opción PPP en el perfil de cliente dinámico, PPP procesa la notificación de authd, pero no realiza ninguna acción. Si LCP en el enrutador no está en el estado Abierto, PPP no realiza ninguna acción en VSA.
Los siguientes pasos describen lo que sucede cuando RADIUS envía el VSA en un mensaje de aceptación de acceso:
-
El proceso authd recibe el VSA Connection-Status-Message en un mensaje Access-Accept del servidor RADIUS.
-
El proceso authd envía el VSA Connection-Status-Message a PPP (jpppd).
-
PPP La negociación NCP tiene lugar entre el cliente PPP de puerta de enlace remota y PPP en el enrutador.
-
La negociación exitosa da como resultado una solicitud de activación familiar. La sesión PPP entra en el estado de sesión ascendente cuando se activa la familia.
-
Si el perfil de cliente dinámico incluye la
lcp-connection-updateopción PPP y LCP en el enrutador está en estado Abierto, PPP envía un mensaje LCP Connection-Update-Request a la puerta de enlace. Este mensaje incluye la información de VSA en la opción Connection-Status-Message.-
Si la puerta de enlace admite la LCP Connection-Update-Request, devuelve un mensaje LCP Connection-Update-Ack al enrutador. La LCP de la puerta de enlace doméstica debe estar en el estado Abierto cuando recibe la solicitud, de lo contrario descarta la solicitud.
-
Si la puerta de enlace no admite la solicitud de actualización de conexión LCP, devuelve un mensaje de rechazo de código LCP al enrutador.
Nota:Si la puerta de enlace no responde, el enrutador vuelve a intentar la solicitud de actualización. Utiliza los valores predeterminados de PPP de hasta un máximo de 10 reintentos con un intervalo de 3 segundos entre los intentos.
Nota:Si no incluye la
lcp-connection-updateopción PPP en el perfil de cliente dinámico, PPP procesa la notificación de authd, pero no realiza ninguna acción. Si la opción está presente pero LCP en el enrutador no está en el estado Abierto, PPP no realiza ninguna acción con respecto al VSA. -
Los siguientes pasos describen lo que sucede cuando RADIUS envía el VSA en una solicitud de CoA. Esto supone que la negociación del NCP ya se realizó correctamente y que la sesión está activa.
-
El proceso authd recibe el VSA Connection-Status-Message en una solicitud CoA del servidor RADIUS.
-
El proceso authd envía el VSA Connection-Status-Message a PPP (jpppd).
-
Si el perfil de cliente dinámico incluye la
lcp-connection-updateopción PPP y LCP en el enrutador está en estado Abierto, PPP envía un mensaje LCP Connection-Update-Request a la puerta de enlace. Este mensaje incluye la información de VSA en la opción Connection-Status-Message.-
Si la puerta de enlace admite la LCP Connection-Update-Request, devuelve un mensaje LCP Connection-Update-Ack al enrutador. La LCP de la puerta de enlace doméstica debe estar en el estado Abierto cuando recibe la solicitud, de lo contrario descarta la solicitud.
-
Si la puerta de enlace no admite la solicitud de actualización de conexión LCP, devuelve un mensaje de rechazo de código LCP al enrutador.
Nota:Si la puerta de enlace no responde, el enrutador vuelve a intentar la solicitud de actualización. Utiliza los valores predeterminados de PPP de hasta un máximo de 10 reintentos con un intervalo de 3 segundos entre los intentos.
-
Si la puerta de enlace doméstica no recibe un mensaje de solicitud de actualización de conexión, el enrutador vuelve a intentar enviar el mensaje. El enrutador también vuelve a intentar la solicitud cuando no recibe un reconocimiento de actualización de conexión o un rechazo de código LCP de la puerta de enlace, o cuando hay algún problema con el mensaje de confirmación. El intervalo de reintento predeterminado es de 3 segundos. El enrutador volverá a intentar el mensaje hasta el valor predeterminado 10 veces antes de que se cierre. Si el enrutador agota todos los intentos de reintento sin recibir un mensaje Connection-Update-Ack adecuado, registra el mensaje como si hubiera recibido un mensaje PPP Code-Reject.
RADIUS puede incluir varias instancias del VSA Connection-Status-Message en el mensaje Access-Accept o en una solicitud CoA. Si esto ocurre, authd usa solo la primera instancia e ignora cualquier otra.
Las solicitudes Access-Accept o CoA pueden contener otros atributos además del VSA Connection-Status-Message, pero no hay interdependencia entre el VSA y ningún otro atributo. Esto es cierto incluso cuando el mensaje incluye los VSA Activate-Service (26-65) o Deactivate-Service (26-66). La falta de dependencia significa que incluso si authd no aplica con éxito los otros atributos, aún envía la información de conexión a PPP, que a su vez envía el contenido de VSA a la puerta de enlace de inicio.
Del mismo modo, authd aplica cualquier otro atributo y devuelve una respuesta CoA independientemente de si PPP comunica correctamente el contenido del VSA Connection-Status-Message a la puerta de enlace remota. Esto es cierto incluso cuando la CoA contiene solo el VSA de mensaje de estado de conexión. Esta capacidad es necesaria porque no todas las puertas de enlace aceptarán la extensión LCP utilizada en esta función.
Formatos de mensajes y opciones
La Figura 1 muestra el formato de los mensajes Connection-Update-Request y Connection-Update-Ack. Los formatos son los mismos, pero el Cuadro 1muestra que algunos valores de campo son diferentes para los dos mensajes.
| Campo |
Solicitud de actualización de conexión |
conexión-actualización-reconocimiento |
|---|---|---|
| Código |
0 para proveedores específicos |
0 para proveedores específicos |
| Identificador |
Identificador del paquete específico del proveedor |
El mismo identificador que en el mensaje de solicitud de actualización de conexión. Si este valor no coincide, el enrutador registra el error y descarta el paquete. Esto permite volver a intentar el mensaje de solicitud, como si la puerta de enlace no lo hubiera recibido. |
| Longitud |
Número de bytes en el paquete: 12 más la longitud de la opción Connection-Status-Message |
Número de bytes en el paquete Connection-Update-Ack: 12 |
| Número mágico |
Valor negociado para el número mágico de PPP local |
Valor negociado para el número mágico de PPP local |
| Identificador único organizacional (OUI) |
21/00/59 para Juniper Networks |
21/00/59 para Juniper Networks |
| Amable |
1 para actualización de sesión |
2 para reconocimiento de sesión. Para cualquier otro valor, el enrutador registra el error y descarta el paquete. Esto permite volver a intentar el mensaje de solicitud, como si la puerta de enlace no lo hubiera recibido. |
| Valores |
Opción Connection-Status-Message en formato TLV |
No se admite ningún valor |
Puede configurar cómo se utilizan los números mágicos de PPP.
-
Si configura
ignore-magic-number-mismatchla opción PPP, está impidiendo que se validen los números mágicos. PPP ignora una discrepancia entre los números mágicos de la solicitud y los mensajes Ack. Si no hay otros errores de validación, PPP acepta el mensaje Connection-Update-Ack. -
Si no configura
ignore-magic-number-mismatchla opción PPP, los números mágicos pasan por la validación. Si el número mágico del mensaje Ack no coincide con el número mágico de la puerta de enlace establecido durante la negociación LCP, el enrutador registra el error y descarta el mensaje Connection-Update-Ack como una respuesta no válida. Esto permite volver a intentar el mensaje de solicitud, como si la puerta de enlace no lo hubiera recibido.
Consulte Prevención de la validación de números mágicos PPP durante intercambios PPP Keepalive para obtener más información sobre los números mágicos.
La Figura 2 muestra el formato de las opciones Connection-Status-Message. En la tabla 2 se enumeran los valores de campo.
| Campo |
Valor |
|---|---|
| Tipo |
1 |
| Longitud |
Número de bytes en la opción; 2 más la longitud del mensaje. La longitud del mensaje puede ser de 1 a 247 bytes. |
| Mensaje de estado |
Contenido del VSA de mensaje de estado de conexión |
Configurar perfiles dinámicos para PPP
Un perfil dinámico actúa como una plantilla que le permite crear, actualizar o eliminar una configuración que incluye atributos de acceso de cliente (como interfaz o protocolo) o servicio (como IGMP). Con los perfiles dinámicos, puede consolidar todos los atributos comunes de un cliente (y, eventualmente, de un grupo de clientes) y aplicar los atributos simultáneamente.
Después de crear los perfiles dinámicos, estos residen en una biblioteca de perfiles en el enrutador. A continuación, puede utilizar la dynamic-profile instrucción para asociar perfiles a interfaces. Para asignar un perfil dinámico a una interfaz PPP, puede incluir la dynamic-profile instrucción en el nivel de [edit interfaces interface-name unit logical-unit-number ppp-options] jerarquía:
[edit interfaces interface-name unit logical-unit-number ppp-options] dynamic-profile profile-name;
Para supervisar la configuración, ejecute el show interfaces interface-name comando.
Para obtener más información acerca de los perfiles dinámicos, consulte Descripción general de perfiles dinámicos en la Guía de configuración de acceso de suscriptor de Junos.
Para obtener información acerca de cómo crear perfiles dinámicos, consulte Configuración de un perfil dinámico básico en la Guía de configuración de acceso de suscriptor de Junos.
Para obtener información acerca de cómo asignar un perfil dinámico a una interfaz PPP, consulte Asociar perfiles dinámicos a interfaces de suscriptor PPP estáticas en la Guía de configuración de acceso de suscriptor de Junos.
Para obtener información sobre el uso de perfiles dinámicos para autenticar suscriptores PPP, consulte Configuración de autenticación dinámica para suscriptores PPP.
Los perfiles dinámicos para suscriptores PPP solo se admiten en interfaces PPPoE para esta versión.
Prevención de la validación de números mágicos de PPP durante los intercambios de keepalive de PPP
Los números mágicos de PPP se negocian entre pares durante la negociación de LCP. Los pares deben tener números mágicos diferentes. Cuando los números son iguales, indica que puede haber un circuito cerrado en el tráfico enviado por el par local. En este caso, el par local envía un nuevo número al par remoto. Si el número mágico devuelto por el par remoto es diferente del último número enviado por el par local, entonces los números se acuerdan. De lo contrario, el intercambio de números mágicos continúa hasta que se recibe un número válido (diferente) o se agota el tiempo de espera del proceso, en cuyo caso se interrumpe la sesión.
Una vez acordados los números, los pares incluyen sus respectivos números mágicos cuando intercambian paquetes PPP keepalive (Echo-Request/Echo-Reply). El motor de reenvío de paquetes valida el número mágico recibido para cada intercambio. Se produce una discrepancia cuando el número mágico de PPP recibido del par remoto no coincide con el valor acordado durante la negociación de LCP. Cuando la comprobación de validación determina que hay una discrepancia, el motor de reenvío de paquetes envía el paquete de solicitud de eco con errores al motor de enrutamiento. Si no se recibe una respuesta de eco con un número mágico válido dentro de un intervalo determinado, PPP considera que se trata de una falla de mantenimiento y desactiva la sesión PPP.
En algunas circunstancias, este comportamiento no es deseable. Algunos equipos de clientes no negocian su número mágico local; En su lugar, inserta un valor arbitrario como el número mágico que envía al enrutador en los paquetes keepalive. De forma predeterminada, este número se identifica como una discrepancia y la sesión se interrumpe finalmente. Este resultado puede evitarse impidiendo que el motor de reenvío de paquetes realice la comprobación de validación del número mágico. Dado que nunca se identifica la discordancia, el enrutador sigue intercambiando paquetes PPP keepalive con el par remoto.
Deshabilite la comprobación de validación de números mágicos incluyendo la ignore-magic-number-mismatch instrucción como una de las opciones PPP aplicadas en un perfil PPP dinámico, un perfil dinámico LNS L2TP o un perfil de grupo L2TP. La configuración de esta instrucción no tiene ningún efecto en la negociación del número mágico de LCP ni en el intercambio de señales de mantenimiento cuando el número mágico del par remoto es el número negociado esperado.
Dado que no se realiza la validación del número mágico, el motor de reenvío de paquetes no detecta si el par remoto envía el número mágico del par local, lo que indicaría un circuito cerrado u otro problema de red. Esta se considera una situación poco probable, porque la negociación de LCP se completó con éxito, lo que significa que no había ningún circuito cerrado en ese momento.
Para configurar perfiles dinámicos a fin de evitar que el motor de reenvío de paquetes detecte errores coincidencia en los números mágicos:
Configure la opción PPP.
Para conexiones dinámicas de suscriptor PPP terminadas en el enrutador:
[edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
Para suscriptores de PPP con túnel dinámico en interfaces de servicio en línea LNS:
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
Puede usar el show ppp interface interface-name extensive comando para ver si se ignoran los números mágicos.
Cómo configurar las actualizaciones de estado de conexión de origen RADIUS para dispositivos CPE
Puede usar mensajes de origen de RADIUS para transmitir información que el BNG reenvía de forma transparente a un dispositivo CPE, como una puerta de enlace doméstica. Por ejemplo, esta información puede ser el ancho de banda ascendente o algún otro parámetro de velocidad de conexión que necesite el dispositivo CPE.
Cuando habilita esta característica, PPP puede actuar en un VSA de mensaje de estado de conexión (26–218) recibido por authd en un mensaje de aceptación de acceso de RADIUS o en un mensaje CoA. A continuación, PPP transmite el contenido del VSA en un mensaje de solicitud de actualización de conexión LCP al par remoto. Esta acción requiere que se cumpla lo siguiente:
Al menos la primera familia de direcciones se ha negociado con éxito y la sesión está activa.
El LCP del enrutador está en estado Abierto.
De lo contrario, PPP no toma ninguna medida sobre el VSA. Si no habilita la lcp-connection-update opción, PPP procesa la notificación de authd, pero no realiza ninguna acción.
Esta capacidad se configura en el perfil de cliente dinámico asociado a los suscriptores que utilizan el dispositivo CPE. En la práctica, está agregando esto a muchas otras funciones en el perfil del cliente. En este ejemplo, solo se muestra la configuración específica de esta función. Esta función también requiere que configure VSA 26-218 en su servidor RADIUS; Eso está fuera del alcance de esta documentación.
Para configurar las actualizaciones de estado de conexión en un perfil dinámico para interfaces de suscriptor PPP:
Puede utilizar el comando de la interfaz lógica PPP para determinar si las actualizaciones de show ppp interface extensive conexión LCP se realizan correctamente. Puede supervisar las estadísticas relevantes con el show system subscriber-management statistics ppp comando.
Adjuntar perfiles dinámicos a interfaces de suscriptor PPP estáticas
Puede adjuntar un perfil dinámico a una interfaz de suscriptor PPP estática. Cuando un suscriptor PPP inicia sesión, se crea una instancia del perfil dinámico especificado y los servicios definidos en el perfil se aplican a la interfaz.
Para adjuntar un perfil dinámico a una interfaz de suscriptor PPP estática:
Descripción general de la migración de configuraciones de suscriptor PPP estático a perfiles dinámicos
En este tema se tratan varias consideraciones para migrar ciertas configuraciones de suscriptor PPP IPv4 estáticas y terminadas a configuraciones dinámicas mediante perfiles dinámicos. Los proveedores de servicios que administran suscriptores estáticos en enrutadores con versiones heredadas de Junos OS (anteriores a la versión 15.1R4 de Junos OS) tienen requisitos para migrar sus suscriptores estáticos para que se administren con perfiles dinámicos en enrutadores que ejecutan administración de suscriptores mejorada (versión 15.1R4 de Junos OS y versiones posteriores). A partir de la versión 18.2R1 de Junos OS, se agregaron varias mejoras para facilitar la transición de estas configuraciones estáticas de proveedor de servicios a perfiles dinámicos.
Autenticación local
Algunos proveedores con configuraciones estáticas pueden usar dispositivos CPE que no admiten ningún protocolo de autenticación, ni siquiera CHAP o PAP. Los proveedores pueden utilizar tablas de nombres de servicio PPPoE como un método rudimentario para autenticar y autorizar a los suscriptores en interfaces lógicas PPPoE estáticas. Si el suscriptor ACI o ARI no coinciden con una entrada de tabla, entonces los paquetes PPP PADI y PADR generalmente se descartan. Las versiones heredadas de Junos OS no admiten suscriptores configurados con no-authentication para el método de autenticación.
Para los suscriptores en los que el CPE no admite protocolos de autenticación como PAP y CHAP, puede configurar los nombres de usuario y contraseñas localmente. El enrutador utiliza estos valores cuando se pone en contacto con el servidor de RADIUS para la autenticación.
Para configurar el nombre de usuario para la autenticación local, incluya la
username-includeinstrucción en las opciones PPP para la interfaz lógica dinámica. Puede definir el nombre en función de uno o varios de los siguientes atributos: dirección MAC, ID de circuito del agente, ID remoto del agente y nombre de dominio. De forma predeterminada, un punto (.) es el delimitador entre los elementos del nombre, pero puede definir otros caracteres en su lugar.Para configurar la contraseña para la autenticación local, incluya la
passwordinstrucción en las opciones de PPP para la interfaz lógica dinámica.
Puede usar el mismo perfil dinámico para admitir tanto CPE que no admiten un protocolo de autenticación como CPE que sí lo hacen.
Asignación de direcciones de origen CPE
Para algunas configuraciones estáticas, la dirección del suscriptor no se asigna mediante RADIUS o un conjunto de direcciones local en el enrutador. En su lugar, el CPE tiene una dirección estática configurada para el suscriptor; durante la negociación IPCP, el CPE solicita al enrutador que asigne esa dirección al suscriptor.
A partir de Junos OS versión 18.2R1, puede asignar una dirección comodín de 255.255.255.255 al atributo Framed-Route-Address [8] en la configuración del servidor RADIUS. Cuando RADIUS devuelve el atributo con ese valor, jpppd acepta automáticamente la asignación de dirección IP del suscriptor proporcionada por el cliente en un mensaje de solicitud de configuración IPCP en lugar de asignar otra dirección.
Atributo de ruta Tag2
En algunas configuraciones, las interfaces de suscriptor PPP estáticas se configuran en VRF diferentes. Cada configuración VRF tiene rutas estáticas que apuntan a interfaces de suscriptores PPP estáticas como la dirección de salto siguiente. Estas rutas pueden tener configurado el atributo tag2; MP-BGP requiere que aplique la preferencia local y la comunidad adecuadas cuando anuncie las rutas.
A partir de Junos OS versión 18.2R1, puede configurar el servidor RADIUS para que incluya el atributo tag2 en el atributo Framed-Route [22] cuando autentifique a un suscriptor.
También debe configurar el perfil dinámico para derivar el valor tag2 del atributo Framed-Route. Para ello, especifique la variable predefinida $junos-framed-route-tag2 que se utilizará cuando se cree una instancia dinámica de la ruta de acceso. Como alternativa, puede configurar el perfil dinámico para proporcionar un valor tag2 específico para un prefijo de ruta de acceso específico.
Consulte Variables predefinidas de Junos OS para obtener más información sobre las variables predefinidas.
Beneficios
La autenticación local permite la autenticación con contraseñas y nombres de usuario almacenados localmente para suscriptores cuando el CPE no admite protocolos de autenticación como PAP y CHAP.
La asignación de direcciones de origen de CPE permite que el enrutador acepte direcciones IP de suscriptor configuradas estáticamente solicitadas por el CPE en lugar de asignar la dirección de un conjunto de direcciones de origen local o externo.
El atributo tag2 permite una especificación más detallada de las rutas.
Configuración de la autenticación local en perfiles dinámicos para suscriptores PPP IPv4 terminados estáticamente
Algunos proveedores con configuraciones estáticas pueden usar dispositivos CPE que no admiten ningún protocolo de autenticación, ni siquiera CHAP o PAP. Los proveedores pueden utilizar tablas de nombres de servicio PPPoE como un método rudimentario para autenticar y autorizar a los suscriptores en interfaces lógicas PPPoE estáticas. Si el suscriptor ACI o ARI no coincide con una entrada de tabla, entonces los paquetes PPP PADI y PADR generalmente se descartan.
A partir de Junos OS versión 18.2R1, puede configurar nombres de usuario y contraseñas localmente para clientes que no admitan protocolos de autenticación como PAP y CHAP. El enrutador utiliza estos valores cuando se pone en contacto con el servidor de RADIUS para la autenticación. Esto ayuda en la migración de los suscriptores estáticos al uso de perfiles dinámicos en un enrutador que ejecuta una administración mejorada de suscriptores.
Para configurar la autenticación local:
El nombre de usuario adopta el formato siguiente cuando se incluyen todas las opciones y se utiliza el delimitador predeterminado:
mac-address.circuit-id.remote-id@domain-name
Por ejemplo, considere la siguiente configuración de ejemplo, donde ACI es aci1002, ARI es ari349 y la dirección MAC es 00:00:5e:00:53:ff:
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" ppp-options local-authentication] user@host# set username-include circuit-id user@host# set username-include remote-id user@host# set username-include mac-address user@host# set username-include domain-name example.com user@host# set username-include delimiter - user@host# set password $ABC123$ABC123
Esta configuración da como resultado una contraseña local de $ABC 123$ABC123 para el siguiente nombre de usuario local único:
0000.5e00.53ff-aci1002-ari349@example.com
Configuración de atributos de etiqueta2 en perfiles dinámicos para suscriptores PPP IPv4 terminados estáticamente
En algunas configuraciones, los suscriptores PPP utilizan rutas estáticas con un atributo tag2. Por ejemplo, MP-BGP utiliza tag2 para poder aplicar las preferencias locales y la comunidad adecuadas cuando anuncia rutas. Cuando migre a estos suscriptores para usar perfiles dinámicos en un enrutador que ejecute administración de suscriptores mejorada, puede configurar el atributo tag2 configurando un valor específico para una ruta o derivando el valor desde un servidor RADIUS. Esta compatibilidad está disponible por primera vez en Junos OS versión 18.2R1.
Para configurar un valor tag2 específico para una ruta:
Especifique el valor.
[edit dynamic-profiles profile-name routing-options access route prefix] user@host# set tag2 route-tag2
Para derivar el valor tag2 de un servidor RADIUS:
Configure el servidor RADIUS para incluir el atributo tag2 en el atributo Framed-Route [22] cuando autentique a un suscriptor. Consulte la documentación del servidor RADIUS para obtener información de configuración. La configuración puede ser similar al siguiente ejemplo:
user@sub.example.com User-Password := "$ABC123" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Route += "198.51.100.0/24 203.0.113.27 tag 5 distance 10 tag2 3"
Configure el perfil dinámico para utilizar la variable predefinida $junos-framed-route-tag2 para derivar dinámicamente el valor tag2 del atributo Framed-Route.
[edit dynamic-profiles profile-name routing-options access route "$junos-framed-route-ip-address-prefix] user@host# set tag2 $junos-framed-route-tag2
La variable predefinida $junos-framed-route-ip-address-prefix deriva el prefijo de dirección IPv4 para la ruta de acceso del atributo Framed-Route también.
Configuración de la autenticación dinámica para suscriptores PPP
Puede configurar un perfil dinámico que incluya autenticación PPP que permita a los clientes PPP acceder dinámicamente a la red. Puede especificar la autenticación CHAP o PAP. Opcionalmente, también puede controlar el orden en que el enrutador negocia los protocolos CHAP y PAP.
En el caso de las interfaces dinámicas, el enrutador solo admite la autenticación unidireccional; el enrutador siempre funciona como autenticador. Cuando se configura la autenticación PPP en un perfil dinámico, la autenticación CHAP admite la challenge-length opción, que permite configurar la longitud mínima y la longitud máxima del mensaje de desafío CHAP. Ni la autenticación CHAP ni la autenticación PAP admiten ninguna otra opción de configuración, incluida la passive instrucción.
Los perfiles dinámicos para suscriptores PPP solo se admiten en interfaces PPPoE.
Para configurar la autenticación en un perfil dinámico para interfaces de suscriptor PPP:
Modificación de la duración del desafío CHAP
Puede modificar la longitud mínima y máxima predeterminadas del mensaje de desafío del Protocolo de autenticación de desafío mutuo (CHAP) que el enrutador envía a un cliente PPP. El mensaje de desafío CHAP, que contiene información que es exclusiva de una sesión de suscriptor PPP en particular, se utiliza como parte del mecanismo de autenticación entre el enrutador y el cliente para comprobar la identidad del cliente para acceder al enrutador.
De forma predeterminada, la longitud mínima del desafío CHAP es de 16 bytes y la longitud máxima es de 32 bytes. Puede anular este valor predeterminado para configurar la longitud mínima y máxima del desafío CHAP en el intervalo de 8 bytes a 63 bytes.
Le recomendamos que configure tanto la longitud mínima como la longitud máxima del desafío CHAP en al menos 16 bytes.
Antes de empezar:
Configure el protocolo CHAP en la interfaz.
Para interfaces dinámicas de suscriptor PPP, consulte Configuración de autenticación dinámica para suscriptores PPP.
Para interfaces estáticas con encapsulación PPP, consulte Configuración del protocolo de autenticación por desafío PPP.
Para configurar la longitud mínima y máxima del mensaje de desafío CHAP:
Ejemplo: Perfil dinámico PPPoE mínimo
En este ejemplo, se muestra la configuración mínima de un perfil dinámico que se utiliza para interfaces PPPoE estáticas. La configuración debe incluir la interfaces pp0 estrofa.
dynamic-profiles {
ppp-profile-1 {
interfaces {
pp0 {
unit "$junos-interface-unit";
}
}
}
}
Verificar y administrar la configuración de PPP para la administración de suscriptores
Propósito
Vea o borre información sobre la configuración de PPP para la administración de suscriptores.
Acción
Para mostrar información sobre interfaces PPP:
user@host> show ppp interface
Para mostrar información de estadísticas PPP:
user@host> show ppp statistics
Para mostrar información de resumen de sesión PPP:
user@host> show ppp summary
Para mostrar información de conjunto de direcciones PPP:
user@host>show ppp address-pool
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.