El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los pasos para comprender y resolver problemas de reenvío de Capa 2 en ACI
El material de este documento se ha extraído de la Solución de problemas de Cisco Application Centric Infrastructure, segunda edición libro, específicamente el Reenvío dentro del fabric: reenvío de L2: dos terminales en el mismo BD: sin routing de unidifusión capítulo.
Esta sección explica un ejemplo de troubleshooting donde los extremos en el mismo dominio de bridge y la misma subred no pueden comunicarse entre sí. La siguiente figura ilustra la topología donde el BD no tiene ninguna subred y tiene el ruteo unicast inhabilitado.
Normalmente, cuando se solucionan problemas de flujos de tráfico con conectividad de terminales, se recomienda comenzar a identificar un par de terminales. Consulte la topología siguiente con los EP A y B. Estos tendrán respectivamente las direcciones IP 10.1.1.1/24 y 10.1.1.2/24. Las direcciones MAC serán 00:00:10:01:01:01 y 00:00:10:01:01:01:02, respectivamente.
En esta sección hay tres escenarios:
Los flujos de troubleshooting que se seguirán pueden resumirse mediante el siguiente esquema:
El primer nivel de solución de problemas consiste en validar desde la GUI que la MAC del terminal se aprendió correctamente. Esto se puede hacer desde la ficha operativa del EPG donde se encuentra el terminal.
'Ficha operativa de EPG > Terminales del cliente'
En esta situación, ambos extremos A y B se muestran en la GUI. La GUI muestra sus direcciones MAC, la interfaz en la que están conectados al fabric y la encapsulación, en este caso ambas se encuentran en la VLAN 2501 de encapsulación.
Se espera que la dirección IP no se aprenda del fabric de ACI, ya que el routing de unidifusión se ha deshabilitado en el nivel BD.
Consulte la columna de origen de aprendizaje en la captura de pantalla anterior. Si denota "detectado", el switch de hoja ACI recibió al menos un paquete del terminal.
Dado que en este caso los terminales se aprenden del fabric de ACI, pase al siguiente caso de solución de problemas para el tráfico de unidifusión de capa 2 conocido.
En el caso del reenvío de Capa 2 en el mismo BD, ACI solo aprenderá el MAC de origen y el reenvío basado en el MAC de destino. Las direcciones MAC se aprenden en el ámbito del BD.
Primero, verifique si se aprende el punto final:
leaf1# show endpoint mac 0000.1001.0101
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
4/Prod:VRF1 vlan-2501 0000.1001.0101 L eth1/3
El resultado anterior proporciona la siguiente información:
Suponga que se conoce el destino MAC (unidifusión conocida).
leaf1# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
7/Prod:VRF1 vxlan-16351141 0000.1001.0102 tunnel4
El resultado anterior proporciona la siguiente información:
A continuación, verifique el destino de la interfaz de túnel mediante el comando 'show interface tunnel <x>'
leaf1# show interface tunnel 4
Tunnel4 is up
MTU 9000 bytes, BW 0 Kbit
Transport protocol is in VRF "overlay-1"
Tunnel protocol/transport is ivxlan
Tunnel source 10.0.88.95/32 (lo0)
Tunnel destination 10.0.96.66
Last clearing of "show interface" counters never
Tx
0 packets output, 1 minute output rate 0 packets/sec
Rx
0 packets input, 1 minute input rate 0 packets/sec
Por lo tanto, el paquete será encapsulado en VXLAN con el origen TEP IP 10.0.88.95 (asignado a loopback0) y enviado hacia el destino TEP IP 10.0.96.66.
Confirme la IP de origen:
leaf1# show ip interface loopback 0 vrf overlay-1
IP Interface Status for VRF "overlay-1"
lo0, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: ptep
IP address: 10.0.88.95, IP subnet: 10.0.88.95/32
IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0
El TEP IP 10.0.96.66 de destino puede ser uno de los siguientes:
Grupos de protección VPC explícitos
La hoja de ingreso ahora encapsulará la trama en VXLAN con la IP de destino externa establecida en 10.0.96.66 que es la IP de destino del túnel enumerada en el comando 'show interface tunnel 4' anterior. Lo encapsulará en VXLAN con el VNID del dominio de bridge - vxlan-16351141 - como se muestra en el resultado del comando 'show endpoint mac 0000.1001.0102' anterior.
Según la ruta IS-IS en VRF overlay-1, determine dónde enviarla:
leaf1# show ip route 10.0.96.66 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.96.66/32, ubest/mbest: 4/0
*via 10.0.88.65, Eth1/49.10, [115/3], 2w5d, isis-isis_infra, isis-l1-int
*via 10.0.88.94, Eth1/50.128, [115/3], 2w5d, isis-isis_infra, isis-l1-int
Por lo tanto, existe un routing ECMP (múltiples rutas de igual coste) al destino mediante eth1/49 y 1/50, que son los enlaces ascendentes de fabric a los switches de columna.
La tabla de ruteo de superposición 1 de VRF en la columna muestra que la ruta del host 10.0.96.66 es alcanzable a través de leaf3 u leaf4. Esto se espera ya que 10.0.96.66 es el VIP de VPC de los switches de hoja 103 y 104:
spine1# show ip route 10.0.96.66 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.96.66/32, ubest/mbest: 2/0
*via 10.0.88.91, eth1/3.35, [115/2], 02w05d, isis-isis_infra, isis-l1-int
*via 10.0.88.90, eth1/4.39, [115/2], 02w05d, isis-isis_infra, isis-l1-int
spine1# show lldp neighbors | egrep "1\/3 |1\/4 "
leaf3 Eth1/3 120 BR Eth1/49
leaf4 Eth1/4 120 BR Eth1/49
En este caso, el TEP de destino es un par VPC por lo que el paquete llegará en la hoja 3 u hoja 4. Consulte los resultados del comando a continuación. Leaf4 debe mostrar un resultado similar. Dado que forman parte del mismo par VPC, todos los terminales están sincronizados entre los dos switches de hoja.
El aprendizaje del terminal para el tráfico de Capa 2 en la hoja de salida se basa en la dirección MAC de origen que se aprende en el BD correspondiente al VNID en el paquete recibido. Esto se puede verificar en la tabla de terminales.
La dirección MAC de origen se encuentra detrás del túnel 26 en VXLAN-16351141.
El túnel 26 va al TEP IP 10.0.88.95 que es leaf1:
leaf3# show endpoint mac 0000.1001.0101
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
136/Prod:VRF1 vxlan-16351141 0000.1001.0101 tunnel26
leaf3# show interface tunnel 26
Tunnel26 is up
MTU 9000 bytes, BW 0 Kbit
Transport protocol is in VRF "overlay-1"
Tunnel protocol/transport is ivxlan
Tunnel source 10.0.88.91/32 (lo0)
Tunnel destination 10.0.88.95
Last clearing of "show interface" counters never
Tx
0 packets output, 1 minute output rate 0 packets/sec
Rx
0 packets input, 1 minute input rate 0 packets/sec
leaf3# acidiag fnvread | egrep "10.0.88.95"
101 1 leaf1 FDO20160TPA 10.0.88.95/32 leaf active 0
El comando 'show endpoint' confirma que el MAC de destino se aprende detrás del canal de puerto 1 y utiliza la encapsulación VLAN-2501
leaf3# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
135/Prod:VRF1 vlan-2501 0000.1001.0102 LpV po1
Esto indica que la trama está dejando el fabric ACI en el canal de puerto 1 de la interfaz leaf3 con el ID de VLAN encapsulada 2501. Puede encontrar el VNID BD en la pestaña de funcionamiento del arrendatario en la GUI.
El repo COOP EP debe sincronizarse en todos los nodos de la columna vertebral. el repo de COOP EP se puede comprobar utilizando el VNID BD como clave e introduciendo la dirección MAC EP.
La dirección MAC de origen de este flujo se aprende de tunnel next-hop 10.0.88.95 que es la IP TEP de leaf1. Además, el resultado del comando muestra VNID 16351141 que corresponde al dominio de bridge correcto.
spine1# show coop internal info repo ep key 16351141 00:00:10:01:01:01
Repo Hdr Checksum : 24197
Repo Hdr record timestamp : 10 01 2019 10:16:50 278195866
Repo Hdr last pub timestamp : 10 01 2019 10:16:50 283699467
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:01
flags : 0x80
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 10:16:50 278195866
Tunnel nh : 10.0.88.95
MAC Tunnel : 10.0.88.95
IPv4 Tunnel : 10.0.88.95
IPv6 Tunnel : 10.0.88.95
ETEP Tunnel : 0.0.0.0
El MAC de destino de este flujo se aprende contra el VIP VPC 10.0.96.66 de la hoja 3 y la hoja 4. El VNID de BD EP 16351141 también se enumera, que corresponde al BD correcto.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Repo Hdr Checksum : 16897
Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334
Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:02
flags : 0x90
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 11:05:46 351360334
Tunnel nh : 10.0.96.66
MAC Tunnel : 10.0.96.66
IPv4 Tunnel : 10.0.96.66
IPv6 Tunnel : 10.0.96.66
ETEP Tunnel : 0.0.0.0
ELAM Assistant es una potente aplicación de ACI que puede simplificar la ejecución de capturas de ELAM en un fabric de ACI.
Los disparadores de ELAM Assistant se pueden iniciar simultáneamente en múltiples nodos de hoja. Como resultado, se pueden verificar paquetes específicos en paralelo en leaf1, leaf3 y leaf4.
La captura de ELAM configurada aparecerá como se muestra a continuación. Como se ha observado, el paquete se ve en la hoja 1 (nodo 101) y en la hoja 3 (nodo 103).
ELAM Assistant: parámetros
El informe de leaf1 (node-101) muestra lo siguiente:
ELAM Assistant — leaf1 (node-101) — Información de paquetes capturados
ELAM Assistant — leaf1 (node-101) — Información de reenvío de paquetes
En la hoja de salida 3 (nodo-103), se observa lo siguiente:
En la información del paquete capturado en leaf3, ingresa desde eth1/49. La dirección IP externa confirma lo siguiente:
ELAM Assistant — leaf3 (node-103) — Información de paquetes capturados
La información de reenvío de paquetes muestra que el tráfico se reenvía en el canal de puerto 1 y específicamente en Ethernet 1/12.
Se recomienda utilizar ELAM Assistant ya que simplifica la operación de ejecución de capturas de ELAM. Sin embargo, también es posible utilizar comandos CLI en switches ACI para generar un informe ELAM. A continuación se muestra un ejemplo de cómo se haría esto.
Utilice la secuencia de disparo mostrada para capturar el paquete en la hoja de ingreso. Consulte la sección "Herramientas" para obtener más información sobre las opciones de ELAM.
module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger init in-select ?
10 Outerl4-innerl4-ieth
13 Outer(l2|l3|l4)-inner(l2|l3|l4)-noieth
14 Outer(l2(vntag)|l3|l4)-inner(l2|l3|l4)-ieth
15 Outer(l2|l3|l4)-inner(l2|l3|l4)-ieth
6 Outerl2-outerl3-outerl4
7 Innerl2-innerl3-innerl4
8 Outerl2-innerl2-ieth
9 Outerl3-innerl3
module-1(DBG-elam)# trigger init in-select 6 out-select 1
module-1(DBG-elam-insel6)# reset
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2
module-1(DBG-elam-insel6)# start
Para ver si se recibió el paquete, verifique el estado de ELAM. Si hay un disparador, significa que se capturó un paquete que coincide con las condiciones.
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
Asic 0 Slice 1 Status Armed
El siguiente resultado muestra que el informe se muestra con el comando 'report'. El resultado es muy largo, por lo que sólo se pega aquí el principio. Pero tenga en cuenta que el informe completo se guarda para su posterior análisis en una ubicación del sistema de archivos hoja. El nombre de archivo también contiene las marcas de tiempo cuando se tomó el ELAM.
leaf1# ls -al /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt
-rw-rw-rw- 1 root root 699106 Sep 30 23:03 /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt
El 'informe' valida que el paquete ha sido recibido y la información es la esperada (MAC de origen y destino, IP de origen y destino, etc.)
module-1(DBG-elam-insel6)# ereport
Python available. Continue ELAM decode with LC Pkg
ELAM REPORT
===========================================================================================================
Trigger/Basic Information
===========================================================================================================
ELAM Report File : /tmp/logs/elam_2019-09-30-03m-23h-14s.txt
In-Select Trigger : Outerl2-outerl3-outerl4( 6 )
Out-Select Trigger : Pktrw-sideband-drpvec( 1 )
ELAM Captured Device : LEAF
Packet Direction : ingress
Triggered ASIC type : Sugarbowl
Triggered ASIC instance : 0
Triggered Slice : 0
Incoming Interface : 0x24( 0x24 )
( Slice Source ID(Ss) in "show plat int hal l2 port gpd" )
===========================================================================================================
Captured Packet
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes : l2uc ipv4 ip ipuc ipv4uc
Opcode : OPCODE_UC
-----------------------------------------------------------------------------------------------------------
Outer L2 Header
-----------------------------------------------------------------------------------------------------------
Destination MAC : 0000.1001.0102
Source MAC : 0000.1001.0101
802.1Q tag is valid : yes( 0x1 )
CoS : 0( 0x0 )
Access Encap VLAN : 2501( 0x9C5 )
-----------------------------------------------------------------------------------------------------------
Outer L3 Header
-----------------------------------------------------------------------------------------------------------
L3 Type : IPv4
IP Version : 4
DSCP : 0
IP Packet Length : 84 ( = IP header(28 bytes) + IP payload )
Don't Fragment Bit : not set
TTL : 255
IP Protocol Number : ICMP
IP CheckSum : 51097( 0xC799 )
Destination IP : 10.1.1.2
Source IP : 10.1.1.1
===========================================================================================================
Forwarding Lookup ( FPB )
===========================================================================================================
-----------------------------------------------------------------------------------------------------------
Destination MAC (Lookup Key)
-----------------------------------------------------------------------------------------------------------
Dst MAC Lookup was performed : yes
Dst MAC Lookup BD : 522( 0x20A )
( Hw BDID in "show plat int hal l2 bd pi" )
Dst MAC Address : 0000.1001.0102
-----------------------------------------------------------------------------------------------------------
Destination MAC (Lookup Result)
-----------------------------------------------------------------------------------------------------------
Dst MAC is Hit : yes
Dst MAC is Hit Index : 6443( 0x192B )
( phy_id in "show plat int hal objects ep l2 mac (MAC) extensions" )
or ( HIT IDX in "show plat int hal l3 nexthops" for L3OUT/L3 EP)
.....
El triaje se ejecuta desde una CLI APIC y se puede utilizar para seguir la ruta completa a través del fabric ACI. Especifique al menos la hoja de ingreso (nodo-101), la IP de origen y la IP de destino. En este caso específico es un flujo puenteado (Capa 2), por lo que se debe utilizar la opción fTriage bridge.
Tenga en cuenta que fTriage genera un archivo de registro en el directorio actual. Este archivo de registro contendrá todos los registros e informes ELAM recopilados. Esto permite que el paquete sea capturado en cada salto. La versión abreviada del resultado es la siguiente:
apic1# ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "12181", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-18-53-24-125.txt
2019-10-01 18:53:24,129 INFO /controller/bin/ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2
2019-10-01 18:53:49,280 INFO ftriage: main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 18:54:10,204 INFO ftriage: main:839 L2 frame Seen on leaf1 Ingress: Eth1/3 Egress: Eth1/49 Vnid: 15302583
2019-10-01 18:54:10,422 INFO ftriage: main:242 ingress encap string vlan-2501
2019-10-01 18:54:10,427 INFO ftriage: main:271 Building ingress BD(s), Ctx
2019-10-01 18:54:12,288 INFO ftriage: main:294 Ingress BD(s) Prod:BD1
2019-10-01 18:54:12,288 INFO ftriage: main:301 Ingress Ctx: Prod:VRF1
2019-10-01 18:54:12,397 INFO ftriage: pktrec:490 leaf1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:54:30,079 INFO ftriage: main:933 SMAC 00:00:10:01:01:01 DMAC 00:00:10:01:01:02
2019-10-01 18:54:30,080 INFO ftriage: unicast:973 leaf1: <- is ingress node
2019-10-01 18:54:30,320 INFO ftriage: unicast:1215 leaf1: Dst EP is remote
2019-10-01 18:54:31,155 INFO ftriage: misc:659 leaf1: L2 frame getting bridged in SUG
2019-10-01 18:54:31,380 INFO ftriage: misc:657 leaf1: Dst MAC is present in SUG L2 tbl
2019-10-01 18:54:31,826 INFO ftriage: misc:657 leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']
2019-10-01 18:56:16,249 INFO ftriage: main:622 Found peer-node spine1 and IF: Eth1/1 in candidate list
2019-10-01 18:56:21,346 INFO ftriage: node:643 spine1: Extracted Internal-port GPD Info for lc: 1
2019-10-01 18:56:21,348 INFO ftriage: fcls:4414 spine1: LC trigger ELAM with IFS: Eth1/1 Asic :0 Slice: 0 Srcid: 32
2019-10-01 18:56:54,424 INFO ftriage: main:839 L2 frame Seen on spine1 Ingress: Eth1/1 Egress: LC-1/0 FC-24/0 Port-0 Vnid: 15302583
2019-10-01 18:56:54,424 INFO ftriage: pktrec:490 spine1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:57:15,093 INFO ftriage: fib:332 spine1: Transit in spine
2019-10-01 18:57:21,394 INFO ftriage: unicast:1252 spine1: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66
2019-10-01 18:57:21,508 INFO ftriage: unicast:1417 spine1: EP is known in COOP (DIPo = 10.0.96.66)
2019-10-01 18:57:25,537 INFO ftriage: unicast:1458 spine1: Infra route 10.0.96.66 present in RIB
2019-10-01 18:57:25,537 INFO ftriage: node:1331 spine1: Mapped LC interface: LC-1/0 FC-24/0 Port-0 to FC interface: FC-24/0 LC-1/0 Port-0
2019-10-01 18:57:30,616 INFO ftriage: node:460 spine1: Extracted GPD Info for fc: 24
2019-10-01 18:57:30,617 INFO ftriage: fcls:5748 spine1: FC trigger ELAM with IFS: FC-24/0 LC-1/0 Port-0 Asic :0 Slice: 2 Srcid: 0
2019-10-01 18:57:49,611 INFO ftriage: unicast:1774 L2 frame Seen on FC of node: spine1 with Ingress: FC-24/0 LC-1/0 Port-0 Egress: FC-24/0 LC-1/0 Port-0 Vnid: 15302583
2019-10-01 18:57:49,611 INFO ftriage: pktrec:487 spine1: Collecting transient losses snapshot for FC module: 24
2019-10-01 18:57:53,110 INFO ftriage: node:1339 spine1: Mapped FC interface: FC-24/0 LC-1/0 Port-0 to LC interface: LC-1/0 FC-24/0 Port-0
2019-10-01 18:57:53,111 INFO ftriage: unicast:1474 spine1: Capturing Spine Transit pkt-type L2 frame on egress LC on Node: spine1 IFS: LC-1/0 FC-24/0 Port-0
2019-10-01 18:57:53,530 INFO ftriage: fcls:4414 spine1: LC trigger ELAM with IFS: LC-1/0 FC-24/0 Port-0 Asic :0 Slice: 0 Srcid: 64
2019-10-01 18:58:26,497 INFO ftriage: unicast:1510 spine1: L2 frame Spine egress Transit pkt Seen on spine1 Ingress: LC-1/0 FC-24/0 Port-0 Egress: Eth1/3 Vnid: 15302583
2019-10-01 18:58:26,498 INFO ftriage: pktrec:490 spine1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:59:28,634 INFO ftriage: main:622 Found peer-node leaf3 and IF: Eth1/49 in candidate list
2019-10-01 18:59:39,235 INFO ftriage: main:839 L2 frame Seen on leaf3 Ingress: Eth1/49 Egress: Eth1/12 (Po1) Vnid: 11364
2019-10-01 18:59:39,350 INFO ftriage: pktrec:490 leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:59:54,373 INFO ftriage: main:522 Computed egress encap string vlan-2501
2019-10-01 18:59:54,379 INFO ftriage: main:313 Building egress BD(s), Ctx
2019-10-01 18:59:57,152 INFO ftriage: main:331 Egress Ctx Prod:VRF1
2019-10-01 18:59:57,153 INFO ftriage: main:332 Egress BD(s): Prod:BD1
2019-10-01 18:59:59,230 INFO ftriage: unicast:1252 leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66
2019-10-01 18:59:59,231 INFO ftriage: unicast:1257 leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip
2019-10-01 18:59:59,231 INFO ftriage: unicast:1784 leaf3: <- is egress node
2019-10-01 18:59:59,377 INFO ftriage: unicast:1833 leaf3: Dst EP is local
2019-10-01 18:59:59,378 INFO ftriage: misc:657 leaf3: EP if(Po1) same as egr if(Po1)
2019-10-01 18:59:59,378 INFO ftriage: misc:659 leaf3: L2 frame getting bridged in SUG
2019-10-01 18:59:59,613 INFO ftriage: misc:657 leaf3: Dst MAC is present in SUG L2 tbl
2019-10-01 19:00:06,122 INFO ftriage: main:961 Packet is Exiting fabric with peer-device: n3k-3 and peer-port: Ethernet1/16
En este ejemplo, el MAC de destino es desconocido. La búsqueda MAC de destino en la hoja de ingreso no muestra resultados.
leaf1# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
Dado que BD está configurado como 'Inundación' para unidifusión desconocida L2, esto es lo que sucederá a un nivel alto:
Esta sección resaltará lo que se puede comprobar.
La GUI identifica el grupo multicast 225.1.5.48 utilizado por el BD para el tráfico multidestino.
BD GIPo
Con el asistente de ELAM, se comprueba el informe de ELAM de la hoja de entrada. Esto muestra que la trama se inundó en el BD y está egresando en todos los enlaces ascendentes de fabric (aquí eth1/49, 1/50, 1/51 y 1/52).
ELAM Assistant - hoja de ingreso - Información de reenvío de paquetes
Para encontrar el valor FTAG seleccionado por la hoja de ingreso, vaya al informe sin procesar del Asistente de ELAM.
sug_lu2ba_sb_info.mc_info.mc_info_nopad.ftag: 0xC
Al convertir el valor hexadecimal de 0xC a decimal, esto da como resultado FTAG 12.
IS-IS calcula la topología FTAG. Se crea una topología de árbol para cada valor FTAG, con una lista de interfaz raíz y de salida que permite una topología de distribución de carga óptima.
Muestre la topología FTAG local mediante el siguiente comando. En el siguiente ejemplo, estamos usando la topología FTAG ID 12 en spine1.
spine1# show isis internal mcast routes ftag
IS-IS process: isis_infra
VRF : default
FTAG Routes
====================================
FTAG ID: 12 [Enabled] Cost:( 2/ 11/ 0)
----------------------------------
Root port: Ethernet1/4.39
OIF List:
Ethernet1/11.11
Ethernet1/12.12
Dibujar la topología FTAG completa en un fabric ACI de gran tamaño puede resultar una tarea larga y compleja. El script Python 'aci-ftag-viewer' (https://github.com/agccie/aci-ftag-viewer) se puede copiar en un APIC. Genera la topología FTAG completa del fabric en una sola pasada.
El siguiente resultado muestra el árbol FTAG 12 en Pod1 de un entramado de varios dispositivos e incluye la topología FTAG en los dispositivos IPN.
Esto muestra que si el tráfico ingresa al fabric ACI desde leaf101, atravesará las siguientes trayectorias según se indica en la salida del script a continuación.
admin@apic1:tmp> python aci_ftag_viewer.py --ftag 12 --pod 1
################################################################################
# Pod 1 FTAG 12
# Root spine-204
# active nodes: 8, inactive nodes: 1
################################################################################
spine-204
+- 1/1 -------- 1/52 leaf-101
+- 1/2 -------- 1/52 leaf-102
+- 1/3 -------- 1/52 leaf-103
+- 1/4 -------- 1/52 leaf-104
+- 1/49 -------- 1/4 spine-201
| +- 1/11 ...... (EXT) Eth2/13 n7706-01-Multipod-A1
| +- 1/12 ...... (EXT) Eth2/9 n7706-01-Multipod-A2
|
+- 1/50 -------- 1/4 spine-202
| +- 1/11 ...... (EXT) Eth2/14 n7706-01-Multipod-A1
| +- 1/12 ...... (EXT) Eth2/10 n7706-01-Multipod-A2
|
+- 1/51 -------- 2/4 spine-203
+- 2/11 ...... (EXT) Eth2/15 n7706-01-Multipod-A1
+- 2/12 ...... (EXT) Eth2/11 n7706-01-Multipod-A2
+- 1/11 ...... (EXT) Eth2/16 n7706-01-Multipod-A1
+- 1/12 ...... (EXT) Eth2/12 n7706-01-Multipod-A2
En este caso, el tráfico inundado llega a todas las hojas del fabric de ACI. Por lo tanto, alcanzará tanto la hoja 3 como la hoja 4 que son el par VPC. Ambos nodos de hoja tienen un VPC al destino. Para evitar los paquetes duplicados, el par VPC elige solamente una hoja para reenviar el tráfico inundado al destino. La hoja seleccionada se denomina hoja VPC DF (hoja de reenviador designada VPC).
Esto se puede verificar en ELAM mediante el siguiente disparador en ambos nodos de hoja.
module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 14 out-select 1
module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2
module-1(DBG-elam-insel14)# start
salida de leaf3:
module-1(DBG-elam-insel14)# ereport | egrep vpc.*df
sug_lub_latch_results_vec.lub4_1.vpc_df: 0x1
salida de hoja4:
module-1(DBG-elam-insel14)# ereport | egrep vpc.*df
sug_lub_latch_results_vec.lub4_1.vpc_df: 0x0
En el resultado anterior, leaf3 tiene el valor '0x1' configurado para el campo 'vpc_df', mientras que leaf4 tiene '0x0' configurado para el campo 'vpc_df'. Por lo tanto, el reenviador designado será leaf3. leaf3 reenviará el paquete inundado en su link VPC al EP de destino.
La situación actual enumerada es la del tráfico unicast desconocido de Capa 2 con el BD en modo proxy de hardware. En este escenario, dado que la hoja de ingreso no conoce la dirección MAC de destino, reenviará el paquete a la dirección MAC de proxy de difusión por proximidad de la columna. La columna realizará una búsqueda COOP para la dirección MAC de destino.
Si la búsqueda se realiza correctamente, como se muestra a continuación, la columna reescribirá la IP de destino externa en el destino del túnel (aquí 10.0.96.66) y la enviará al par VPC hoja3-hoja4.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Repo Hdr Checksum : 16897
Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334
Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:02
flags : 0x90
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 11:05:46 351360334
Tunnel nh : 10.0.96.66
MAC Tunnel : 10.0.96.66
IPv4 Tunnel : 10.0.96.66
IPv6 Tunnel : 10.0.96.66
ETEP Tunnel : 0.0.0.0
Si la búsqueda falla (el terminal es desconocido en el fabric de ACI), la columna descartará la unidifusión desconocida.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Key not found in repo
El siguiente diagrama resume el posible comportamiento de reenvío para el tráfico de capa 2 en el fabric de ACI.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
08-Aug-2022 |
Versión inicial |