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 suscriptor puede incluir varios componentes, incluidas tecnologías de acceso de suscriptor y protocolos de autenticación.
Las tecnologías de acceso de 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.
Esta función requiere una licencia. Para obtener más información sobre las licencias de acceso de suscriptores, consulte Descripción general de licencias de acceso de suscriptores. Consulte la Guía de licencias de Juniper para obtener información general sobre la administración de licencias. Consulte las hojas de datos del producto en Enrutadores de la serie MX para obtener más detalles, o comuníquese con su equipo de cuentas de Juniper o con su socio de Juniper.
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 de 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, además de proporcionar conexiones para circuitos adicionales, como el servicio telefónico antiguo (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 según la forma en que 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 utilizan conmutación Ethernet (o ATM) para reenviar el tráfico. La MSAN reenvía todo el tráfico de suscriptores ascendente a un enrutador perimetral que actúa como punto de control centralizado e impide la comunicación directa de suscriptor a suscriptor. La agregación de vínculo Ethernet (LAG) proporciona la resistencia 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 IP puede interpretar y responder a solicitudes IGMP replicando localmente una transmisión de multidifusión y reenviando la transmisión a cualquier suscriptor que la 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 compatibles con 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 al DSLAM. Sin embargo, los DSLAM dinámicos compatibles con IP pueden informar a la red para que comience (o interrumpa) el envío de canales individuales al DSLAM. La configuración del proxy IGMP o del espionaje IGMP en el DSLAM cumple esta función.
Layer–3 MSAN—Estas MSAN utilizan la funcionalidad de enrutamiento IP en lugar de las 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 enlaces ascendentes que van a diferentes enrutadores ascendentes y mejorar la resistencia de la red. Sin embargo, para lograr este nivel de resistencia, debe asignar una subred IP independiente a cada MSAN, agregando 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:
Opciones de agregación de MSAN Ethernet
Cada MSAN puede conectarse directamente a un enrutador perimetral (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 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 opcionales. |
Conexión del 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 opcionales. |
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 diferentes 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 perimetral.
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 multiplexación por división de onda (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 utilice una MSAN de capa 3 que tenga la capacidad de determinar qué vínculo utilizar al reenviar tráfico.
Cuando utilice el método de conexión directa, tenga en cuenta lo siguiente:
Recomendamos este enfoque cuando sea posible para simplificar la administración de la red.
Debido a 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 MSAN se utilizan menos del 33 por ciento y hay poco valor en combinar el tráfico de múltiples MSAN.
Conexión del conmutador de agregación Ethernet
Un conmutador de agregación Ethernet agrega tráfico de varias MSAN descendentes en una única 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 de Ethernet se usa normalmente cuando la mayoría de los vínculos MSAN se utilizan en más del 33 % o para agregar tráfico de MSAN de menor velocidad (por ejemplo, 1 Gbps) a una conexión de mayor velocidad al enrutador de servicios (por ejemplo, 10 Gbps).
Puede utilizar 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 remoto (RT). Este dispositivo puede ubicarse en la planta exterior (OSP) o en una oficina central remota (CO). El tráfico atraviesa el anillo hasta que llega a la terminal de la oficina central (COT) en la cabecera del anillo. A continuación, el COT se conecta directamente al enrutador de servicios (enrutador de servicios de banda ancha o enrutador de servicios de vídeo).
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 de 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 MPLS. En una red típica de borde de banda ancha o de borde empresarial, un extremo de un pseudocable termina como un circuito de capa 2 en un nodo de acceso, y el otro extremo termina como un circuito de capa 2 en un nodo de servicio que sirve como nodo de agregación o como red central 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 finales 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 tanto la identidad como los atributos de pseudocable a un nodo de servicio. Un servidor RADIUS autentica la identidad y, a continuación, se utiliza junto con los atributos señalados por LDP y los atributos transmitidos por el servidor RADIUS para crear la configuración del extremo de pseudocable, incluido el circuito de capa 2.
- Antecedentes de terminación de ingreso de pseudocable
- Enfoque de detección automática de pseudocables
- Configuración de ejemplo
Antecedentes de terminación de ingreso de pseudocable
En una red de borde empresarial o de acceso de banda ancha habilitado para MPLS sin interrupciones, los pseudocables Ethernet se usan 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 nodo de acceso suele iniciar el establecimiento del pseudocable, ya sea en función de la configuración estática o de la detección dinámica de un nuevo suscriptor de banda ancha o cliente de borde empresarial que llega a un puerto orientado hacia el cliente en el nodo de acceso.
Idealmente, el nodo de acceso debería crear un pseudocable por puerto cliente, donde todos los suscriptores o clientes alojados en el puerto se asignan 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 el modo sin procesar.
La S-VLAN, si no se usa para delimitar el servicio en el nodo de servicio o si no se combina con C-VLAN para distinguir suscriptores o clientes, se eliminará antes de que el tráfico se encapsule en la carga útil 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 carga de pseudocable al nodo de servicio. En el nodo de servicio, el pseudocable termina. A continuación, 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 conectar aún más a las instancias de servicio, como las instancias de VPLS y VPN de capa 3.
En Junos OS, la terminación de entrada de pseudocables en los 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 la interfaz de túnel lógico, debido a su capacidad de multiplexar y demultiplexar suscriptores o clientes a través de un solo 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 se crea un circuito de capa 2 o VPN de capa 2 para alojar la interfaz lógica ps.0 como interfaz de adjuntos.
El circuito de capa 2 o VPN de capa 2 permite la señalización de pseudocables 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 ps.n (también conocidas como interfaces lógicas de servicio, donde n>0) en la interfaz física del servicio pseudocable para modelar flujos individuales de suscriptor/cliente como interfaces lógicas. Estas interfaces se pueden conectar a los servicios de banda ancha y borde empresarial deseados o a instancias 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 el motor de reenvío de paquetes para procesar el tráfico bidireccional del pseudocable, incluida la encapsulación, la desencapsulación, VLAN mux o demux, QoS, policía, forma y muchos más.
Para Junos OS versión 16.2 y anteriores, la creación y eliminación de las interfaces físicas de servicio de pseudocable, las interfaces lógicas de servicio de pseudocable, los circuitos de capa 2 y las VPN de capa 2 para la terminación de entrada de pseudocable se basa en la configuración estática. Esto no se considera la mejor opción desde la perspectiva de escalabilidad, eficiencia y flexibilidad, especialmente en una red donde cada nodo de servicio puede albergar potencialmente 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 LDP recibido de un nodo de acceso como desencadenador para generar dinámicamente la configuración de una interfaz física de servicio de pseudocable, una interfaz lógica de servicio de pseudocable, un circuito de capa 2. Del mismo modo, utiliza el mensaje de retirada de etiquetas LDP recibido del nodo de acceso y el evento de inactividad de sesión LDP como desencadenadores 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 pseudocables 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 a los nodos de acceso un modelo de selección y conexión para el establecimiento del servicio. El flujo de control básico de la detección automática de pseudocables se muestra en la Figura 3
El procedimiento básico de flujo de control de la detección automática de pseudocables es el siguiente:
El equipo en las instalaciones del cliente (CPE) entra en línea 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 comprueba con el servidor 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 un pseudocable al nodo de servicio a través de un mensaje de asignación de etiquetas 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 autorización y selección de una interfaz física de servicio de pseudocable o una interfaz lógica.
El servidor RADIUS envía una aceptación de acceso al nodo de servicio con una cadena de servicio que especifica la interfaz física o lógica del servicio de pseudocable seleccionada. El nodo de servicio crea una configuración de circuito de capa 2, la información del pseudocable y la interfaz física o interfaz lógica del servicio de pseudocable. El nodo de servicio señala el pseudocable hacia el nodo de acceso a través de un mensaje de asignación de etiquetas LDP. El pseudocable aparece bidireccionalmente.
Configuración de ejemplo
La siguiente configuración marca explícitamente el circuito de capa 2 como generado por detección automática. La interfaz física del servicio de pseudocable y la configuración de la 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 los servicios de capa 2 en la interfaz de servicio de Pseudowire
La interfaz lógica del 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 principal de 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 de LAN privada virtual (VPLS). Existe un circuito de capa 2 o VPN de capa 2 en el acceso MLPS entre un dispositivo de agregación Ethernet y un dispositivo perimetral 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 perimetral de servicio.
Junos OS admite el servicio de pseudocable en las interfaces lógicas de servicio psn.1 a psn.n en el dominio de puente o en la instancia de VPLS, que recibe el tráfico que sale del servicio de pseudocable 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 pseudowire en interfaces lógicas de servicio.
Cuando el tráfico va en sentido inverso, la MAC de destino entra en el dominio de capa 2 en el dispositivo perimetral de servicio, que se aprende como MAC de origen en el servicio de pseudocable 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 próximos 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 Junos OS versión 18.4R1, la compatibilidad del servicio de capa 2 con las interfaces lógicas de servicio de pseudocable se extiende también a las interfaces de servicio de pseudocable ancladas sobre interfaces de túnel lógico redundantes. Estos servicios de capa 2 solo se admiten en el servicio de pseudocable en 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 las manipulaciones de VLAN y otras, están habilitadas en las interfaces de servicio de pseudocable. El tráfico enviado fuera de las interfaces entra en el servicio de 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 versiones anteriores, no se pudieron configurar las encapsulaciones o funciones de capa 2 en el servicio de pseudocable en interfaces lógicas de servicio.
- Tráfico de LAN del cliente a MPLS
- Tráfico desde el borde de servicio a la LAN del cliente
- Interfaces de servicio de Pseudowire
- Configuración de ejemplo
Tráfico de LAN del cliente a MPLS
Las instancias VPLS-x y VPLS-y se configuran en el lado central MPLS del dispositivo perimetral 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 perimetral 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 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 (en un circuito de capa 2 o en VPN de capa 2) con cualquier ID de VLAN, el tráfico saldrá a través de ps0.0. En función del 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.
Cuando el tráfico entra en el servicio de pseudocable 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 de pseudocable de capa 2 de la interfaz lógica del servicio. El motor de reenvío de paquetes de origen para este MAC es el motor de reenvío de paquetes de la interfaz de túnel lógico en la que el servicio de pseudocable está anclado en una instancia de VPLS o un dominio de puente en el dispositivo PE A.
La búsqueda MAC de destino se realiza en el lado de entrada como una lista de características de la familia de puentes de entrada de servicios 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, el MAC de destino, el MAC de difusión y el MAC de multidifusión se inundan.
Si se produce un error en la búsqueda MAC de destino para el tráfico procedente de un servicio de pseudocable en una interfaz lógica de servicio, el
mlp query
comando 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 de pseudocable en una interfaz lógica de servicio, el
mlp add
comando 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 desde el borde de servicio a la LAN del cliente
Cuando el tráfico entra en la instancia de VPLS o en el dominio de puente en el dispositivo perimetral de servicio y si la MAC de destino en el tráfico se aprende en un servicio de pseudocable en una interfaz lógica de servicio, el token asociado con esa interfaz lógica de servicio de pseudocable se establece en el lado de entrada. A continuación, el tráfico se envía al motor de reenvío de paquetes en el que la interfaz de túnel lógico de la interfaz física del servicio de pseudocable está anclada a través de una estructura. Cuando se lanza este token, admite encapsulaciones VLAN VPLS, puente 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 de pseudocable 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 de pseudocable 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 de pseudocable, el motor de reenvío de paquetes envía la respuesta sólo cuando el MAC aprendido en el servicio de pseudocable en la interfaz lógica del servicio está presente. El token de capa 2 asociado con el servicio de pseudocable en la interfaz lógica de servicio visto después de la búsqueda MAC de destino para el MAC aprendido en el servicio de pseudocable en la interfaz lógica de servicio debe apuntar al siguiente salto asociado con el lado de acceso del servicio de pseudocable en el servicio de 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 de servicio y los dispositivos de agregación de Ethernet. El tráfico se envía al dispositivo de agregación Ethernet a través del circuito de capa 2 o 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 perimetral de servicio es desconocido o multidifusión o difusión, es necesario inundar el tráfico. Para ello, es necesario que el siguiente salto de una inundación de dispositivos perimetrales del cliente incluya el servicio de pseudocable en la interfaz lógica de servicio, que actúa como interfaz lógica de acceso para la instancia de VPLS o el dominio de puente.
Interfaces de servicio de Pseudowire
Las siguientes características son compatibles con las interfaces de servicio de pseudocable:
Una interfaz de servicio de pseudocable se aloja sobre 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 hasta 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 el ID de canal a través de una dirección IP de circuito cerrado disponible.
El servicio de pseudocable en interfaces lógicas de servicio se admite en la instancia de enrutamiento y reenvío virtual (VRF).
-
Servicio de suscriptor de pseudocable (ps) 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 diferentes interfaces lógicas de servicio y en la instancia de enrutamiento de tipo instancia VRF VPN de capa 3 que también utiliza otra interfaz lógica de servicio.
Configuración de ejemplo
Las siguientes configuraciones de ejemplo muestran 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 perimetral de servicio, y un servicio de pseudocable en una interfaz de servicio troncal en una instancia de VPLS:
Servicio de pseudocable en una interfaz lógica de servicio en un 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 de 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 servicios de acceso de banda ancha
Hoy en día existen cuatro opciones de entrega principales para la prestación de servicios de red de banda ancha. Estas opciones incluyen lo siguiente:
Línea de suscriptor digital
La línea de abonado digital (DSL) es la tecnología de banda ancha más 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 utilizada para el servicio de voz existente. Muchas generaciones de DSL se utilizan para el servicio residencial, incluida la línea 2 del suscriptor digital de muy alta velocidad (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 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 generalmente se usan en aplicaciones comerciales.
La cabecera de un sistema DSL es el Multiplexor de acceso a la 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 están definidos por el Foro de Banda Ancha (anteriormente llamado Foro DSL).
Ethernet activo
Active Ethernet utiliza la tecnología Ethernet tradicional para ofrecer un servicio de banda ancha a través de una red de fibra óptica. Active Ethernet no proporciona un canal separado para el servicio de voz existente, por lo que se requiere un equipo de VoIP (o TDM a VoIP). Además, el envío de Ethernet de velocidad completa (10 o 100 Mbps) requiere una potencia significativa, lo que requiere la 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 la Ethernet activa, utilizan cable 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 mayor velocidad a cada suscriptor, requiere una mayor inversión en cable y conectividad.
Una ventaja clave de PON es que no requiere ningún equipo motorizado fuera de la oficina central. Cada fibra que sale de la oficina central se divide utilizando un divisor óptico sin alimentación. Luego, la fibra dividida sigue una conexión punto a punto con cada suscriptor.
Las tecnologías 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 usan las siguientes opciones de entrega:
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 ondas (WDM), asignación dinámica y más alta de ancho de banda ascendente 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 elegir qué protocolo de capa 2 usar (ATM, modelo genérico de equipo [GEM] o Ethernet).
PON de Ethernet (EPON): proporciona capacidades similares a GPON, BPON y APON, pero utiliza estándares de Ethernet. Estos estándares son definidos por el IEEE. Gigabit Ethernet PON (GEPON) es la versión de mayor velocidad.
PON de multiplexación por división de onda (WDM-PON): un 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 multisistema (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 coaxiales utilizando una serie de nodos ópticos y, cuando es 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 por cable (CMTS) en la cabecera de MSO o instalación primaria 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 Data Over Cable Service Interface Specification (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 utilizan una combinación de cableado de cobre y fibra óptica. El término fibra a la x (FTTx) describe qué tan lejos se ejecuta el cableado de fibra óptica de la red 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 una sola hebra 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. 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 la prestación de servicios a las empresas.
Fibra a la acera (FTTC): la fibra se extiende la mayor parte del camino (normalmente, 500 pies/150 metros o menos) hasta el suscriptor. El cobre existente se utiliza para la distancia restante al suscriptor.
Fibra al nodo/vecindario (FTTN): la fibra se extiende a unos pocos miles de pies del suscriptor y se convierte en xDSL para la distancia restante del suscriptor.
Fibra al intercambio (FTTE): una implementación típica de xDSL basada en 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 de la compatibilidad de BNG para despliegues 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 ANCP mediante el uso del multiplexor de acceso DSL como 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, la línea de acceso puede ser de uno de los siguientes tipos:
PON, fibra al edificio (FTTB)
DSL unido de cobre al edificio (CTTB)
A partir de Junos OS versión 18.2R1, 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 una implementación de BBE. Esta característica amplía 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. 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 DSL para admitir el ajuste de la velocidad de línea de acceso para las nuevas tecnologías de acceso.
Se introduce un nuevo RADIUS VSA, Inner-Tag-Protocol-Id
26-211 para obtener el valor interno del identificador de protocolo de etiqueta VLAN para los suscriptores de L2BSA para permitir el mantenimiento de un perfil dinámico en lugar de dos perfiles dinámicos separados. Una nueva variable $junos-inner-vlan-tag-protocol-id de perfil dinámico de Junos OS permite establecer un mapa VLAN inner-tag-protocol-id
mediante RADIUS o un valor predeterminado predefinido proporcionado en la configuración.
- Beneficios de los despliegues de DSLAM en cascada a través de canales DSL enlazados
- Jerarquía del programador de 4 niveles
- Casos de uso de despliegues DSLAM en cascada a través de canales DSL enlazados
- DSL unido para cobre al edificio (CuTTB)
- PON híbrido + G.fast
- Características soportadas
Beneficios de los despliegues de DSLAM en cascada a través de canales DSL enlazados
Esta característica es útil para admitir implementaciones de red de acceso en las que varios suscriptores comparten la misma línea de acceso aggegrated por un nodo intermedio entre el nodo de acceso y las puertas de enlace de enrutamiento de origen. Otro beneficio es conservar los nodos CoS de capa 2. Normalmente, 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 utilizan modelos de acceso DSL, G.Fast y PON vinculados pueden conservar nodos CoS de capa 2.
Jerarquía del programador de 4 niveles
Junos OS admite la jerarquía del programador de QoS de 4 niveles, lo que admite como mínimo el acceso residencial y L2BSA a través de implementaciones de red de acceso de cobre al edificio (CTTB) o fibra al edificio. Se admiten los siguientes niveles de jerarquía del programador 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 determinada agregada por un nodo intermedio)
Sesiones de suscriptor de nivel 3
Colas de nivel 4 (servicios)
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 del programador de 4 niveles es suficiente para los servicios CuTTB y PON dirigidos a un edificio de apartamentos.
Casos de uso de despliegues DSLAM en cascada a través de canales DSL enlazados
DSL unido para cobre al edificio (CuTTB) introduce un nodo intermedio Unidad de punto de distribución de cobre (DPU-C) 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 de tipo red óptica pasiva (PON) o líneas de cobre DSL enlazadas. A continuación se enumeran algunos nodos intermedios de ejemplo:
DPU-C - DSL unido para cobre al edificio (CTTB)
ONU - PON (Fibra al edificio (FTTB)
PON híbrido y G.Fast
DSL unido para cobre al edificio (CuTTB)
En la Figura 6, cada DPU-C tiene una sesión ANCP para informar los parámetros de la línea de acceso de suscriptores individuales conectados al nodo. La MSAN también tiene una sesión ANCP para informar los parámetros de la línea de acceso de la línea de acceso DSL enlazada a la DPU-C. 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 la DPU-C se agrupan en un conjunto de interfaces. Puede ajustar las velocidades notificadas en este puerto y aplicarlas al nodo CoS para el ste 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 ANCP de DPU-C y del nodo de acceso multiservicio (MSAN) son completamente independientes y las etiquetas PPPoE-IA solo reflejan los atributos notificados en la sesión ANCP de dPU-C
PON híbrido + G.fast
En la figura 7, la OLT tiene una sesión ANCP con el BNG y proxies para todos los nodos 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íbrida conecta líneas de abonado basadas en DSL utilizando tanto acceso PON como 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. El modelado es necesario tanto a nivel de suscriptor como a nivel de hoja de PON. Los suscriptores de G.fast están asociados con la ONU intermedia como un suscriptor PON nativo. Los nuevos TLV de tipo DSL son compatibles con la AN y sus valores se informan en el ANCP Port-Up para la línea de acceso de suscriptor correspondiente. Sin embargo, todavía no es posible distinguir entre un nodo intermedio y una conexión convencional para una sesión PPPoE dada.
Características soportadas
Admite la configuració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.
El nuevo VSA de Juniper, ERX-Inner-Vlan-Tag-Protocol-Id (4874-26-211) es compatible para obtener el valor interno del identificador de protocolo de etiqueta VLAN para suscriptores de L2BSA como una optimización para mantener dos perfiles dinámicos separados, 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 TLV de tipo DSL. Todos los suscriptores incluyen estos TLV de tipo DSL en las etiquetas PPPoE IA de los mensajes PPPoE PADR.
(8) G.fast
(9) Anexo Q de VDSL2
(10) SDSL en condiciones de servidumbre
(11) VDSL2 en régimen de servidumbre
(12) G, unión rápida
(13) Anexo Q de VDSL2 en régimen de servidumbre
Detección de identificadores de línea de retorno y autogeneración de conjuntos de interfaces de nodos intermedios
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 de nivel de sistema, el análisis se aplica a todos los nodos de acceso ANCP e IA PPPoE a nivel mundial. El carácter principal #
no es configurable. El análisis está deshabilitado de forma predeterminada en caso de que algunos proveedores utilicen ese carácter para algún otro propósito.
A partir de Junos OS versión 18.4R1, puede configurar el enrutador para detectar 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 se configura 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 notifica en el TLV o IA para todos los suscriptores conectados a esa DPU-C o PON.
La parte de la cadena que sigue al #
carácter representa el nodo intermedio lógico. Se utiliza como nombre del conjunto de interfaz dinámica para el nodo CoS nivel 2 que agrupa a los suscriptores que utilizan ese nodo intermedio. Este conjunto de interfaces se conoce como conjunto de interfaces principal. 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 nombre de un conjunto de interfaces de nivel 2 de CoS que agrupa a los suscriptores que comparten esa cadena. Invalida el valor predeterminado de la variable 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 TLV es #TEST-DPU-C-100, el valor de la variable predefinida y, en consecuencia, el nombre del conjunto de interfaz, se convierte en TEST-DPU-C-100.
El ID remoto de bucle de acceso (TLV (0x02) se analiza de manera 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 programadores de 4 niveles, por lo que el acceso empresarial está limitado a las MPC de acceso DSL convencionales.
Para habilitar el análisis de la TLV Access-Aggregation-Circuit-ID-ASCII y establecer el nombre del conjunto de interfaces:
La siguiente configuración de ejemplo muestra un perfil dinámico para los 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 la 0x03 TLV comienza con
#
, entonces $junos-aggregation-interface-set-name es el resto de la cadena, excluyendo la inicial#
.Cuando el 0x03 TLV comienza con cualquier otro carácter, entonces $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 con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.