Descripción general de la red de acceso de suscriptores de banda ancha
Descripción general de la red de acceso de suscriptores
Un entorno de acceso de suscriptores puede incluir varios componentes, incluyendo tecnologías de acceso de suscriptores y protocolos de autenticación.
Las tecnologías de acceso de los suscriptores incluyen:
-
Servidor de protocolo de configuración dinámica de host (DHCP)
-
Servidor DHCP local
-
Servidor DHCP externo
-
-
Protocolo punto a punto (PPP)
Los protocolos de autenticación del suscriptor incluyen el servidor RADIUS.
La figura 1 muestra un ejemplo de una red básica de acceso de suscriptores.
de red de acceso de suscriptor
Esta función requiere una licencia. Para obtener más información sobre las licencias de acceso de suscriptor, consulte Descripción general de licencias de acceso de suscriptor. Consulte la Guía de licencias de Juniper para obtener información general acerca de la administración de licencias. Consulte las hojas de datos de los productos en Enrutadores de la serie MX para obtener más detalles, o comuníquese con su equipo de cuenta de Juniper o su socio de Juniper.
El acceso de flujo de bits de capa 2 (L2-BSA) le permite proporcionar servicios de acceso de flujo de bits de capa 2, lo que permite a los proveedores de servicios de red (NSP) al por mayor el tráfico de suscriptores de manera eficiente. Esta funcionalidad admite la creación y el reenvío dinámicos de VLAN a través de interfaces de conexión directa o pseudocable VPLS.
Los mecanismos L2-BSA en línea y fuera de banda utilizan mensajes ANCP para la administración dinámica de VLAN. La autorización basada en RADIUS para procesos al por mayor de suscriptores y administración de flujo de paquetes mantienen una entrega de tráfico precisa y eficiente.
La L2-BSA en línea utiliza VLAN de detección automática, en las que los paquetes se exceptúan inicialmente al motor de enrutamiento para obtener autorización opcional y creación de VLAN dinámica. Esto garantiza un procesamiento eficiente y una participación mínima del motor de enrutamiento una vez que la VLAN está operativa. Por el contrario, la L2-BSA fuera de banda extiende el mecanismo de VLAN de detección automática mediante mensajes ANCP para la detección y creación de VLAN, lo que proporciona activadores fuera de banda para la administración dinámica, lo que mejora la escalabilidad y la flexibilidad de sus servicios de red.
El proceso al por mayor de suscriptores utiliza autorización basada en RADIUS para el acceso de los suscriptores, creando VLAN dinámicamente y asignándolas a interfaces orientadas al núcleo según la distribución de carga ponderada. Este proceso garantiza una entrega precisa y eficiente del tráfico de suscriptores, con mecanismos de flujo de paquetes detallados, que incluyen el intercambio de etiquetas VLAN y las actualizaciones de la tabla de reenvío de direcciones MAC. Estas características facilitan el mantenimiento de una alta calidad del servicio con medidas de seguridad de red para mitigar los ataques de DS, garantizando una prestación de servicio estable y continua.
Servicio de acceso al tren de bits de capa 2 (L2-BSA) en tarjetas de línea de nueva generación (MX304-LMIC16 en MX304, MPC10E-10C y MPC10E-15C en MX960, MX10004, MX10008 y MX10016)
Compatibilidad con el servicio de acceso al tren de bits de capa 2 (L2-BSA) en tarjetas de línea basadas en AFT, MX304-LMIC16 en MX304 y en dispositivos de la serie MX con tarjetas de línea basadas en trío MPC MPC10E-10C y MPC10E-15C en MX960, MX10004, MX10008 y MX10016 que incluye soporte para:
- L2-BSA en línea.
- L2-BSA fuera de banda.
- Aumento de suscriptores de L2BSA.
- Reducción de suscriptores de L2BSA.
- Flujo de paquetes ascendente.
- Flujo de paquetes descendente.
- Los proveedores de servicios ahora pueden ofrecer compatibilidad con VDSL2 de velocidad DSL de 100 Mbps con el servicio de acceso de flujo de bits de capa 2 (L2-BSA) para socios NSP (proveedor de servicios de red).
Descripción general del nodo de acceso multiservicio
Un nodo de acceso multiservicio es un término más amplio que se refiere a un grupo de dispositivos de agregación de uso común. Estos dispositivos incluyen multiplexores de acceso a línea de suscriptor digital (DSLAM) utilizados en redes xDSL, terminación de línea óptica (OLT) para redes PON/FTTx y conmutadores Ethernet para conexiones Ethernet activas. Las MSAN modernas a menudo admiten todas estas conexiones, así como también proporcionan conexiones para circuitos adicionales, como el antiguo servicio telefónico (denominado POTS) o la señal digital 1 (DS1 o T1).
La función definitoria de un nodo de acceso multiservicio es agregar tráfico de varios suscriptores. A nivel físico, la MSAN también convierte el tráfico de la tecnología de última milla (por ejemplo, ADSL) a Ethernet para su entrega a los suscriptores.
En términos generales, puede clasificar las MSAN en tres tipos en función de cómo reenvían el tráfico en la red:
-
Layer–2 MSAN: este tipo de MSAN es esencialmente un conmutador de capa 2 (aunque normalmente no es un conmutador completamente funcional) con algunas mejoras relevantes. Estas MSAN usan conmutación Ethernet (o ATM) para reenviar el tráfico. La MSAN reenvía todo el tráfico de suscriptor ascendente a un enrutador de borde que actúa como punto de control centralizado e impide la comunicación directa de suscriptor a suscriptor. La agregación de vínculos Ethernet (LAG) proporciona la resiliencia en este tipo de red.
Los DSLAM de capa 2 no pueden interpretar IGMP, por lo que no pueden replicar selectivamente los canales de IPTV.
-
Layer–3 aware MSAN: esta MSAN con reconocimiento de IP puede interpretar y responder a las solicitudes IGMP replicando localmente una secuencia de multidifusión y reenviando la secuencia a cualquier suscriptor que lo solicite. El conocimiento de la capa 3 es importante cuando se admite el tráfico de IPTV para realizar cambios de canal (a veces denominados zaps de canal). Las MSAN estáticas conscientes de IP siempre reciben todos los canales de televisión de multidifusión. No tienen la capacidad de solicitar que se reenvíen canales específicos a la DSLAM. Sin embargo, los DSLAM dinámicos conscientes de IP pueden informar a la red que comience (o interrumpa) el envío de canales individuales al DSLAM. La configuración del proxy IGMP o la supervisión IGMP en el DSLAM cumple esta función.
-
Layer–3 MSAN: estas MSAN usan la funcionalidad de enrutamiento IP en lugar de tecnologías de capa 2 para reenviar el tráfico. La ventaja de este método de reenvío es la capacidad de admitir múltiples vínculos ascendentes que van a diferentes enrutadores ascendentes y mejora la resistencia de la red. Sin embargo, para lograr este nivel de resistencia, debe asignar una subred IP independiente a cada MSAN, lo que agrega un nivel de complejidad que puede ser más difícil de mantener o administrar.
Al elegir un tipo de MSAN, consulte la Figura 2:
de MSAN
Opciones de agregación de Ethernet MSAN
Cada MSAN puede conectarse directamente a un enrutador de borde (enrutador de servicios de banda ancha o enrutador de servicios de video), o un dispositivo intermedio (por ejemplo, un conmutador Ethernet) puede agregar tráfico de MSAN antes de enviarlo al enrutador de servicios. En la Tabla 1 se enumeran los posibles métodos de agregación de MSAN y en qué condiciones se utilizan.
Método |
Cuando se usa |
|---|---|
Conexión directa |
Cada MSAN se conecta directamente al enrutador de servicios de banda ancha y al enrutador de servicios de video opcional. |
Conexión de conmutador de agregación Ethernet |
Cada MSAN se conecta directamente a un conmutador Ethernet intermedio. El conmutador, a su vez, se conecta al enrutador de servicios de banda ancha o al enrutador de servicios de video opcional. |
Conexión de agregación de anillo Ethernet |
Cada MSAN se conecta a una topología de anillo de MSAN. La MSAN de cabecera (el dispositivo más cercano al enrutador de borde ascendente) se conecta al enrutador de servicios de banda ancha. |
Puede utilizar diferentes métodos de agregación en distintas partes de la red. También puede crear varias capas de agregación de tráfico dentro de la red. Por ejemplo, una MSAN puede conectarse a un terminal de oficina central (COT), que, a su vez, se conecta a un conmutador de agregación Ethernet, o puede crear varios niveles de conmutadores de agregación Ethernet antes de conectarse al enrutador de borde.
Conexión directa
En el método de conexión directa, cada MSAN tiene una conexión punto a punto con el enrutador de servicios de banda ancha. Si existe una oficina central intermedia, el tráfico de varias MSAN se puede combinar en una sola conexión mediante la multiplexación por división de ondas (WDM). También puede conectar la MSAN a un enrutador de servicios de vídeo. Sin embargo, este método de conexión requiere que use una MSAN de capa 3 que tenga la capacidad de determinar qué vínculo se va a usar al reenviar el tráfico.
Cuando utilice el método de conexión directa, tenga en cuenta lo siguiente:
Recomendamos este enfoque siempre que sea posible para simplificar la administración de red.
Dado que se usan varias MSAN para conectarse al enrutador de servicios, y las MSAN de capa 3 generalmente requieren un costo de equipo más alto, este método rara vez se usa en un modelo de administración de suscriptores de múltiples bordes.
La conexión directa se usa normalmente cuando la mayoría de los vínculos de MSAN se utilizan menos del 33 por ciento y hay poco valor en combinar el tráfico de varias MSAN.
Conexión del conmutador de agregación Ethernet
Un conmutador de agregación Ethernet agrega tráfico desde varias MSAN descendentes en una sola conexión al enrutador de servicios (enrutador de servicios de banda ancha o enrutador de servicios de video opcional).
Cuando utilice el método de conexión del conmutador de agregación Ethernet, tenga en cuenta lo siguiente:
La agregación Ethernet se utiliza normalmente cuando la mayoría de los vínculos de MSAN se utilizan por encima del 33 % o para agregar tráfico desde MSAN de menor velocidad (por ejemplo, 1 Gbps) a una conexión de mayor velocidad al enrutador de servicios (por ejemplo, 10 Gbps).
Puede usar un enrutador de la serie MX como conmutador de agregación Ethernet. Para obtener información acerca de cómo configurar el enrutador de la serie MX en escenarios de capa 2, consulte la Guía del usuario de redes Ethernet para enrutadores de la serie MX.
Conexión de agregación de anillo
En una topología de anillo, la MSAN remota que se conecta a los suscriptores se denomina terminal remota (RT). Este dispositivo puede ubicarse en la planta exterior (OSP) o en una oficina central remota (CO). El tráfico atraviesa el anillo hasta llegar a la terminal de la oficina central (COT) en la cabecera del anillo. Luego, el COT se conecta directamente al enrutador de servicios (enrutador de servicios de banda ancha o enrutador de servicios de video).
El RT y el COT deben admitir el mismo protocolo de resistencia de anillo.
Puede usar un enrutador de la serie MX en una topología de agregación en anillo Ethernet. Para obtener información acerca de cómo configurar el enrutador de la serie MX en escenarios de capa 2, consulte la Guía del usuario de redes Ethernet para enrutadores de la serie MX.
Descripción general de la detección automática de pseudocables de LDP
Un pseudocable es un vínculo virtual que se utiliza para transportar un servicio de capa 2 a través de una red de acceso o borde de MPLS. En una red típica de borde de banda ancha o de borde empresarial, un extremo de un pseudocable se termina como un circuito de capa 2 en un nodo de acceso, y el otro extremo se termina como un circuito de capa 2 en un nodo de servicio que sirve como nodo de agregación o como red central de MPLS. Tradicionalmente, ambos puntos de conexión se aprovisionan manualmente a través de la configuración. La detección automática de pseudocables de LDP introduce un nuevo modelo de aprovisionamiento que permite que los puntos de conexión de pseudocables se aprovisionen y desaprovisionen automáticamente en los nodos de servicio en función de los mensajes de señalización de LDP. Este modelo puede facilitar el aprovisionamiento de pseudocables a gran escala. Un nodo de acceso utiliza LDP para señalar la identidad del pseudocable y los atributos a un nodo de servicio. La identidad se autentica mediante un servidor RADIUS y, luego, se utiliza junto con los atributos señalados por LDP y los atributos transmitidos por el servidor RADIUS para crear la configuración del punto de conexión pseudowire, incluido el circuito de capa 2.
- Antecedentes de la terminación de entrada de pseudocables
- Enfoque de detección automática de pseudocables
- Configuración de ejemplo
Antecedentes de la terminación de entrada de pseudocables
En una red de borde empresarial o de acceso de banda ancha habilitada para MPLS sin interrupciones, los pseudocables Ethernet se utilizan comúnmente como interfaces virtuales para conectar nodos de acceso a nodos de servicio. Cada pseudocable transporta el tráfico bidireccional de uno o varios suscriptores de banda ancha o clientes de borde empresarial entre un nodo de acceso y un par de nodos de servicio. El establecimiento del pseudocable generalmente lo inicia el nodo de acceso, ya sea en función de la configuración estática o la detección dinámica de un nuevo suscriptor de banda ancha o cliente de borde empresarial que llega a un puerto orientado al cliente en el nodo de acceso.
Idealmente, el nodo de acceso debería crear un pseudocable por puerto de cliente, donde todos los suscriptores o clientes alojados por el puerto estén asignados al pseudocable. La alternativa es cuando hay un pseudocable por puerto de cliente (S-VLAN) y todos los suscriptores o clientes que comparten una S-VLAN común en el puerto se asignan al pseudocable. En cualquier caso, el pseudocable se señala en modo sin procesar.
La S-VLAN, si no se usa para delimitar el servicio en el nodo de servicio o se combina con C-VLAN para distinguir suscriptores o clientes, se eliminará antes de que el tráfico se encapsule en la carga del pseudocable y se transporte al nodo de servicio. Los suscriptores o clientes individuales pueden distinguirse por C-VLAN o un encabezado de capa 2, como DHCP y PPP, que se transportará en una carga útil de pseudocable al nodo de servicio. En el nodo de servicio, el pseudocable se termina. Luego, los suscriptores o clientes individuales se demultiplexan y modelan como interfaces de suscriptor de banda ancha, interfaces de borde empresarial (por ejemplo, PPPoE), interfaces Ethernet o interfaces IP. Las interfaces Ethernet e IP se pueden adjuntar aún más a instancias de servicio, como VPLS e instancias de VPN de capa 3.
En Junos OS, la terminación de entrada de pseudocable en nodos de servicio se admite mediante el uso de interfaces físicas y lógicas de servicio de pseudocable. Este enfoque se considera superior en escalabilidad al antiguo enfoque basado en interfaz de túnel lógico, debido a su capacidad de multiplexar y demultiplexar suscriptores o clientes a través de un único pseudocable. Para cada pseudocable, se crea una interfaz física de servicio de pseudocable en un motor de reenvío de paquetes seleccionado, que se denomina motor de reenvío de paquetes de ancla. Además de esta interfaz física de servicio de pseudocable, se crea una interfaz lógica ps.0 (interfaz lógica de transporte) y un circuito de capa 2 o VPN de capa 2 para alojar la interfaz lógica ps.0 como una interfaz de adjuntos.
El circuito de capa 2 o VPN de capa 2 habilita la señalización de pseudocable hacia el nodo de acceso, y la interfaz lógica ps.0 cumple la función de interfaz orientada al borde del cliente para el pseudocable. Además, se pueden crear una o varias interfaces lógicas de ps.n (también conocidas como interfaces lógicas de servicio, donde n>0) en la interfaz física del servicio de pseudocable para modelar los flujos individuales de suscriptor/cliente como interfaces lógicas. Estas interfaces se pueden asociar a los servicios de borde empresarial y de banda ancha deseados o a instancias de VPN de capa 2 o capa 3.
Tenga en cuenta que el propósito del motor de reenvío de paquetes de anclaje es designar al motor de reenvío de paquetes para procesar el tráfico bidireccional del pseudocable, incluidos la encapsulación, la desencapsulación, VLAN mux o demux, QoS, políticas, formas y muchos más.
Para Junos OS versión 16.2 y anteriores, la creación y eliminación de las interfaces físicas del servicio de pseudocable, las interfaces lógicas del servicio de pseudocable, los circuitos de capa 2 y las VPN de capa 2 para la terminación de la entrada de pseudocables dependen de la configuración estática. Esta no se considera la mejor opción desde la perspectiva de la escalabilidad, eficiencia y flexibilidad, especialmente en una red donde cada nodo de servicio puede potencialmente alojar una gran cantidad de pseudocables. El objetivo es ayudar a los proveedores de servicios a salir de la configuración estática en el aprovisionamiento y desaprovisionamiento de la terminación de entrada de pseudocables en los nodos de servicio.
Enfoque de detección automática de pseudocables
En el enfoque de detección automática de pseudocables, un nodo de servicio utiliza el mensaje de asignación de etiquetas de LDP recibido de un nodo de acceso como desencadenante para generar dinámicamente la configuración de una interfaz física de servicio de pseudocable, una interfaz lógica de servicio de pseudocable y un circuito de capa 2. Del mismo modo, utiliza la etiqueta de LDP, el mensaje de retirada recibido del nodo de acceso y el evento de sesión inactiva de LDP como desencadenantes para eliminar la configuración generada. En la detección automática de pseudocables, se supone que los nodos de acceso son los iniciadores de la señalización de pseudocable y los nodos de servicio son los destinos. En una red en la que un servicio puede estar alojado por varios nodos de servicio para redundancia o equilibrio de carga, esto también proporciona nodos de acceso con un modelo de selección y conexión para el establecimiento de servicios. El flujo de control básico de la detección automática de pseudocables se muestra en la Figura 3
automática de pseudocables
El procedimiento básico de flujo de control de la autodetección de pseudocables es el siguiente:
El equipo local del cliente (CPE) se conecta y envía una trama Ethernet con C-VLAN al terminador de línea óptica (OLT). OLT agrega S-VLAN a la trama y envía la trama al nodo de acceso. El nodo de acceso consulta con el servidor de RADIUS para autorizar las VLAN.
El servidor RADIUS envía una aceptación de acceso al nodo de acceso. El nodo de acceso crea un circuito de capa 2 y envía una señal de pseudocable al nodo de servicio a través de un mensaje de asignación de etiquetas de LDP.
El nodo de servicio acepta el mensaje de asignación de etiquetas y envía una solicitud de acceso con información de pseudocable al servidor RADIUS para su autorización y selección de una interfaz física o lógica de servicio de pseudocable.
El servidor RADIUS envía una aceptación de acceso al nodo de servicio con una cadena de servicio que especifica el servicio, la interfaz física o la interfaz lógica del servicio de pseudocable seleccionado. El nodo de servicio crea una configuración de circuito de capa 2, la información del pseudocable y la interfaz física o lógica del servicio de pseudocable. El nodo de servicio envía una señal al pseudocable hacia el nodo de acceso a través de un mensaje de asignación de etiquetas de LDP. El pseudocable aparece bidireccionalmente.
Configuración de ejemplo
La siguiente configuración marca explícitamente el circuito de capa 2 como generado por la detección automática. La interfaz física del servicio de pseudocable y la configuración de interfaz lógica del servicio de pseudocable son opcionales, dependiendo de si preexisten.
Enrutador 0
[edit]
protocols {
Layer 2 circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
control-word;
mtu 9100;
auto-sensed;
}
}
}
}
Descripción general de la interfaz de servicio de servicios de capa 2 en pseudocable
La interfaz lógica de servicio pseudowire admite la interfaz lógica de transporte (psn.0) en el lado de acceso MPLS y las interfaces lógicas de servicio (psn.1 a psn.n) en el lado del núcleo MPLS de la red de administración de suscriptores.
El servicio pseudowire en las interfaces lógicas de servicio psn.1 a psn.n se configuran como interfaces de capa 2 en el dominio de puente o en una instancia de servicio LAN privada virtual (VPLS). Existe un circuito de capa 2 o una VPN de capa 2 a través de acceso MLPS entre un dispositivo de agregación Ethernet y un dispositivo de borde de servicio con el servicio pseudowire en la interfaz lógica de transporte psn.0 como interfaz de terminación del circuito de capa 2 o la VPN de capa 2 en el dispositivo de borde de servicio.
Junos OS admite el servicio pseudowire en las interfaces lógicas de servicio psn.1 a psn.n en el dominio de puente o la instancia VPLS, que recibe tráfico que sale del servicio pseudowire en la interfaz lógica de transporte en el dispositivo perimetral de servicio. También habilita funciones de entrada de capa 2, como el aprendizaje de MAC, las manipulaciones de VLAN y la búsqueda de MAC de destino en el servicio de pseudocable en interfaces lógicas de servicio.
Cuando el tráfico está en dirección inversa, la MAC de destino entra en el dominio de capa 2 en el dispositivo de borde de servicio, que se aprende como la MAC de origen en el servicio pseudowire en las interfaces lógicas de servicio. A partir de Junos OS versión 17.1R1, las interfaces de túnel lógico de pseudocable admiten los siguientes saltos de encapsulación de Ethernet VPLS, puente Ethernet, VLAN VPLS y puente VLAN para salir del tráfico de capa 2. A partir de la versión 18.4R1 de Junos OS, la compatibilidad del servicio de capa 2 con las interfaces lógicas del servicio pseudowire se extiende a las interfaces de servicio pseudowire ancladas también a interfaces de túnel lógico redundantes. Estos servicios de capa 2 solo se admiten en el servicio pseudowire en las interfaces lógicas de servicio (psn.1 a psn.n) y no en la interfaz lógica de transporte (psn.0). Las características de salida de capa 2, como manipulaciones de VLAN y otras, se habilitan en las interfaces de servicio de pseudocable. El tráfico que se envía fuera de las interfaces entra por el servicio pseudocable en las interfaces lógicas de transporte, que es la interfaz de circuito de capa 2 entre la agregación de Ethernet y los dispositivos de borde de servicio en todo el dominio de acceso MPLS.
Para Junos OS versión 16.2 y anteriores, no se pudieron configurar las encapsulaciones ni las funciones de capa 2 en el servicio pseudowire en interfaces lógicas de servicio.
- Tráfico de la LAN del cliente a MPLS
- Tráfico del borde del servicio a la LAN del cliente
- Interfaces de servicio de pseudocable
- Configuración de ejemplo
Tráfico de la LAN del cliente a MPLS
Las instancias VPLS-x y VPLS-y se configuran en el lado del núcleo de MPLS del dispositivo de borde de servicio (PE A). Se configura un circuito de capa 2 o VPN de capa 2 entre el dispositivo de agregación Ethernet (EAD 1) y el dispositivo de borde de servicio. ps0.0 (interfaz lógica de transporte) es la interfaz local en el circuito de capa 2 o la VPN de capa 2 en PE A. Junos OS admite el servicio de pseudocable en la interfaz lógica de servicio ps0.x (x>0) en la instancia VPLS VPLS-x (ID de VLAN en VPLS-x = m) y el servicio de pseudocable en la interfaz lógica de servicio ps0.y(y>0) en la instancia VPLS-y (ID de VLAN en VPLS-y = n).
En la Figura 4, cuando el tráfico proviene de EAD 1 a PE A (ya sea en el circuito de capa 2 o en VPN de capa 2) con cualquier ID de VLAN, el tráfico saldrá por ps0.0. Según el ID de VLAN en el tráfico, se selecciona el servicio pseudowire en la interfaz lógica del servicio. Por ejemplo, si el ID de VLAN es m, el tráfico entrará en ps0.x y si el ID de VLAN es n, el tráfico entrará en ps0.y.
lógica de servicio
Cuando el tráfico entra en el servicio pseudowire en la interfaz lógica de servicio ps0.n, donde n>0, se realizan los siguientes pasos.
El aprendizaje de MAC de origen debe producirse en el servicio pseudocable de capa 2 en la interfaz lógica de servicio. El motor de reenvío de paquetes de origen para esta MAC es el motor de reenvío de paquetes de la interfaz de túnel lógico en la que se ancla el servicio pseudowire en una instancia de VPLS o un dominio de puente en el dispositivo PE A.
La búsqueda de MAC de destino se realiza en el lado de entrada como una lista de características de familia de puentes de entrada de servicios de pseudocable en interfaces lógicas de servicio.
Si la búsqueda MAC de destino se realiza correctamente, el tráfico se envía como unidifusión; de lo contrario, se inundan la MAC de destino, la MAC de difusión y la MAC de multidifusión.
Si se produce un error en la búsqueda MAC de destino para el tráfico que llega a un servicio de pseudocable en una interfaz lógica de servicio, el
mlp querycomando se envía al motor de enrutamiento y al otro motor de reenvío de paquetes en el dominio de puente o en la instancia de VPLS.
Si se aprende un nuevo MAC en un servicio pseudowire en una interfaz lógica de servicio, el
mlp addcomando se envía al motor de enrutamiento y al otro motor de reenvío de paquetes en el dominio de puente o en la instancia de VPLS.
Tráfico del borde del servicio a la LAN del cliente
Cuando el tráfico entra en la instancia de VPLS o el dominio de puente en el dispositivo de borde de servicio, y si se aprende la MAC de destino en el tráfico en un servicio pseudowire en una interfaz lógica de servicio, el token asociado con esa interfaz lógica de servicio pseudowire se establece en el lado de la entrada. Luego, el tráfico se envía al motor de reenvío de paquetes, en el cual la interfaz de túnel lógico de la interfaz física del servicio pseudowire está anclada a través de una estructura. Cuando se inicia este token, es compatible con encapsulaciones de vlan, vpls, puente de vlan, Ethernet VPLS y puente Ethernet. El siguiente salto de encapsulación apunta a la lista de características de interfaz lógica de salida del servicio pseudowire en la interfaz lógica de servicio para ejecutar todas las características de salida de capa 2 y enviar el paquete al lado de entrada del servicio pseudowire en la interfaz lógica de transporte ps0.0.
Si la consulta MAC llega al motor de reenvío de paquetes en el que está anclado el servicio pseudowire, el motor de reenvío de paquetes envía la respuesta solo cuando el MAC aprendido en el servicio pseudowire en la interfaz lógica de servicio está presente. El token de capa 2 asociado con el servicio pseudowire en la interfaz lógica de servicio, visto después de la búsqueda MAC de destino para el MAC aprendido en el servicio pseudowire en la interfaz lógica de servicio, debe apuntar al siguiente salto asociado con el lado de acceso del servicio pseudowire en servicio la interfaz lógica.
El servicio de pseudocable en la interfaz lógica de transporte es la interfaz local ps0.0 del circuito de capa 2 o VPN de capa 2 entre el borde del servicio y los dispositivos de agregación Ethernet. El tráfico se envía al dispositivo de agregación Ethernet a través del circuito de capa 2 o la VPN de capa 2 a través del dominio de acceso MPLS.
Si el tráfico MAC de destino procedente del lado de entrada y salida del dispositivo de borde de servicio es desconocido o de multidifusión o difusión, el tráfico debe inundarse. Esto requiere que el siguiente salto de inundación de dispositivos de borde del cliente incluya el servicio pseudowire en la interfaz lógica del servicio, la cual actúa como interfaz lógica de acceso para la instancia de VPLS o el dominio de puente.
Interfaces de servicio de pseudocable
Las siguientes características son compatibles con las interfaces de servicio de pseudocable:
Una interfaz de servicio de pseudocable se aloja en una interfaz de túnel lógico (lt-x/y/z). El tráfico desde un servicio de pseudocable de transporte en una interfaz lógica a un servicio de pseudocable de suscriptor en una interfaz lógica se basa en el ID de VLAN disponible.
La transferencia de tráfico de un servicio de pseudocable de suscriptor en una interfaz lógica a un servicio de pseudocable de transporte en una interfaz lógica se basa en channelID a través de una dirección IP de circuito cerrado disponible.
Las interfaces lógicas del servicio Pseudowire en el servicio se admiten en la instancia de enrutamiento virtual de enrutamiento y reenvío (VRF).
-
Servicio de suscriptor (ps) de pseudocable en una interfaz troncal para terminar la instancia de circuito de capa 2 en un conmutador virtual habilitado para VPLS. El mismo circuito de capa 2 también se puede terminar en la instancia de enrutamiento de tipo instancia VPLS con interfaces lógicas de servicio diferentes, y la instancia de enrutamiento de tipo instancia VRF VPN de capa 3 utilizando también otra interfaz lógica de servicio.
Configuración de ejemplo
En las siguientes configuraciones de ejemplo, se muestra un servicio de pseudocable en una interfaz lógica de transporte en un circuito de capa 2, un servicio de pseudocable en interfaces lógicas de servicio en un dominio de puente y una instancia de VPLS en un dispositivo de borde de servicio, y un servicio de pseudocable en una interfaz de servicio de troncalización en una instancia de VPLS:
Servicio de pseudocable en una interfaz lógica de servicio en dominio de puente en el enrutador 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
}
}
bridge-domains {
bd1 {
domain-type bridge;
vlan-id 1;
interface ps0.1;
interface ge-0/0/0.1;
}
bd2 {
domain-type bridge;
vlan-id 2;
interface ps0.2;
interface ge-0/0/0.2;
}
}
Servicio de pseudocable en una interfaz lógica de servicio en una instancia de VPLS en el enrutador 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
}
}
routing-instances {
vpls-1 {
instance-type vpls;
vlan-id 1;
interface ps0.1;
interface ge-0/0/0.1;
}
vpls-2 {
instance-type vpls;
vlan-id 2;
interface ps0.2;
interface ge-0/0/0.2;
}
}
Servicio de pseudocable en una interfaz de servicio troncal en una instancia VPLS en el enrutador 0
[edit]
interfaces {
ps0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
family bridge {
interface-mode trunk;
vlan-id 1;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
family bridge;
}
}
}
routing-instances {
vpls-1 {
instance-type virtual-switch;
protocols {
vpls {
site PE3 {
interface ps0.1;
site-identifier 1;
}
}
}
bridge-domains {
bd1 {
vlan-id 1;
}
}
interface ps0.1;
route-distinguisher 65001:1;
vrf-target target:1:1;
}
}
Servicio de pseudocable en una interfaz lógica de servicio en un circuito de capa 2 en el enrutador 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-ccc;
vlan-id 1;
}
unit 2 {
encapsulation vlan-ccc;
vlan-id 2;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
neighbor 10.10.10.10 {
interface ps0.1 {
virtual-circuit-id 1;
}
}
neighbor 10.11.11.11 {
interface ps0.2 {
virtual-circuit-id 2;
}
}
}
}
Opciones de prestación de servicio de acceso de banda ancha
Hoy en día existen cuatro opciones de entrega principales para brindar el servicio de red de banda ancha. Estas opciones incluyen las siguientes:
Línea de suscriptor digital
La línea de suscriptor digital (DSL) es la tecnología de banda ancha más ampliamente desplegada en todo el mundo. Esta opción de entrega utiliza las líneas telefónicas existentes para enviar información de banda ancha en una frecuencia diferente a la que se utiliza para el servicio de voz existente. Muchas generaciones de DSL se utilizan para el servicio residencial, incluida la línea de suscriptor digital de muy alta velocidad 2 (VDSL2) y las versiones de la línea de suscriptor digital asimétrica (ADSL, ADSL2 y ADSL2+). Estas variaciones de DSL ofrecen principalmente un servicio de banda ancha residencial asimétrico donde se implementan diferentes velocidades ascendentes y descendentes. (VDSL2 también admite la operación simétrica). Otras variaciones de DSL, como la línea de suscriptor digital de alta velocidad de bits (HDSL) y la línea de suscriptor digital simétrica (SDSL), proporcionan velocidades simétricas y se utilizan normalmente en aplicaciones empresariales.
La cabecera de un sistema DSL es el multiplexor de acceso a línea de suscriptor digital (DSLAM). El dispositivo de demarcación en las instalaciones del cliente es un módem DSL. Los modelos de servicio DSL se definen en el Foro de banda ancha (anteriormente llamado Foro DSL).
Ethernet activo
Active Ethernet utiliza la tecnología Ethernet tradicional para ofrecer el servicio de banda ancha en una red de fibra óptica. Ethernet activa no proporciona un canal separado para el servicio de voz existente, por lo que se requiere equipo VoIP (o TDM a VoIP). Además, el envío de Ethernet a máxima velocidad (10 o 100 Mbps) requiere una potencia significativa, lo que requiere distribución a conmutadores Ethernet y repetidores ópticos ubicados en gabinetes fuera de la oficina central. Debido a estas restricciones, los primeros despliegues de Active Ethernet suelen aparecer en áreas densamente pobladas.
Redes ópticas pasivas
Las redes ópticas pasivas (PON), al igual que Active Ethernet, utilizan cables de fibra óptica para prestar servicios a las instalaciones. Esta opción de entrega proporciona velocidades más altas que DSL, pero velocidades más bajas que Active Ethernet. Aunque PON proporciona una mayor velocidad a cada suscriptor, requiere una mayor inversión en cable y conectividad.
Una ventaja clave de la PON es que no requiere ningún equipo con energía fuera de la oficina central. Cada fibra que sale de la oficina central se divide mediante un divisor óptico sin alimentación. La fibra dividida sigue una conexión de punto a punto a cada suscriptor.
Las tecnologías de PON se dividen en tres categorías generales:
PON ATM (APON), PON de banda ancha (BPON) y PON con capacidad de Gigabit (GPON): estándares de PON que utilizan las siguientes opciones de entrega diferentes:
APON: el primer estándar de red óptica pasiva se utiliza principalmente para aplicaciones empresariales.
BPON: basado en APON, BPON agrega multiplexación por división de onda (WDM), asignación de ancho de banda ascendente dinámica y más alta, y una interfaz de administración estándar para habilitar redes de proveedores mixtos.
GPON: GPON se basa en BPON, pero admite velocidades más altas, seguridad mejorada y la opción de qué protocolo de capa 2 usar (ATM, modelo de equipo genérico [GEM] o Ethernet).
PON Ethernet (EPON): proporciona capacidades similares a GPON, BPON y APON, pero usa estándares Ethernet. Estos estándares son definidos por el IEEE. La PON de Gigabit Ethernet (GEPON) es la versión de mayor velocidad.
PON de multiplexación por división de onda (WDM-PON): una PON no estándar que, como su nombre lo indica, proporciona una longitud de onda separada para cada suscriptor.
La cabecera de un sistema PON es un terminador de línea óptica (OLT). El dispositivo de demarcación en las instalaciones del cliente es un terminador de red óptica (ONT). La ONT proporciona puertos del lado del suscriptor para conectar Ethernet (RJ-45), cables telefónicos (RJ-11) o cable coaxial (conector F).
Fibra híbrida coaxial
Los operadores de sistemas múltiples (MSO; también conocidos como operadores de televisión por cable) ofrecen servicio de banda ancha a través de su red híbrida de fibra coaxial (HFC). La red HFC combina fibra óptica y cable coaxial para ofrecer servicio directamente al cliente. Los servicios salen de la oficina central (CO) mediante un cable de fibra óptica. Luego, el servicio se convierte fuera del CO en un árbol de cables coaxial utilizando una serie de nodos ópticos y, cuando sea necesario, a través de un amplificador de radiofrecuencia troncal (RF). Luego, los cables coaxiales se conectan a múltiples suscriptores. El dispositivo de demarcación es un módem de cable o decodificador, que se comunica con un sistema de terminación de módem de cable (CMTS) en la cabecera o instalación primaria de MSO que recibe señales de televisión para su procesamiento y distribución. El tráfico de banda ancha se transporta utilizando el estándar de especificación de interfaz de servicio de datos por cable (DOCSIS) definido por CableLabs y muchas empresas contribuyentes.
Entrega de banda ancha y FTTx
Muchas implementaciones utilizan el cableado de cobre existente para entregar la señal a las instalaciones, pero la conectividad del cable de fibra óptica se está acercando al suscriptor. La mayoría de las redes usan una combinación de cableado de cobre y fibra óptica. El término fibra a la x (FTTx) describe qué tan lejos en la red corre el cableado de fibra óptica antes de que se produzca un cambio al cableado de cobre. Tanto PON como Active Ethernet pueden usar la parte de fibra óptica de la red, mientras que xDSL se usa típicamente en la parte de cobre. Esto significa que un solo hilo de fibra óptica puede admitir múltiples suscriptores basados en cobre.
Aumentar el uso de fibra en la red aumenta el costo, pero también aumenta la velocidad de acceso a la red para cada suscriptor.
Los siguientes términos se utilizan para describir el punto de terminación del cable de fibra óptica en una red:
Fibra a las instalaciones (FTTP), fibra al hogar (FTTH), fibra a la empresa (FTTB): la fibra se extiende hasta el suscriptor. La PON es más común para el acceso residencial, aunque Active Ethernet se puede usar de manera eficiente en áreas densas, como complejos de apartamentos. Ethernet activa es más común para prestar servicios a empresas.
Fibra hasta la acera (FTTC): la fibra se extiende la mayor parte del camino (por lo general, 500 pies/150 metros o menos) hasta el suscriptor. El cobre existente se utiliza para la distancia restante al suscriptor.
Fibra al nodo o vecindad (FTTN): la fibra se extiende hasta unos pocos miles de pies del suscriptor y se convierte a xDSL para la distancia restante hasta el suscriptor.
Fibra al intercambio (FTTE): una implementación típica de xDSL basada en una oficina central en la que la fibra se usa para entregar tráfico a la oficina central y xDSL se usa en el bucle local existente.
Descripción del soporte de BNG para despliegues de DSLAM en cascada a través de canales DSL enlazados
Junos OS admite la configuración y el mantenimiento de las líneas de acceso entre los nodos de acceso y sus suscriptores de ANCP mediante el multiplexor de acceso DSL como la tecnología de acceso de banda ancha para cobre al edificio (CuTTB) y fibra al edificio (FTTB). Cuando varios suscriptores comparten la misma línea de acceso, esta puede ser de uno de los siguientes tipos:
-
PON, fibra hasta el edificio (FTTB)
-
DSL adherido de cobre al edificio (CTTB)
A partir de la versión 18.2R1 de Junos OS, las tecnologías de acceso a la red óptica pasiva (PON) son compatibles con cuatro niveles de jerarquía de programador de calidad de servicio (QoS) para suscriptores residenciales en un despliegue de BBE. Esta función extiende la implementación del Protocolo de control de nodo de acceso (ANCP) para manejar la configuración de red para clientes residenciales que usan PON como tecnología de acceso de banda ancha para CuTTB y FTTB. El ANCP utiliza un perfil de control de tráfico controlado estáticamente en el conjunto de interfaces para dar forma al nivel de suscriptor en el nodo intermedio al que están conectados los suscriptores. Se proporcionan nuevos tipos de DSL para soportar el ajuste de la velocidad de línea de acceso para las nuevas tecnologías de acceso.
Se introduce un nuevo VSA Inner-Tag-Protocol-Id de RADIUS, 26-211, para obtener el valor del identificador de protocolo de etiqueta VLAN interno para los suscriptores de L2BSA a fin de permitir el mantenimiento de un perfil dinámico en lugar de dos perfiles dinámicos independientes. Una nueva variable $junos-inner-vlan-tag-protocol-id de perfil dinámico de Junos OS permite establecer un mapa de inner-tag-protocol-id VLAN mediante RADIUS o un valor predeterminado predefinido proporcionado en la configuración.
- Beneficios de los despliegues de DSLAM en cascada sobre canales DSL vinculados
- Jerarquía de programador de 4 niveles
- Casos de uso de despliegues de DSLAM en cascada sobre canales DSL enlazados
- DSL adherido para cobre hasta el edificio (CuTTB)
- PON híbrida + G.fast
- Funciones compatibles
Beneficios de los despliegues de DSLAM en cascada sobre canales DSL vinculados
Esta función es útil para admitir despliegues de red de acceso en los que varios suscriptores comparten la misma línea de acceso agravada por un nodo intermedio entre el nodo de acceso y las puertas de enlace de enrutamiento domésticas. Otro beneficio es conservar los nodos CoS de capa 2. Por lo general, se crea un nodo ficticio de capa 2 para cada hogar residencial, lo que podría agotar los recursos de CoS de capa 2. Por lo tanto, los modelos de red que usan DSL vinculado, G.Fast y modelos de acceso PON pueden conservar los nodos CoS de capa 2.
Jerarquía de programador de 4 niveles
Junos OS es compatible con una jerarquía de programador de QoS de 4 niveles, lo que admite mínimamente el acceso residencial y L2BSA a través de despliegues de red de acceso de cobre al edificio (CTTB) o de fibra al edificio. Se admiten los siguientes niveles de jerarquía de programador de QoS:
-
Puerto de nivel 1 (interfaz física o AE)
-
Línea de acceso de nivel 2 (conjunto de interfaz lógica, representa una colección de suscriptores que comparten una línea de acceso dada agregada por un nodo intermedio)
-
Sesiones de suscriptor de nivel 3
-
Colas de nivel 4 (servicios)
del programador
En la Figura 5, el acceso residencial y L2BSA solo requieren una jerarquía de programador de 4 niveles. Actualmente no se admite el acceso de suscriptores empresariales y, por lo tanto, la jerarquía de programador de 4 niveles es suficiente para los servicios CuTTB y PON destinados a un edificio de apartamentos.
Casos de uso de despliegues de DSLAM en cascada sobre canales DSL enlazados
El DSL adherido para cobre al edificio (CuTTB) introduce una unidad de punto de distribución de cobre (DPU-C) de nodo intermedio entre el multiplexor de acceso DSL (DSLAM) y un grupo de suscriptores en la ubicación del cliente. Los modelos de despliegue de líneas de acceso compartido pueden ser del tipo Red óptica pasiva (PON) o líneas de cobre DSL vinculadas. A continuación se enumeran ejemplos de nodos intermedios:
-
DPU-C - DSL adherido para cobre hasta el edificio (CTTB)
-
ONU - PON (fibra hasta el edificio (FTTB)
-
PON híbrida y G.Fast
DSL adherido para cobre hasta el edificio (CuTTB)
enlazado
En la Figura 6, cada DPU-C tiene una sesión ANCP para informar los parámetros de línea de acceso de los suscriptores individuales conectados al nodo. La MSAN también tiene una sesión ANCP para informar a la DPU-C de los parámetros de la línea de acceso DSL enlazada. Por lo tanto, todos los suscriptores conectados a la DPU-C están sujetos a la velocidad descendente de la línea de acceso DSL, los suscriptores de DPU-C se agrupan en un conjunto de interfaces. Puede ajustar las velocidades notificadas en esta subida de puertos y aplicarlas al nodo CoS para el segmento de interfaz correspondiente, manteniendo la semántica del perfil de control de ajuste de CoS que se utiliza para líneas de suscriptor individuales. El modelo de acceso consiste en un híbrido de acceso DSL vinculado y acceso convencional no vinculado. Las sesiones de DPU-C y de ANCP del nodo de acceso multiservicio (MSAN) son completamente independientes y las etiquetas PPPoE-IA solo reflejan los atributos notificados en la sesión de ANCP de dPU-C
PON híbrida + G.fast
En la Figura 7, la OLT tiene una sesión de ANCP con el BNG y servidores proxy para todos los nodos de PON nativos descendentes. Los suscriptores de G.fast DSL están conectados a un nodo intermedio, que tiene una conexión PON a la ONU intermedia delante de la OLT.
Una red de acceso híbrido conecta líneas de suscriptores basadas en DSL utilizando tanto el acceso PON como los nodos G.fast con un nodo intermedio entre la OLT y las puertas de enlace domésticas (HG). Tanto las empresas como las residencias están conectadas al nodo intermedio, que es la hoja PON. La configuración es necesaria tanto a nivel de suscriptor como a nivel de hoja de PON. Estos suscriptores de G.fast están asociados con la ONU intermedia como un suscriptor PON nativo. La AN admite nuevos TLV de tipo DSL y sus valores se informan en el puerto ANCP para la línea de acceso del suscriptor correspondiente. Sin embargo, todavía no es posible distinguir entre un nodo intermedio y una conexión convencional para una sesión PPPoE determinada.
Funciones compatibles
-
Compatibilidad con la formación de tráfico basada en ANCP en iflsets dinámicos.
-
Preservación de la independencia de PPP0E-IA y ANCP mediante la configuración de CLI para suscriptores residenciales.
-
Nuevo VSA Juniper, se admite ERX-Inner-Vlan-Tag-Protocol-Id (4874-26-211) para obtener el valor del identificador de protocolo de etiqueta VLAN interno para suscriptores de L2BSA como una optimización para mantener dos perfiles dinámicos independientes, uno para TPID - 0x88a8 y otro para 0x8100, y obtener el valor deseado devolviendo 4874-26-174 (Client-Profile-Name) en Access-Accept.
-
Se admiten los siguientes valores de tipo adicionales para el tipo DSL TLV. Todos los suscriptores incluyen estos TLV de tipo DSL en las etiquetas IA PPPoE de los mensajes PPPoE PADR.
-
(8) G.rápido
-
(9) Anexo Q de VDSL2
-
(10) SDSL en condiciones de servidumbre
-
(11) VDSL2 unido
-
(12) G, unión rápida
-
(13) VDSL2 Anexo Q unido
-
Detección de identificadores de línea de retorno y generación automática de conjuntos de interfaces de nodo intermedio
Antes de comenzar, debe confirmar que los nodos de acceso o IA existentes no estén insertando cadenas que comiencen por el # carácter. Dado que se trata de una configuración a nivel del sistema, el análisis se aplica a todos los nodos de acceso de ANCP y los AI PPPoE a nivel global. El personaje principal # no es configurable. El análisis está deshabilitado de forma predeterminada en caso de que algunos proveedores usen ese carácter para algún otro propósito.
A partir de la versión 18.4R1 de Junos OS, puede configurar el enrutador para que detecte un nodo intermedio lógico en una red de acceso. El nodo identifica a los suscriptores que están conectados al mismo medio compartido, como un árbol PON o una línea de cobre enlazada que se conecta a una DPU-C para CuTTB. Cuando configure esta detección, el enrutador analiza el atributo ANCP Access-Aggregation-Circuit-ID-ASCII (TLV 0x03) que se recibe en el mensaje ANCP Port Up o en las etiquetas PPPoE PADR IA. Si la cadena TLV comienza con el # carácter, la cadena es un identificador de línea de retorno que es único en toda la red para identificar la línea DSL enlazada o el árbol PON. La misma cadena se informa en el TLV o IA para todos los suscriptores conectados a esa DPU-C o PON.
La parte de la cadena después del # carácter representa el nodo intermedio lógico. Se utiliza como nombre del conjunto de interfaces dinámicas para el nodo de nivel 2 de CoS que agrupa a los suscriptores mediante ese nodo intermedio. Este conjunto de interfaces se conoce como conjunto de interfaces primario. Cada interfaz lógica PPPoE o VLAN (L2BSA) con el mismo valor para TLV 0x03 es miembro de ese conjunto de interfaces.
El valor TLV debe coincidir con los requisitos para la nomenclatura del conjunto de interfaces; Puede incluir caracteres alfanuméricos y los siguientes caracteres especiales:
# % / = + - : ; @ . _
Esta parte de la cadena también establece el valor de la variable predefinida $junos-aggregation-interface-set-name en el perfil dinámico. Este valor se utiliza como el nombre de un conjunto de interfaces de nivel 2 de CoS que agrupa a los suscriptores que comparten esa cadena. Anula la variable predeterminada predefinida, que utiliza el valor de $junos-phy-ifd-interface-set-name como nombre del conjunto de interfaces.
Por ejemplo, si el valor de la cadena de TLV es #TEST-DPU-C-100, el valor de la variable predefinida (y, por consiguiente, el nombre del conjunto de interfaces) se convierte en TEST-DPU-C-100.
El Access-Loop-Remote-ID (TLV (0x02) se analiza de forma similar para el # carácter, pero la cadena resultante no se utiliza en la versión actual.
La detección de nodos intermedios solo se admite para jerarquías de programador de 4 niveles, por lo que el acceso empresarial se limita a las MPC de acceso DSL convencionales.
Para habilitar el análisis del TLV Access-Aggregation-Circuit-ID-ASCII y establecer el nombre del conjunto de interfaces:
En la siguiente configuración de ejemplo, se muestra un perfil dinámico para suscriptores de L2BSA. Tres cosas a tener en cuenta aquí son las siguientes:
Se define un valor predeterminado de $junos-phy-ifd-interface-set-name para la variable predefinida $junos-aggregation-interface-set-name.
El nombre del conjunto de interfaces está configurado para ser el valor de $junos-aggregation-interface-set-name.
La configuración del programador de CoS especifica una interfaz denominada con el valor de $junos-aggregation-interface-set-name.
Cuando hierarchical-access-network-detection se configura para las líneas de acceso, el nombre del conjunto de interfaces del programador de nivel 2 se determina de la siguiente manera:
Cuando TLV 0x03 comienza con
#, $junos-aggregation-interface-set-name es el resto de la cadena, excluyendo la inicial#.Cuando TLV 0x03 comienza con cualquier otro carácter, $junos-aggregation-interface-set-name es el valor de $junos-phy-ifd-interface-set-name.
[edit dynamic-profiles L2BSA-subscriber]
predefined-variable-defaults {
aggregation-interface-set-name phy-ifd-interface-set-name;
cos-shaping-rate 1g;
cos-scheduler-map schedmap_L2BSA;
inner-vlan-tag-protocol-id 0x88a8;
}
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
}
}
interfaces {
interface-set $junos-aggregation-interface-set-name {
interface "$junos-interface-ifd-name" {
unit "$junos-interface-unit";
}
}
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
encapsulation vlan-vpls;
no-traps;
vlan-id "$junos-vlan-id";
input-vlan-map {
swap-push;
inner-tag-protocol-id "$junos-inner-vlan-tag-protocol-id"
vlan-id "$junos-vlan-map-id";
inner-vlan-id "$junos-inner-vlan-map-id";
}
output-vlan-map {
pop-swap;
inner-tag-protocol-id 0x8100;
}
family vpls;
}
}
}
class-of-service {
traffic-control-profiles {
L2BSAShaper {
scheduler-map "$junos-cos-scheduler-map";
shaping-rate "$junos-cos-shaping-rate" burst-size 17k;
overhead-accounting frame-mode cell-mode-bytes 6;
}
L2iflsetShaper {
shaping-rate 1G burst-size 17k;
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
output-traffic-control-profile L2BSAShaper;
classifiers {
ieee-802.1 L2BSA vlan-tag outer;
}
rewrite-rules {
ieee-802.1 L2BSA vlan-tag outer;
}
}
}
interface-set "$junos-aggregation-interface-set-name" {
output-traffic-control-profile L2iflsetShaper;
}
}
}
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.