Ejemplo: Configuración de la duplicación de puertos remotos en enrutadores PTX
En este ejemplo, se muestra cómo configurar y verificar la duplicación de puertos remotos en plataformas PTX que ejecutan Junos Evolved. Las plataformas PTX incluyen PTX10001-36MR, LC1201 y LC1202 en chasis PTX10004, PTX10008 y PTX10016.
Antes de empezar
| Requisitos de hardware y software | Junos OS evolucionado versión 22.2R1.12-EVO o posterior. PTX10001-36MR Consulte Explorador de características para obtener una lista completa de plataformas compatibles y versiones de Junos OS. |
| Tiempo estimado de lectura |
Quince minutos. |
| Tiempo estimado de configuración |
Treinta minutos |
| Impacto comercial |
La duplicación de puertos es una herramienta fundamental para la depuración y las tareas relacionadas con la seguridad. El tráfico duplicado se puede analizar fuera de línea mediante una variedad de herramientas para analizar interacciones de protocolo, detección de anomalías u operaciones de interceptación legal de escuchas telefónicas. |
| Saber más |
Para comprender mejor la duplicación de puertos, consulte Imitación y analizadores de puertos |
| Aprende más |
Portal de aprendizaje |
Descripción general funcional
Descripción general funcional de la replicación de puertos remotos proporciona un resumen rápido de los protocolos y tecnologías implementados en este ejemplo.
| Protocolos de enrutamiento y señalización |
|
| OSPF y OSPF3 |
Todos los enrutadores ejecutan OSPF y OSPF3 como IGP. Todos los enrutadores de proveedor pertenecen al área 0 (también denominada área troncal). Los dominios de enrutamiento OSPF/OSPF3 proporcionan accesibilidad interna a todas las redes e interfaces de la topología. Los enrutadores CE utilizan OSPF y OSPF3 para intercambiar rutas con los PE. |
| MPLS y RSVP | Los enrutadores del proveedor señalan a los LSP de MPLS mediante el protocolo RSVP. La tunelización de IPv6 está habilitada para admitir IPv6 a través de MPLS. MPLS se utiliza para admitir una VPN de capa 3. |
| MP-BGP | El BGP multiprotocolo se utiliza entre los enrutadores de PE para anunciar las rutas VPN del cliente. |
| VPN de capa 3 | Los enrutadores de PE utilizan una instancia de enrutamiento VRF para admitir el servicio VPN de capa 3 para los enrutadores CE. El tráfico del cliente se transporta a través del núcleo dentro de los LSP señalizados RSVP. Para obtener más información sobre el funcionamiento de una VPN L3 basada en MPLS, consulte Ejemplo: Configurar una VPN de capa 3 básica basada en MPLS. |
| Protocolos enrutados |
|
| IPv4 e IPv6 |
Todos los enrutadores están configurados para admitir el enrutamiento de IPv4 e IPv6. |
| Analizador (estación de monitoreo) |
|
| Centos y Wireshark |
El analizador ejecuta Centos 7.x con una versión GUI de Wireshark. |
Descripción general de la topología
En este ejemplo, se utiliza el contexto de una VPN L3 basada en MPLS para demostrar la función de duplicación de puertos remotos en enrutadores PTX. La VPN L3 está configurada para admitir tráfico IPv4 e IPv6 entre los enrutadores perimetrales del cliente (CE) y perimetrales del proveedor (PE).
| Nombre del enrutador | Función |
Función |
| CE | Enrutador de borde de cliente (CE) que envía tráfico de prueba para confirmar que la duplicación de puertos funciona correctamente. | Estos enrutadores se designan como enrutadores CE. Los enrutadores CE obtienen el servicio VPN de capa 3 de la red del proveedor. Los CE no comparten el mismo dominio de enrutamiento de OSPF que los enrutadores del proveedor. |
| PE | El borde del proveedor (PE) enrutador conectado al CE. | Los PE se encuentran en el borde de la red de un proveedor. Nuestros PE admiten VPN de capa 3 mediante el uso de instancias de enrutamiento, MP-BGP, RSVP y un plano de datos MPLS. El enrutador PE1 funciona como uno de los DUT de duplicación de puerto remoto. |
| P | Un enrutador de núcleo de proveedor (P). | El enrutador P representa un enrutador de núcleo de proveedor sin BGP. Es compatible con el transporte OSPF, OSPF3 y MPLS. No ejecuta BGP ni lleva el estado VPN. El enrutador P funciona como uno de los DUT de imitación de puerto remoto. |
| analizador | El dispositivo analizador recibe el tráfico espejo para su almacenamiento y análisis. | Los detalles del analizador están fuera del alcance de este documento. Hay una serie de opciones comerciales y de código abierto disponibles. Nuestro analizador está ejecutando Centos 7.x con un escritorio Gnome compatible con una versión GUI de Wireshark. |
Ilustraciones de topología
puerto remoto
En este ejemplo, se muestran dos maneras de reflejar el tráfico de CE enviado a través de la red del proveedor:
-
El primer método utiliza un filtro de coincidencia en la interfaz PE-CE VRF.
-
El segundo método muestra un filtro de coincidencia de etiquetas MPLS que se aplica en el enrutador del proveedor (P).
El enrutador PE1 (R2) y el enrutador P (R3) son los enrutadores donde se configura la duplicación de puertos remotos y funcionan como nuestros DUT. Estos enrutadores utilizan filtros de firewall de familia any para coincidir en el tráfico seleccionado para la duplicación de puertos. Se emplea una combinación de filtros de entrada y salida para reflejar el tráfico de solicitud y respuesta que fluye entre los enrutadores CE (R1 y R5).
La duplicación de puerto remoto utiliza un túnel para la encapsulación GRE a fin de enviar tráfico reflejado a un dispositivo analizador remoto. Nuestra topología tiene dos analizadores. Uno está conectado al enrutador R2/PE1 y el otro al enrutador R3/P. Esto nos permite demostrar dos maneras de duplicar el tráfico de CE, una en un PE y la otra en un enrutador de núcleo P. Usamos un host Centos con Wireshark para la captura y el análisis de paquetes.
Las plataformas PTX utilizan la infraestructura de interfaz de túnel flexible (FTI) para admitir una variedad de aplicaciones de tunelización. En el caso de las duplicaciones de puertos remotos, los túneles GRE se configuran en interfaces FTI para transportar el tráfico reflejado a un dispositivo analizador remoto. Como parte de este ejemplo, configurará túneles GRE basados en fti, una instancia de duplicación y los filtros de firewall que seleccionan el tráfico que se va a reflejar.
Pasos de configuración R2/PE1
Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración
Para obtener una configuración completa en todos los enrutadores, consulte: Apéndice 2: Establecer comandos en todos los enrutadores
En esta sección, se destacan las tareas de configuración necesarias para configurar el enrutador PE1/R2 en este ejemplo. Proporcionamos configuraciones completas para todos los enrutadores en el apéndice. En el paso 1 se resume la línea base del ejemplo. Esta línea de base consta de conectividad IPv4 e IPv6, MPLS y una VPN de capa 3. Nuestro ejemplo se centra en la configuración y verificación de la duplicación de puertos remotos.
Para obtener más información sobre la operación VPN de capa 3 y la configuración de línea base , consulte Ejemplo: Configure una VPN de capa 3 básica basada en MPLS.
-
Configure el enrutamiento IP y la línea base de VPN L3 en el enrutador PE1. Esto implica lo siguiente:
-
Numeración de las interfaces para IPv4 e IPv6 e inclusión
family mplsde compatibilidad con interfaces frontales de núcleo. -
Configurar los protocolos de enrutamiento OSPF y OSPFv3 para proporcionar accesibilidad entre todas las interfaces de red.
-
Etiquetar las rutas conmutadas (LSP) RSVP y MPLS para admitir el tráfico VPN L3.
-
Configurar el emparejamiento VRF y BGP con las familias de
direcciones para un enrutador PE. Nuestro ejemplo de VRF utiliza OSPF y OSPF3 como protocolo de enrutamiento PE-CE.inet-vpnandinet6-vpn[edit] set interfaces et-0/0/0 unit 0 family inet address 10.0.12.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:12::2/64 set interfaces et-0/0/1 unit 0 family inet address 10.0.23.1/24 set interfaces et-0/0/1 unit 0 family inet6 address 2001:db8:10:0:23::1/64 set interfaces et-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:192:168:0::2/128 set policy-options policy-statement ospf-export term 1 from protocol bgp set policy-options policy-statement ospf-export term 1 then accept set routing-instances ce1 instance-type vrf set routing-instances ce1 protocols ospf area 0.0.0.0 interface all set routing-instances ce1 protocols ospf export ospf-export set routing-instances ce1 protocols ospf3 area 0.0.0.0 interface all set routing-instances ce1 protocols ospf3 export ospf-export set routing-instances ce1 interface et-0/0/0.0 set routing-instances ce1 route-distinguisher 65001:1 set routing-instances ce1 vrf-target target:65001:100 set routing-instances ce1 vrf-table-label set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65001 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp family inet6-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.4 set protocols mpls label-switched-path pe2 to 192.168.0.4 set protocols mpls label-switched-path pe2 no-cspf set protocols mpls ipv6-tunneling set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable set protocols rsvp interface all set protocols rsvp interface fxp0 disable
Con la línea de base cubierta, los pasos restantes se centran en configurar el enrutador R2/PE1 para reflejar todo el tráfico enviado y recibido en su interfaz VRF orientada a CE1.
-
- Comience con la configuración del túnel GRE. En un enrutador PTX, el túnel se implementa a través de una interfaz FTI. La dirección de origen del túnel GRE no tiene que ser enrutable, a menos que espere realizar pruebas de ping de diagnóstico con origen o destino en el origen del túnel GRE. El destino GRE para el tráfico reflejado por PE1 es el enrutador del analizador 1. Este destino debe ser accesible para que el tráfico espejo se envíe al analizador. Usamos una instancia pasiva de IGP para garantizar el alcance de IGP a las redes de analizadores.
La dirección de destino se asigna al dispositivo del analizador 1 conectado a la interfaz et-0/0/2 en el enrutador P/R3. Debe configurar la interfaz lógica fti con
family cccpara que admita la duplicación de puerto remoto en el PTX. Esto se debe a que la acción de duplicación se produce en la capa 2.set interfaces fti0 unit 1 description "GRE tunnel for remote port mirror" set interfaces fti0 unit 1 tunnel encapsulation gre source address 10.100.0.1 set interfaces fti0 unit 1 tunnel encapsulation gre destination address 10.0.100.1 set interfaces fti0 unit 1 family ccc
Nota:Se aprovisiona una instancia de IGP pasiva para las interfaces conectadas a los dispositivos del analizador. Esto proporciona accesibilidad de IGP a los puertos del analizador para el tráfico reflejado encapsulado GRE. La configuración pasiva evita la generación de paquetes de saludo a los analizadores, ya que esto solo saturaría las capturas.
Además, configuramos una ruta estática en el dispositivo analizador para permitirle responder a los pings como ayuda en las pruebas de diagnóstico. Estrictamente hablando, solo se necesita conectividad o enrutamiento símplex entre los DUT y el analizador para que funcione la duplicación de puertos remotos.
- Configure la instancia de muestreo. Usamos una tasa de 1 para muestrear todos los paquetes coincidentes. El valor predeterminado
run-lengthde 1 se mantiene en su lugar, dado que todo el tráfico coincidente ya está muestreado. Debe especificar la interfaz lógica en el enrutador FTI que se utiliza para transportar el tráfico reflejado. Configuróunit 1en la interfaz fti0 para el túnel GRE en el paso anterior, de modo que se especifiquen la misma interfaz y unidad como interfaz de salida en la instancia reflejada.[edit] set forwarding-options port-mirroring instance pe-mirror input rate 1 set forwarding-options port-mirroring instance pe-mirror family any output interface fti0.1
Nota:Puede especificar una longitud máxima de paquete para el tráfico reflejado en la
[edit forwarding-options port-mirroring instance instance-name input]jerarquía con lamaximum-packet-lengthopción. De forma predeterminada, la longitud del paquete es 0, lo que significa que todo el paquete está reflejado. -
Defina dos filtros de firewall de familia
anypara que coincidan con el tráfico de CE y lo reflejen. Se definen dos filtros, uno para la duplicación del tráfico CE1 a CE2 y el otro para la duplicación de CE2 a CE1. Los filtros incluyen una función de recuento para ayudar en la verificación. La acción de duplicación de puerto dirige el tráfico coincidente a la instancia de duplicación de puerto que configuró anteriormente.Los filtros de familia
anyadmiten la coincidencia de capa 2 y capa 3. Para el primero, puede hacer coincidir el ID de VLAN, la interfaz, la dirección MAC o la etiqueta MPLS. Para este último, puede coincidir en los campos de encabezados IPv4 o IPv6 estándar.Dada nuestra topología, usamos un término de coincidencia total que captura todo el tráfico enviado o recibido por los CE. Esto incluye IPv4, IPv6, ARP, LLDP y cualquier protocolo de enrutamiento, como OSPF.
[edit] set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then count ce1-ce2-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then port-mirror-instance pe-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then accept set firewall family any filter ce1-ce2 term else then accept set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then count ce2-ce1-mirror set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then port-mirror-instance pe-mirror set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then accept set firewall family any filter ce2-ce1 term else then accept
Ambos filtros terminan con un término de coincidencia para anular la acción predeterminada de denegación de todo al final de un filtro de Junos. De esta forma se acepta el tráfico que no coincide en el primer término. Este término se agrega como protección en caso de que posteriormente se agregue una condición de coincidencia específica al primer término.
Si lo desea, puede evocar una acción de policía en el filtro para limitar el número de paquetes reflejados enviados a través del túnel GRE. El regulador de políticas se define con un límite de ancho de banda y ráfaga, junto con una acción de descarte para el tráfico que supere el aplicador de políticas.
No se puede aplicar un filtro PM con una acción de policía en la dirección de salida.Nota:Si desea hacer coincidir solo el tráfico ICMP enviado entre las direcciones de circuito cerrado IPv4 de los dispositivos CE, agregue criterios de coincidencia de capa 3 al filtro.
set firewall family any filter ce1-ce2 term mirror-ce1-ce2 from ip-version ipv4 ip-protocol icmp set firewall family any filter ce1-ce2 term mirror-ce1-ce2 from ip-version ipv4 ip-source-address 172.16.1.1/32 set firewall family any filter ce1-ce2 term mirror-ce1-ce2 from ip-version ipv4 ip-destination-address 172.16.2.1/32 set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then count ce1-ce2-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then port-mirror-instance pe-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then accept set firewall family any filter ce1-ce2 term else then accept
-
Aplique los filtros a la interfaz de cara a CE en R2/PE1. Para nuestro ejemplo, eso significa la aplicación de los filtros a la interfaz et-0/0/0 en PE1. Tenga en cuenta la direccionalidad de la aplicación del filtro. Se necesita un filtro de entrada y salida para reflejar ambas direcciones del flujo de tráfico de la CE.
[edit] set interfaces et-0/0/0 unit 0 filter input ce1-ce2 set interfaces et-0/0/0 unit 0 filter output ce2-ce1
Para completar, mostramos la configuración de R2 / PE1 en formato de llave.
system {
host-name r2-ptx;
}
interfaces {
et-0/0/0 {
unit 0 {
filter {
input ce1-ce2;
output ce2-ce1;
}
family inet {
address 10.0.12.2/24;
}
family inet6 {
address 2001:db8:10:0:12::2/64;
}
}
}
et-0/0/1 {
unit 0 {
family inet {
address 10.0.23.1/24;
}
family inet6 {
address 2001:db8:10:0:23::1/64;
}
family mpls;
}
}
fti0 {
unit 1 {
description "GRE tunnel for remote port mirror";
tunnel {
encapsulation gre {
source {
address 10.100.0.1;
}
destination {
address 10.0.100.1;
}
}
}
family ccc;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
family inet6 {
address 2001:db8:192:168:0::2/128;
}
}
}
}
forwarding-options {
port-mirroring {
instance {
pe-mirror {
input {
rate 1;
}
family any {
output {
interface fti0.1;
}
}
}
}
}
}
policy-options {
policy-statement ospf-export {
term 1 {
from protocol bgp;
then accept;
}
}
}
firewall {
family any {
filter ce1-ce2 {
term mirror-ce1-ce2 {
then {
count ce1-ce2-mirror;
port-mirror-instance pe-mirror;
accept;
}
}
}
filter ce2-ce1 {
term mirror-ce2-ce1 {
then {
count ce2-ce1-mirror;
port-mirror-instance pe-mirror;
accept;
}
}
}
}
}
routing-instances {
ce1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface all;
}
export ospf-export;
}
ospf3 {
area 0.0.0.0 {
interface all;
}
export ospf-export;
}
}
interface et-0/0/0.0;
route-distinguisher 65001:1;
vrf-target target:65001:100;
vrf-table-label;
}
}
routing-options {
router-id 192.168.0.2;
autonomous-system 65001;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.2;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
family inet6-vpn {
unicast;
}
neighbor 192.168.0.4;
}
}
mpls {
label-switched-path pe2 {
to 192.168.0.4;
no-cspf;
}
ipv6-tunneling;
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
ospf3 {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface et-0/0/2.0 {
passive;
}
}
}
rsvp {
interface all;
}
}
Pasos de configuración de R3
Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración
Para obtener una configuración completa en todos los enrutadores, consulte: Apéndice 2: Establecer comandos en todos los enrutadores
En esta sección, se destacan las principales tareas de configuración necesarias para configurar el enrutador P/R3 en este ejemplo. Comenzamos con la línea de base de VPN L3 basada en MPLS. A continuación, mostramos los pasos necesarios para configurar la duplicación de puertos remotos en un enrutador P para que coincida y refleje el tráfico de MPLS.
-
Configure el enrutamiento IPv4 e IPv6 y la línea de base de MPLS en el enrutador P/R3. Esto implica algunas cosas:
-
Numeración de las interfaces para IPv4 e IPv6 e inclusión
family mplsde compatibilidad con interfaces frontales de núcleo. -
Configure los protocolos de enrutamiento OSPF y OSPFv3 para proporcionar accesibilidad entre todas las interfaces de red.
-
RSVP y MPLS para admitir el plano de datos VPN L3. Como un enrutador P, el emparejamiento BGP y las definiciones de VRF no están presentes.
[edit] set interfaces et-0/0/0 description "R3-R2 P-PE" set interfaces et-0/0/0 unit 0 family inet address 10.0.23.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:23::2/64 set interfaces et-0/0/0 unit 0 family mpls set interfaces et-0/0/1 unit 0 family inet address 10.0.34.1/24 set interfaces et-0/0/1 unit 0 family inet6 address 2001:db8:10:0:34::1/64 set interfaces et-0/0/1 unit 0 family mpls set interfaces et-0/0/2 unit 0 family inet address 10.0.100.2/24 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:192:168:0::3/128 set routing-options router-id 192.168.0.3 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface et-0/0/2.0 disable set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface et-0/0/2.0 passive set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface et-0/0/2.0 passive set protocols rsvp interface all set protocols rsvp interface fxp0 disable set protocols rsvp interface et-0/02.0 disable
El enrutador P1/R3 se conecta al analizador 1 a través de la interfaz et-0/0/2 . Deshabilitamos el protocolo RSVP y la compatibilidad con MPLS en esta interfaz, ya que el tráfico reflejado llega como IPv4 mediante la encapsulación GRE. Los LSP no se extienden al analizador.
Nota:La configuración de interfaz et-0/0/2 utilizada aquí asume que el analizador responde a la solicitud ARP y ND enviada por el DUT para la resolución de la dirección MAC. Si este no es el caso, o si desea que el tráfico ARP no forme parte de sus capturas de paquetes, debe configurar una entrada ARP estática. Asegúrese de especificar la dirección MAC correcta para la interfaz en el dispositivo analizador que está conectado al DUT.
Una vez cubierta la línea base, los siguientes pasos se centran en configurar la imitación de puerto remoto para el tráfico MPLS en un enrutador P.
-
- Comience con la definición del túnel GRE. En las plataformas PTX, los túneles se implementan en una interfaz fti . La dirección de origen del túnel GRE no tiene que ser enrutable, a menos que espere realizar pruebas de ping de diagnóstico con origen o destino en el origen del túnel GRE. El destino GRE para el tráfico reflejado es el dispositivo del analizador 2 conectado a PE2/R4. Este destino debe ser accesible para que el tráfico espejo se envíe al analizador. Usamos una instancia pasiva de IGP para garantizar el alcance de IGP a las redes de analizadores.
Debe configurar la interfaz lógica fti con
family cccpara que admita la duplicación de puerto remoto en el PTX. Esto se debe a que la acción de duplicación se produce en la capa 2.[edit] set interfaces fti0 unit 1 tunnel encapsulation gre source address 10.100.0.3 set interfaces fti0 unit 1 tunnel encapsulation gre destination address 10.0.200.1 set interfaces fti0 unit 1 family ccc
Nota:Se aprovisiona una instancia de IGP pasiva para las interfaces conectadas a los dispositivos del analizador. Esto proporciona accesibilidad de IGP a los puertos del analizador para el tráfico reflejado encapsulado GRE. La configuración pasiva impide la generación de paquetes de saludo a los analizadores, ya que esto solo saturaría las capturas de paquetes.
Además, configuramos una ruta estática en el dispositivo analizador para que pueda responder a los pings como ayuda en las pruebas de diagnóstico. Estrictamente hablando, solo se necesita conectividad o enrutamiento símplex entre los DUT y el analizador para que funcione la duplicación de puertos remotos.
- Configure la instancia de muestreo. Usamos una tasa de 1 para seleccionar y muestrear todos los paquetes coincidentes. De forma predeterminada, es
run-length1. Esto está bien dado que todo el tráfico coincidente se muestrea con una tasa de 1. Debe especificar la interfaz lógica en el enrutador FTI que se utiliza para enviar el tráfico reflejado. Configuró la unidad 1 para la interfaz fti en el paso anterior para que se especifique la misma unidad como interfaz de salida para la instancia reflejada.[edit] set forwarding-options port-mirroring instance p-router-mirror input rate 1 set forwarding-options port-mirroring instance p-router-mirror family any output interface fti0.1
-
Defina los filtros de firewall para reflejar el tráfico enviado entre los enrutadores CE.
Los filtros de familia
anysolo permiten tipos de coincidencia de capa 2. Por ejemplo, ID de VLAN, interfaz, dirección MAC o etiqueta MPLS. Como resultado, no puede utilizar IPv4 o condiciones de coincidencia específicas de IPv4.Se definen dos filtros, uno para cada dirección del flujo de tráfico entre las CE.
Dado nuestro objetivo de reflejar el tráfico VPN en un enrutador P, los filtros se escriben para que coincidan en las etiquetas específicas que identifican los flujos de tráfico MPLS entre los dos enrutadores PE.
Para la dirección CE1 a CE2, el filtro coincide con la etiqueta de transporte RSVP utilizada por PE1 para llegar a PE2. Debido a PHP y la aplicación de salida, el filtro utilizado en la dirección CE2 a CE1 coincide con la etiqueta VRF anunciada por PE1 a PE2. El tráfico coincidente evoca la acción de duplicación de puerto a las instancias de duplicación definidas anteriormente. Los filtros incluyen una función de conteo para ayudar en la confirmación del funcionamiento adecuado.
Determinamos las etiquetas correctas usando estos comandos:
-
Para el tráfico enviado por CE1 a CE2, la etiqueta de transporte RSVP actual se muestra con un
show rsvp session ingress detailcomando. Esta es la etiqueta asignada de RSVP que utiliza PE1 para comunicarse con PE2 mediante MPLS. Debe tenerse en cuenta que todo el tráfico VPN enviado entre este par de PE utiliza el mismo transporte RSVP. El filtro resultante no es específico del VRF CE1 en el enrutador de PE.user@r2-ptx> show rsvp session ingress detail Ingress RSVP: 1 sessions 192.168.0.4 From: 192.168.0.2, LSPstate: Up, ActiveRoute: 0 LSPname: pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 22 Resv style: 1 FF, Label in: -, Label out: 22 Time left: -, Since: Tue Apr 18 12:58:47 2023 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 65196 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.0.23.2 (et-0/0/1.0) 1 pkts RESV rcvfrom: 10.0.23.2 (et-0/0/1.0) 1 pkts, Entropy label: Yes Record route: <self> 10.0.23.2 10.0.34.2 Total 1 displayed, Up 1, Down 0
En este caso, el resultado muestra que la etiqueta RSVP 22 está asignada al enrutador PE1/R2 para alcanzar la salida de LSP en el enrutador PE2/R4.
-
Para el tráfico enviado por CE2 a CE1, debe coincidir en la etiqueta VRF. Esto se debe a que el enrutador P es el penúltimo nodo de salto y, en la interfaz de salida, habrá desplegado la etiqueta de transporte RSVP. Esto deja la etiqueta VRF como la parte inferior de la pila. Confirme la etiqueta VRF anunciada por PE1 al PE2 con un
show route advertising-protocol bgp remote-peer-address detailcomando. Este comando muestra las rutas anunciadas por el PE local junto con la etiqueta VRF que está enlazada a la instancia de enrutamiento.user@r2-ptx> show route advertising-protocol bgp 192.168.0.4 detail ce1.inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) * 10.0.12.0/24 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 65001:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [65001] I Communities: target:65001:100 * 172.16.1.1/32 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 65001:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change MED: 1 Localpref: 100 AS path: [65001] I Communities: target:65001:100 rte-type:0.0.0.0:1:0 . . .El resultado muestra que PE1 señaló la etiqueta VRF 16 al enrutador PE2 para las rutas asociadas con la instancia de enrutamiento CE1.
Con la información de los comandos anteriores, sabemos con qué etiquetas RSVP/VRF coincidir en el filtro del firewall.
[edit] set firewall family any filter ce1-ce2 term ce1-ce2-mirror from mpls-label 22 set firewall family any filter ce1-ce2 term ce1-ce2-mirror then count ce1-ce2-traffic set firewall family any filter ce1-ce2 term ce1-ce2-mirror then port-mirror-instance p-router-mirror set firewall family any filter ce1-ce2 term else then accept set firewall family any filter ce2-ce1 term ce2-ce1-mirror from mpls-label 16 set firewall family any filter ce2-ce1 term ce2-ce1-mirror then count ce2-ce1-traffic set firewall family any filter ce2-ce1 term ce2-ce1-mirror then port-mirror-instance p-router-mirror set firewall family any filter ce2-ce1 term else then accept
Los filtros terminan con un término de coincidencia de aceptar todos para anular la denegación predeterminada de todos al final de un filtro de Junos. De esta forma se acepta el tráfico que no coincide en el primer término. Esto es fundamental para evitar interrumpir todo el resto del tráfico que utiliza esta interfaz.
Nota:Las etiquetas de RSVP pueden cambiar debido a la reseñalización del LSP causada por interrupciones del vínculo u otros cambios de configuración. Demostramos cómo se puede usar un filtro para que coincida con etiquetas específicas y ayude a restringir el tráfico que se refleja. Siempre puede aplicar un filtro de coincidencia de todos para asegurarse de que los cambios en la etiqueta de MPLS no afecten a la duplicación. La desventaja del enfoque de coincidencia total es que reflejará todo el tráfico recibido en la interfaz del enrutador P para incluir los protocolos principales y el tráfico que no es VPN.
-
-
Aplique los filtros a la interfaz orientada al PE1 en el enrutador P/R3. La direccionalidad de la aplicación del filtro es importante. Nuestros filtros están diseñados para funcionar en la dirección de entrada para el tráfico CE1 a CE2 y en la dirección de salida para el tráfico CE2 a CE1. Dado que se trata de filtros de familia cual, se aplican a nivel de unidad independientemente de IPv4 o IPv6. Familia de cualquier filtro funciona en la capa 2, que es independiente de cualquier familia de protocolos.
[edit] set interfaces et-0/0/0 unit 0 filter input ce1-ce2 set interfaces et-0/0/0 unit 0 filter output ce2-ce1
Para completar, mostramos la configuración de R2 / PE1 en formato de llave.
system {
host-name r3-ptx;
}
interfaces {
et-0/0/0 {
description "R3-R2 P-PE";
unit 0 {
filter {
input ce1-ce2;
output ce2-ce1;
}
family inet {
address 10.0.23.2/24;
}
family inet6 {
address 2001:db8:10:0:23::2/64;
}
family mpls;
}
}
et-0/0/1 {
unit 0 {
family inet {
address 10.0.34.1/24;
}
family inet6 {
address 2001:db8:10:0:34::1/64;
}
family mpls;
}
}
et-0/0/2 {
unit 0 {
family inet {
address 10.0.100.2/24;
}
}
}
fti0 {
unit 1 {
tunnel {
encapsulation gre {
source {
address 10.100.0.3;
}
destination {
address 10.0.200.1;
}
}
}
family ccc;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
family inet6 {
address 2001:db8:192:168:0::3/128;
}
}
}
}
forwarding-options {
port-mirroring {
instance {
p-router-mirror {
input {
rate 1;
}
family any {
output {
interface fti0.1;
}
}
}
}
}
}
firewall {
family any {
filter ce1-ce2 {
term ce1-ce2-mirror {
from {
mpls-label 22;
}
then {
count ce1-ce2-traffic;
port-mirror-instance p-router-mirror;
}
}
term else {
then accept;
}
}
filter ce2-ce1 {
term ce2-ce1-mirror {
from {
mpls-label 16;
}
then {
count ce2-ce1-traffic;
port-mirror-instance p-router-mirror;
}
}
term else {
then accept;
}
}
}
}
routing-options {
router-id 192.168.0.3;
}
protocols {
mpls {
interface all;
interface fxp0.0 {
disable;
}
interface et-0/0/2.0 {
disable;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface et-0/0/2.0 {
passive;
}
}
}
ospf3 {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface et-0/0/2.0 {
passive;
}
}
}
rsvp {
interface all;
interface et-0/0/2.0 {
disable;
}
}
}
Verificación
En este ejemplo, hay dos DUT en los que se configura la duplicación de puertos. Los mecanismos de verificación son los mismos. En ambos casos, confirmará que el filtro coincide con el tráfico esperado y que los paquetes reflejados se envían al analizador asociado.
Con nuestra configuración, el tráfico duplicado de PE se envía al analizador 1, mientras que el tráfico reflejado del enrutador P se envía al analizador 2. Si se desea, todo el tráfico reflejado se puede enviar al mismo destino, pero esto da como resultado la intercalación de tráfico si la duplicación del puerto se produce en varios lugares simultáneamente.
Estos pasos se pueden realizar en uno o ambos enrutadores DUT, según se desee. R2/PE1 es el primer DUT y el enrutador/R3 P es el segundo.
-
Confirme los vecinos y rutas de OSPF y OSPF3 a todas las direcciones de circuito cerrado. Además, verifique la ruta a la dirección IP del analizador remoto. Debe poder enviar paquetes IPv4 al analizador remoto. Opcionalmente, el analizador puede configurarse con rutas estáticas para que pueda responder.
user@r2-ptx> show ospf neighbor Address Interface State ID Pri Dead 10.0.23.2 et-0/0/1.0 Full 192.168.0.3 128 36 user@r2-ptx> show ospf3 neighbor ID Interface State Pri Dead 192.168.0.3 et-0/0/1.0 Full 128 36 Neighbor-address fe80::569e:18ff:fe45:ffff user@r2-ptx> show route protocol ospf | match /32 192.168.0.3/32 *[OSPF/10] 2d 22:41:49, metric 1 192.168.0.4/32 *[OSPF/10] 2d 22:41:49, metric 2 224.0.0.5/32 *[OSPF/10] 2d 22:43:37, metric 1 172.16.1.1/32 *[OSPF/10] 2d 22:41:45, metric 1 224.0.0.5/32 *[OSPF/10] 2d 22:43:37, metric 1 user@r2-ptx> show route protocol ospf3 | match /128 2001:db8:192:168::3/128 2001:db8:192:168::4/128 ff02::5/128 *[OSPF3/10] 2d 22:47:10, metric 1 2001:db8:172:16:1::1/128 ff02::5/128 *[OSPF3/10] 2d 21:38:06, metric 1
Nota:En el resultado anterior, la ruta 172.16.1.1/32 se aprende en la instancia de
ce1enrutamiento. Por lo tanto, con este comando ha confirmado el funcionamiento adecuado de OSPF tanto en el núcleo como en el borde del cliente. Solo se muestra el circuito cerrado CE1 local, ya que el circuito cerrado CE remoto se aprende como una ruta BGP.La instancia pasiva de IGP configurada en la interfaz conectada a los analizadores proporcionó la conectividad IP necesaria. Nuevamente, agregamos rutas estáticas a los analizadores para permitir el tráfico de retorno para pruebas de diagnóstico.
user@r2-ptx> show route 10.0.100.1 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.100.0/24 *[OSPF/10] 2d 22:49:10, metric 2 > to 10.0.23.2 via et-0/0/1.0 user@r2-ptx> show route 10.0.200.1 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.200.0/24 *[OSPF/10] 1d 20:36:13, metric 3 > to 10.0.23.2 via et-0/0/1.0 user@r2-ptx> ping 10.0.100.1 count 2 PING 10.0.100.1 (10.0.100.1) 56(84) bytes of data. 64 bytes from 10.0.100.1: icmp_seq=1 ttl=63 time=5.48 ms 64 bytes from 10.0.100.1: icmp_seq=2 ttl=63 time=4.91 ms --- 10.0.100.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 4.908/5.196/5.484/0.288 ms -
Confirme el estado de la interfaz fti y del túnel GRE.
user@r2-ptx> show interfaces fti0.1 detail Logical interface fti0.1 (Index 1000) (SNMP ifIndex 543) (Generation 609885357005) Description: GRE tunnel for remote port mirror Flags: Up Point-To-Point Encapsulation: GRE DF , Source address: 10.100.0.1/32, Destination address: 10.0.100.1 Traffic statistics: Input bytes : 0 Output bytes : 12887342 Input packets: 0 Output packets: 99020 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 12887342 0 bps Input packets: 0 0 pps Output packets: 99020 0 pps Protocol ccc, MTU: 1476, Generation: 609885357006, Route table: 0 Flags: Is-PrimaryLos resaltados en el resultado indican que la interfaz del túnel y el túnel GRE están operativos. El contador de paquetes de salida distinto de 0 es una buena señal de que el tráfico se está reflejando. No esperamos ningún paquete de entrada, ya que este túnel GRE solo se usa para enviar tráfico duplicado a un analizador remoto.
-
Confirme la instancia de duplicación del puerto. El estado de replicación del puerto debe ser
up, y la interfaz de duplicación correcta debe aparecer en el destino. La familiaanyindica que se trata de una instancia de réplica de puerto de capa 2 que es independiente de la familia de protocolos. El tráfico reflejado incluye la trama de capa 2 original junto con su contenido.user@r2-ptx> show forwarding-options port-mirroring Instance Name: pe-mirror Instance Id: 1 Input parameters: Rate : 1 Run-length : 1 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop any up fti0.1 NA -
Borre los contadores de firewall y las estadísticas de interfaz en el DUT. A continuación, genere un número conocido de paquetes de prueba IPv4 e IPv6 entre las direcciones CE enrutador circuito cerrado.
user@r2-ptx> clear firewall all user@r2-ptx> clear interfaces statistics all
user@r1-ptx> ping 172.16.2.1 source 172.16.1.1 count 4 PING 172.16.2.1 (172.16.2.1) from 172.16.1.1 : 56(84) bytes of data. 64 bytes from 172.16.2.1: icmp_seq=1 ttl=61 time=1237 ms 64 bytes from 172.16.2.1: icmp_seq=2 ttl=61 time=178 ms 64 bytes from 172.16.2.1: icmp_seq=3 ttl=61 time=507 ms 64 bytes from 172.16.2.1: icmp_seq=4 ttl=61 time=417 ms --- 172.16.2.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3066ms rtt min/avg/max/mdev = 177.830/584.676/1237.435/395.575 ms, pipe 2 user@r1-ptx> ping 2001:db8:172:16:2::1 source 2001:db8:172:16:1::1 count 4 64 bytes from 2001:db8:172:16:2::1: icmp_seq=1 ttl=62 time=978 ms 64 bytes from 2001:db8:172:16:2::1: icmp_seq=2 ttl=62 time=621 ms 64 bytes from 2001:db8:172:16:2::1: icmp_seq=3 ttl=62 time=782 ms 64 bytes from 2001:db8:172:16:2::1: icmp_seq=4 ttl=62 time=920 ms --- 2001:db8:172:16:2::1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 621.122/825.114/978.021/137.715 ms
-
De vuelta en R2/PE1, muestre los contadores del firewall y las estadísticas de la interfaz para confirmar que reflejan el tráfico de prueba. Es posible que vea algunos paquetes adicionales contados en la dirección CE1 a CE 2 que reflejan los intercambios OSPF, OSPF3 o ARP entre los enrutadores CE12 y PE1. Tenga en cuenta que en la dirección CE12 a CE1, la aplicación de filtros en la dirección de salida solo captura el tráfico de extremo a extremo. Por lo tanto, el contador CE2-CE1 refleja el tráfico de prueba generado.
user@r2-ptx> show firewall Filter: ce1-ce2 Counters: Name Bytes Packets ce1-ce2-mirror 1353 13 Filter: ce2-ce1 Counters: Name Bytes Packets ce2-ce1-mirror 752 8
Muestra estadísticas de interfaz para la interfaz fti0./1 utilizada para reflejar el tráfico al analizador remoto.
user@r3-ptx> show interfaces fti0.1 detail Logical interface fti0.1 (Index 1000) (SNMP ifIndex 543) (Generation 609885357005) Description: GRE tunnel for remote port mirror Flags: Up Point-To-Point Encapsulation: GRE DF , Source address: 10.100.0.1/32, Destination address: 10.0.100.1 Traffic statistics: Input bytes : 0 Output bytes : 2424 Input packets: 0 Output packets: 20 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 2424 2096 bps Input packets: 0 0 pps Output packets: 20 2 pps Protocol ccc, MTU: 1476, Generation: 609885357006, Route table: 0 Flags: Is-PrimaryCon 8 paquetes de prueba generados, es posible que se sorprenda al ver un recuento de paquetes en la salida de la interfaz fti0.1 de 20. Primero, recuerde que los paquetes OSPF y OSPF3 hellos enviados por el enrutador CE1 se están reflejando. En segundo lugar, considere que tanto la solicitud de ping como las respuestas se reflejan en PE1 / R2. Eso significa que hay 8 solicitudes de ping y 8 respuestas, para un total de 16 paquetes de prueba ICMP.
-
Ejecute tcpdump o la aplicación de análisis de su elección en la estación de monitoreo para confirmar la recepción y el procesamiento del tráfico de prueba duplicado. Nuestra configuración tiene dos dispositivos analizadores, o precisamente, un host analizador con dos interfaces. Si lo desea, puede realizar este paso en ambas interfaces del analizador simultáneamente. Recuerde que el tráfico reflejado en la interfaz eth2 en el analizador 2 se refleja en el enrutador P/R3 y, por lo tanto, incluye encapsulación MPLS. El tráfico reflejado desde R1/PE1 no incluye la encapsulación de MPLS.
Comenzamos con una captura en la interfaz eth1 que recibe tráfico reflejado de R2/PE1. Después de iniciar la captura, realizamos un único ping IPv4 entre los enrutadores CE.
Nota:Después de la captura, pegamos la salida tcpdump basada en texto en una aplicación de texto que muestra los números de línea. Esto hace que sea más fácil llamar a partes clave de la captura. También habilitamos la envoltura de línea para mejorar la visibilidad.

Las áreas a tener en cuenta en la captura incluyen:
-
Evocamos tcpdump en la interfaz eth1 e incluimos indicadores para evitar la resolución de nombres, proporcionar detalles, capturar hasta 400 bytes e incluir encabezados de capa 2.
-
La línea 3 es el inicio del primer paquete IP y trama de capa 2. El marco Ethernet es la encapsulación utilizada por el enrutador R3/P1 para enviar tráfico al dispositivo analizador conectado localmente. La dirección MAC de destino es propiedad de la interfaz eth1 en el analizador 1. La resolución 100.0.100.1 de IP a dirección MAC se realiza a través de ARP. El marco Ethernet indica que lleva el protocolo IP. En la capa IP, vemos que el paquete tiene el bit Don't Fragment establecido e identifica que la carga útil es GRE.
-
La línea 4 muestra la decodificación del paquete IP externo y su carga GRE. Las direcciones IP de origen y destino reflejan el túnel GRE configurado en la interfaz fti0.1 en R2/PE1. El encabezado GRE identifica que su carga útil es una trama de capa 2 a través del ID de protocolo de puente Ethernet transparente (TEB). Esto confirma que la duplicación de puerto remoto en plataformas PTX con un filtro de familia
anyda como resultado la duplicación de tramas de capa 2. -
La línea 5 es la decodificación de la carga útil del paquete GRE. Las direcciones MAC de origen y destino (de:99:7e:32:ff:ff y 01:00:5e:00:00:05, respectivamente) reflejan las utilizadas para la multidifusión de saludo de OSPF en la capa de vínculo. La línea 5 también muestra que la carga útil de la trama de capa 2 encapsulada GRE es IP y que la carga útil del paquete IP es OSPF.
Nota:El intercambio de saludo de OSPF entre CE y PE es local en una VPN de capa 3. Vemos los paquetes OSPF enviados por el CE local porque la acción de duplicación del puerto en la entrada capturó todo el tráfico. Los paquetes de saludo de OSPF generados por el CE remoto no se transportan a través del núcleo y, por lo tanto, no se ven como salida en la captura.
-
La línea 6 decodifica el saludo de OSPF enviado por el enrutador CE1. La dirección IP de origen se asigna a la interfaz et-0/0/0.0 de CE1. La dirección IP de destino se utiliza para la multidifusión de OSPF.
-
Omitimos la decodificación de OSPF y aterrizamos en la línea 16. Esta es la segunda trama de la captura y refleja una solicitud de eco ICMP IPv4. Una vez más, la trama de capa 2 refleja las direcciones MAC de los dispositivos P1/R3 y del analizador 1. Vemos que la trama externa lleva un paquete IP con una carga GRE. Las direcciones IP de origen y destino del paquete IP externo reflejan el túnel GRE configurado en R2/PE2.
-
La línea 18 comienza la decodificación de la carga útil GRE. Volvemos a ver las direcciones MAC de los enrutadores CE1 y PE1. En la capa IP, vemos que el paquete se envía desde la dirección de circuito cerrado del enrutador CE1. La IP de destino es la dirección de circuito cerrado de CE2. La carga útil del paquete IP interno es la solicitud de eco ICMP tal como se envió de CE1 a CE2.
-
La línea 20 decodifica la respuesta de eco ICMP enviada por CE2. Esto confirma que la duplicación de puertos funciona tanto en la dirección de transmisión CE1 como en la de recepción.
-
A continuación, generamos un único ping IPv6 entre enrutadores CE mientras capturamos en la interfaz eth2 del analizador 2. Esto confirma la configuración de duplicación de puerto en el enrutador R3/P, así como la compatibilidad con duplicación de puerto IPv6.
Nota:Después de la captura, pegamos la salida tcpdump basada en texto en una aplicación de texto que muestra los números de línea. Esto hace que sea más fácil llamar a partes clave de la captura. También habilitamos la envoltura de línea para mejorar la visibilidad.
Tenga en cuenta que se muestra tanto el tráfico de solicitud como el de respuesta. Dado que esta duplicación de puerto se produce en un enrutador P, los paquetes OSPF entre los enrutadores CE no se reflejan, ya que no se envían a través del núcleo del proveedor. Las cosas a tener en cuenta en esta captura incluyen:
-
En la línea 3 se decodifica la trama Ethernet exterior. Las direcciones MAC de origen y destino ahora reflejan los dispositivos R4/PE2 y analizador, respectivamente.
-
En la línea 4 se decodifica el paquete IP interno. La trama indica la encapsulación GRE, y las direcciones IP de origen y destino confirman que este tráfico se refleja a través del túnel GRE fti0.1 configurado en el enrutador R3/P1. La encapsulación GRE muestra el protocolo TEB, lo que indica que una trama Ethernet de capa 2 está encapsulada.
-
La línea 5 comienza la decodificación de la trama Ethernet interna y su carga MPLS. La dirección MAC de origen se asigna a la interfaz et-0/0/1 en el enrutador R2/PE1. La MAC de destino está asociada con la interfaz et-0/0/0 en el enrutador R3/P1.
El marco Ethernet interno identifica una carga útil de MPLS. Esto está en consonancia con la duplicación de puertos de capa 2 realizada en un enrutador P con términos de filtro que coinciden en las etiquetas MPLS.
Tenga en cuenta que en la dirección CE1 a CE2, el tráfico reflejado muestra dos etiquetas MPLS. La etiqueta de transporte de RSVP es 24 (esto puede cambiar debido a la reseñalización del LSP) y la etiqueta VRF interna establecida en 23, que es la etiqueta VRF asociada con la instancia de enrutamiento CE1 en el enrutador R2/PE1.
Nota:En el momento de esta captura, la etiqueta de transporte MPLS utilizada por PE1 para llegar a PE2 había cambiado. Actualizamos la definición de filtro en R3/P1 para reflejar el valor actual de la etiqueta de transporte RSVP de 24 para las capturas de esta sección.
-
La línea 7 decodifica la carga IPv6 de la trama MPLS. Este es el paquete IPv6 enviado por CE1 al CE2. El paquete IPv6 identifica su carga como ICMP6 y muestra que se trata de una solicitud de eco.
-
La línea 8 comienza la decodificación del tráfico de respuesta desde CE2. En la dirección CE2 a CE1, solo hay una etiqueta en el tráfico de reflejo. Esta es la etiqueta VRF que permanece después de que el enrutador R3/PE1 realiza el penúltimo salto emergente (PHP) antes de enviar el tráfico al enrutador R2/PE1. El tráfico se reflejó en la salida en la dirección P1 a PE2.
Las capturas en ambos dispositivos analizadores confirman que la duplicación de puerto remoto funciona según lo esperado.
-
-
Concluimos con una decodificación GUI del mismo tráfico de prueba de CE a CE capturado en el dispositivo Analyzer 2. Observe de nuevo la presencia de etiquetas MPLS que reflejan una operación de duplicación de puerto en un enrutador de PE basado en MPLS.
La captura muestra que se refleja el tráfico de prueba IPv4 e IPv6. Esta captura refleja el tráfico que refleja el tráfico que refleja el enrutador P. Como resultado, la encapsulación MPLS está presente.
Apéndice: Establecer comandos en todos los enrutadores
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit].
R1 (CE1)
del interfaces et-0/0/0 set interfaces et-0/0/0 unit 0 family inet address 10.0.12.1/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:12::1/64 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:172:16:1::1/128 set routing-options router-id 172.16.1.1 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable
R2 (PE1) DUT1
set interfaces et-0/0/0 unit 0 filter input ce1-ce2 set interfaces et-0/0/0 unit 0 filter output ce2-ce1 set interfaces et-0/0/0 unit 0 family inet address 10.0.12.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:12::2/64 set interfaces et-0/0/1 unit 0 family inet address 10.0.23.1/24 set interfaces et-0/0/1 unit 0 family inet6 address 2001:db8:10:0:23::1/64 set interfaces et-0/0/1 unit 0 family mpls set interfaces fti0 unit 1 description "GRE tunnel for remote port mirror" set interfaces fti0 unit 1 tunnel encapsulation gre source address 10.100.0.1 set interfaces fti0 unit 1 tunnel encapsulation gre destination address 10.0.100.1 set interfaces fti0 unit 1 family ccc set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:192:168:0::2/128 set forwarding-options port-mirroring instance pe-mirror input rate 1 set forwarding-options port-mirroring instance pe-mirror input run-length 1 set forwarding-options port-mirroring instance pe-mirror family any output interface fti0.1 set policy-options policy-statement ospf-export term 1 from protocol bgp set policy-options policy-statement ospf-export term 1 then accept set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then count ce1-ce2-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then port-mirror-instance pe-mirror set firewall family any filter ce1-ce2 term mirror-ce1-ce2 then accept set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then count ce2-ce1-mirror set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then port-mirror-instance pe-mirror set firewall family any filter ce2-ce1 term mirror-ce2-ce1 then accept set routing-instances ce1 instance-type vrf set routing-instances ce1 protocols ospf area 0.0.0.0 interface all set routing-instances ce1 protocols ospf export ospf-export set routing-instances ce1 protocols ospf3 area 0.0.0.0 interface all set routing-instances ce1 protocols ospf3 export ospf-export set routing-instances ce1 interface et-0/0/0.0 set routing-instances ce1 route-distinguisher 65001:1 set routing-instances ce1 vrf-target target:65001:100 set routing-instances ce1 vrf-table-label set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65001 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp family inet6-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.4 set protocols mpls label-switched-path pe2 to 192.168.0.4 set protocols mpls label-switched-path pe2 no-cspf set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface et-0/0/2.0 passive set protocols rsvp interface all set protocols rsvp interface fxp0 disable
R3 (enrutador P) DUT 2
set interfaces et-0/0/0 description "R3-R2 P-PE" set interfaces et-0/0/0 unit 0 filter input ce1-ce2 set interfaces et-0/0/0 unit 0 filter output ce2-ce1 set interfaces et-0/0/0 unit 0 family inet address 10.0.23.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:23::2/64 set interfaces et-0/0/0 unit 0 family mpls set interfaces et-0/0/1 unit 0 family inet address 10.0.34.1/24 set interfaces et-0/0/1 unit 0 family inet6 address 2001:db8:10:0:34::1/64 set interfaces et-0/0/1 unit 0 family mpls set interfaces et-0/0/2 unit 0 family inet address 10.0.100.2/24 set interfaces fti0 unit 1 tunnel encapsulation gre source address 10.100.0.3 set interfaces fti0 unit 1 tunnel encapsulation gre destination address 10.0.200.1 set interfaces fti0 unit 1 family ccc set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:192:168:0::3/128 set forwarding-options port-mirroring instance p-router-mirror input rate 1 set forwarding-options port-mirroring instance p-router-mirror input run-length 0 set forwarding-options port-mirroring instance p-router-mirror family any output interface fti0.1 set firewall family any filter ce1-ce2 term ce1-ce2-mirror from mpls-label 22 set firewall family any filter ce1-ce2 term ce1-ce2-mirror then count ce1-ce2-traffic set firewall family any filter ce1-ce2 term ce1-ce2-mirror then port-mirror-instance p-router-mirror set firewall family any filter ce1-ce2 term else then accept set firewall family any filter ce2-ce1 term ce2-ce1-mirror from mpls-label 16 set firewall family any filter ce2-ce1 term ce2-ce1-mirror then count ce2-ce1-traffic set firewall family any filter ce2-ce1 term ce2-ce1-mirror then port-mirror-instance p-router-mirror set firewall family any filter ce2-ce1 term else then accept set routing-options router-id 192.168.0.3 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface et-0/0/2.0 disable set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface et-0/0/2.0 passive set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface et-0/0/2.0 passive set protocols rsvp interface all set protocols rsvp interface fxp0 disable
R4 (PE2)
set interfaces et-0/0/0 unit 0 family inet address 10.0.34.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:34::2/64 set interfaces et-0/0/0 unit 0 family mpls set interfaces et-0/0/1 unit 0 family inet address 10.0.45.1/24 set interfaces et-0/0/1 unit 0 family inet6 address 2001:db8:10:0:45::1/64 set interfaces et-0/0/2 unit 0 family inet address 10.0.200.2/24 set interfaces lo0 unit 0 family inet address 192.168.0.4/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:192:168:0::4/128 set policy-options policy-statement ospf-export term 1 from protocol bgp set policy-options policy-statement ospf-export term 1 then accept set routing-instances ce2 instance-type vrf set routing-instances ce2 protocols ospf area 0.0.0.0 interface all set routing-instances ce2 protocols ospf export ospf-export set routing-instances ce2 protocols ospf3 area 0.0.0.0 interface all set routing-instances ce2 protocols ospf3 export ospf-export set routing-instances ce2 interface et-0/0/1.0 set routing-instances ce2 route-distinguisher 65001:2 set routing-instances ce2 vrf-target target:65001:100 set routing-options router-id 192.168.0.4 set routing-options autonomous-system 65001 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.4 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp family inet6-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls label-switched-path pe1 to 192.168.0.2 set protocols mpls label-switched-path pe1 no-cspf set protocols mpls ipv6-tunneling set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface et-0/0/2.0 passive set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface et-0/0/2.0 passive set protocols rsvp interface all
R5 (CE2)
set interfaces et-0/0/0 unit 0 family inet address 10.0.45.2/24 set interfaces et-0/0/0 unit 0 family inet6 address 2001:db8:10:0:45::2/64 set interfaces lo0 unit 0 family inet address 172.16.2.1/32 set interfaces lo0 unit 0 family inet6 address 2001:db8:172:16:2::1/128 set routing-options router-id 172.16.2.1 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf3 area 0.0.0.0 interface all set protocols ospf3 area 0.0.0.0 interface fxp0.0 disable
Advertencias y limitaciones
Esta sección enumera las advertencias y limitaciones para la duplicación de puertos remotos en plataformas PTX.
-
Si se debe cambiar la parte de salida de la configuración de instancia de duplicación de puerto, primero se debe eliminar la configuración de salida existente y confirmar el cambio antes de agregar la nueva configuración.
-
Se admiten un total de 15 instancias espejo. No hay ningún error de confirmación si el número de instancias espejo de puerto remoto supera las 15.
-
Un paquete duplicado determinado solo se puede enviar a un analizador remoto.
-
La longitud máxima del paquete se puede configurar como un múltiplo de 128 bytes. El paquete exportado será 22 bytes menos que el valor configurado.
-
No se admiten varias interfaces de salida en una instancia de duplicación determinada. No hay ningún error de confirmación si se configuran varias interfaces de salida.
-
El proceso de muestreo no es compatible con GRES. Habrá caídas de tráfico reflejado en caso de un evento GRES o reinicio del
mirrordproceso. -
El tráfico de túnel que termina en el enrutador local no se puede reflejar en la dirección de salida.
-
No se puede utilizar la duplicación de puertos con un filtro que evoque una acción de policía en la dirección de salida.
-
Las estadísticas relacionadas con los paquetes duplicados se deben verificar mediante contadores de firewall o estadísticas de interfaz FTI.