Arquitectura básica PPPoE para Cisco 6400 UAC

Introducción

Este documento describe una arquitectura ADSL (Asymmetric Digital Subscriber Line) de fin a fin que utiliza PPPoE Ethernet (Point-to-Point Protocol over Ethernet).

En el entorno actual de las tecnologías de acceso, es deseable conectar varios hosts en un sitio remoto a través del mismo dispositivo de acceso a las instalaciones del cliente. También es esencial proporcionar control de acceso y funcionalidad de facturación de una manera similar a los servicios de marcación manual que utilizan el Protocolo punto a punto (PPP). En muchas tecnologías de acceso, el método más rentable para conectar varios hosts al dispositivo de acceso a las instalaciones del cliente es a través de Ethernet. Además, es deseable mantener el coste de este dispositivo lo más bajo posible y el requisito de configuración menos o ninguno.

A medida que los clientes implementan ADSL, deben admitir autenticación y autorización de estilo PPP en una gran base instalada de equipos de las instalaciones del cliente (CPE) antiguos en puente. PPPoE proporciona la capacidad de conectar una red de hosts a través de un simple dispositivo de acceso en puente a un concentrador de acceso remoto o concentrador de agregación. Con este modelo, cada host utiliza su propia pila PPP. Por lo tanto, presenta al usuario una interfaz de usuario familiar. Puede acceder al control, la facturación y el tipo de servicio por usuario, en lugar de por sitio.

Suposición

La arquitectura de línea de base supone que se proporcionan estos elementos:

• Acceso a Internet de alta velocidad y acceso corporativo al suscriptor final que utiliza PPPoE.

• ATM como la tecnología de red troncal principal, implementada por el concentrador de acceso universal (UAC) Cisco 6400.

Esta restricción en la implementación del diseño puede limitar el uso de esta arquitectura en otras plataformas, pero PPPoE evoluciona constantemente. Lea las últimas notas de la versión de productos relacionados para aprovechar las funciones nuevas y actualizadas.

Este informe se basa en las implementaciones actuales, así como en pruebas internas que utilizan Cisco 6400 UAC. Este documento es una continuación del documento PPPoA Baseline Architecture y se refiere a él con frecuencia. Se supone que ha leído el informe técnico sobre la arquitectura de línea de base PPPoA y que comprende los fundamentos de PPP, y que ha leído las notas de la versión de la última versión del software.

Resumen de tecnología

Como se especifica en RFC 2516, PPPoE tiene dos etapas distintas: una etapa de detección y una etapa de sesión PPP. Cuando un host inicia una sesión PPPoE, primero debe realizar la detección para identificar qué servidor puede satisfacer la solicitud del cliente. En segundo lugar, necesita identificar la dirección MAC Ethernet del par y establecer un ID de sesión PPPoE. Mientras que PPP define una relación de par a par, la detección es inherentemente una relación cliente-servidor.

En el proceso de detección, un host (el cliente) detecta uno o más concentradores de acceso (los servidores) y selecciona uno. Cuando la detección se completa con éxito, tanto el host como el concentrador de acceso seleccionado tienen la información para construir su conexión punto a punto sobre Ethernet. Después de establecer una sesión PPP, tanto el host como el concentrador de acceso deben asignar los recursos para una interfaz virtual PPP (probablemente no sea el caso para todas las implementaciones). Para obtener más detalles sobre la especificación PPPoE, consulte RFC 2516.

Ventajas y desventajas de la arquitectura PPPoE

La arquitectura PPPoE hereda la mayoría de las ventajas de PPP utilizadas en el modelo de marcación manual y en la arquitectura PPPoA. En estas secciones se enumeran algunas de las principales ventajas y desventajas de PPPoE y en qué se diferencian de PPPoA.

Ventajas

Estas son algunas de las ventajas clave de PPPoE y en qué se diferencian de PPPoA:

• Autenticación por sesión basada en el protocolo de autenticación por contraseña (PAP) o el protocolo de autenticación por desafío mutuo (CHAP). Esta es la mayor ventaja de PPPoE ya que la autenticación supera el agujero de seguridad en una arquitectura de conexión en puente.

• Es posible la contabilización por sesión, lo que permite al proveedor de servicios cobrar al suscriptor en función del tiempo de sesión por los diversos servicios ofrecidos. El proveedor de servicios también puede requerir un cargo de acceso mínimo.

• Puede utilizar PPPoE en instalaciones CPE actuales que no se pueden actualizar a PPP o que no tienen la capacidad de ejecutar PPPoA, que extiende la sesión PPP sobre la LAN Ethernet puenteada al PC.

• PPPoE conserva la sesión punto a punto utilizada por los proveedores de servicios de Internet (ISP) en el modelo de marcación manual actual. PPPoE es el único protocolo capaz de ejecutar punto a punto en Ethernet sin el requisito de una pila IP intermedia.

• El proveedor de acceso a la red (NAP) o el proveedor de servicios de red (NSP) pueden proporcionar acceso seguro a un gateway corporativo sin la administración de circuitos virtuales permanentes (PVC) de extremo a extremo y sin el uso del routing de capa 3 o túneles de protocolo de túnel de capa 2 (L2TP). Esto hace que el modelo de negocio de la venta de servicios al por mayor y redes privadas virtuales (VPN) sea escalable.

• PPPoE puede proporcionar un acceso de host (PC) a varios destinos en un momento determinado. Puede tener varias sesiones PPPoE por PVC.

• El NSP puede suscribirse en exceso mediante la implementación de tiempos de espera de sesión y de inactividad con la ayuda de un servidor RADIUS (servicio de usuario de acceso telefónico de autenticación remota) estándar del sector para cada suscriptor.

• Puede utilizar PPP con la función Service Selection Gateway (SSG).

Desventajas

Estas son algunas de las principales desventajas de PPPoE y en qué se diferencian de PPPoA:

• Debe instalar el software de cliente PPPoE en todos los hosts (PC) que se conectan al segmento Ethernet. Esto significa que el proveedor de acceso debe mantener el CPE y el software cliente en la PC.

• Dado que la implementación de PPPoE utiliza puentes RFC 1483, es susceptible a tormentas de difusión y posibles ataques de denegación de servicio.

Consideraciones de instrumentación de la arquitectura PPPoE

Estos son algunos puntos clave que debe tener en cuenta antes de implementar este tipo de arquitectura.

• El número de suscriptores admitidos. El número de servidores PPPoE necesarios depende del número de sesiones.

• Si las sesiones PPP se terminan en el router de agregación del proveedor de servicios o se reenvían a otros gateways corporativos o ISP.

• Si el proveedor de servicios o el destino final del servicio proporcionan la dirección IP.

• En el caso de más de un usuario, si todos los usuarios necesitan alcanzar el mismo destino o servicio final, o si todos tienen destinos de servicio diferentes. ¿Necesitan los suscriptores finales acceso simultáneo a varios destinos?

• El software cliente PPPoE que utiliza el proveedor de acceso y si el software se ha probado, el sistema operativo que utiliza el host y si dicho sistema operativo puede tomar una decisión de enrutamiento inteligente.

• Cómo factura el proveedor de servicios a los suscriptores en función de una tarifa plana, el uso por sesión o los servicios utilizados.

• Implementación y suministro de CPE, DSLAM y puntos de presencia de agregación (POP).

• El modelo de negocio para el NAP. ¿El modelo también incluye la venta de servicios al por mayor como acceso corporativo seguro y servicios de valor añadido como voz y vídeo? ¿Los NAP y los NSP son la misma entidad?

• El modelo de negocio de la empresa. ¿Es comparable a una compañía de intercambio local independiente (ILEC), una compañía de intercambio local competitiva (CLEC) o un ISP?

• Los tipos de aplicaciones que el NSP ofrece al suscriptor final.

• El volumen de flujo de datos ascendente y descendente previsto. Tenga en cuenta el rendimiento de NRP, la ingeniería de tráfico y cualquier problema de QoS.

Este documento explica cómo la arquitectura PPPoE se adapta y escala a los diferentes modelos de negocio para los proveedores de servicios y cómo los proveedores pueden beneficiarse con la ayuda de esta arquitectura.

Arquitectura de red

Consideraciones de diseño para la arquitectura PPPoE

En esta sección se tratan los problemas que se aplican específicamente a la arquitectura PPPoE.

Antes de implementar cualquier arquitectura, es fundamental comprender el modelo empresarial del proveedor de servicios y los servicios que ofrece. Debe conocer el software cliente que se utiliza en el PC. El software más común proviene de Routerware. Dado que el software cliente está instalado en un PC, el técnico del proveedor de servicios debe tener un buen conocimiento de dicho PC y de su sistema operativo.

Tal como se especifica en RFC 2516, la opción de unidad de recepción máxima (MRU) no debe negociar con un tamaño superior a 1492. Ethernet tiene un tamaño máximo de carga útil de 1500 octetos. El encabezado PPPoE es de 6 octetos y el ID de protocolo PPP es de 2 octetos, por lo que la unidad de transmisión máxima (MTU) PPP no debe ser mayor que 1492. Esto se logra con la configuración de IP MTU 1492 para interfaces de plantilla virtual PPPoE.

De forma predeterminada, no se preclona ninguna interfaz de acceso virtual cuando se configura un grupo de VPDN PPPoE. Los usuarios pueden cambiar el número máximo de interfaces de acceso virtual preclonadas mediante la ejecución del comando global virtual-template <number> pre-clone <number>.

Para proteger el router contra ataques de denegación de servicio, PPPoE (de forma predeterminada) permite que sólo se obtenga una sesión de una dirección MAC a través de un VC. Los usuarios pueden ejecutar los comandos pppoe session-limit per-mac y pppoe session-limit per-vc para cambiar los valores predeterminados.

El proceso de contabilización, autorización y autenticación es el mismo que el de PPPoA. La única diferencia es que actualmente, la autenticación basada en VPI/VCI, que está disponible para PPPoA y no está disponible para PPPoE, puede utilizar las arquitecturas L2TP y SSG para los servicios mayoristas.

Puntos clave de la arquitectura PPPoE

CPE

El CPE está configurado para puentes RFC 1483 puros. Cada CPE consume sólo un par VPI/VCI y todas las sesiones PPPoE iniciadas por los hosts detrás de este CPE se traspasan en este único VC.

Administración de IP

La asignación de direcciones IP para el host individual que ejecuta el cliente PPPoE se basa en el mismo principio de PPP en la negociación de IPCP en modo de marcado. El origen de la dirección IP depende del tipo de servicio que adquiera el suscriptor y de dónde terminen las sesiones PPP. PPPoE utiliza la función de red de marcación manual de Microsoft Windows y la dirección IP asignada se refleja en el adaptador PPP.

La asignación de la dirección IP puede provenir del concentrador de acceso que termina las sesiones PPPoE o, en el caso de L2TP, de los gateways de inicio. La dirección IP se asigna para cada sesión PPPoE.

El CPE no puede realizar la traducción de direcciones de red/protocolo de configuración dinámica de host (NAT/DHCP) porque está conectado en puente y no tiene ninguna dirección IP asignada.

Cómo se llega al destino de servicio

Estas son las formas de llegar al destino del servicio:

• La terminación de las sesiones PPP en el proveedor de servicios

• Tunelización L2TP

• Con el uso de SSG

Las explicaciones detalladas de estas arquitecturas se tratan en documentos independientes.

Descripción operativa de PPPoE

Esta versión del software cliente PPPoE admite las fases de detección y sesión descritas en RFC 2516. La fase de descubrimiento consta de cuatro pasos. Cuando se completa, ambos peers conocen el ID de sesión PPPoE y la dirección Ethernet del peer, que juntos definen de manera única la sesión PPPoE. Estos son los pasos:

1. El host transmite un paquete de iniciación.

   El host envía el paquete de iniciación de detección activa (PADI) PPPoE con destination_addr configurado en la dirección de difusión. El PADI consta de una etiqueta que indica el tipo de servicio que solicita.

2. Uno o más concentradores de acceso envían paquetes de oferta.

   Cuando el concentrador de acceso o el router recibe un PADI que puede servir, envía un paquete de oferta de detección activa (PADO) PPPoE. destination_addr es la dirección de unidifusión del host que envió el PADI. Si el concentrador de acceso no puede servir al PADI, no debe responder con un PADO. Desde que se transmitió el PADI, el host puede recibir más de un PADO.

   

3. El host envía un paquete de solicitud de sesión de unidifusión.

   El host mira a través de los paquetes PADO que recibe y elige uno. La elección se basa en los servicios ofrecidos por cada concentrador de acceso. El host luego envía un paquete PADR al concentrador de acceso que elija. El campo destination_addr se establece en la dirección Ethernet de unidifusión del concentrador de acceso o el router que envía el PADO.

4. El concentrador de acceso seleccionado envía un paquete de confirmación.

   Cuando el concentrador de acceso recibe un paquete PADR, se prepara para iniciar una sesión PPP. Genera un identificador de sesión único para la sesión PPPoE y responde al host con un paquete de confirmación de sesión de detección activa (PADS) PPPoE. El campo destination_addr es la dirección Ethernet de unidifusión del host que envía el PADR.

Una vez que comienza la sesión PPPoE, los datos PPP se envían como en cualquier otra encapsulación PPP. Todos los paquetes Ethernet son de unidifusión.

El host o el concentrador de acceso pueden enviar un paquete de terminación de detección activa (PADT) PPPoE en cualquier momento después de que se haya establecido una sesión para indicar que se ha finalizado una sesión PPPoE.

Para obtener una explicación más detallada, consulte RFC 2516.

Conclusión

En el caso de ADSL, PPPoE gana popularidad y sólo ocupa el segundo lugar con respecto a PPPoA.

Referencias

• RFC 2516: método para transmitir PPP sobre Ethernet (PPPoE)

• RFC 1483: encapsulación multiprotocolo sobre capa 5 de adaptación ATM

• RFC 2364: Point-to-Point over AAL5

Información Relacionada

• Arquitectura de línea de base PPPoA
• Soporte técnico de DSL
• Soporte Técnico - Cisco Systems