Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

Tabla 1: Descripción general funcional de la imitación de puerto remoto

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).

Tabla 2: Descripción general de la topología de ejemplo de imitación de puerto remoto
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

Figura 1: Duplicación de A network topology diagram for an MPLS-based Layer 3 VPN with routers, links, and analyzers. R1 and R5 are customer edge routers; R2 and R4 are provider edge routers; R3P is the device under test in the MPLS core. Links are labeled with subnet info and interface names. The MPLS core uses AS 65001 OSPF Area 0. Traffic mirroring to Analyzer 1 from R2 and Analyzer 2 from R4. IP addressing includes placeholders for link and loopback IPs. 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

Nota:

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.

Nota:

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.

  1. Configure el enrutamiento IP y la línea base de VPN L3 en el enrutador PE1. Esto implica lo siguiente:

    1. Numeración de las interfaces para IPv4 e IPv6 e inclusión family mpls de compatibilidad con interfaces frontales de núcleo.

    2. Configurar los protocolos de enrutamiento OSPF y OSPFv3 para proporcionar accesibilidad entre todas las interfaces de red.

    3. Etiquetar las rutas conmutadas (LSP) RSVP y MPLS para admitir el tráfico VPN L3.

    4. Configurar el emparejamiento VRF y BGP con las familias de inet-vpn and inet6-vpn direcciones para un enrutador PE. Nuestro ejemplo de VRF utiliza OSPF y OSPF3 como protocolo de enrutamiento PE-CE.

    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.

  2. 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 ccc para 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.

    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.

  3. Configure la instancia de muestreo. Usamos una tasa de 1 para muestrear todos los paquetes coincidentes. El valor predeterminado run-length de 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 1 en 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.
    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 la maximum-packet-length opción. De forma predeterminada, la longitud del paquete es 0, lo que significa que todo el paquete está reflejado.

  4. Defina dos filtros de firewall de familia any para 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 any admiten 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.

    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.

  5. 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.

Para completar, mostramos la configuración de R2 / PE1 en formato de llave.

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

Nota:

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.

  1. Configure el enrutamiento IPv4 e IPv6 y la línea de base de MPLS en el enrutador P/R3. Esto implica algunas cosas:

    1. Numeración de las interfaces para IPv4 e IPv6 e inclusión family mpls de compatibilidad con interfaces frontales de núcleo.

    2. Configure los protocolos de enrutamiento OSPF y OSPFv3 para proporcionar accesibilidad entre todas las interfaces de red.

    3. 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.

      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.

  2. 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 ccc para 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.

    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.

  3. Configure la instancia de muestreo. Usamos una tasa de 1 para seleccionar y muestrear todos los paquetes coincidentes. De forma predeterminada, es run-length 1. 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.
  4. Defina los filtros de firewall para reflejar el tráfico enviado entre los enrutadores CE.

    Los filtros de familia any solo 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:

    1. Para el tráfico enviado por CE1 a CE2, la etiqueta de transporte RSVP actual se muestra con un show rsvp session ingress detail comando. 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.

      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.

    2. 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 detail comando. Este comando muestra las rutas anunciadas por el PE local junto con la etiqueta VRF que está enlazada a la instancia de enrutamiento.

      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.

      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.

  5. 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.

Para completar, mostramos la configuración de R2 / PE1 en formato de llave.

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.

  1. 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.

    Nota:

    En el resultado anterior, la ruta 172.16.1.1/32 se aprende en la instancia de ce1 enrutamiento. 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.

  2. Confirme el estado de la interfaz fti y del túnel GRE.

    Los 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.

  3. 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 familia any indica 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.

  4. 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.

  5. 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.

    Muestra estadísticas de interfaz para la interfaz fti0./1 utilizada para reflejar el tráfico al analizador remoto.

    Con 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.

  6. 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.

    Output of tcpdump command on Linux, showing packet details on eth1: timestamps, MAC addresses, IP addresses, protocols like GRE, OSPFv2, ICMP, and a summary of 3 packets captured, received by filter, none dropped.

    Las áreas a tener en cuenta en la captura incluyen:

    1. 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.

    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.

    3. 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 any da como resultado la duplicación de tramas de capa 2.

    4. 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.

    5. 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.

    6. 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.

    7. 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.

    8. 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.

  7. 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.

    Tcpdump output showing ICMPv6 echo request and reply packets on eth2 with MPLS labels; 2 packets captured, 0 dropped by kernel.

    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:

    1. 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.

    2. 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.

    3. 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.

    4. 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.

    5. 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.

  8. 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. Wireshark screenshot showing captured network packets, highlighting ICMPv6 and ICMP packets, with detailed packet info and raw data. 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)

R2 (PE1) DUT1

R3 (enrutador P) DUT 2

R4 (PE2)

R5 (CE2)

Advertencias y limitaciones

Esta sección enumera las advertencias y limitaciones para la duplicación de puertos remotos en plataformas PTX.

  1. 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.

  2. 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.

  3. Un paquete duplicado determinado solo se puede enviar a un analizador remoto.

  4. 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.

  5. 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.

  6. 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 mirrord proceso.

  7. El tráfico de túnel que termina en el enrutador local no se puede reflejar en la dirección de salida.

  8. 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.

  9. Las estadísticas relacionadas con los paquetes duplicados se deben verificar mediante contadores de firewall o estadísticas de interfaz FTI.