Resolución de Problemas de Reenvío Intra-Fabric ACI - Reenvío L3: Dos terminales en diferentes BD

Introducción

Este documento describe los pasos para comprender y resolver problemas de un escenario de reenvío ACI L3.

Antecedentes

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 capa 3: dos terminales en BD diferentes capítulo.

Reenvío L3: dos terminales en BD diferentes

En este capítulo se explica un ejemplo de solución de problemas en el que los terminales de diferentes dominios puente no pueden comunicarse entre sí. Este sería un flujo dirigido por el fabric ACI. La figura 1 ilustra la topología.

Terminales en diferentes dominios de bridge

Flujo de trabajo de resolución de problemas

A continuación se indican los pasos de solución de problemas y los comandos de verificación habituales:

Primeras comprobaciones — validar programación

• El gateway ubicuo de BD debe enviarse a los nodos de hoja.
• La ruta a la subred BD de destino debe enviarse a los nodos de hoja.
• ARP para el gateway predeterminado de los hosts debe resolverse.

Segundas comprobaciones: validar el aprendizaje y las entradas de tabla mediante CLI en los nodos de hoja

• Verifique que la hoja de origen y los nodos de hoja de destino aprendan el punto final y si aprenden el punto final de destino:
  • Tabla de terminales: 'show endpoint'.
  • TEP destination — 'show interface tunnel <x>'.
  • Localizando el destino TEP en el comando 'show ip route <dirección TEP> vrf overlay-1'.
• Comprobar nodos de columna aprende el punto final:
  • 'show coop internal info'.

Terceras comprobaciones: tomar un paquete y analizar las decisiones de reenvío

• Con ELAM (ELAM Assistant o CLI) para validar la trama está ahí.
• O con fTriage para rastrear el flujo.

Flujo de trabajo de solución de problemas para terminales conocidos

Compruebe el gateway ubicuo del BD

En este ejemplo, se utilizarán los siguientes extremos de origen y destino:

• EP A 10.1.1.1 bajo hoja1.
• EP B 10.1.2.1 bajo par VPC hoja3 y hoja4.

Deben verse los siguientes gateways generalizados:

• 10.1.1.254/24 para la gateway BD1 en leaf1.
• 10.1.2.254/24 para la gateway BD2 en leaf3 y leaf4.

Esto se puede comprobar mediante: 'show ip interface vrf <vrf name>' en los nodos de hoja.

hoja1:

leaf1# show ip interface vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan7, Interface status: protocol-up/link-up/admin-up, iod: 106, mode: pervasive
 IP address: 10.1.1.254, IP subnet: 10.1.1.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

hoja 3 y 4:

leaf3# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan1, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

leaf4# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan132, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

Tenga en cuenta que leaf3 y leaf4 tienen la misma dirección de gateway ubicua, pero es probable que se observe una encapsulación VLAN diferente para la SVI.

• leaf3 utiliza VLAN 1.
• leaf4 utiliza VLAN 132.

Esto se espera ya que VLAN 1 o VLAN 132 es VLAN local en la hoja.

Si la dirección IP del gateway ubicuo no se envía a la hoja, verifique en la GUI de APIC que no haya fallas que impidan que se implemente la VLAN.

Comprobando tabla de enrutamiento en la hoja

Leaf1 no tiene ningún punto final en la subred 10.1.2.0/24, sin embargo debe tener la ruta a esa subred para alcanzarla:

leaf1# show ip route 10.1.2.0/24 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:22:37, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Observe que la ruta marcada con 'ubicua' y 'directa' tiene el salto siguiente de 10.0.8.65. Esta es la dirección de loopback anycast-v4 que existe en todas las columnas.

leaf1# show isis  dteps  vrf overlay-1 | egrep 10.0.8.65
10.0.8.65          SPINE   N/A             PHYSICAL,PROXY-ACAST-V4

De manera similar, leaf3 y leaf4 deben tener una ruta para 10.1.1.0/24.

leaf3# show ip route 10.1.1.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:30:25, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Si faltan estas rutas, es probable que se deba a que no hay un contrato entre un EPG en BD1 y un EPG en BD2. Si no hay un punto final local en BD1 bajo una hoja, el gateway ubicuo en BD1 no se empuja a la hoja. Si hay un terminal local en un EPG que tiene un contrato con otro EPG en BD1, la subred BD1 se aprende en la hoja.

Resolución ARP para la IP de gateway predeterminada

Dado que la hoja donde reside un punto final local debe tener un gateway ubicuo, las solicitudes ARP para el gateway ubicuo siempre deben ser resueltas por la hoja local. Esto se puede verificar en la hoja local mediante el siguiente comando:

leaf1# show ip arp internal event-history event  | egrep 10.1.1.1
   [116] TID 26571:arp_handle_arp_request:6135: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_inteface = Ethernet1/3; flood = 0; Info = Sent ARP response.
    [116] TID 26571:arp_process_receive_packet_msg:8384: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_interface = Ethernet1/3;Info = Received arp request

Aprendizaje de terminales MAC e IP de origen de hoja de entrada

En el caso del reenvío de capa 3, ACI realizará el aprendizaje de IP de origen de capa 3 y la búsqueda de IP de destino. Las direcciones IP aprendidas se asignan al VRF.

Esto se puede verificar en la GUI en la pestaña 'operacional' de un EPG. Tenga en cuenta que aquí se aprenden tanto la dirección IP como la dirección MAC.

Terminales operativos de EPG

Terminales operativos de EPG: detalles

Verifique que el punto final local se aprende en la hoja local. Aquí verifique en leaf1 que se aprende la IP 10.1.1.1:

leaf1# show endpoint ip 10.1.1.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
46                                        vlan-2501    0000.1001.0101 L                      eth1/3
Prod:VRF1                                 vlan-2501          10.1.1.1 L                      eth1/3

Como se muestra anteriormente, el contenido del terminal es:

• BD (la VLAN interna para BD es 46) con encapsulación VLAN del EPG (vlan-2501) y la dirección MAC aprendida en eth1/3
• VRF (Prod:VRF1) con IP 10.1.1.1

Esto se puede entender como equivalente a una entrada ARP en una red tradicional. ACI no almacena información ARP en una tabla ARP para terminales. Los extremos sólo están visibles en la tabla de extremos.

La tabla ARP en una hoja sólo se utiliza para saltos siguientes L3Out.

leaf1# show ip arp vrf Prod:VRF1    
Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       D - Static Adjacencies attached to down interface    IP ARP Table for context Prod:VRF1
Total number of entries: 0
Address         Age       MAC Address     Interface    
< NO ENTRY >

Búsqueda IP de destino de hoja de entrada: punto final remoto conocido

Suponiendo que se conoce la IP de destino (unidifusión conocida), a continuación se muestra el resultado de 'show endpoint' para la IP de destino 10.1.2.1. Esto es un aprendizaje remoto ya que no reside en leaf1, apuntando específicamente a la interfaz de túnel donde se aprende localmente (túnel 4).

Los terminales remotos sólo contienen la IP o la MAC, nunca ambos en la misma entrada. La dirección MAC e IP del mismo terminal sólo se producen cuando el terminal se detecta localmente.

leaf1# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.2.1 p                     tunnel4

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

El TEP de destino es el TEP de difusión por proximidad del par VPC hoja3 y 4 y se aprende a través de enlaces ascendentes a la columna.

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], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.128.64, eth1/51.8, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.64, eth1/52.126, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.94, eth1/50.128, [115/3], 02w06d, isis-isis_infra, isis-l1-int

Se puede recopilar información adicional del terminal para IP 10.1.2.1 mediante el comando 'show system internal epm endpoint ip <ip>'.

leaf1# show system internal epm endpoint ip 10.1.2.1
MAC : 0000.0000.0000 ::: Num IPs : 1
IP# 0 : 10.1.2.1 ::: IP# 0 flags :  ::: l3-sw-hit: No
Vlan id : 0 ::: Vlan vnid : 0 ::: VRF name : Prod:VRF1
BD vnid : 0 ::: VRF vnid : 2097154
Phy If : 0 ::: Tunnel If : 0x18010004
Interface : Tunnel4
Flags : 0x80004420 ::: sclass : 32771 ::: Ref count : 3
EP Create Timestamp : 10/01/2019 13:53:16.228319
EP Update Timestamp : 10/01/2019 14:04:40.757229
EP Flags : peer-aged|IP|sclass|timer|
::::

​En esa comprobación de salida:

• VRF VNID se rellena: se trata del VNID utilizado para encapsular la trama en VXLAN en el fabric.
• La dirección MAC es 0000.0000.0000, ya que la dirección MAC nunca se rellena en una entrada IP remota.
• BD VNID es desconocido ya que para las tramas ruteadas, la hoja de ingreso actúa como el router y realiza una reescritura MAC. Esto significa que la hoja remota no tendrá visibilidad en el BD del destino, solamente el VRF.

La trama se encapsulará ahora en una trama VXLAN que irá al TEP 10.0.96.66 remoto con un ID de VXLAN de 2097154 que es el VNID del VRF. Se ruteará en la tabla de ruteo superpuesta-1 (ruta IS-IS) y alcanzará el TEP de destino. Aquí alcanzará ya sea la hoja 3 o la hoja 4, ya que 10.0.96.66 es la dirección TEP de difusión por proximidad del par VPC hoja 3 y hoja 4.

Aprendizaje de IP de origen en hoja de salida

Las salidas aquí son tomadas de leaf3 pero serían similares en leaf4. Cuando los paquetes alcanzan leaf3 (hoja de destino y propietario del TEP), leaf aprenderá la IP de origen del paquete en el VRF.

leaf3# show endpoint ip 10.1.1.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.1.1 p                    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

El destino TEP 10.0.88.95 es la dirección TEP de leaf1 y se aprende a través de todos los enlaces ascendentes a la columna.

Búsqueda de IP de destino en hoja de salida

El último paso es que la hoja de egreso busque la IP de destino. Observe la tabla de terminales para 10.1.2.1.

Esto proporciona la siguiente información:

• La hoja de egreso conoce el destino 10.1.2.1 (similar a una ruta de host /32 en la tabla de ruteo) y la ruta se aprende en el VRF correcto.
• La hoja de salida conoce el MAC 0000.1001.0201 (información de punto final).
• La hoja de salida sabe que el tráfico destinado a 10.1.2.1 debe encapsularse en vlan-2502 y enviarse en el canal de puerto 1 (po1).

leaf3# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
2                                         vlan-2502    0000.1001.0201 LpV                       po1
Prod:VRF1                                 vlan-2502          10.1.2.1 LpV                       po1

fTriage para seguir la ruta de datos

Utilice fTriage en el APIC para seguir el flujo de la ruta de datos. Recuerde, fTriage depende de ELAM, por lo que necesita un flujo de datos real. Esto permite la confirmación de la ruta de datos completa, con la confirmación de que el paquete sale del fabric en el puerto 1/16 de la hoja 3.

apic1# ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "6888", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-21-17-54-175.txt
2019-10-01 21:17:54,179 INFO     /controller/bin/ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
2019-10-01 21:18:18,149 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 21:18:39,194 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf1 Ingress: Eth1/3 Egress: Eth1/51 Vnid: 2097154
2019-10-01 21:18:39,413 INFO     ftriage:     main:242  ingress encap string vlan-2501
2019-10-01 21:18:39,419 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-01 21:18:41,240 INFO     ftriage:     main:294  Ingress BD(s) Prod:BD1
2019-10-01 21:18:41,240 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-01 21:18:41,349 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf1: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:19:05,747 INFO     ftriage:     main:933  SIP 10.1.1.1 DIP 10.1.2.1
2019-10-01 21:19:05,749 INFO     ftriage:  unicast:973  bdsol-aci32-leaf1: <- is ingress node
2019-10-01 21:19:08,459 INFO     ftriage:  unicast:1215 bdsol-aci32-leaf1: Dst EP is remote
2019-10-01 21:19:09,984 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-01 21:19:09,984 INFO     ftriage:     misc:659  bdsol-aci32-leaf1: L3 packet getting routed/bounced in SUG
2019-10-01 21:19:10,248 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: Dst IP is present in SUG L3 tbl
2019-10-01 21:19:10,689 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']
2019-10-01 21:20:56,148 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-spine3 and IF: Eth2/1 in candidate list
2019-10-01 21:21:01,245 INFO     ftriage:     node:643  bdsol-aci32-spine3: Extracted Internal-port GPD Info for lc: 2
2019-10-01 21:21:01,245 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: Eth2/1 Asic :0 Slice: 0 Srcid: 32
2019-10-01 21:21:33,894 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-spine3 Ingress: Eth2/1 Egress: LC-2/0 FC-22/0 Port-1 Vnid: 2097154
2019-10-01 21:21:33,895 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:21:54,487 INFO     ftriage:      fib:332  bdsol-aci32-spine3: Transit in spine
2019-10-01 21:22:01,568 INFO     ftriage:  unicast:1252 bdsol-aci32-spine3: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:22:01,682 INFO     ftriage:  unicast:1417 bdsol-aci32-spine3: EP is known in COOP (DIPo = 10.0.96.66)
2019-10-01 21:22:05,713 INFO     ftriage:  unicast:1458 bdsol-aci32-spine3: Infra route 10.0.96.66 present in RIB
2019-10-01 21:22:05,713 INFO     ftriage:     node:1331 bdsol-aci32-spine3: Mapped LC interface: LC-2/0 FC-22/0 Port-1 to FC interface: FC-22/0 LC-2/0 Port-1
2019-10-01 21:22:10,799 INFO     ftriage:     node:460  bdsol-aci32-spine3: Extracted GPD Info for fc: 22
2019-10-01 21:22:10,799 INFO     ftriage:     fcls:5748 bdsol-aci32-spine3: FC trigger ELAM with IFS: FC-22/0 LC-2/0 Port-1 Asic :0 Slice: 2 Srcid: 24
2019-10-01 21:22:29,322 INFO     ftriage:  unicast:1774 L3 packet Seen on FC of node: bdsol-aci32-spine3  with Ingress: FC-22/0 LC-2/0 Port-1  Egress: FC-22/0 LC-2/0 Port-1 Vnid: 2097154
2019-10-01 21:22:29,322 INFO     ftriage:   pktrec:487  bdsol-aci32-spine3: Collecting transient losses snapshot for FC module: 22
2019-10-01 21:22:31,571 INFO     ftriage:     node:1339 bdsol-aci32-spine3: Mapped FC interface: FC-22/0 LC-2/0 Port-1 to LC interface: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,572 INFO     ftriage:  unicast:1474 bdsol-aci32-spine3: Capturing Spine  Transit pkt-type L3 packet on egress LC on Node: bdsol-aci32-spine3 IFS: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,991 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: LC-2/0 FC-22/0 Port-1 Asic :0 Slice: 1 Srcid: 0
2019-10-01 21:22:48,952 INFO     ftriage:  unicast:1510 bdsol-aci32-spine3: L3 packet Spine egress  Transit pkt Seen on bdsol-aci32-spine3 Ingress: LC-2/0 FC-22/0 Port-1 Egress: Eth2/3 Vnid: 2097154
2019-10-01 21:22:48,952 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:23:50,748 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-leaf3 and IF: Eth1/51 in candidate list
2019-10-01 21:24:05,313 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/51 Egress: Eth1/12 (Po1) Vnid: 11365
2019-10-01 21:24:05,427 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:24:24,369 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4326 scope:34 filter:65534
2019-10-01 21:24:25,698 INFO     ftriage:     main:522  Computed egress encap string vlan-2502
2019-10-01 21:24:25,704 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-01 21:24:27,510 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-01 21:24:27,510 INFO     ftriage:     main:332  Egress BD(s): Prod:BD2
2019-10-01 21:24:30,536 INFO     ftriage:  unicast:1252 bdsol-aci32-leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1257 bdsol-aci32-leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1784 bdsol-aci32-leaf3: <- is egress node
2019-10-01 21:24:30,684 INFO     ftriage:  unicast:1833 bdsol-aci32-leaf3: Dst EP is local
2019-10-01 21:24:30,685 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-01 21:24:30,943 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-01 21:24:31,242 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11365 in SUG same as EP segid:11365
2019-10-01 21:24:37,631 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/12

Captura de paquetes en hoja de salida mediante la aplicación ELAM Assistant

A continuación se muestra el paquete capturado con la aplicación ELAM Assistant en leaf3 proveniente de la columna. Esto muestra que:

• El VNID de la información de capa 4 externa (VNID es 2097154).
• Origen del encabezado L3 externo TEP y destino TEP.

ELAM Assistant: hoja de salida de flujo L3 (parte 1)

Asistente de ELAM: hoja de salida de flujo L3 (parte 2)

La sección Información de Reenvío de Paquetes prueba que se publicó en el canal de puerto 1

ELAM Assistant — Hoja de egreso L3 — Información de reenvío de paquetes

Flujo de trabajo de solución de problemas para terminales desconocidos

Esta sección muestra qué difiere cuando la hoja de ingreso no conoce la IP de destino.

Búsqueda IP de destino de hoja de ingreso

El primer paso es verificar si hay un aprendizaje de terminal para la IP de destino.

leaf1# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+------------+   
<NO ENTRY>

No hay nada en la tabla de extremos para el destino, así que el siguiente paso es verificar la tabla de ruteo que busca la ruta de coincidencia de prefijo más larga al destino:

leaf1# show ip route 10.1.2.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 01:40:18, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Si cae en la subred /24 BD 10.1.2.0/24 significa que la hoja encapsulará la trama en VXLAN con destino TEP 10.0.8.65 (anycast-v4 en la columna). La trama utilizará una ID de VXLAN que es VRF VNID.

Búsqueda COOP en columna: se conoce la IP de destino

El paquete alcanzará una de las columnas que realiza la búsqueda COOP en la base de datos IP. El origen debe verificarse y la IP de destino debe aprenderse correctamente de la base de datos COOP.

Para buscar una IP en la base de datos COOP, la clave es VRF VNID (2097154 en este ejemplo)

De la salida siguiente, hay confirmación de que la base de datos COOP tiene la entrada para la IP de origen de TEP 10.0.88.95 (leaf1) correctamente.

spine1# show coop internal info ip-db key 2097154 10.1.1.1
IP address : 10.1.1.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15302583
EP mac :  00:00:10:01:01:01
Publisher Id : 10.0.88.95
Record timestamp : 10 01 2019 14:16:50 522482647
Publish timestamp : 10 01 2019 14:16:50 532239332
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.88.95
       Tunnel ref count : 1

El siguiente resultado muestra que la base de datos COOP tiene la entrada para la IP de destino de TEP 10.0.96.66 (TEP Anycast del par de hoja3 y 4 VPC) correctamente

spine1# show coop internal info ip-db key 2097154 10.1.2.1
IP address : 10.1.2.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15957974
EP mac :  00:00:10:01:02:01
Publisher Id : 10.0.88.90
Record timestamp : 10 01 2019 14:52:52 558812544
Publish timestamp : 10 01 2019 14:52:52 559479076
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.96.66
       Tunnel ref count : 1

En este escenario, COOP conoce la IP de destino, por lo que reescribirá la IP de destino del encabezado IP externo en el paquete VXLAN para que sea 10.0.96.66 y luego enviará a leaf3 u leaf4 (dependiendo del hashing ECMP). Tenga en cuenta que la IP de origen de la trama VXLAN no se cambia, por lo que sigue siendo el PTEP hoja1.

Búsqueda COOP en columna: IP de destino desconocida

En el caso de que la entrada COOP para la IP de destino no se rellene (punto final silencioso o desfasado), la columna generará una limpieza ARP para resolverla. Para obtener más información, consulte la sección "Reenvío de varios paquetes".

resumen de reenvío de ACI

El siguiente dibujo resume el reenvío de ACI para el caso práctico de las capas 2 y 3.