EN ESTA PÁGINA
Descripción general de los perfiles dinámicos para interfaces de suscriptor PPP
Actualizaciones del estado de conexión de origen RADIUS para dispositivos CPE
Prevención de la validación de números mágicos PPP durante los intercambios PPP Keepalive
Cómo configurar 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
Administración de suscriptores La compatibilidad con PPP 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, a continuación, aplica los atributos definidos en el perfil a la interfaz.
Los perfiles dinámicos se utilizan para interfaces PPP estáticas y dinámicas. Para las interfaces PPP estáticas, la CLI se usa para adjuntar perfiles dinámicos, que especifican las opciones de PPP. Para 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 es realizada solo por el enrutador, nunca por el par remoto. El proceso AAA del enrutador administra la autenticación y la asignación de direcciones para la administración de suscriptores. Al configurar las opciones PPP para un perfil dinámico, puede configurar la autenticación del Protocolo de autenticación por desafío mutuo (CHAP) o del Protocolo de autenticación de 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 de PPP, que se usan habitualmente o son obligatorias para una configuración de interfaz PPP tradicional, no se admiten en 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 los enrutadores de la serie MX con concentradores de puertos modulares/tarjetas de interfaz modular (MPC/MIC), el motor de reenvío de paquetes en un MPC/MIC procesa y responde a los paquetes de solicitud de eco del Protocolo de control de vínculo (LCP) que el suscriptor (cliente) PPP inicia y envía al enrutador. Los paquetes LCP Echo-Request y LCP Echo-Reply forman parte del mecanismo PPP keepalive que ayuda a determinar si un vínculo funciona correctamente.
Anteriormente, los paquetes de solicitud de eco LCP y los paquetes de respuesta de eco LCP se manejaban en un enrutador de la serie MX mediante el motor de enrutamiento. 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 conservaciones rápidas PPP.
- Beneficios de PPP Fast Keepalives
- Cómo funciona el procesamiento rápido 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 discrepancia de números mágicos
Beneficios de PPP Fast Keepalives
Las conservaciones rápidas PPP reducen el tiempo requerido para los intercambios keepalive al permitir que el motor de reenvío de paquetes reciba paquetes de solicitud de eco LCP del suscriptor PPP y responda con paquetes de respuesta de eco LCP, sin tener que enviar los paquetes LCP al motor de enrutamiento para su procesamiento.
Las conservaciones rápidas 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 LCP Echo-Request y Echo-Rep.
Los keepalives rápidos PPP utilizan números mágicos negociados para identificar posibles bucles de tráfico al enrutador o problemas de red. También puede deshabilitar la validación si es necesario para evitar la finalización no deseada de la sesión PPP, por ejemplo, cuando los pares remotos PPP utilizan números arbitrarios en lugar del número negociado.
Cómo funciona el procesamiento rápido 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 PPP en el motor de reenvío de paquetes. La característica está habilitada de forma predeterminada y no se puede deshabilitar.
En la siguiente secuencia se describe cómo un enrutador de la serie MX procesa los paquetes de solicitud de eco LCP y los paquetes de respuesta de eco LCP en el motor de reenvío de paquetes del MPC/MIC:
El motor de enrutamiento notifica al motor de reenvío de paquetes cuando la transmisión de solicitudes keepalive está habilitada en una interfaz lógica PPP. La notificación incluye los números mágicos tanto del servidor como 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 del mismo nivel en el paquete de solicitud de eco LCP y transmite el paquete de eco-respuesta LCP 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 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 campo en la salida del show interfaces pp0.logical statistics comando operacional no incluye estadísticas para la cantidad de paquetes keepalive recibidos o enviados, ni la cantidad de tiempo desde que el enrutador recibió o envió el Keepalive statistics último paquete 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 nivel de [edit class-of-service host-outbound-traffic] jerarquía.
Para los paquetes de eco-solicitud de eco LCP y de respuesta de eco LCP rápidos (en línea) PPP transmitidos entre un enrutador serie MX con MPC/MIC y un cliente PPP, el cambio de la configuración de la clase de reenvío surte efecto inmediatamente para las nuevas sesiones de suscriptor PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA) y servidor de red L2TP (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 discrepancia de números mágicos
Cuando el motor de reenvío de paquetes valida el número mágico par en el paquete de solicitud de eco LCP recibido, comprueba si el número mágico es inesperado. El número recibido debe coincidir con el número del par remoto que se acordó durante la negociación de LCP. El número del par remoto debe ser diferente del número del par local; Cuando son iguales, la expectativa es que exista una condición de circuito cerrado (el tráfico regresa 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 diferente del número negociado, el motor de reenvío de paquetes envía los paquetes de respuesta de eco fallidos al motor de enrutamiento. Si no se recibe una Echo-Reply con un número mágico válido dentro de un cierto intervalo, PPP considera que esto es una falla keepalive y derriba la sesión PPP.
Es posible que algunos equipos del cliente 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 interrumpe. A partir de Junos OS versión 18.1R1, este resultado se puede evitar configurando el enrutador para que no realice una comprobación de validación de números mágicos. Debido a que nunca se identifica la discrepancia, el enrutador continúa intercambiando paquetes keepalive PPP 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 de suscriptor PPP dinámicas terminadas en el enrutador o en el perfil dinámico para suscriptores PPP tunelizados dinámicos en el LNS.
Ver también
Actualizaciones del estado de conexión de origen RADIUS para dispositivos CPE
A partir de Junos OS versión 20.2R1, puede utilizar mensajes de origen 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 se 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 mensaje 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 usa una extensión específica del proveedor de Juniper Networks para LCP para enviar el contenido del VSA del mensaje de estado de conexión a la puerta de enlace principal 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 del mensaje de estado de conexión a authd de las siguientes maneras:
En el mensaje de acceso-aceptación 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 usar ambos métodos para cualquier sesión determinada para suscriptores comerciales o residenciales. El mensaje Access-Accept proporciona los parámetros de conexión iniciales. La capacidad de CoA le permite actualizar los parámetros de velocidad de conexión según sea necesario a lo largo de la duración de una sesión. La información transportada en el VSA de estado de conexión suele ser tasas de tráfico aplicadas por configuración local, como un perfil de servicio dinámico o el mensaje de puerto arriba de ANCP correspondiente.
Si no incluye la opción PPP en el perfil de cliente dinámico, PPP procesa la lcp-connection-update notificación desde 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 el VSA.
Los pasos siguientes describen lo que sucede cuando RADIUS envía el VSA en un mensaje de acceso-aceptación:
El proceso authd recibe el VSA Connection-Status-Message en un mensaje Access-Accept del servidor RADIUS.
El proceso authd envía el VSA del mensaje de estado de conexión a PPP (jpppd).
La negociación de NCP PPP tiene lugar entre el cliente PPP de puerta de enlace remota y PPP en el enrutador.
Una negociación exitosa da como resultado una solicitud de activación familiar. La sesión PPP entra en el estado Session Up cuando se activa la familia.
Si el perfil de cliente dinámico incluye la opción PPP y LCP en el enrutador está en el estado Abierto, PPP envía un mensaje LCP Connection-Update-Request a la
lcp-connection-updatepuerta de enlace. Este mensaje incluye la información de VSA en la opción Connection-Status-Message.Si la puerta de enlace admite la solicitud de actualización de conexión LCP, devuelve un mensaje de conexión-actualización de LCP al enrutador. El 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 conexión-actualizació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 PPP de hasta un máximo de 10 reintentos con un intervalo de 3 segundos entre los intentos.
Nota:Si no incluye la opción PPP en el perfil de cliente dinámico, PPP procesa la
lcp-connection-updatenotificación desde 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 pasos siguientes describen lo que sucede cuando RADIUS envía el VSA en una solicitud CoA. Esto supone que la negociación 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 del mensaje de estado de conexión a PPP (jpppd).
Si el perfil de cliente dinámico incluye la opción PPP y LCP en el enrutador está en el estado Abierto, PPP envía un mensaje LCP Connection-Update-Request a la
lcp-connection-updatepuerta de enlace. Este mensaje incluye la información de VSA en la opción Connection-Status-Message.Si la puerta de enlace admite la solicitud de actualización de conexión LCP, devuelve un mensaje de conexión-actualización de LCP al enrutador. El 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 conexión-actualizació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 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 conexión-actualización-solicitud, el enrutador vuelve a intentar enviar el mensaje. El enrutador también reintenta la solicitud cuando no recibe un Connection-Update-Ack o un LCP Code-Reject de la puerta de enlace, o cuando algo está mal con el mensaje Ack. 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 de rechazo de código PPP.
RADIUS puede incluir varias instancias del VSA del mensaje de estado de conexión en el mensaje de acceso-aceptación o en una solicitud de CoA. Si esto ocurre, authd utiliza sólo la primera instancia e ignora cualquier otra.
Las solicitudes de aceptación de acceso o CoA pueden contener otros atributos además del VSA del mensaje de estado de conexión, 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 correctamente los otros atributos, sigue enviando la información de conexión a PPP, que a su vez envía el contenido de VSA a la puerta de enlace doméstica.
Del mismo modo, authd aplica cualquier otro atributo y devuelve una respuesta de CoA independientemente de si PPP comunica correctamente el contenido del VSA de mensaje de estado de conexión a la puerta de enlace remota. Esto es cierto incluso cuando el CoA contiene solo el VSA del 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 la Tabla 1muestra que algunos valores de campo son diferentes para los dos mensajes.
Campo |
Conexión-Actualización-Solicitud |
conexión-actualización-ack |
|---|---|---|
Código |
0 para proveedores específicos |
0 para proveedores específicos |
Identificador |
Identificador de paquete específico del proveedor |
El mismo identificador que en el mensaje Connection-Update-Request. 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 Conexión-Estado-Mensaje |
Número de bytes en el paquete Connection-Update-Ack: 12 |
Número mágico |
Valor negociado para el número mágico PPP local |
Valor negociado para el número mágico PPP local |
Identificador único organizacional (OUI) |
21/00/59 para Juniper Networks |
21/00/59 para Juniper Networks |
Tipo |
1 para la actualización de la sesión |
2 para Session-ACK. 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 admiten valores |
Puede configurar cómo se utilizan los números mágicos PPP.
Si configura
ignore-magic-number-mismatchla opción PPP, está impidiendo que se validen los números mágicos. PPP ignora una falta de coincidencia entre los números mágicos en 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 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 los intercambios PPP Keepalive para obtener más información sobre los números mágicos.
La figura 2 muestra el formato de las opciones Conexión-Estado-Mensaje. En la tabla 2 se enumeran los valores de campo.
de opción de mensaje de estado de conexión
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 del mensaje de estado de conexión |
Configuración de perfiles dinámicos para PPP
Un perfil dinámico actúa como una plantilla que permite crear, actualizar o quitar una configuración que incluye atributos para el acceso de cliente (como interfaz o protocolo) o servicio (como IGMP). Mediante el uso de perfiles dinámicos, puede consolidar todos los atributos comunes de un cliente (y, finalmente, de un grupo de clientes) y aplicar los atributos simultáneamente.
Después de crear los perfiles dinámicos, los perfiles residen en una biblioteca de perfiles del enrutador. A continuación, puede utilizar la dynamic-profile instrucción para adjuntar perfiles a las 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 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 la creación de 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 Adjuntar 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 acerca del uso de perfiles dinámicos para autenticar suscriptores PPP, consulte Configuración de la 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 PPP durante los intercambios PPP Keepalive
Los números mágicos PPP se negocian entre pares durante la negociación LCP. Los pares deben tener diferentes números mágicos. Cuando los números son los mismos, indica que puede haber un loopback 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 al ú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 reciba un número válido (diferente) o se agote el tiempo de espera del proceso, en cuyo caso se interrumpe la sesión.
Después de acordar 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 PPP recibido del par remoto no coincide con el valor acordado durante la negociación 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 fallido al motor de enrutamiento. Si no se recibe una Echo-Reply con un número mágico válido dentro de un cierto intervalo, PPP considera que esto es una falla keepalive y derriba la sesión PPP.
En algunas circunstancias, este comportamiento no es deseable. Algunos equipos del cliente 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 finalmente se interrumpe. Este resultado puede evitarse impidiendo que el motor de reenvío de paquetes realice la comprobación de validación de números mágicos. Debido a que nunca se identifica la discrepancia, el enrutador continúa intercambiando paquetes keepalive PPP 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, perfil dinámico LNS L2TP o 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 LCP ni en el intercambio de keepalives cuando el número mágico 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. Esto se considera una situación poco probable, porque la negociación LCP se completó con éxito, lo que significa que no había ningún loopback presente en ese momento.
Para configurar perfiles dinámicos que impidan que el motor de reenvío de paquetes detecte discrepancias en números mágicos:
Configure la opción PPP.
Para conexiones dinámicas de suscriptor PPP que terminan 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 tunelizados dinámicos 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 actualizaciones de estado de conexión de origen RADIUS para dispositivos CPE
Puede utilizar mensajes con origen 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 sobre un VSA (26–218) de mensaje de estado de conexión recibido por authd en un mensaje de aceptación de acceso RADIUS o en un mensaje CoA. PPP luego transmite el contenido del VSA en un mensaje LCP Connection-Update-Request al par remoto. Esta acción requiere que se cumpla lo siguiente:
Al menos la primera familia de direcciones se ha negociado correctamente y la sesión está activa.
El LCP del enrutador está en el estado Abierto.
De lo contrario, PPP no toma ninguna medida sobre el VSA. Si no habilita la opción, PPP procesa la lcp-connection-update notificación desde authd, pero no realiza ninguna acción.
Esta funcionalidad 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 características en el perfil del cliente. En este ejemplo solo se muestra la configuración específica de esta característica. Esta función también requiere que configure VSA 26-218 en el servidor RADIUS; que 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 show ppp interface extensive comando de la interfaz lógica PPP para determinar si las actualizaciones de 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 suscriptores PPP estáticos a perfiles dinámicos
En este tema se describen varias consideraciones para migrar determinadas 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 Junos OS versión 15.1R4) tienen requisitos para migrar a sus suscriptores estáticos para administrarse con perfiles dinámicos en enrutadores que ejecutan administración mejorada de suscriptores (Junos OS versión 15.1R4 y versiones posteriores). A partir de Junos OS versión 18.2R1, se agregaron varias mejoras para facilitar la transición de estas configuraciones de proveedor de servicios estáticos 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 usar 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 eliminan. Las versiones heredadas de Junos OS no admiten suscriptores configurados sin autenticación 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 nombres de usuario y contraseñas localmente. El enrutador utiliza estos valores cuando se pone en contacto con el servidor RADIUS para la autenticación.
Para configurar el nombre de usuario para la autenticación local, incluya la instrucción en las opciones PPP de la
username-includeinterfaz lógica dinámica. Puede definir el nombre en función de uno o varios de los siguientes atributos: dirección MAC, ID del 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 instrucción en las opciones PPP de la
passwordinterfaz lógica dinámica.
Puede utilizar 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 grupo 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 de VRF tiene rutas estáticas que apuntan a interfaces de suscriptor PPP estáticas como la dirección del próximo salto. Estas rutas pueden tener configurado el atributo tag2; MP-BGP le exige que aplique la preferencia local y la comunidad apropiadas cuando anuncia 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 autentique 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.
Ventajas
La autenticación local permite la autenticación con contraseñas y nombres de usuario almacenados localmente para los suscriptores cuando el CPE no admite protocolos de autenticación como PAP y CHAP.
La asignación de direcciones de origen 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 grupo de direcciones local o de origen 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 usar 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 ACI o ARI del suscriptor no coincide con una entrada de tabla, entonces los paquetes PPP PADI y PADR generalmente se eliminan.
A partir de Junos OS versión 18.2R1, puede configurar nombres de usuario y contraseñas localmente para clientes que no admiten protocolos de autenticación como PAP y CHAP. El enrutador utiliza estos valores cuando se pone en contacto con el servidor 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 siguiente formato 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 la ACI es aci1002, el 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 Tag2 en perfiles dinámicos para suscriptores PPP IPv4 terminados estáticamente
En algunas configuraciones, los suscriptores de PPP utilizan rutas estáticas con un atributo tag2. Por ejemplo, MP-BGP usa tag2 para permitirle aplicar la preferencia local y la comunidad apropiadas cuando anuncia rutas. Al migrar estos suscriptores mediante el uso de perfiles dinámicos en un enrutador que ejecuta administración mejorada de suscriptores, puede configurar el atributo tag2 configurando un valor específico para una ruta o derivando el valor de 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 que incluya 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 podría 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 que utilice 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.
Para 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 opción, que permite configurar la challenge-length longitud mínima y 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 longitud del desafío CHAP
Puede modificar la longitud mínima predeterminada y la longitud máxima del mensaje de desafío del Protocolo de autenticación por protocolo de enlace por desafío mutuo (CHAP) que el enrutador envía a un cliente PPP. El mensaje de desafío CHAP, que contiene información exclusiva de una sesión de suscriptor PPP determinada, se usa como parte del mecanismo de autenticación entre el enrutador y el cliente para comprobar la identidad del cliente para tener acceso 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 invalidar este valor predeterminado para configurar la longitud mínima y la longitud máxima del desafío CHAP en el intervalo de 8 bytes a 63 bytes.
Se recomienda configurar la longitud mínima y la longitud máxima del desafío CHAP en al menos 16 bytes.
Antes de empezar:
Configure el protocolo CHAP en la interfaz.
Para las interfaces de suscriptor PPP dinámicas, consulte Configuración de la 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 mutuo 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 usa 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
Ver o borrar 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 PPA:
user@host> show ppp statistics
Para mostrar información de resumen de sesión PPP:
user@host> show ppp summary
Para mostrar información del conjunto de direcciones PPP:
user@host>show ppp address-pool