EN ESTA PÁGINA
Ejemplo: solución de entrada/salida para un dispositivo EVPN-VXLAN ERB Fabric Spine
Ejemplo: solución de entrada para un dispositivo leaf de estructura EVPN-VXLAN ERB
Ejemplo: habilitar una instancia de creación remota de reflejo en una interfaz ESI-LAG
Ejemplo: habilitar una instancia de analizador remoto en una interfaz ESI-LAG
Cómo configurar la creación de reflejo de puerto remoto para estructuras EVPN-VXLAN
Acerca de este ejemplo de configuración de red
Este ejemplo de configuración de red (NCE) muestra cómo configurar la duplicación de puertos remotos para estructuras EVPN-VXLAN. La duplicación de puertos copia un flujo de tráfico y lo envía a una estación de monitoreo remoto (RMON) mediante un túnel GRE. Al igual que ERSPAN, la duplicación remota de puertos del tráfico de inquilinos con encapsulación VXLAN se usa a menudo en el entorno del centro de datos para la solución de problemas o el monitoreo.
Demostramos cómo agregar duplicación remota de puertos en conmutadores lean spine y en dispositivos leaf enrutados en el borde en una estructura EVPN-VXLAN. Nuestra estructura de muestra se basa en una arquitectura de puente enrutado por borde (ERB). La duplicación del puerto VXLAN también se admite en las estructuras de puente de enrutamiento centralizado (CRB).
Ver también
Descripción general del caso de uso
- Estructuras de EVPN-VXLAN y duplicación de puerto remoto
- Métodos de creación de reflejo de puerto: instancia de analizador e instancia de creación de reflejo de puerto
Estructuras de EVPN-VXLAN y duplicación de puerto remoto
La creación de reflejo de puerto remoto copia un flujo de tráfico y entrega el tráfico reflejado a uno o más hosts de destino de creación de reflejo. El flujo de tráfico se identifica mediante la interfaz de entrada o salida, en algunos casos mediante un filtro de firewall para mayor granularidad. Los hosts de destino de creación de reflejo están conectados a un conmutador leaf que forma parte de la misma estructura que el conmutador de origen.
Para las estructuras IP de EVPN-VXLAN, el flujo de tráfico reflejado se encapsula en encapsulación de enrutamiento genérico (GRE) y se entrega a través de la estructura IP subyacente a la dirección IP del host de supervisión. Este host se utiliza como estación de supervisión para capturar y descodificar el flujo de tráfico.
La duplicación remota de puertos con un túnel GRE es una combinación perfecta para estructuras IP como EVPN-VXLAN, ya que puede conectar la estación de monitoreo a cualquier conmutador leaf de la estructura anunciando la subred de host en la base EBGP. Además, el conmutador de destino conectado a la estación de monitoreo no tiene que realizar la desencapsulación GRE antes de entregar la transmisión GRE a la estación de monitoreo. El túnel GRE puede cruzar varios nodos IP intermedios o enviarse fuera de la estructura.
Métodos de creación de reflejo de puerto: instancia de analizador e instancia de creación de reflejo de puerto
Hay dos métodos disponibles para la duplicación de puertos: una instancia de analizador y una instancia de creación de reflejo de puerto. Cada enfoque ofrece diferentes ventajas y es compatible con diferentes arquitecturas. En ambos casos, el túnel GRE para fines de duplicación se crea automáticamente, por lo que no es necesario configurar un túnel GRE.
La instancia del analizador es la duplicación de puertos sin ningún criterio de filtrado. Un analizador es la forma más sencilla de duplicación de tráfico para implementar. Solo necesita especificar la interfaz que es el origen del tráfico reflejado y si el tráfico que se reflejará en esa interfaz es de salida, entrada o ambas. También puede especificar la dirección IP para el destino del tráfico reflejado. No es necesario configurar ni aplicar un filtro de firewall.
Dado que la instancia del analizador no es específica del inquilino, es el mejor enfoque cuando no se dispone de información sobre la secuencia de inquilinos.
La instancia de creación de reflejo de puertos utiliza criterios específicos del tráfico del inquilino para reflejar el tráfico. El administrador de la estructura decide qué dirección IP de origen del inquilino específico, protocolo, puerto, etc., es de interés para la interfaz que se refleja. Utilice una instancia de creación de reflejo de puerto cuando sea necesario reflejar un tráfico específico.
Juniper Networks admite tres arquitecturas principales de centros de datos. Todos son compatibles con la duplicación remota de puertos. Para cada arquitectura, recomendamos el siguiente método de creación de reflejo de puertos:
-
Superposición puenteada: instancia de analizador
-
Puente enrutado centralmente (CRB): instancia de creación de reflejo de puerto
-
Puente enrutado en el borde (ERB): instancia de creación de reflejo de puerto
Descripción técnica
- Duplicación remota de puertos en una estructura ERB EVPN-VXLAN
- Duplicación remota de puertos con conmutadores de la serie QFX
Duplicación remota de puertos en una estructura ERB EVPN-VXLAN
Este NCE cubre la duplicación de puertos remotos para una arquitectura ERB con una spine lean.
En una estructura ERB EVPN-VXLAN con una columna vertebral delgada, los flujos internos específicos del inquilino no se pueden enviar selectivamente al túnel. Solo se admite el filtrado externo basado en encabezado (subyacente) en un dispositivo de columna lean. Por ejemplo, un conmutador spine puede filtrar los paquetes procedentes de una dirección de circuito cerrado IPv4 de origen específica y enviar el tráfico a la estación de monitoreo conectada a otro dispositivo leaf mediante el túnel GRE.
La duplicación de puerto remoto con GRE para flujo específico del inquilino se admite en dispositivos leaf en una arquitectura ERB. En este caso, puede implementar el filtro de duplicación de puerto remoto en la interfaz de enrutamiento y puente integrados (IRB) para reflejar el tráfico entre VLAN (enrutado). Para reflejar el tráfico intra-VLAN (puente), aplique un filtro de interfaz a la interfaz de entrada conectada al servidor o dispositivo host.
En cualquiera de los métodos, spine u leaf, el tráfico reflejado fluye hacia el analizador remoto a través de un túnel GRE.
Duplicación remota de puertos con conmutadores de la serie QFX
En los siguientes ejemplos, demostramos diferentes formas de usar la duplicación remota de puertos para una arquitectura ERB basada en conmutadores de la serie QFX.
Los conmutadores QFX5110 y QFX5120 funcionan bien como dispositivos leaf en una arquitectura de centro de datos de referencia ERB, ya que estos modelos pueden realizar enrutamiento de identificadores de red intervirtuales (VNI).
En la Tabla 1 se muestra la compatibilidad del tipo de instancia de creación de reflejo de puertos para diversos casos de uso cuando se utilizan conmutadores QFX10002 y QFX10008. La Tabla 2 muestra lo mismo cuando se utilizan conmutadores QFX5110 y QFX5120.
| Caso de uso |
Sub Caso de uso |
Instancia del analizador |
Instancia de creación de reflejo de puerto |
|---|---|---|---|
| Spine que proporciona tránsito IP |
Entrada de la hoja a la espina dorsal |
Apoyado |
Apoyado |
| Salida de la columna vertebral a la hoja |
Apoyado |
Apoyado |
|
| Columna vertebral en un escenario CRB |
Entrada de IRB que termina el tráfico |
Solo se admiten las interfaces ge, xe, et y ae |
No compatible |
| Salida de IRB que termina el tráfico |
Solo se admiten las interfaces ge, xe, et y ae |
No compatible |
|
| Encapsulación de borde |
Entrada de acceso de ESI-LAG |
Apoyado |
Apoyado |
| Desencapsulación de bordes |
Salida del tejido |
No compatible |
No compatible |
| Caso de uso |
Sub Caso de uso |
Instancia del analizador |
Instancia de creación de reflejo de puerto |
|---|---|---|---|
| Lean spine que proporciona tránsito IP |
Entrada de la hoja a la espina dorsal |
Apoyado |
Apoyado |
| Salida de la columna vertebral a la hoja |
Apoyado |
No compatible |
|
| Leaf en un escenario ERB |
Entrada de IRB que termina el tráfico |
Solo se admiten las interfaces ge, xe, et y ae |
Apoyado |
| Salida de IRB que termina el tráfico |
Solo se admiten las interfaces ge, xe, et y ae |
No compatible |
|
| Encapsulación de borde |
Entrada de acceso de ESI-LAG |
Apoyado |
Apoyado |
| Salida de acceso de ESI-LAG |
Apoyado |
No compatible |
|
| Desencapsulación de bordes |
Entrada de la estructura |
No compatible |
No compatible |
| Salida del tejido |
No compatible |
No compatible |
Todos los conmutadores QFX de este ejemplo ejecutan Junos OS versión 18.4R2 o posterior. Los conmutadores QFX5110 y QFX5120 que ejecutan Junos OS versión 18.4R2 admiten estos números de escala:
-
Sesiones predeterminadas del analizador: 4
-
Sesiones de duplicación de puertos: sesiones de creación de reflejo de 3 puertos + 1 sesión de creación de reflejo de puerto global
Esta NCE cubre los siguientes casos de uso:
-
Ejemplo: La solución de entrada/salida para un dispositivo EVPN-VXLAN ERB Fabric Spine muestra cómo reflejar el tráfico de entrada y salida a través de un dispositivo lean spine en una estructura ERB.
-
Ejemplo: Solución de entrada para un dispositivo leaf de estructura EVPN-VXLAN ERB muestra cómo reflejar el tráfico de entrada a través de un dispositivo LEAF en un escenario ERB.
-
Ejemplo: Habilitar una instancia de espejado remoto en una interfaz ESI-LAG muestra cómo utilizar una instancia de creación de reflejo de puerto o una instancia de analizador en el caso de uso de encapsulación de borde para acceder al tráfico de entrada y salida a través de una interfaz ESI-LAG.
-
Ejemplo: Habilitar una instancia de analizador remoto en una interfaz ESI-LAG muestra cómo utilizar una instancia de analizador para reflejar el tráfico de entrada y salida a través de una interfaz ESI-LAG.
Utilice los procedimientos descritos en estos ejemplos para habilitar la creación de reflejo de puerto remoto para su caso de uso particular.
Topología
Requisitos
Este ejemplo de configuración utiliza los siguientes dispositivos que ejecutan Junos OS versión 18.4R2 o posterior. Este ejemplo se volvió a validar en conmutadores QFX que ejecutan Junos 22.2R1.
-
Dos conmutadores QFX5110 como dispositivos de columna esbelta.
-
Un conmutador QFX10002 como dispositivo de hoja de borde.
-
Dos conmutadores QFX5110 o 5120 como dispositivos Leaf 1 y Leaf 2 de servidor.
-
Un QFX10002 como servidor Leaf 4. Si lo desea, puede utilizar una QFX5110 o QFX5120 en lugar de una QFX10002.
-
Dos servidores que envían y reciben tráfico a través de la estructura EVPN-VXLAN.
-
Una estación de monitoreo equipada con una aplicación de analizador. En este ejemplo, usamos Wireshark.
Topología de línea base
Este NCE se centra en cómo agregar diferentes tipos de duplicación de puertos a una estructura EVPN-VXLAN existente. En la figura 1 se detalla la topología de línea base de todos los ejemplos siguientes.
de línea base de creación de reflejo de puertos
Las espinas 1 y 2 son dispositivos de espinas magras que no realizan ninguna encapsulación o desencapsulación VXLAN. Los servidores 1 y 2 comparten la VLAN 101 y la subred 10.1.101.0/24. El servidor 1 comienza con base única en la hoja 1. En secciones posteriores, lo adjuntamos a la hoja 2 para formar una interfaz ESI-LAG. El servidor 2 se conecta al Leaf 4. La hoja 3 funciona como una hoja de borde. Su configuración es la misma que la utilizada en las hojas del servidor. Tenga en cuenta que en este ejemplo, Leaf 4 es un conmutador QFX10000 conectado al dispositivo analizador en la interfaz xe-0/0/33:1.
La topología admite multiconexión con ESI-LAG entre el servidor 1 y las hojas 1 y 2. No todos los escenarios de este NCE usan esta capacidad de host múltiple. Para ver las configuraciones completas del dispositivo de inicio, consulte el Apéndice: Configuraciones completas de dispositivos.
Ejemplo: solución de entrada/salida para un dispositivo EVPN-VXLAN ERB Fabric Spine
Visión general
En este ejemplo, habilitamos la duplicación remota de puertos en un conmutador lean spine. El tráfico reflejado se envía a través de un túnel GRE a la estación de monitoreo remoto. Este caso de uso se basa en el método de instancia de creación de reflejo de puertos.
En este ejemplo se utiliza una arquitectura ERB EVPN-VXLAN en la que el enrutamiento del identificador de red intervirtual (VNI) de unidifusión tiene lugar en los dispositivos leaf. Los dispositivos lean spine no terminan ningún túnel VXLAN. Proporcionan reenvío de IP y, en el caso de una superposición basada en IBGP, capacidades de reflexión de ruta. Nuestra superposición está basada en EBGP, por lo que no utilizamos la reflexión de ruta.
Esta configuración refleja todo el tráfico enviado entre los dispositivos leaf. La estación de monitoreo captura el tráfico intra-VLAN (puenteado) e inter-VLAN (enrutado) para todas las VLAN en las hojas. La información específica del inquilino no se aprovisiona en los dispositivos lean spine, pero puede habilitar las sesiones de duplicación en lean spine.
Tenga en cuenta la capacidad del puerto del analizador. Una gran cantidad de tráfico pasa a través del puerto del analizador porque está reflejando todo el tráfico de superposición enviado entre el emparejamiento de hojas. Los dispositivos leaf están unidos a la columna vertebral con dos interfaces 40GE, por lo que tienen la capacidad de transportar grandes volúmenes de tráfico. Los conmutadores tienen capacidades limitadas de almacenamiento en búfer. Las caídas de tramas se producen si refleja más tráfico del que admite la estación de supervisión.
Para agregar capacidad, utilice una interfaz Ethernet agregada con varios miembros de vínculo. Reduzca la carga de tráfico realizando la creación de reflejo en los dispositivos leaf y la duplicación selectiva del tráfico solo para ciertos inquilinos.
Topología
En este ejemplo de configuración se utilizan los componentes de hardware y software que se muestran en Requisitos. Los dispositivos de la topología comienzan con sus configuraciones de línea base, tal como se proporciona en el Apéndice: Configuraciones completas de dispositivos.
Como se muestra en la Figura 2, Spine 1 refleja el tráfico de superposición de entrada y salida que fluye entre Leaf 1 y Leaf 4 a través de un filtro de firewall aplicado a su interfaz et-0/0/7. Esta interfaz se conecta al servidor Leaf 1. El tráfico de superposición se genera mediante el envío de tráfico de ping entre el servidor 1 y el servidor 2. El tráfico reflejado es enviado por Spine 1 a la estación de monitoreo remoto conectada a la interfaz xe-0/0/33:1 en el borde Leaf 3.
spine
La columna vertebral utiliza un túnel GRE para enviar el tráfico reflejado a la estación de monitoreo. GRE es necesario, ya que el tráfico reflejado puede ser de capa 2 o capa 3 de superposición y, por lo tanto, no se puede enrutar sobre la capa subyacente de la estructura. El túnel GRE se forma automáticamente una vez que se establece la accesibilidad IP hacia la subred de monitoreo 172.16.1.0/24 a través de la capa subyacente.
En este escenario, el servidor 1 es de base única para la hoja 1.
Configuración
Utilice este ejemplo para reflejar el tráfico que pasa por Spine 1. Para reflejar todo el tráfico, repita la configuración en Spine 2. Cuando la duplicación de puertos está configurada en los espines 1 y 2, el tráfico se refleja independientemente del siguiente salto de la estructura ECMP que seleccione la hoja.
-
(Opcional) Desactive BGP en la columna vertebral 2. Para nuestras pruebas, desactivamos la estrofa BGP en Spine 2. De esta manera, podemos centrarnos solo en Spine 1 y asegurarnos de que todo el tráfico entre Leaf 1 y Leaf 4 se refleje.
user@spine2# deactivate protocols bgp user@spine2# commit
Después de desactivar BGP en Spine 2, Leaf 1 tiene un solo salto siguiente para llegar al loopback de Leaf 4. Esto es a través de Spine 1 a través de su interfaz et-0/0/48.
user@leaf1> show route 10.1.255.14 inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.255.14/32 *[BGP/170] 04:10:11, localpref 100 AS path: 65001 65014 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0 -
Cree una instancia de creación de reflejo en Spine 1 para enviar el tráfico reflejado a la estación de supervisión remota.
user@spine1# set forwarding-options port-mirroring instance mirror-leaf1-and-leaf4 family inet output ip-address 172.16.1.2
-
Las espinas delgadas no son conscientes de la superposición en una tela ERB. Todo el tráfico encapsulado en VXLAN enviado entre dispositivos leaf utiliza la dirección VTEP local. La dirección VTEP normalmente coincide con la dirección de circuito cerrado del dispositivo. Esto significa que podemos usar un filtro en los dispositivos spine para que coincida con las direcciones de circuito cerrado de los dispositivos leaf relacionados para dirigir el tráfico a la instancia de duplicación de puertos.
En Spine 1, cree filtros de firewall que coincidan con las direcciones IP de origen y destino de Leaf 1 y Leaf 4. Al hacer coincidir tanto la IP de origen como la de destino, todo el tráfico de superposición enviado entre estas hojas se refleja en el túnel GRE.
Nota:Debido a que las espinas delgadas no son compatibles con VXLAN, este método refleja todo el tráfico de superposición enviado por el dispositivo leaf. Por ejemplo, si la hoja tiene definidas 100 VNI VLAN o VXLAN, se refleja el tráfico de todos los 100 VNI. Si desea reflejar en un nivel más fino de granularidad, consulte Ejemplo: Solución de entrada para un dispositivo Leaf de estructura ERB EVPN-VXLAN. En ese ejemplo, la función mirror se produce en el dispositivo leaf compatible con VXLAN.
Establezca un filtro de firewall para el tráfico enviado desde Leaf 1. En nuestro ejemplo, todo el tráfico VXLAN enviado por la hoja 1 (a través de las espinas) tiene una dirección de origen de 10.1.255.11. Todo el tráfico VXLAN enviado por Leaf 4 tiene una dirección de origen de 10.1.255.14.
[edit firewall family inet filter port-mirror-from-leaf1] user@spine1# set term term1 from source-address 10.1.255.11/32 user@spine1# set term term1 from destination-address 10.1.255.14/32 user@spine1# set term term1 then count from-leaf1-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
Establezca un filtro de firewall para el tráfico enviado desde Leaf 4.
[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from source-address 10.1.255.14/32 user@spine1# set term term1 from destination-address 10.1.255.11/32 user@spine1# set term term1 then count from-leaf4-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
-
Aplique los filtros de firewall a las interfaces de estructura orientadas a Leaf 1 y Leaf 4 en Spine 1.
user@spine1# set interfaces et-0/0/7 unit 0 family inet filter input port-mirror-from-leaf1 user@spine1# set interfaces et-0/0/6 unit 0 family inet filter input port-mirror-from-leaf4
Tenga en cuenta la direccionalidad de la aplicación de filtro. Nuestros filtros se adaptan a una plataforma QFX5110, que solo admite filtros de entrada para la duplicación de puertos, según la Tabla 2. Mediante el uso de filtros de entrada que coinciden en el VTEP de la hoja local como dirección de origen y el VTEP de la hoja remota como dirección de destino, nos aseguramos de que solo se refleje el tráfico de superposición entre estas dos hojas. Si desea reflejar todo el tráfico VXLAN enviado por un leaf, independientemente del leaf de destino, simplemente haga coincidir la dirección de origen del leaf local en su filtro.
-
(Opcional) Agregue los filtros adicionales.
En este ejemplo hasta ahora, hemos asumido que el servidor 1 es de base única solo para Leaf 1. Si el servidor es multihost para Leaf 1 y Leaf 2, debe adaptar los filtros que se muestran para capturar también el tráfico enviado desde Leaf 2 a Leaf 4, y viceversa.
Como ejemplo, estas instrucciones crean un filtro de entrada para la interfaz orientada a Leaf 2 de Spine 1:
[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from source-address 10.1.255.12/32 user@spine1# set term term1 from destination-address 10.1.255.14/32 user@spine1# set term term1 then count from-leaf2-vtep user@spine1# set term term1 then port-mirror-instance mirror-leaf1-and-leaf4 user@spine1# set term term1 then accept user@spine1# set term term2 then accept
[edit] user@spine1# set interfaces et-0/0/8 unit 0 family inet filter input port-mirror-from-leaf2
Se necesita una modificación rápida del filtro existente
port-mirror-from-leaf4para que también coincida con la dirección de destino de 2 VTEP de Leaf.[edit firewall family inet filter port-mirror-from-leaf4] user@spine1# set term term1 from destination-address 10.1.255.12/32
-
Confirmar los cambios en Spine 1.
Se muestran los cambios con respecto a la línea base inicial de EVPN-VXLAN:
user@spine1# show | compare rollback 1 [edit interfaces et-0/0/6 unit 0 family inet] + filter { + input port-mirror-from-leaf4; + } [edit interfaces et-0/0/7 unit 0 family inet] + filter { + input port-mirror-from-leaf1; + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1-and-leaf4 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family inet { + filter port-mirror-from-leaf1 { + term term1 { + from { + source-address { + 10.1.255.11/32; + } + destination-address { + 10.1.255.14/32; + } + } + then { + count from-leaf1-vtep; + port-mirror-instance mirror-leaf1-and-leaf4; + accept; + } + } + term term2 { + then accept; + } + } + filter port-mirror-from-leaf4 { + term term1 { + from { + source-address { + 10.1.255.14/32; + } + destination-address { + 10.1.255.11/32; + } + } + then { + count from-leaf4-vtep; + port-mirror-instance mirror-leaf1-and-leaf4; + accept; + } + } + term term2 { + then accept; + } + } + } + } -
Modifique la configuración en la hoja 3 para configurar la interfaz xe-0/0/33:1 conectada a la estación de monitoreo.
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
El dispositivo leaf conectado a la estación de monitoreo no necesita una configuración GRE explícita. Esto se debe a que el túnel GRE termina en la estación de monitoreo. Debe asegurarse de que la dirección IP de la estación de supervisión sea accesible en la capa subyacente de la estructura. Dicho de otra manera, la columna vertebral no puede enviar el tráfico encapsulado GRE a la estación de monitoreo si no tiene accesibilidad subyacente a la estación de monitoreo.
-
Modifique la política de exportación subyacente en la hoja 3 del borde para anunciar el prefijo de la estación de monitoreo. Nuestra topología utiliza una base de EBGP. Simplemente añadimos un nuevo término a la política de exportación subyacente existente.
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
Confirmar los cambios en el borde Leaf 3.
Se muestran los cambios en la línea base inicial:
user@bl-leaf3# show | compare rollback 1 [edit interfaces] + xe-0/0/33:1 { + unit 0 { + family inet { + address 172.16.1.1/24; + } + } + } [edit policy-options policy-statement send-direct] term 1 { ... } + term 2 { + from { + protocol direct; + route-filter 172.16.1.0/24 exact; + } + then accept; + }
Verificación
-
Verifique la conectividad subyacente desde Spine 1 hasta la estación de monitoreo.
En la columna vertebral 1, muestra la ruta a 172.16.1.0/24.
user@spine1> show route 172.16.1.0/24 inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 00:32:00, localpref 100 AS path: 65013 I, validation-state: unverified > to 10.1.13.2 via et-0/0/5.0Nota:Estrictamente hablando, solo se requiere una conectividad simple entre la columna vertebral y la estación de monitoreo. Hemos configurado una ruta estática en la estación de monitoreo para permitir que llegue a la capa subyacente de la estructura. Esto permite realizar pruebas de ping para el aislamiento de fallas.
Haga ping a la estación de monitoreo para confirmar la conectividad.
user@spine1> ping 172.16.1.2 count 2 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=63 time=1.116 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=63 time=1.046 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.046/1.081/1.116/0.035 ms
La salida confirma la accesibilidad esperada de la capa subyacente desde la columna vertebral hasta la estación de monitoreo.
- Confirme las instancias de creación de reflejo de puertos en Spine 1. En el spine 1, compruebe que el estado de creación de reflejo del puerto remoto es
up.user@spine1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1-and-leaf4 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 .local..0El resultado confirma la definición correcta de la instancia de creación de reflejo del puerto. El estado de indica que la columna vertebral tiene una ruta subyacente a la estación de
upmonitoreo. Recuerde que GRE es un protocolo sin estado. Es por eso que es una buena idea verificar la conectividad entre la columna vertebral y la estación de monitoreo, como lo hicimos en el paso anterior. -
Compruebe que los filtros aplicados a Spine 1 reflejan correctamente el tráfico de prueba.
Borre los contadores justo antes de generar cualquier ping.
user@server1> clear firewall all
Comience a hacer ping entre el servidor 1 y el servidor 2 a través de la estructura.
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
Ahora muestre los contadores de firewall en Spine 1. Compruebe que los filtros aplicados a Spine 1 reflejan correctamente el tráfico de prueba. Nuestra topología de ejemplo solo tiene una VLAN y un par de servidores. Esto facilita la correlación del tráfico de prueba para filtrar coincidencias. Cualquier recuento distinto de cero es una buena señal de que el filtro está funcionando.
user@spine1> show firewall Filter: port-mirror-from-leaf1 Counters: Name Bytes Packets from-leaf1-vtep 1520 10 Filter: port-mirror-from-leaf4 Counters: Name Bytes Packets from-leaf4-vtep 1520 10
Los contadores de firewall reflejan correctamente el tráfico de prueba entre los dos servidores.
-
Confirme que el tráfico enviado entre el servidor 1 y el servidor 2 se refleja en Spine 1 y se envía a la estación de supervisión.
Una vez más, genere tráfico entre los servidores 1 y 2 (no se muestra por brevedad). Use la opción del comando ping para generar un mayor volumen de tráfico de prueba que facilite la
rapidcorrelación.El tráfico de la interfaz de monitoreo cuenta en la interfaz en el borde Leaf 3 que se conecta a la estación de monitoreo. Confirme que los recuentos de paquetes de salida reflejan el tráfico de prueba generado.
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]La salida confirma que el tráfico se refleja en la estación de monitoreo. Se espera la falta de paquetes de entrada, ya que la estación de monitoreo no genera ninguna respuesta al tráfico GRE recibido.
-
Utilice Wireshark o una aplicación de análisis equivalente para capturar y decodificar el tráfico reflejado.
Figura 3: Análisis
de tráfico reflejado
La captura muestra que el Servidor 1 envía tráfico de ping al Servidor 2 y que el Servidor 2 responde. Esto confirma que el tráfico de superposición enviado entre el emparejamiento Leaf 1 y Leaf 4 se refleja correctamente en Spine 1. Tenga en cuenta que el tráfico encapsulado de VXLAN (puerto UDP 4789) se encapsula a su vez en GRE (protocolo IP 47). El tipo de protocolo del encabezado GRE es "ERSPAN" (comparable a la duplicación de puerto remoto) y todos los demás indicadores se establecen en cero.
La decodificación le permite ver el VTEP de hoja o las direcciones de bucle invertido utilizadas en la capa subyacente (10.1.255.x). También está presente la trama original de capa 2 enviada por los servidores, que ahora se muestra encapsulada en VXLAN usando VNI 101. El paquete IP enviado por los servidores también se decodifica. Las direcciones IP utilizadas por los servidores en la superposición son visibles (10.1.100.x/24), al igual que los detalles de los paquetes IP/ICMP que generaron.
Ha configurado correctamente la creación de reflejo de puertos en la topología.
Ejemplo: solución de entrada para un dispositivo leaf de estructura EVPN-VXLAN ERB
Visión general
Utilice el siguiente ejemplo para reflejar el tráfico que fluye a través de un dispositivo leaf en una estructura ERB EVPN-VXLAN. A diferencia del escenario de creación de reflejo de puertos basado en spine lean que se describe en el primer ejemplo, la hoja es compatible con inquilinos y VLAN en un diseño de ERB. Esto significa que podemos reflejar el tráfico específico enviado entre nuestros dispositivos leaf en lugar de todo el tráfico superpuesto. Los flujos de inquilino que coinciden con los criterios de filtrado del dispositivo ERB leaf se reflejan en un túnel GRE que termina en la estación de supervisión adjunta al borde Leaf 3.
Topología
En este ejemplo de configuración se utilizan los componentes de hardware y software que se muestran en Requisitos. Los dispositivos de la topología comienzan con sus configuraciones de línea base, tal como se proporciona en el Apéndice: Configuraciones completas de dispositivos.
La figura 4 muestra la topología para la creación de reflejo de puertos remotos con capacidades de filtrado de flujo de inquilinos.
Leaf
Tenga en cuenta que el servidor 1 sigue siendo de base única solo para Leaf 1. La diferencia es que los filtros y la instancia de duplicación de puertos ahora se definen en el dispositivo leaf. El objetivo es hacer coincidir todo el tráfico enviado por el servidor 1 con la subred 10.1.101.0/24 asociada con la VLAN 101. El tráfico enviado desde el servidor 1 a los destinos de VLAN 101 se empareja y se envía a la estación de duplicación de puertos en la hoja 3 del borde.
Configuración
En el primer escenario, desactivamos BGP en Spine 2 para centrarnos en la aplicación de filtros en Spine 1. En los ejemplos restantes, tanto Spine 1 como Spine 2 están en pleno funcionamiento.
-
Configure una instancia de creación de reflejo de puerto en la hoja 1. Utilice la dirección IP 172.16.1.2 para la estación de monitoreo.
user@leaf1# set forwarding-options port-mirroring instance mirror-leaf1-v101 family inet output ip-address 172.16.1.2
-
A continuación, cree un filtro de firewall que coincida con la subred asignada a VLAN 101. El objetivo es reflejar todo el tráfico intra-VLAN 101 enviado por el servidor 1 a través de la hoja 1. Para capturar tráfico entre VLAN, especifique la subred de la VLAN de destino para la dirección de destino.
[edit firewall family ethernet-switching filter mirror-leaf-1] user@leaf1# set term 1 from ip-source-address 10.1.101.0/24 user@leaf1# set term 1 from ip-destination-address 10.1.101.0/24 user@leaf1# set term 1 then accept user@leaf1# set term 1 then port-mirror-instance mirror-leaf1-v101 user@leaf1# set term 1 then count from-s1-v101 user@leaf1# set term 2 then accept
Nota:Si desea reflejar solo el tráfico enrutado (inter-VLAN), utilice un
family inetfiltro aplicado a la interfaz IRB de la VLAN. Solo se define una interfaz IRB para cada VLAN. Un filtro aplicado a la interfaz IRB de la VLAN captura todo el tráfico entre VLAN para la VLAN asociada, independientemente del puerto del panel frontal en el que llegue el tráfico.El método que se muestra aquí funciona para el tráfico entre VLAN y dentro de VLAN, pero requiere que se apliquen filtros a las interfaces orientadas al servidor en función de su pertenencia a VLAN. Un
inetfiltro aplicado a una interfaz IRB no ve el tráfico en puente (intra-VLAN). -
Aplique el filtro de firewall de duplicación de puerto remoto al puerto de acceso conectado al servidor 1 en la dirección de entrada.
user@leaf1# set interfaces xe-0/0/0 unit 0 family ethernet-switching filter input mirror-leaf-1
Nota:En los conmutadores QFX5110 y QFX5120, el filtro de firewall no se puede aplicar en la dirección de salida ni utilizarse en las interfaces de estructura conectadas a los dispositivos spine.
-
No es necesario configurar Border Leaf 3 para realizar la desencapsulación GRE, ya que el túnel GRE termina en la estación de monitoreo. Sin embargo, Leaf 3 necesita anunciar la accesibilidad de la subred de la estación de monitoreo en la capa subyacente de la estructura. Configure lo siguiente en la hoja 3 para establecer la accesibilidad a la estación de monitoreo.
Comience configurando la interfaz xe-0/0/33:1 conectada a la estación de monitoreo.
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
-
Modifique la política de exportación subyacente en la hoja 3 del borde para anunciar el prefijo de la estación de monitoreo. Nuestra topología utiliza una base de EBGP. Simplemente añadimos un nuevo término a la política de exportación subyacente existente.
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
Confirme la configuración.
Los cambios desde la línea base inicial se muestran en la hoja 1.
user@bl-leaf1# show | compare rollback 1 [edit interfaces xe-0/0/0 unit 0 family ethernet-switching] + filter { + input mirror-leaf-1; + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family ethernet-switching { + filter mirror-leaf-1 { + term 1 { + from { + ip-source-address { + 10.1.101.0/24; + } + ip-destination-address { + 10.1.101.0/24; + } + } + then { + accept; + port-mirror-instance mirror-leaf1; + count from-s1; + } + } + term 2 { + then accept; + } + } + } + }Ha configurado correctamente la duplicación de puertos remotos a través de un dispositivo leaf en una estructura ERB EVPN-VXLAN.
Verificación
-
Verifique la conectividad subyacente desde la hoja 1 hasta la estación de monitoreo.
En la hoja 1, muestre la ruta a 172.16.1.0/24.
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0Nota:Estrictamente hablando, solo se requiere una conectividad simple entre la hoja y la estación de monitoreo. Hemos configurado una ruta estática en la estación de monitoreo para permitir que llegue a la capa subyacente de la estructura. Esto permite que las pruebas de ping ayuden en el aislamiento de fallas.
Haga ping a la estación de monitoreo para confirmar la conectividad.
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
La salida confirma la accesibilidad esperada de la capa subyacente desde la hoja 1 hasta la estación de monitoreo. Debemos obtener el ping de la dirección de circuito cerrado de la hoja porque nuestra política de exportación subyacente solo anuncia la accesibilidad de la dirección de circuito cerrado. El abastecimiento de la dirección de circuito cerrado no era necesario en el ejemplo de la columna vertebral lean. Esto se debe a que la columna vertebral y la hoja del borde están directamente unidas a través de un enlace de tela. Por lo tanto, la hoja de borde puede enrutar la respuesta de ping a la columna vertebral cuando se obtiene de la interfaz de estructura orientada hacia la hoja de la espina.
-
Confirme la instancia de creación de reflejo del puerto en la hoja 1.
En la hoja 1, compruebe que el estado de creación de reflejo del puerto remoto sea
up.user@leaf1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 et-0/0/48.0El resultado confirma la definición correcta de la instancia de creación de reflejo del puerto. El estado de indica que la hoja tiene una ruta subyacente a la estación de
upmonitoreo. Recuerde que GRE es un protocolo sin estado. Es por eso que es una buena idea verificar la conectividad entre la hoja y la estación de monitoreo, como lo hicimos en el paso anterior. -
Compruebe que el filtro aplicado a Leaf 1 refleja correctamente el tráfico de prueba.
Comience a hacer ping entre el servidor 1 y el servidor 2 a través de la estructura. Verifique que el filtro aplicado a Leaf 1 refleje correctamente el tráfico. Nuestra topología de ejemplo solo tiene una VLAN y un par de servidores. Esto facilita la correlación del tráfico de prueba para filtrar coincidencias. Cualquier recuento distinto de cero es una buena señal de que el filtro está funcionando.
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
Borre los contadores justo antes de generar cualquier ping.
user@server1> clear firewall all
Ahora muestre los contadores de firewall en Spine 1.
user@leaf1> show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 1020 10
Los contadores de firewall reflejan correctamente el tráfico de prueba entre los dos servidores.
-
Confirme que el tráfico enviado entre el servidor 1 y el servidor 2 se refleja en la hoja 1 a la estación de supervisión.
Una vez más, genere tráfico entre los servidores 1 y 2 (no se muestra por brevedad). Usamos la opción rápida para el comando ping para generar un mayor volumen de paquetes para facilitar la detección.
Monitoree los contadores de tráfico de la interfaz en la hoja 3 del borde para verificar que el tráfico de prueba se está enviando a la estación de monitoreo.
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]La salida confirma que el tráfico se refleja en la estación de monitoreo. La falta de paquetes de entrada se espera porque la estación de monitoreo no genera ninguna respuesta al tráfico GRE que recibe.
-
Utilice Wireshark o una aplicación de análisis equivalente para capturar y decodificar el tráfico reflejado.
Figura 5: Análisis
de tráfico reflejado
La captura muestra que el servidor 1 envía tráfico de ping al servidor 2. El tráfico de respuesta no se refleja porque hemos aplicado nuestro filtro en la dirección de entrada solo en la hoja 1. Aplique una instancia de espejo de puerto similar y una configuración de filtro en la hoja 4 para reflejar también el tráfico de retorno. Recuerde que en el caso de la columna vertebral delgada, el tráfico reflejado mostró encapsulación VXLAN. En nuestro caso de hoja ERB, reflejamos el tráfico de capa 2 antes de que se encapsule en VXLAN. El filtro utilizado para reflejar el tráfico se aplica como filtro de entrada en la interfaz orientada al servidor. En la entrada no hay encapsulación VXLAN.
Esto es similar al caso de aplicar el filtro a la interfaz IRB de una VLAN. En el caso IRB, el tráfico reflejado no contiene encapsulación VXLAN. Los filtros basados en IRB procesan el tráfico entre VLAN en la capa IP. Por lo tanto, para el caso del filtro IRB solo se refleja el tráfico IP de capa 3.
La decodificación muestra que el túnel GRE está entre la hoja 1 y la estación de monitoreo a través de la capa subyacente. La trama Ethernet y el paquete IP relacionado, tal como los envía el servidor 1, se decodifican. Las direcciones IP asignadas a los servidores son visibles (10.1.100.x/24), al igual que los detalles del paquete IP/ICMP generado por el servidor 1.
Ha configurado correctamente la creación de reflejo de puertos en la topología.
Ejemplo: habilitar una instancia de creación remota de reflejo en una interfaz ESI-LAG
Visión general
Un identificador de segmento Ethernet (ESI) es el número único de 10 bytes que identifica un segmento Ethernet en una estructura EVPN-VXLAN conectada al servidor. El ESI se configura en la interfaz que se conecta al servidor. Cuando varios vínculos forman un grupo de agregación de vínculos (LAG) y están conectados al servidor, se forma una interfaz ESI-LAG, también conocida como LAG de EVPN. En algunos casos, deberá habilitar la duplicación de puertos para todo o parte del tráfico que entra o sale de la interfaz ESI-LAG.
Utilice esta sección para habilitar la creación de reflejo de puertos remotos en el nivel ESI-LAG de una estructura ERB de EVPN-VXLAN.
Topología
En este ejemplo de configuración se utilizan los componentes de hardware y software que se muestran en Requisitos. Los dispositivos de la topología comienzan con sus configuraciones de línea base, tal como se proporciona en el Apéndice: Configuraciones completas de dispositivos.
En este caso, modificamos la estructura EVPN para admitir la multiconexión del servidor 1 a las hojas 1 y 2. Hacemos esto usando interfaces ESI-LAG, también conocidas como EVPN LAG. Consulte Prácticas recomendadas de configuración del LAG EVPN para conocer las prácticas recomendadas.
La figura 6 muestra la topología de este ejemplo. Ambas espinas están operativas en esta topología. ECMP significa que Leaf 1 y Leaf 2 pueden enviar tráfico a través de cualquiera de los dispositivos de columna vertebral. Para simplificar la ilustración, mostramos el tráfico y las rutas de espejo con Spine 1 como foco.
ESI-LAG
La interfaz ae0.0 es la interfaz ESI-LAG conectada al servidor 1. Al servidor 1 se le asigna la dirección IP 10.1.101.10/24 y está asociado con VLAN 101. El objetivo es filtrar y reflejar el tráfico enviado desde el servidor 1 a medida que pasa a través de ae0.0 en cualquiera de las hojas. El tráfico reflejado se coloca en un túnel GRE y se envía a la estación de monitoreo. Como antes, debe asegurarse de que la subred de la estación de supervisión sea accesible en la base de EBGP.
Antes de empezar
Si está comenzando desde la configuración de línea base que se muestra en el Apéndice: Configuraciones completas de dispositivos, siga estos pasos para modificar la topología antes de comenzar.
-
Modifique la configuración de Leaf 1 y Leaf 2 para admitir la conexión multihost del servidor 1. Comience cambiando el nombre de la interfaz xe-0//0/0 existente para que se convierta en la nueva interfaz ae0.0. Esto afecta a cualquier configuración de la interfaz xe-0/0/0 para ahorrar algo de tiempo.
user@leaf1# rename interfaces xe-0/0/0 to ae0 user@leaf1# set interfaces ae0 esi 00:02:02:02:02:02:02:02:00:04 user@leaf1# set interfaces ae0 esi all-active user@leaf1# set interfaces ae0 aggregated-ether-options lacp active user@leaf1# set interfaces ae0 aggregated-ether-options lacp system-id 00:00:02:02:00:04
-
Los detalles de configuración para la interfaz Ethernet agregada del servidor, a menudo denominada interfaz enlazada en Linux, están fuera del alcance de este NCE. Tenga en cuenta que para el servidor, solo hay una configuración Ethernet agregada estándar. Las instrucciones relacionadas con ESI-LAG solo se aplican a los dispositivos leaf.
Nota:La configuración de línea base inicial habilita una interfaz Ethernet agregada mediante la instrucción de
set chassis aggregated-devices ethernet device-count 1configuración. Debe habilitar la compatibilidad del chasis para dispositivos agregados o no se creará la interfaz agregada. -
Después de aplicar y confirmar estos cambios tanto en los dispositivos leaf como en el servidor, confirme que la interfaz ae0 esté activa en ambas hojas. El resultado de ejemplo siguiente se ha acortado para mayor claridad.
user@leaf2> show interfaces ae0 Physical interface: ae0, Enabled, Physical link is Up Physical interface: ae0, Enabled, Physical link is Up [...] Current address: b8:c2:53:ba:8b:80, Hardware address: b8:c2:53:ba:8b:80 Ethernet segment value: 00:02:02:02:02:02:02:02:00:04, Mode: all-active Last flapped : 2022-09-07 14:57:53 UTC (01:06:43 ago) [...] Egress queues: 12 supported, 5 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 81129 81129 0 3 0 0 0 4 0 0 0 7 4135 4135 0 8 64 64 0 [...] Protocol eth-switch, MTU: 1514, Generation: 266, Route table: 7, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, EVPN multi-homed ESI Split Horizon Label: 0, Next-hop: 1665, vpls-status: up Local Bias Logical Interface Name: vtep.32769, Index: 554, VXLAN Endpoint Address: 10.1.255.11 Flags: Is-PrimaryCompruebe también que el servidor 1 pueda hacer ping al servidor 2 (no se muestra por brevedad).
Configuración
En este ejemplo, se muestra cómo habilitar la creación de reflejo de puerto remoto en el nivel ESI-LAG mediante una instancia de creación de reflejo de puerto remoto. Este método admite criterios de coincidencia específicos del inquilino (dentro de una VLAN superpuesta) para reflejar selectivamente el tráfico.
-
Configure una instancia de creación de reflejo de puerto tanto en la hoja 1 como en la hoja 2. El servidor 1 puede enviar tráfico para la VLAN 101 a través de cualquiera de sus interfaces miembro del LAG. ECMP significa que el tráfico puede llegar a cualquiera de las hojas. La dirección IP 172.16.1.2 es la estación de monitoreo.
user@leaf1# set forwarding-options port-mirroring instance mirror-leaf1-v101 family inet output ip-address 172.16.1.2
-
A continuación, cree un filtro de firewall que coincida con la subred asignada a VLAN 101 en ambas hojas. El objetivo es reflejar todo el tráfico intra-VLAN 101 enviado por el servidor 1 a través de Leaf 1 o Leaf 2. Para capturar tráfico entre VLAN, especifique la subred de la VLAN de destino para la dirección de destino.
Si necesita filtrar por varias direcciones IP de origen o destino, considere usar a y/o a
source-prefix-listdestination-prefix-listen su filtro. De esta forma, puede realizar cambios en la lista de prefijos sin tener que modificar la definición del filtro.[edit firewall family ethernet-switching filter mirror-leaf-1] user@leaf1# set term 1 from ip-source-address 10.1.101.0/24 user@leaf1# set term 1 from ip-destination-address 10.1.101.0/24 user@leaf1# set term 1 then accept user@leaf1# set term 1 then port-mirror-instance mirror-leaf1-v101 user@leaf1# set term 1 then count from-s1-v101 user@leaf1# set term 2 then accept
Nota:Si desea reflejar solo el tráfico enrutado (inter-VLAN), utilice un
family inetfiltro aplicado a la interfaz IRB de la VLAN. Solo se define una interfaz IRB para cada VLAN. Por lo tanto, un filtro aplicado a la interfaz IRB de la VLAN captura todo el tráfico entre VLAN para la VLAN asociada, independientemente del puerto del panel frontal en el que ingrese el tráfico.El método que se muestra en este ejemplo funciona para el tráfico entre VLAN y dentro de VLAN, pero requiere que se apliquen filtros a las interfaces orientadas al servidor en función de su pertenencia a VLAN. Un
inetfiltro aplicado a una interfaz IRB no ve el tráfico en puente (intra-VLAN). -
Aplique el filtro de firewall de duplicación de puerto remoto a la interfaz ae0.0 como filtro de entrada en ambas hojas.
user@leaf1# set interfaces ae0 unit 0 family ethernet-switching filter input mirror-leaf-1
Nota:En los conmutadores QFX5110 y QFX5120, el filtro de firewall no se puede habilitar en la dirección de salida ni utilizarse en las interfaces conectadas a los dispositivos spine.
-
No es necesario configurar Border Leaf 3 para realizar la desencapsulación GRE, ya que el túnel GRE termina en la estación de monitoreo. Sin embargo, Leaf 3 necesita anunciar la accesibilidad de la subred de la estación de monitoreo en la capa subyacente de la estructura. Configure la interfaz xe-0/0/33:1 que se conecta a la estación de monitoreo.
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
Modifique la política de exportación subyacente en la hoja 3 del borde para anunciar el prefijo de la estación de monitoreo. Nuestra topología utiliza una base de EBGP. Simplemente añadimos un nuevo término a la política de exportación subyacente existente.
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set term 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
Los cambios en la línea base inicial se muestran en la hoja 1.
#user@leaf1# show | compare base [edit interfaces xe-0/0/0] + gigether-options { + 802.3ad ae0; + } [edit interfaces xe-0/0/0] - unit 0 { - family ethernet-switching { - vlan { - members v101; - } - } - } [edit interfaces] + ae0 { + esi { + 00:02:02:02:02:02:02:02:00:04; + all-active; + } + aggregated-ether-options { + lacp { + active; + system-id 00:00:02:02:00:04; + } + } + unit 0 { + family ethernet-switching { + interface-mode access; + vlan { + members v101; + } + filter { + input mirror-leaf-1; + } + } + } + } [edit] + forwarding-options { + port-mirroring { + instance { + mirror-leaf1 { + family inet { + output { + ip-address 172.16.1.2; + } + } + } + } + } + } + firewall { + family ethernet-switching { + filter mirror-leaf-1 { + term 1 { + from { + ip-source-address { + 10.1.101.0/24; + } + ip-destination-address { + 10.1.101.0/24; + } + } + then { + accept; + port-mirror-instance mirror-leaf1; + count from-s1; + } + } + term 2 { + then accept; + } + } + } + }Ha configurado correctamente la duplicación de puertos remotos a través de un dispositivo leaf en una estructura ERB EVPN-VXLAN.
Verificación
-
Verifique la conectividad subyacente desde la hoja 1 hasta la estación de monitoreo.
En la hoja 1, muestre la ruta a 172.16.1.0/24.
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0Nota:Estrictamente hablando, solo se requiere una conectividad simple entre la hoja y la estación de monitoreo. Hemos configurado una ruta estática en la estación de monitoreo para permitir que llegue a la capa subyacente de la estructura. Esto permite realizar pruebas de ping como herramienta de aislamiento de fallos.
Haga ping a la estación de monitoreo para confirmar la conectividad.
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
La salida confirma la accesibilidad esperada de la capa subyacente desde la hoja 1 hasta la estación de monitoreo. Debemos obtener el ping de la dirección de circuito cerrado de la hoja porque nuestra política de exportación subyacente solo anuncia la accesibilidad de la dirección de circuito cerrado. El abastecimiento de la dirección de circuito cerrado no es necesario en el caso de la columna vertebral delgada. Esto se debe a que la hoja del lomo y el borde comparten un vínculo de estructura conectado directamente.
-
Confirme la instancia de creación de reflejo del puerto en la hoja 1.
En la hoja 1, compruebe que el estado de creación de reflejo del puerto remoto sea
up.user@leaf1> show forwarding-options port-mirroring detail Instance Name: mirror-leaf1 Instance Id: 2 Input parameters: Rate : 1 Run-length : 0 Maximum-packet-length : 0 Output parameters: Family State Destination Next-hop inet up 172.16.1.2 et-0/0/48.0El resultado confirma la definición correcta de la instancia de creación de reflejo del puerto. El estado de indica que la hoja tiene una ruta subyacente a la estación de
upmonitoreo. Recuerde que GRE es un protocolo sin estado. Es por eso que es una buena idea verificar la conectividad entre la hoja y la estación de monitoreo, como lo hicimos en el paso anterior. -
Compruebe que el filtro aplicado a las hojas 1 y 2 refleja correctamente el tráfico de prueba. Comience a hacer ping entre el servidor 1 y el servidor 2 a través de la estructura.
user@server1> ping 10.1.101.20 count 10 rapid PING 10.1.101.20 (10.1.101.20): 56 data bytes !!!!!!!!!! --- 10.1.101.20 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.731/0.800/1.300/0.167 ms
Verifique que el filtro aplicado a Leaf 1 y Leaf 2 refleje correctamente el tráfico. Nuestra topología de ejemplo solo tiene una VLAN y un par de servidores. Esto facilita la correlación del tráfico de prueba para filtrar coincidencias. Cualquier recuento distinto de cero es una buena señal de que el filtro está funcionando.
Debido al comportamiento de ECMP, el flujo de ping único aplica hash a solo uno de los vínculos miembro de la interfaz Ethernet agregada. Esto significa que se espera que el tráfico de prueba se envíe a una hoja o a la otra, pero no a ambas. Si el servidor 1 genera numerosos flujos, espere ver paquetes reenviados a ambas hojas utilizando ambas interfaces miembro.
Borre los contadores justo antes de generar cualquier ping.
user@server1> clear firewall all
Ahora muestre los contadores de firewall en Leaf 1 y Leaf 2.
user@leaf1> show firewall user@leaf1# run show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 0 0
La salida muestra que no se ven paquetes en la hoja 1. Esto indica que para este flujo, el servidor está hashing a la hoja 2.
Compruebe los contadores de firewall en Leaf 2:
user@leaf2> show firewall Filter: mirror-leaf-1 Counters: Name Bytes Packets from-s1 1020 10
El contador de firewall en Leaf 2 refleja correctamente el tráfico de prueba generado.
-
Confirme que el tráfico enviado entre el servidor 1 y el servidor 2 se refleja en la hoja 1 y/o la hoja 2 para su transmisión a la estación de monitoreo.
Una vez más, genere tráfico entre los servidores 1 y 2 (no se muestra por brevedad). Utilice la opción rápida del comando ping para generar un mayor volumen de paquetes y facilitar la detección.
Monitoree los contadores de tráfico de la interfaz en el borde Leaf 3 para verificar que el tráfico de prueba llegue a la estación de monitoreo.
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]La salida confirma que el tráfico se envía a la estación de monitoreo. La falta de paquetes de entrada se espera porque la estación de monitoreo no genera ninguna respuesta al tráfico GRE que recibe.
-
Utilice Wireshark o una aplicación de análisis equivalente para capturar y decodificar el tráfico reflejado.
Figura 7: Análisis
de tráfico reflejado
La captura muestra que el servidor 1 envía tráfico de ping al servidor 2. El tráfico de respuesta no se refleja porque hemos aplicado nuestro filtro en Leaf 1 y Leaf 2 solo en la dirección de entrada. Aplique una instancia de espejo de puerto similar y una configuración de filtro en Leaf 4 para reflejar el tráfico de retorno. Recuerde que en el caso de la columna vertebral delgada, el tráfico reflejado mostró encapsulación VXLAN. En este caso de hoja ERB, reflejamos el tráfico de capa 2 antes de que se encapsule en VXLAN. El filtro utilizado para reflejar el tráfico se aplica como filtro de entrada en la interfaz ae0.0 orientada al servidor. No hay encapsulación VXLAN en la entrada.
Esto es similar al caso de aplicar un filtro a la interfaz IRB de la VLAN. En el caso del filtrado IRB, el tráfico reflejado tampoco contiene encapsulación VXLAN. Los filtros IRB solo procesan el tráfico entre VLAN en la capa IP. Por lo tanto, para el caso del filtro IRB, solo se refleja el tráfico IP de capa 3.
La decodificación muestra que el túnel GRE está entre la hoja 2 y la estación de monitoreo a través de la capa subyacente. La trama Ethernet y el paquete IP enviados por el servidor 1 también se decodifican. Las direcciones IP asignadas a los servidores son visibles (10.1.100.x/24), al igual que los detalles del paquete IP/ICMP generado por el servidor 1.
Ha configurado correctamente la creación de reflejo de puertos en la topología.
Ejemplo: habilitar una instancia de analizador remoto en una interfaz ESI-LAG
Visión general
Un identificador de segmento Ethernet (ESI) es el número único de 10 bytes que identifica un segmento de Ethernet. El ESI se habilita en la interfaz conectada al servidor. Cuando varios enlaces forman un grupo de agregación de vínculos (LAG), el resultado es una interfaz ESI-LAG, también conocida como LAG de EVPN. En algunos casos, deberá habilitar la duplicación de puertos directamente para todo o parte del tráfico que entra o sale de la interfaz ESI-LAG.
Tanto las instancias del analizador de entrada como las de salida son compatibles con las interfaces ESI-LAG en dispositivos leaf en una estructura EVPN-VXLAN. Esto resulta útil en un centro de datos en el que el administrador debe enviar todo el tráfico que entra o sale de un puerto ESI-LAG determinado hacia o desde un host remoto. Utilice esta sección para habilitar una instancia de analizador en el nivel ESI-LAG de una estructura ERB EVPN-VXLAN.
Una instancia de analizador difiere de una instancia de creación de reflejo de puerto en que el analizador funciona en la entrada, en la salida o en ambas direcciones. Además, refleja todo el tráfico en la interfaz. Por ejemplo, si el servidor 1 tiene 10 VLAN que utilizan una interfaz troncal, el tráfico de las 10 VLAN se envía a la estación de supervisión. En el ejemplo anterior de creación de reflejo de puerto, se utiliza un filtro para permitir la duplicación selectiva del tráfico desde una VLAN o desde direcciones IP particulares en una VLAN.
Las instancias del analizador no usan filtros de firewall para la coincidencia granular. Todo el tráfico en la dirección especificada en la interfaz especificada se refleja.
Topología
En este ejemplo de configuración se utilizan los componentes de hardware y software que se muestran en Requisitos. Los dispositivos de la topología comienzan con sus configuraciones de línea base, tal como se proporciona en el Apéndice: Configuraciones completas de dispositivos.
En este ejemplo, se utiliza una interfaz ESI-LAG, también conocida como LAG EVPN, entre el servidor 1 y la hoja 1 y la hoja 2. Consulte Prácticas recomendadas de configuración del LAG EVPN para conocer las prácticas recomendadas.
Puede configurar la instancia del analizador en un conmutador ACX7100 que ejecute Junos OS Evolved 22.3R1 o posterior.
La figura 8 muestra la topología de este ejemplo.
ESI-LAG
La interfaz ae0.0 es la interfaz ESI-LAG conectada al servidor 1. Al servidor 1 se le asigna la dirección IP 10.1.101.10/24 y está asociado con VLAN 101. El objetivo es configurar una instancia de analizador para reenviar todo el tráfico enviado y recibido en la interfaz ae0.0 tanto en la hoja 1 como en la hoja 2. El tráfico reflejado se coloca en un túnel GRE y se envía a la estación de monitoreo. Como antes, debe asegurarse de que la subred de la estación de supervisión sea accesible en la base de EBGP.
Ambas espinas están operativas en esta topología. ECMP significa que la hoja 1 y la hoja 2 pueden enviar tráfico a través de cualquiera de los dispositivos de la columna vertebral. Para reducir el desorden en el dibujo, mostramos el tráfico y las rutas de espejo con el dispositivo Spine 1 como foco.
Antes de empezar
Si está comenzando desde la configuración de línea base que se muestra en el Apéndice: Configuraciones completas de dispositivos, siga estos pasos para modificar la topología antes de comenzar.
-
Modifique la configuración de Leaf 1 y Leaf 2 para admitir la conexión multihost del servidor 1. Comenzamos cambiando el nombre de la interfaz xe-0//0/0 existente para convertirla en la nueva interfaz ae0.0. Esto afecta a cualquier configuración de la interfaz xe-0/0/0 para ahorrar algo de tiempo.
user@leaf1# rename interfaces xe-0/0/0 to ae0 user@leaf1# set interfaces ae0 esi 00:02:02:02:02:02:02:02:00:04 user@leaf1# set interfaces ae0 esi all-active user@leaf1# set interfaces ae0 aggregated-ether-options lacp active user@leaf1# set interfaces ae0 aggregated-ether-options lacp system-id 00:00:02:02:00:04
Los detalles de configuración para la interfaz Ethernet agregada del servidor, a menudo denominada interfaz enlazada en Linux, están fuera del alcance de este NCE. Cabe destacar que, para el servidor, solo hay una configuración Ethernet agregada estándar. Las instrucciones relacionadas con ESI-LAG solo se aplican a los dispositivos leaf.
Nota:La configuración de línea base inicial habilita un dispositivo Ethernet agregado mediante la instrucción configuration
set chassis aggregated-devices ethernet device-count 1. Debe habilitar la compatibilidad del chasis para dispositivos agregados o no se creará la interfaz agregada. -
Después de aplicar y confirmar estos cambios tanto en los dispositivos leaf como en el servidor, confirme que la interfaz ae0 esté activa en ambas hojas. El resultado de ejemplo siguiente se ha acortado para mayor claridad.
user@leaf2> show interfaces ae0 Physical interface: ae0, Enabled, Physical link is Up Physical interface: ae0, Enabled, Physical link is Up [...] Current address: b8:c2:53:ba:8b:80, Hardware address: b8:c2:53:ba:8b:80 Ethernet segment value: 00:02:02:02:02:02:02:02:00:04, Mode: all-active Last flapped : 2022-09-07 14:57:53 UTC (01:06:43 ago) [...] Queue counters: Queued packets Transmitted packets Dropped packets 0 81129 81129 0 3 0 0 0 4 0 0 0 7 4135 4135 0 8 64 64 0 [...] Protocol eth-switch, MTU: 1514, Generation: 266, Route table: 7, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, EVPN multi-homed ESI Split Horizon Label: 0, Next-hop: 1665, vpls-status: up Local Bias Logical Interface Name: vtep.32769, Index: 554, VXLAN Endpoint Address: 10.1.255.11 Flags: Is-PrimaryCompruebe que el servidor 1 puede hacer ping al servidor 2 (no se muestra por brevedad).
Configuración
En este ejemplo, se muestra cómo habilitar la creación de reflejo de puertos remotos en el nivel ESI-LAG mediante una instancia de analizador remoto.
-
La interfaz ae0.0 es la interfaz ESI-LAG donde se conecta el servidor inquilino 1. Este ESI-LAG termina tanto en la hoja 1 como en la hoja 2. Configure la instancia del analizador en ambas hojas para la interfaz ae0.0. Tenga en cuenta que configura un analizador remoto para las direcciones de entrada y salida.
[edit forwarding-options analyzer my-analyzer1] user@leaf1# set input ingress interface ae0.0 user@leaf1# set input egress interface ae0.0 user@leaf1# set output ip-address 172.16.1.2
-
No es necesario configurar Border Leaf 3 para realizar la desencapsulación GRE, ya que el túnel GRE termina en la estación de monitoreo. Sin embargo, Leaf 3 necesita anunciar la accesibilidad de la subred de la estación de monitoreo en la capa subyacente de la estructura.
Configure la interfaz xe-0/0/33:1 que se conecta a la estación de monitoreo.
user@bl-leaf3# set interfaces xe-0/0/33:1 unit 0 family inet address 172.16.1.1/24
Modifique la política de exportación subyacente en la hoja 3 del borde para anunciar el prefijo de la estación de monitoreo. Nuestra topología utiliza una base de EBGP. Simplemente añadimos un nuevo término a la política de exportación subyacente existente.
[edit policy-options policy-statement send-direct] user@bl-leaf3# set term 2 from protocol direct user@bl-leaf3# set pterm 2 from route-filter 172.16.1.0/24 exact user@bl-leaf3# set term 2 then accept
-
Los cambios desde la línea base inicial se muestran en la hoja 1.
user@leaf1# show | compare base [edit interfaces xe-0/0/0] + gigether-options { + 802.3ad ae0; + } [edit interfaces xe-0/0/0] - unit 0 { - family ethernet-switching { - vlan { - members v101; - } - } - } [edit interfaces] + ae0 { + esi { + 00:02:02:02:02:02:02:02:00:04; + all-active; + } + aggregated-ether-options { + lacp { + active; + system-id 00:00:02:02:00:04; + } + } + unit 0 { + family ethernet-switching { + interface-mode access; + vlan { + members v101; + } + } + } + } [edit] + forwarding-options { + analyzer { + my-analyzer1 { + input { + ingress { + interface ae0.0; + } + egress { + interface ae0.0; + } + } + output { + ip-address 172.16.1.2; + } + } + } + }Ha configurado correctamente la duplicación de puertos remotos a través de un dispositivo leaf en una estructura ERB EVPN-VXLAN.
Verificación
-
Verifique la conectividad subyacente desde Leaf 1 y Leaf 2 hasta la estación de monitoreo.
En la hoja 1, muestre la ruta a 172.16.1.0/24.
user@leaf1> show route 172.16.1.0/24 inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[BGP/170] 4d 00:56:23, localpref 100 AS path: 65001 65013 I, validation-state: unverified > to 10.1.11.1 via et-0/0/48.0Nota:Estrictamente hablando, solo se requiere una conectividad simple entre la hoja y la estación de monitoreo. Hemos configurado una ruta estática en la estación de monitoreo para permitir que llegue a la capa subyacente de la estructura. Esto permite realizar pruebas de ping como herramienta de aislamiento de fallos.
Haga ping a la estación de monitoreo para confirmar la conectividad.
user@leaf1> ping 172.16.1.2 count 2 source 10.1.255.11 PING 172.16.1.2 (172.16.1.2): 56 data bytes 64 bytes from 172.16.1.2: icmp_seq=0 ttl=62 time=1.380 ms 64 bytes from 172.16.1.2: icmp_seq=1 ttl=62 time=7.614 ms --- 172.16.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.380/4.497/7.614/3.117 ms
La salida confirma la accesibilidad esperada de la capa subyacente desde la hoja 1 hasta la estación de monitoreo. Debemos obtener el ping de la dirección de circuito cerrado de la hoja porque nuestra política de exportación subyacente solo anuncia la accesibilidad de la dirección de circuito cerrado. El abastecimiento de la dirección de circuito cerrado no era necesario en el ejemplo de la espina gruesa porque la hoja de la columna vertebral y del borde se adjuntan directamente a través de una subred de vínculo de estructura compartida.
-
Confirme la instancia del analizador en la hoja 1 y la hoja 2.
En la hoja 1, compruebe que el estado del analizador remoto es
up.user@leaf1> show forwarding-options analyzer Analyzer name : my-analyzer1 Mirror rate : 1 Maximum packet length : 0 State : up Ingress monitored interfaces : ae0.0 Egress monitored interfaces : ae0.0 Destination IP : 172.16.1.2
El resultado confirma la definición correcta de la instancia del analizador. El estado de indica que la hoja tiene una ruta subyacente a la estación de
upmonitoreo. Recuerde que GRE es un protocolo sin estado. Es por eso que es una buena idea verificar la conectividad entre la hoja y la estación de monitoreo, como lo hicimos en el paso anterior. -
Confirme que el tráfico enviado entre el servidor 1 y el servidor 2 se refleja en la hoja 1 o la hoja 2 a la estación de monitoreo.
Una vez más, genere tráfico entre los servidores 1 y 2 (no se muestra por brevedad). Usamos la opción rápida para el comando ping para generar un mayor volumen de paquetes para facilitar la detección.
Monitoree los contadores de tráfico de la interfaz en el borde Leaf 3 para verificar que el tráfico de prueba llegue a la estación de monitoreo.
user@bl-leaf3> monitor interface xe-0/0/33:1 bl-leaf3 Seconds: 17 Time: 19:58:30 Delay: 1/0/1 Interface: xe-0/0/33:1, Enabled, Link is Up Encapsulation: Ethernet, Speed: 10000mbps Traffic statistics: Current delta Input bytes: 1019608 (0 bps) [0] Output bytes: 5699872 (4752824 bps) [3382190] Input packets: 10115 (0 pps) [0] Output packets: 34752 (3126 pps) [17801]La salida confirma que el tráfico llega a la estación de monitoreo. La falta de paquetes de entrada es esperada ya que la estación de monitoreo no genera ninguna respuesta al tráfico GRE que recibe.
-
Utilice Wireshark o una aplicación de análisis equivalente para capturar y decodificar el tráfico reflejado.
Figura 9: Análisis
de tráfico reflejado
La captura muestra que el servidor 1 envía tráfico de ping al servidor 2. Debido a que las instancias del analizador se aplican a ambas direcciones de la interfaz ae0.0, el tráfico de respuesta también se refleja. Dado que el analizador funciona en el nivel de interfaz, LACP, que es un protocolo de nivel de vínculo utilizado en la interfaz Ethernet agregada, también se refleja. Recuerde que en el caso de la columna vertebral delgada, el tráfico reflejado mostró encapsulación VXLAN. En este caso de hoja ERB, capturamos el tráfico de capa 2 antes de que se encapsule en VXLAN. En la entrada no hay encapsulación VXLAN.
Esto es similar al caso de aplicar un filtro a la interfaz IRB de una VLAN. En ese caso, el tráfico reflejado tampoco contiene encapsulación VXLAN. Los filtros basados en IRB solo capturan el tráfico entre VLAN en la capa IP. Por lo tanto, para el caso del filtro IRB, solo se refleja el tráfico IP de capa 3 encapsulado que no sea VXLAN.
La decodificación muestra que el túnel GRE está entre la hoja 2 (10.1.12.2) y la estación de monitoreo a través de la capa subyacente. La trama Ethernet y el paquete IP relacionado, tal como los envía el servidor 1, también se decodifican. Las direcciones IP asignadas a los servidores son visibles (10.1.100.x/24), al igual que los detalles del paquete IP/ICMP generado por el servidor 1. La respuesta del servidor 2 también se refleja porque la instancia del analizador se aplica bidireccionalmente en nuestro ejemplo.
Ha configurado correctamente la creación de reflejo de puertos en la topología.