Arquitectura de línea base de la encapsulación con puente encaminada
Contenido
Introducción
Este documento proporciona una descripción de la arquitectura del End-to-End Asymmetric Digital Subscriber Line (ADSL) que utiliza la característica Routed Bridged Encapsulation (RBE) para el Cisco 6400 Universal Access Concentrator (UAC). RBE fue desarrollado para abordar los problemas conocidos de conexión en puente RFC1483 incluyendo tormentas de transmisión y seguridad. Salvo por el hecho que opera exclusivamente sobre ATM, la función RBE funciona igual que la función de medio puente. Puede alcanzarse una escalabilidad, un desempeño y una seguridad adicional mediante las características únicas de los suscriptores xDSL.
Suposición
La arquitectura de línea de base está diseñada mediante del Modelo de arquitectura de referencia del foro de ADSL. La arquitectura cubre diferentes ofertas de servicio a través de Network Access Provider (NAP) y diferentes escenarios sobre cómo el tráfico del suscriptor es reenviado a Network Service Provider (NSP). En esta arquitectura, RBE es el método de encapsulación supuesto utilizado por el Cisco 6400. El contenido de este documento se basa en implementaciones existentes, así como en algunas pruebas internas realizadas en la arquitectura. Para ver las características y modificaciones mejoradas, consulte las notas de la versión para la última versión del software Cisco IOS®. Actualmente, RBE es compatible con las plataformas Cisco 6400, Cisco 7200 y Cisco 7500. Este documento se limita a las conversaciones sobre Cisco 6400.
Resumen de tecnología
Desde el punto de vista de la red, la conexión ATM tiene la apariencia de una conexión enrutada. El tráfico de datos se recibe como paquetes RFC1483, pero se trata de tramas IEEE 802.3 o Ethernet RFC1483. En lugar de puentear la trama Ethernet o IEEE 802.3, como en el caso del puente RFC1483 normal, el router rutea en el encabezado de Capa 3. Con excepción de algunas verificaciones superficiales, el encabezado del puente es ignorado. Esto se explica en detalle en la siguiente sección.
Descripción de la funcionalidad
Desde un punto de vista operacional, el router funciona como si la interfaz de puente enrutado estuviese conectada a una LAN Ethernet. La operación se describe a continuación de dos maneras: paquetes que se originan en las instalaciones del cliente y paquetes destinados a las instalaciones del cliente.
En el caso de los paquetes que se originan en las instalaciones del cliente, se omite el encabezado Ethernet y se examina la dirección IP de destino. Si la dirección IP de destino está en la memoria caché de la ruta, el paquete se conmuta rápidamente a la interfaz de salida Si la dirección IP de destino no está en la memoria caché de la ruta, el paquete se coloca en la cola para la conmutación de proceso. En el modo de conmutación de procesos, la interfaz saliente a través de la cual debe rutearse el paquete se determina mirando en la tabla de ruteo. Luego que la interfaz saliente sea identificada, el paquete es enrutado vía esa interfaz. Esto ocurre sin necesidad de que exista un grupo de puente o interfaz virtual de grupo de puente (BVI).
Para los paquetes destinados a las instalaciones del cliente, la dirección IP de destino del paquete es examinada en primer lugar. La interfaz de destino se determina a partir de la tabla de IP Routing. A continuación, el router comprueba la tabla del protocolo de resolución de direcciones (ARP) asociada con esa interfaz para una dirección MAC de destino a colocar en el encabezado Ethernet. En caso de no encontrar uno, el router genera una petición ARP para la dirección IP de destino. La petición ARP será reenviada solamente a la interfaz de destino. Esto contrasta con el bridging, en el cual la solicitud ARP se envía a todas las interfaces del grupo de bridges.
En un caso de con interfaces no numeradas (donde puede encontrar dos suscriptores en la misma subred), la interfaz del puente de ruteo utiliza un proxy ARP. Por ejemplo, 192.168.1.2 (Host A) desea comunicarse con 192.168.1.3 (Host B). No obstante, el Host A está en la misma subred que el Host B.
El Host A debe aprender la dirección MAC del Host B enviando una difusión ARP al Host B. Cuando la interfaz de puente ruteado en el dispositivo de agregación recibe esta difusión, enviará una respuesta ARP proxy con la dirección MAC 192.168.1.1, Host A. Tomará esa dirección MAC, la colocará en su encabezado Ethernet y enviará el paquete. Cuando el router recibe el paquete, descarta el encabezado y examina la dirección IP de destino, luego la envía en la interfaz correcta.
Ventajas de RBE
Se desarrolló RBE con la intención de solucionar algunos de los inconvenientes con los que la arquitectura de conexión en puente RFC1483 se enfrentó. RBE retiene las ventajas principales de la arquitectura de conexión en puente RFC1483, mientras elimina la mayor parte de sus desventajas.
-
Configuración mínima del equipo en las instalaciones del cliente (CPE).
El proveedor de servicio considera que esto es importante porque ya no requiere una gran cantidad de rollos de cabezales y ya no necesita invertir en personal para brindar asistencia técnica sobre protocolos de mayor nivel. El CPE en modo de puente actúa como un dispositivo muy simple. La solución de problemas de CPE es mínima, ya que todo lo que llega de Ethernet pasa directamente al lado de la WAN.
-
Fácil migración de arquitecturas de puentes puros a RBE. No se requiere ningún cambio en el extremo del suscriptor.
-
Evita los retos de secuestro de IP y simulación ARP que se enfrentan en las arquitecturas de puentes puras típicas. RBE también evita que las tormentas de difusión utilicen conexiones punto a punto. La seguridad es la principal desventaja en las arquitecturas de puentes puros.
-
En comparación con arquitecturas puras de conexión en puente, RBE ofrece un rendimiento superior debido a la implementación del ruteo en el dispositivo de agrupamiento. RBE es también más escalable porque no tiene limitaciones de grupo de puente.
-
Admite la selección de Web de Capa 3 mediante la Gateway de selección de servicio (SSG) de Cisco.
Consideraciones de Implementación
Algunos de los puntos clave a considerar antes de implementar esta arquitectura son los mismos que se mencionan en el documento RFC1483 Bridging Baseline Architecture.
Se recomienda RBE cuando:
-
Los escenarios son los mismos que en las arquitecturas de conexión en puente existentes.
-
El NAP sólo quiere llevar a cabo la administración mínima de los CPE. El concepto de CPE simple requiere una configuración mínima o nula después de que el CPE se implemente en la ubicación del suscriptor.
-
El NAP no quiere instalar y mantener clientes hosts en los hosts que están detrás del CPE con puente. Estas tareas de instalación y mantenimiento aumentan los costos de implementación y mantenimiento, incluida la provisión de personal de mesa ayuda con conocimiento del software del cliente y el sistema operativo que el cliente ejecuta.
-
El NAP desea implementar una red puenteada escalable y segura usando CPE existentes (que sólo pueden funcionar en el modo de puente RFC1483) y desea ofrecer capacidades de selección de servicios.
En la siguiente conversación se explica cómo se adapta la arquitectura RBE a los diferentes modelos empresariales y cómo se adapta a ellos.
Arquitectura de red
La arquitectura de la red RBE es similar a la arquitectura de puente RFC1483. Como se especificó en esa arquitectura, la agrupación de dispositivo puede ser tanto en el NAP o en el NSP. Si se utiliza la arquitectura de un circuito virtual permanente extremo a extremo (PVC), el NSP termina con los abonados y configura el RBE en el dispositivo de agrupamiento. Si el NAP prefiere proveer servicios al por mayor además de selección de servicio, puede optar por finalizar esos abonados y obtener direcciones IP desde un servidor local de Protocolo de configuración de host dinámico (DHCP). En el caso de los servicios mayoristas, el NAP puede optar por obtener las direcciones IP del NSP. Estos escenarios se tratan detalladamente en la sección Administración IP de este documento.
Consideraciones de diseño para la arquitectura RBE
RBE elimina los principales riesgos de seguridad relacionados con la arquitectura de conexión en puente RFC1483. Además, RBE ofrece un mejor rendimiento y es más escalable porque a las subinterfaces se las trata como interfaces enrutadas.
Esta sección explica algunos de los puntos clave que deben ser considerados antes de diseñar una arquitectura RBE. Con respecto al suscriptor, los principios de diseño siguen siendo los mismos que en la arquitectura de puente RFC1483.
En RBE, a un circuito virtual único (VC) se le asigna una ruta, un conjunto de rutas o una subred de ruteo entre dominios sin clase (CIDR). Por lo tanto, el entorno de confianza se reduce a las instalaciones del cliente único representadas por las direcciones IP en el conjunto de rutas o el bloque CIDR. El ISP también controla las direcciones asignadas al usuario. Esto se hace mediante la configuración de una subred en la interfaz hacia ese usuario. Por lo tanto, si un usuario configura mal el equipo con una dirección IP fuera del intervalo de direcciones asignado (lo que posiblemente provoque que los paquetes ARP lleguen al router), el router genera un error de "cable incorrecto" y se niega a ingresar la asignación errónea de IP a direcciones MAC en su tabla ARP.
RBE sólo puede implementarse mediante subinterfaces ATM punto a punto. No se puede implementar en subinterfaces multipunto. Si bien el lado del suscriptor se conecta en puente, no necesita definir grupos de puentes o interfaces BVI dado que las subinterfaces se tratan como interfaces enrutadas.
Las subinterfaces punto a punto ATM pueden ser interfaces numeradas o no numeradas a otras interfaces.
Por definición, una interfaz numerada es una interfaz que cuenta con una dirección IP específica que le fue asignada con una máscara fija de subred. Por ejemplo:
Interface atm0/0/0.132 point-to-point ip address 192.168.1.1 255.255.255.252
Como se muestra en este ejemplo, cuando RBE se implementa con una interfaz numerada, debe existir una subred separada para cada suscriptor. El host en el extremo del suscriptor se debe configurar para 192.168.1.2. Sólo hay un host en el extremo del abonado. Si el requerimiento es admitir más de un host, la máscara de subred elegida deberá alojar más hosts.
Las interfaces numeradas dan el control NAP sobre el número de hosts que el abonado ha conectado detrás del CPE. Como se mencionó anteriormente, esta falta de control constituía un problema significativo con relación a la arquitectura de conexión en puente RFC1483.
Sin embargo, esta metodología consume muchas direcciones IP. Asigne una dirección IP por suscriptor, use una dirección IP para la subinterfaz ATM y deje la dirección de emisión y todas las direcciones de ceros fuera de uso. Por lo tanto, para tener un host detrás del CPE, al menos necesita definir una máscara de subred de 255.255.255.252. Teniendo en cuenta la escasez de direcciones IP, es posible que esta no sea una opción factible a menos que NAP/NSP utilice espacio de direcciones privadas y realice la traducción de direcciones de red (NAT) para llegar al mundo exterior.
Para conservar las direcciones IP, una alternativa sería utilizar interfaces sin numerar. Por definición, una interfaz sin numerar es una interfaz que utiliza la dirección IP de otra interfaz mediante el comando ip unnumbered. Por ejemplo:
! interface loopback 0 ip address 192.168.1.1 255.255.255.0 ! interface atm0/0/0.132 point-to-point ip unnumbered loopback 0 ! interface atm0/0/0.133 point-to-point ip unnumbered loopback 0
Tal como se muestra en el ejemplo anterior, una subred y una dirección IP sólo se aplican a la interfaz de loopback. Todas las subinterfaces ATM no estarán numeradas hacia esa interfaz de loopback. En este escenario, todos los suscriptores que se terminan en subinterfaces ATM (sin numerar a loopback 0) estarían en la misma subred que la del loopback 0. Esto implica que los suscriptores estarían en la misma subred, pero entrarían a través de diferentes interfaces enrutadas. En esta situación, se convierte en un problema para el router identificar qué suscriptor está detrás de qué subinterfaz ATM. Para Cisco IOS, 192.168.1.0 (en el diagrama de administración de IP) se conecta directamente a través del loopback 0 de la interfaz y nunca enviará tráfico destinado a ninguna de las direcciones de host en esa subred a través de ninguna otra interfaz. Para resolver este problema, debe configurar explícitamente las rutas estáticas del host. Por ejemplo:
ip route 192.168.1.2 255.255.255.255 atm0/0/0.132 ip route 192.168.1.3 255.255.255.255 atm0/0/0.133
Como se especifica en este ejemplo, cuando el router necesita tomar una decisión de ruteo y debe reenviar el tráfico destinado a 192.168.1.2, elegirá ATM 0/0/0.132 como la interfaz saliente, y así sucesivamente. Sin especificar esas rutas de host estáticas, el router elegiría la interfaz saliente como loopback 0 y descartaría el paquete.
Aunque la interfaz sin numeración conservara las direcciones IP, necesita una tarea adicional de configuración de rutas de host estáticas en el Procesador de ruta del nodo (NRP) para cada suscriptor. Note que si un suscriptor tiene, por ejemplo, 14 hosts detrás del CPE, no es necesario tener rutas de host estáticas para cada host. Se puede definir una ruta resumida para la subinterfaz ATM.
Hasta aquí, esta explicación asume que los hosts detrás del CPE serán configurados para direcciones IP estáticas. Esta estimación no es verdadera en los diseños reales. En la práctica, el NAP desea realizar la menor cantidad posible de tareas de mantenimiento y configuración del CPE y de los hosts adjuntos a él. Para lograrlo, los hosts deben obtener sus direcciones dinámicamente usando un servidor DHCP.
Para obtener sus direcciones IP dinámicamente, los hosts se deben configurar para obtener direcciones IP de un servidor DHCP. Cuando el host se inicia, envía solicitudes DHCP. Estas solicitudes son pasadas luego al servidor DHCP adecuado el que asigna una dirección IP al host desde una en su alcance definido previamente.
Para reenviar las solicitudes DHCP iniciales del host al servidor DHCP apropiado, debe aplicar el comando ip helper-address a la interfaz que recibe las transmisiones. Después de que se reciben las transmisiones, el IOS de Cisco observa la configuración de la dirección ip helper para esa interfaz y reenvía esas solicitudes en un paquete unicast al servidor DHCP apropiado cuya dirección IP se especifica en ip helper-address. Luego de que el servidor DHCP responde con la dirección IP, envía la respuesta a la interfaz en el router que originalmente reenvió la petición. Esto se utiliza como interfaz de salida para enviar la respuesta del servidor DHCP al host que originariamente solicitó el servicio. El router también instala automáticamente una ruta de host para esta dirección.
Si RBE está habilitado en una subinterfaz y es una unidad de datos de protocolo puenteado (PDU) IEEE 802.3, la encapsulación Ethernet se examina después de la encapsulación de puente ATM. Si es un paquete IP/ARP, se lo gestiona al igual que cualquier otro paquete IP/ARP. El paquete de IP es conmutado rápidamente. Si falla, se lo coloca en la cola para la conmutación del proceso.
El rendimiento de RBE es una gran victoria. En la actualidad, el código de conexión en puente estándar presenta un problema inherente que hace necesario requerir dos clasificaciones separadas para un paquete antes de que se pueda realizar una decisión de reenvío. Se denomina clasificación al proceso relativamente costoso de examinar (en el ascenso) y modificar (en el descenso) el encabezado del paquete para reenviar información. Se requiere una búsqueda de capa 2 para determinar si el paquete debe ser enrutado o conectado con puente. Luego se requiere una búsqueda en la Capa 3 para identificar la ubicación a donde debe ser enrutado el paquete. Esta clasificación se realiza tanto en las direcciones ascendentes como en las descendentes, lo que repercute en el rendimiento.
Para RBE, está predeterminado en la configuración que el paquete será enrutado en la dirección ascendente. Por lo tanto, no es necesario pasar por la ruta de reenvío de puente, que era necesaria en el caso de la conexión en puente estándar.
Puntos clave del RBE
CPE
La configuración CPE permanece igual que en la conexión en puente estándar. Para implementar RBE, no se requiere ningún cambio en el CPE.
Administración de IP
Al implementar las interfaces numeradas para RBE, la asignación de la dirección IP al host detrás del CPE puenteado se maneja generalmente a través de un servidor DHCP. Como se mencionó anteriormente, el servidor DHCP puede residir en el NAP o en el NSP. En cualquier caso, la subinterfaz ATM numerada se debe configurar con el comando ip helper-address. Si el servidor DHCP va a ser ubicado en NSP, el dispositivo de agrupamiento NAP debe tener una ruta para alcanzar a ese servidor. El único caso en el que un NAP utilizaría su propio servidor DHCP y su rango de dirección IP es cuando quiere ofrecer capacidades de selección de servicio a los suscriptores y éstos están conectados por LAN al NAP.
Si el NAP desea utilizar el espacio de dirección IP del NSP, una de las direcciones IP para cada subred debería asignarse a la subinterfaz ATM. Además, debería haber acuerdo entre NAP y NSP a fin de que NAP configure la dirección correcta. Cuando el servidor DHCP de NSP asigna direcciones IP, debe existir este acuerdo a fin de garantizar que el servidor proporcione al host la información del gateway adecuada. El NAP puede entonces resumir una ruta estática para todas esas direcciones asignadas a los suscriptores o puede elegir ejecutar un protocolo de ruteo con el NSP para anunciar esas rutas. En la mayoría de los escenarios, tanto el NAP como el NSP preferirían no usar un protocolo de ruteo. Proporcionar una ruta estática es una buena opción.
Esta es la configuración básica requerida en el NRP para implementar RBE con interfaces numeradas:
! interface ATM0/0/0.132 point-to-point ip address 192.168.1.1 255.255.255.0 ip helper-address 192.168.3.1 no ip directed-broadcast atm route-bridged ip pvc 1/32 encapsulation aal5snap ! interface ATM0/0/0.133 point-to-point ip address 192.168.2.1 255.255.255.0 ip helper-address 192.168.3.1 no ip directed-broadcast atm route-bridged ip pvc 1/33 encapsulation aal5snap
El uso de interfaces sin numerar es la mejor manera de conservar las direcciones IP. Como se explicó anteriormente, cuando se utilizan interfaces sin numerar con DHCP, las rutas de host se instalan dinámicamente. Tal vez, este sea el mejor enfoque para implementar RBE. El servidor DHCP se puede ubicar entonces en el NAP o en el NSP, como en el caso de las interfaces numeradas.
Esta es la configuración básica requerida en el NRP para implementar RBE con interfaces sin numerar:
interface Loopback0 ip address 192.168.1.1 255.255.255.0 no ip directed-broadcast ! interface ATM0/0/0.132 point-to-point ip unnumbered Loopback0 no ip directed-broadcast ATM route-bridged ip pvc 1/32 encapsulation aal5snap ! interface ATM0/0/0.133 point-to-point ip unnumbered Loopback0 no ip directed-broadcast ATM route-bridged ip pvc 1/33 encapsulation aal5snap
Cómo se llega a un destino de servicio
Hasta ahora, este documento ha discutido la tecnología de acceso básica usando RBE como el método de encapsulación. Sin embargo, con esta arquitectura, NAP/NSP también puede ofrecer diversos servicios y diferentes opciones para el caso en el que NAP puede reenviar el tráfico del suscriptor al NSP. Estos conceptos se explican en las secciones siguientes.
Suministro de acceso a Internet
En este escenario, la función primaria del NSP es proveer acceso a Internet de alta velocidad para los suscriptores finales. Debido a que el NSP va a proporcionar el servicio final, la administración de direcciones IP se convierte en responsabilidad del NSP. Puede asignar direcciones IP públicas a sus suscriptores finales mediante el uso de un servidor DHCP o puede optar por proporcionar direcciones IP privadas a sus suscriptores y luego realizar NAT para llegar al mundo exterior.
Servicios mayoristas
Si el NAP desea ofrecer servicios mayoristas a otros ISP, puede hacerlo. En esta situación, el NAP normalmente no prefiere manejar las direcciones IP para todos los suscriptores para los diferentes NSP. El NAP establece algún acuerdo con el ISP para proporcionar direcciones IP a esos suscriptores. Esto puede lograrse mediante el reenvío de NAP de las solicitudes DHCP que vienen de los suscriptores a los servidores DHCP en los NSP. El NAP tiene que configurar sus subinterfaces ATM con una de las direcciones IP de ese rango, y necesita anunciar esas rutas al NSP. El anuncio de ruteo podría ser en forma de ruta estática o de algún protocolo de ruteo entre el NAP y el NSP. La ruta estática es el método preferido para el NAP y para el NSP.
Acceso corporativo
El acceso corporativo generalmente requiere los servicios de Red privada virtual (VPN). Esto significa que la corporación no ofrecerá ninguna dirección IP al NAP y no le permitirá anunciar el espacio de la dirección IP corporativa en el núcleo IP del NAP, lo que podría resultar en una violación a la seguridad. En general, las empresas prefieren asignar sus propios IP Addresses a sus clientes o permiten el acceso a través de algún medio seguro, como Multiprotocol Label Switching/Virtual Private Network (MPLS/VPN) o Layer 2 Tunneling Protocol (L2TP).
El otro enfoque para proporcionar acceso corporativo seguro es donde el NAP proporciona las direcciones IP iniciales a esos suscriptores. Por lo tanto, los suscriptores se conectan a la LAN al NAP. Luego de que los suscriptores obtengan direcciones IP iniciales, pueden iniciar un túnel hacia la corporación a través del software del cliente L2TP que se ejecuta en el host. A su vez, la empresa autenticará a este suscriptor y le brindará una dirección IP de su espacio de direcciones IP. El adaptador VPN L2TP utiliza esta dirección IP. De esta manera, los suscriptores tienen la opción de conectarse a su ISP para la conexión a Internet o obtener acceso a su corporación a través de un acceso de túnel L2TP seguro. Sin embargo, esto requiere que la corporación proporcione la dirección IP de destino del túnel al suscriptor, que debería ser enrutable a través del núcleo IP del NAP.
Capacidades de selección de servicios
El NAP puede ofrecer diversas capacidades de selección de servicio mediante la funcionalidad Cisco SSG. El SSG ofrece dos métodos para proporcionar la selección de servicios: a través de la selección web de capa 2 (conocida como PTA-MD) y capa 3. Con RBE, puede utilizarse sólo el método de selección Web de la Capa 3. Esto requiere que los suscriptores estén conectados a LAN al NAP; es decir, el NAP proporciona la dirección IP inicial al suscriptor y proporciona acceso al panel de selección de servicios (SSD) de Cisco.
En el caso de la arquitectura RBE, el método de selección Web de Cisco SSG es una buena manera de contabilizar el tráfico del suscriptor.
Conclusión
RBE ofrece un mejor rendimiento y es más escalable que el puente estándar. También supera los problemas de seguridad de la conexión en puente estándar. RBE elimina los problemas de tormenta de transmisión de la conexión en puente estándar. RBE proporciona una arquitectura robusta para NAP que desea evitar el mantenimiento del software host del cliente, los problemas relacionados con el puente y desea reducir los costes de implementación. Con RBE, todo esto es posible mientras se utiliza la arquitectura de puente existente.
Comentarios