Probleemoplossing voor ACI Intra-Fabric Forwarding - MultiPod Forwarding

Inleiding

Dit document beschrijft stappen om een ACI Multi-Pod Forwarding Scenario te begrijpen en problemen op te lossen.

Achtergrondinformatie

Het materiaal van dit document is Problemen oplossen met Cisco Application Centric Infrastructure, tweede editie het boek, met name het Intra-Fabric doorsturen - Multi-Pod Forwarding hoofdstuk.

Multi-Pod Forwarding Overzicht

Dit hoofdstuk zal behandelen hoe te probleemoplossing scenario's waarin de connectiviteit niet correct over Pods in een milieu van de multi-Pod werkt

Alvorens te kijken naar specifieke probleemoplossing voorbeelden, is het belangrijk om een moment te nemen om de Multi-Pod componenten op een hoog niveau te begrijpen.

Componenten voor meerdere pennen

Net als bij een traditionele ACI-stof, wordt een Multi-Pod-stof nog steeds beschouwd als één ACI-stof en is voor het beheer afhankelijk van één APIC-cluster.

Binnen elke individuele pod, ACI hefboomt de zelfde protocollen in de bekleding als traditionele stof. Dit omvat IS-IS voor de uitwisseling van TEP-informatie, evenals de selectie van multicast uitgaande interface (OIF), COOP voor een wereldwijde endpointopslagplaats, en BGP VPNv4 voor de distributie van externe routers via de fabric.

Multi-Pod bouwt voort op die componenten aangezien het elke Pod samen moet verbinden.

• Om het routing-informatie over TEP's in de externe pod uit te wisselen, wordt OSPF gebruikt om de summiere TEP-pool via het IPN te adverteren.
• Om externe routes te ruilen die van één Pod naar een andere geleerd zijn, wordt de BGP VPNv4-adresfamilie uitgebreid tussen wervelkolomknooppunten. Elke pod wordt een aparte routereflectorcluster.
• Om zowel eindpunten als andere informatie die in COOP over Pods is opgeslagen te synchroniseren, wordt de BGP EVPN-adresfamilie uitgebreid tussen wervelkolomknooppunten.
• Ten slotte, om de overstroming van Uitzending, Onbekend-Unicast, en Multicast (BUM) verkeer over Peulen te behandelen, de wervelknooppunten in elke Peul handelen als IGMP-gastheren en de routers IPN ruilen multicast routing informatie door Bidirectionele PIM.

Een groot deel van de Multi-Pod probleemoplossing scenario's en werkstromen zijn vergelijkbaar met Single Pod ACI stoffen. Deze Multi-Pod-sectie zal zich voornamelijk richten op de verschillen tussen Single Pod en Multi-Pod-doorsturen.

Topologie voor Multi-Pod Voorbeelden

Zoals met het oplossen van problemen om het even welk scenario, is het belangrijk om te beginnen door te begrijpen wat de verwachte staat is. Verwijs naar deze topologie voor de voorbeelden van dit hoofdstuk.

Algemene werkstroom voor probleemoplossing bij het doorsturen van meerdere pods

Op een hoog niveau, wanneer het zuiveren van een multi-pod het door:sturen kwestie, kunnen de volgende stappen worden geëvalueerd:

1. Is de flow Unicast of multi-destroom? Vergeet niet dat zelfs als de stroom naar verwachting unicast zal zijn in de werkstaat, als ARP niet wordt opgelost dan is het een multi-destroom.
2. Wordt de stroom gerouteerd of overbrugd? Traditioneel, zou een gerouteerde stroom vanuit een ACI perspectief om het even welke stroom zijn waar het adres van bestemmingsMAC het adres is van routerMAC dat door een gateway bezeten is die op ACI wordt gevormd. Bovendien, als ARP overstroming is uitgeschakeld, dan zou het toegangsblad leiden gebaseerd op het doel-IP adres. Als het doeladres van MAC niet wordt bezeten door ACI, dan zou de switch of voorwaarts gebaseerd op het adres van MAC of het "onbekende unicast"gedrag volgen dat op het brugdomein wordt gevormd.
3. Laat het toegangsblad de stroom vallen? fTriage en ELAM zijn de beste tools om dit te bevestigen.

Als de stroom Layer 3 unicast is:

1. Heeft het indringenblad een eindpunt leren voor de bestemming IP in dezelfde VRF als de bron EPG? Als dit zo is, zal dit altijd voorrang hebben over elke geleerde route. Het blad zal rechtstreeks door:sturen naar het tunneladres of de uitgangsinterface waar het eindpunt wordt geleerd.
2. Als er geen eindpunt leer, heeft het ingangsblad een route voor de bestemming die de "Pervasive"vlagreeks heeft? Dit geeft aan dat het doelsubnet is geconfigureerd als een Bridge Domain-subnet en dat de volgende-hop de spinproxy in de lokale Pod moet zijn.
3. Als er geen Pervasief route is, dan zou het laatste redmiddel om het even welke routes zijn die door een L3Out worden geleerd. Dit gedeelte is identiek aan Single Pod L3Out doorsturen.

Als de stroom Layer 2 unicast is:

1. Heeft het ingangsblad een eindpunt leren voor het bestemmingsMAC-adres in hetzelfde Bridge Domain als de bron-EPG? Als dit het geval is, wordt het blad doorgestuurd naar de externe IP-tunnel of naar de lokale interface waar het eindpunt wordt geleerd.
2. Als er geen leer voor het adres van bestemmingsMAC in het brondomein van de Brug is, dan zal het blad door:sturen gebaseerd op het "onbekend-unicast"gedrag BD aan wordt geplaatst. Als het wordt ingesteld op 'Flood', dan zal het blad overstromen naar de GIPo multicast groep toegewezen voor het Bridge Domain. Lokale en afgelegen Pods moeten een overstroomde kopie krijgen. Als het wordt ingesteld op 'Hardware Proxy' dan wordt het frame verzonden naar de ruggengraat voor een proxy lookup en doorgestuurd gebaseerd op de COOP-ingang van de wervelkolom.

Aangezien de output voor probleemoplossing aanzienlijk anders zou zijn voor unicast dan voor BUM, zullen de werkoutput en de scenario's voor unicast eerst worden overwogen en vervolgens naar BUM worden verplaatst.

Werkstroom voor probleemoplossing met meerdere pennen

Volg de topologie, loop door de stroom van 10.0.2.100 op leaf205 tot 10.0.1.100 op leaf101.

Opmerking, alvorens hier verder te gaan, is het belangrijk om te bevestigen of de bron ARP heeft opgelost voor de gateway (voor een routed flow) of het doeladres van MAC (voor een overbrugde flow)

1. Bevestig dat het toegangsblad het pakket ontvangt. Gebruik de ELAM CLI-tool die in het gedeelte "Tools" wordt getoond, samen met de reportoutput die beschikbaar is in 4.2. De ELAM Assistant-app wordt ook gebruikt.

module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 6 out-select 1
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.0.2.100 dst_ip 10.0.1.100
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Triggered

Merk op dat ELAM geactiveerd wat bevestigt dat het pakket is ontvangen op de switch van de toegang. Bekijk nu een paar velden in het rapport omdat de output uitgebreid is.

===========================================================================================================
                                                           Captured Packet

===========================================================================================================

-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes       : l2uc ipv4 ip ipuc ipv4uc
Opcode                        : OPCODE_UC

-----------------------------------------------------------------------------------------------------------
Outer L2 Header
-----------------------------------------------------------------------------------------------------------
Destination MAC               : 0022.BDF8.19FF
Source MAC                    : 0000.2222.2222
802.1Q tag is valid           : yes( 0x1 )
CoS                           : 0( 0x0 )
Access Encap VLAN             : 1021( 0x3FD )

------------------------------------------------------------------------------------------------------------
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                   : 10988( 0x2AEC )
Destination IP                : 10.0.1.100
Source IP                     : 10.0.2.100

Er is veel meer informatie in het verslag over waar het pakket gaat, maar de ELAM Assistant App is momenteel nuttiger voor het interpreteren van deze gegevens. De ELAM Assistant-uitvoer voor deze stroom wordt later in dit hoofdstuk weergegeven.

2. Leert het toegangsblad de bestemming als eindpunt in de toegang VRF? Zo niet, is er een route?

a-leaf205# show endpoint ip 10.0.1.100 detail
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     Endpoint Group
     Domain                          VLAN            IP Address        IP Info                       Info
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+

Geen uitvoer in de bovengenoemde opdracht betekent dat de bestemming IP niet wordt geleerd. Controleer daarna de routeringstabel.

a-leaf205# show ip route 10.0.1.100 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.0.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.120.34%overlay-1, [1/0], 01:55:37, static, tag 4294967294
        recursive next hop: 10.0.120.34/32%overlay-1

In de bovengenoemde output, wordt de doordringende vlag gezien die wijst op dit een Subnetroute van het Domein van de Brug is. De volgende hop moet een anycast proxyadres op de ruggengraat zijn.

a-leaf205# show isis dtep vrf overlay-1 | grep 10.0.120.34
10.0.120.34        SPINE   N/A             PHYSICAL,PROXY-ACAST-V4

Merk op dat als het eindpunt op een tunnel of een fysieke interface wordt geleerd, dit voorrang zal nemen, veroorzakend dat het pakket daar direct wordt door:sturen. Raadpleeg het hoofdstuk "Extern doorsturen" van dit boek voor meer informatie.

Gebruik de ELAM-assistent om de in de bovenstaande uitgangen aangetoonde doorsturen te bevestigen.

Configuratie ELAM Assistant

Controleer de doorsturen beslissingen

De bovenstaande output toont aan dat het ingangsblad het pakket doorstuurt naar het IPv4 spine proxy adres. Dat is wat er verwacht wordt.

3. Bevestig op de ruggengraat dat de bestemmings-IP in COOP aanwezig is, zodat de proxy aanvraag werkt.

Er zijn meerdere manieren om de COOP-uitvoer op de ruggengraat te krijgen, kijk er bijvoorbeeld naar met een 'show coop interne info ip-db' opdracht:

a-spine4# show coop internal info ip-db | grep -B 2 -A 15 "10.0.1.100"

------------------------------
IP address : 10.0.1.100
Vrf : 2392068                          <-- This vnid should correspond to vrf where the IP is learned. Check operational tab of the tenant vrfs
Flags : 0x2
EP bd vnid : 15728642
EP mac :  00:00:11:11:11:11
Publisher Id : 192.168.1.254
Record timestamp : 12 31 1969 19:00:00 0
Publish timestamp : 12 31 1969 19:00:00 0
Seq No: 0
Remote publish timestamp: 09 30 2019 20:29:07 9900483
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.0.34       <-- When learned from a remote pod this will be an External Proxy TEP. We'll cover this more
       Tunnel ref count : 1

------------------------------

Andere opdrachten die u op de as kunt uitvoeren:

Query COOP voor l2-ingang:

moquery -c coopEpRec -f 'coop.EpRec.mac=="00:00:11:11:22:22"

Query COOP voor l3 entry en get parent l2 entry:

moquery -c coopEpRec -x rsp-subtree=children 'rsp-subtree-filter=eq(coopIpv4Rec.addr,"192.168.1.1")' rsp-subtree-include=required

Query COOP alleen voor l3-vermeldingen:

moquery -c coopIpv4Rec -f 'coop.Ipv4Rec.addr=="192.168.1.1"'

Het handige aan de meervoudige moquery is dat ze ook direct op een APIC kunnen worden uitgevoerd en dat de gebruiker elke ruggengraat kan zien die het record in coop heeft.

4. Multi-Pod spine proxy doorsturen besluit

Als de COOP ingangspunten van de wervelkolom naar een tunnel in de lokale Pod dan voorwaarts is gebaseerd op traditioneel ACI gedrag.

Merk op dat de eigenaar van een TEP kan worden geverifieerd in de stof door te lopen van een APIC: moquery -c ipv4Addr -f 'ipv4.Addr.addr=="<tunneladres>"

In het proxyscenario is de volgende-hop tunnel 10.0.0.34. Wie is de eigenaar van dit IP-adres?:

a-apic1# moquery -c ipv4Addr -f 'ipv4.Addr.addr=="10.0.0.34"' | grep dn
dn               : topology/pod-1/node-1002/sys/ipv4/inst/dom-overlay-1/if-[lo9]/addr-[10.0.0.34/32]
dn               : topology/pod-1/node-1001/sys/ipv4/inst/dom-overlay-1/if-[lo2]/addr-[10.0.0.34/32]

Deze IP is eigendom van beide wervelkolomknooppunten in Pod 1. Dit is een specifiek IP genoemd een extern proxyadres. Net zoals ACI proxyadressen heeft die eigendom zijn van de wervelkolom knooppunten binnen een Pod (zie stap 2 van deze sectie), zijn er ook proxyadressen toegewezen aan de Pod zelf. Dit interfacetype kan worden geverifieerd door te draaien:

a-apic1# moquery -c ipv4If -x rsp-subtree=children 'rsp-subtree-filter=eq(ipv4Addr.addr,"10.0.0.34")' rsp-subtree-include=required
   
...
# ipv4.If
mode         : anycast-v4,external

# ipv4.Addr
 addr             : 10.0.0.34/32
 dn               : topology/pod-1/node-1002/sys/ipv4/inst/dom-overlay-1/if-[lo9]/addr-[10.0.0.34/32]

De 'externe' vlag geeft aan dat dit een externe proxy TEP is.

5. Controleer de BGP VPN op de wervelkolom

Het coop-endpointrecord moet worden geïmporteerd van BGP EVPN op de ruggengraat. De volgende opdracht kan worden gebruikt om te verifiëren dat het in EVPN is (hoewel als het reeds in COOP met een volgende-hop van de externe proxy TEP van de afstandsbediening van de pod is kan worden verondersteld dat het van EVPN kwam):

a-spine4# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
Route Distinguisher: 1:16777199
BGP routing table entry for [2]:[0]:[15728642]:[48]:[0000.1111.1111]:[32]:[10.0.1.100]/272, version 689242 dest ptr 0xaf42a4ca
Paths: (2 available, best #2)
Flags: (0x000202 00000000) on xmit-list, is not in rib/evpn, is not in HW, is locked
Multipath: eBGP iBGP

 Path type: internal 0x40000018 0x2040 ref 0 adv path ref 0, path is valid, not best reason: Router Id, remote nh not installed
 AS-Path: NONE, path sourced internal to AS
   192.168.1.254 (metric 7) from 192.168.1.102 (192.168.1.102)
     Origin IGP, MED not set, localpref 100, weight 0
     Received label 15728642 2392068
     Received path-id 1
     Extcommunity:
         RT:5:16
         SOO:1:1
         ENCAP:8
         Router MAC:0200.0000.0000            
         
           Advertised path-id 1
 Path type: internal 0x40000018 0x2040 ref 1 adv path ref 1, path is valid, is best path, remote nh not installed
 AS-Path: NONE, path sourced internal to AS
   192.168.1.254 (metric 7) from 192.168.1.101 (192.168.1.101)
     Origin IGP, MED not set, localpref 100, weight 0
     Received label 15728642 2392068
     Received path-id 1
     Extcommunity:
         RT:5:16
         SOO:1:1
         ENCAP:8
         Router MAC:0200.0000.0000            
         
           Path-id 1 not advertised to any peer

Merk op dat de bovenstaande opdracht ook kan worden uitgevoerd voor een MAC-adres.

-192.168.1.254 is de TEP van het dataplane die tijdens de opstelling van meerdere poden wordt gevormd. Merk echter op dat, ook al wordt het geadverteerd in BGP als de NH, de daadwerkelijke volgende-hop de externe proxy TEP zal zijn.

-192.168.1.101 en .102 zijn de Pod 1 wervelknooppunten die deze weg adverteren.

6. Controleer COOP op de stekels in de bestemmingspeul.

U kunt dezelfde opdracht gebruiken als voorheen:

a-spine2# show coop internal info ip-db | grep -B 2 -A 15 "10.0.1.100"

------------------------------
IP address : 10.0.1.100
Vrf : 2392068
Flags : 0
EP bd vnid : 15728642
EP mac :  00:50:56:81:3E:E6
Publisher Id : 10.0.72.67
Record timestamp : 10 01 2019 15:46:24 502206158
Publish timestamp : 10 01 2019 15:46:24 524378376
Seq No: 0
Remote publish timestamp: 12 31 1969 19:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.72.67
       Tunnel ref count : 1

------------------------------

Controleer wie eigenaar is van het tunneladres door de volgende opdracht uit te voeren op een APIC:

a-apic1# moquery -c ipv4Addr -f 'ipv4.Addr.addr=="10.0.72.67"'
Total Objects shown: 1

# ipv4.Addr
addr             : 10.0.72.67/32
childAction      :
ctrl             :
dn               : topology/pod-1/node-101/sys/ipv4/inst/dom-overlay-1/if-[lo0]/addr-[10.0.72.67/32]
ipv4CfgFailedBmp :
ipv4CfgFailedTs  : 00:00:00:00.000
ipv4CfgState     : 0
lcOwn            : local
modTs            : 2019-09-30T18:42:43.262-04:00
monPolDn         : uni/fabric/monfab-default
operSt           : up
operStQual       : up
pref             : 0
rn               : addr-[10.0.72.67/32]
status           :
tag              : 0
type             : primary
vpcPeer          : 0.0.0.0

Het bovenstaande commando toont aan dat de tunnel van COOP punten naar leaf101. Dit betekent dat leaf101 de lokale learning voor het eindpunt van bestemming moet hebben.

7. Controleer dat het uitgangsblad de lokale leer heeft.

Dit kan worden gedaan via een 'show endpoint' opdracht:

a-leaf101# show endpoint ip 10.0.1.100 detail
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     Endpoint Group
     Domain                          VLAN            IP Address        IP Info                       Info
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+
341                                       vlan-1075    0000.1111.1111 LV                        po5                  Prod:ap1:epg1
Prod:Vrf1                                 vlan-1075        10.0.1.100 LV                        po5

Merk op dat het eindpunt wordt geleerd. Het pakket moet worden doorgestuurd op basis van poortkanaal 5 met VLAN-tag 1075.

Met behulp van Triage om de end-to-end stroom te verifiëren

Zoals besproken in de sectie "Gereedschappen" van dit hoofdstuk, kan fTriage worden gebruikt om een bestaande stroom van begin tot eind in kaart te brengen en te begrijpen wat elke switch in het pad doet met het pakket. Dit is bijzonder nuttig in grotere en complexere implementaties zoals Multi-Pod.

Let op dat fTriage enige tijd in beslag neemt om volledig te starten (mogelijk 15 minuten).

Als Triage wordt uitgevoerd op de voorbeeldstroom:

a-apic1# ftriage route -ii LEAF:205 -dip 10.0.1.100 -sip 10.0.2.100
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "7297", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-16-04-15-438.txt
2019-10-01 16:04:15,442 INFO     /controller/bin/ftriage route -ii LEAF:205 -dip 10.0.1.100 -sip 10.0.2.100
2019-10-01 16:04:38,883 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 16:04:54,678 INFO     ftriage:     main:839  L3 packet Seen on a-leaf205 Ingress: Eth1/31  Egress: Eth1/53 Vnid: 2392068
2019-10-01 16:04:54,896 INFO     ftriage:     main:242  ingress encap string vlan-1021
2019-10-01 16:04:54,899 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-01 16:04:56,778 INFO     ftriage:     main:294  Ingress BD(s) Prod:Bd2
2019-10-01 16:04:56,778 INFO     ftriage:     main:301  Ingress Ctx: Prod:Vrf1
2019-10-01 16:04:56,887 INFO     ftriage:   pktrec:490  a-leaf205: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:05:22,458 INFO     ftriage:     main:933  SIP 10.0.2.100 DIP 10.0.1.100
2019-10-01 16:05:22,459 INFO     ftriage:  unicast:973  a-leaf205: <- is ingress node
2019-10-01 16:05:25,206 INFO     ftriage:  unicast:1215 a-leaf205: Dst EP is remote
2019-10-01 16:05:26,758 INFO     ftriage:     misc:657  a-leaf205: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-01 16:05:26,758 INFO     ftriage:     misc:659  a-leaf205: L3 packet getting routed/bounced in SUG
2019-10-01 16:05:27,030 INFO     ftriage:     misc:657  a-leaf205: Dst IP is present in SUG L3 tbl
2019-10-01 16:05:27,473 INFO     ftriage:     misc:657  a-leaf205: RwDMAC DIPo(10.0.72.67) is one of dst TEPs ['10.0.72.67']
2019-10-01 16:06:25,200 INFO     ftriage:     main:622  Found peer-node a-spine3 and IF: Eth1/31 in candidate list
2019-10-01 16:06:30,802 INFO     ftriage:     node:643  a-spine3: Extracted Internal-port GPD Info for lc: 1
2019-10-01 16:06:30,803 INFO     ftriage:     fcls:4414 a-spine3: LC trigger ELAM with IFS: Eth1/31 Asic :3 Slice: 1 Srcid: 24
2019-10-01 16:07:05,717 INFO     ftriage:     main:839  L3 packet Seen on a-spine3 Ingress: Eth1/31 Egress: LC-1/3 FC-24/0 Port-1 Vnid: 2392068
2019-10-01 16:07:05,718 INFO     ftriage:   pktrec:490  a-spine3: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:07:28,043 INFO     ftriage:      fib:332  a-spine3: Transit in spine
2019-10-01 16:07:35,902 INFO     ftriage:  unicast:1252 a-spine3: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:07:36,018 INFO     ftriage:  unicast:1417 a-spine3: EP is known in COOP (DIPo = 10.0.72.67)
2019-10-01 16:07:40,422 INFO     ftriage:  unicast:1458 a-spine3: Infra route 10.0.72.67 present in RIB
2019-10-01 16:07:40,423 INFO     ftriage:     node:1331 a-spine3: Mapped LC interface: LC-1/3 FC-24/0 Port-1 to FC interface: FC-24/0 LC-1/3 Port-1
2019-10-01 16:07:46,059 INFO     ftriage:     node:460  a-spine3: Extracted GPD Info for fc: 24
2019-10-01 16:07:46,060 INFO     ftriage:     fcls:5748 a-spine3: FC trigger ELAM with IFS: FC-24/0 LC-1/3 Port-1 Asic :0 Slice: 1 Srcid: 40
2019-10-01 16:08:06,735 INFO     ftriage:  unicast:1774 L3 packet Seen on FC of node: a-spine3  with Ingress: FC-24/0 LC-1/3 Port-1  Egress: FC-24/0 LC-1/3 Port-1 Vnid: 2392068
2019-10-01 16:08:06,735 INFO     ftriage:   pktrec:487  a-spine3: Collecting transient losses snapshot for FC module: 24
2019-10-01 16:08:09,123 INFO     ftriage:     node:1339 a-spine3: Mapped FC interface: FC-24/0 LC-1/3 Port-1 to LC interface: LC-1/3 FC-24/0 Port-1
2019-10-01 16:08:09,124 INFO     ftriage:  unicast:1474 a-spine3: Capturing Spine  Transit pkt-type L3 packet on egress LC on Node: a-spine3 IFS: LC-1/3 FC-24/0 Port-1
2019-10-01 16:08:09,594 INFO     ftriage:     fcls:4414 a-spine3: LC trigger ELAM with IFS: LC-1/3 FC-24/0 Port-1 Asic :3 Slice: 1 Srcid: 48
2019-10-01 16:08:44,447 INFO     ftriage:  unicast:1510 a-spine3: L3 packet Spine egress  Transit pkt Seen on a-spine3 Ingress: LC-1/3 FC-24/0 Port-1 Egress: Eth1/29 Vnid: 2392068
2019-10-01 16:08:44,448 INFO     ftriage:   pktrec:490  a-spine3: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:08:46,691 INFO     ftriage:  unicast:1681 a-spine3: Packet is exiting the fabric through {a-spine3: ['Eth1/29']} Dipo 10.0.72.67 and filter SIP 10.0.2.100 DIP 10.0.1.100
2019-10-01 16:10:19,947 INFO     ftriage:     main:716  Capturing L3 packet Fex: False on node: a-spine1 IF: Eth2/25
2019-10-01 16:10:25,752 INFO     ftriage:     node:643  a-spine1: Extracted Internal-port GPD Info for lc: 2
2019-10-01 16:10:25,754 INFO     ftriage:     fcls:4414 a-spine1: LC trigger ELAM with IFS: Eth2/25 Asic :3 Slice: 0 Srcid: 24
2019-10-01 16:10:51,164 INFO     ftriage:     main:716  Capturing L3 packet Fex: False on node: a-spine2 IF: Eth1/31
2019-10-01 16:11:09,690 INFO     ftriage:     main:839  L3 packet Seen on a-spine2 Ingress: Eth1/31 Egress: Eth1/25 Vnid: 2392068
2019-10-01 16:11:09,690 INFO     ftriage:   pktrec:490  a-spine2: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:11:24,882 INFO     ftriage:      fib:332  a-spine2: Transit in spine
2019-10-01 16:11:32,598 INFO     ftriage:  unicast:1252 a-spine2: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:11:32,714 INFO     ftriage:  unicast:1417 a-spine2: EP is known in COOP (DIPo = 10.0.72.67)
2019-10-01 16:11:36,901 INFO     ftriage:  unicast:1458 a-spine2: Infra route 10.0.72.67 present in RIB
2019-10-01 16:11:47,106 INFO     ftriage:     main:622  Found peer-node a-leaf101 and IF: Eth1/54 in candidate list
2019-10-01 16:12:09,836 INFO     ftriage:     main:839  L3 packet Seen on a-leaf101 Ingress: Eth1/54 Egress: Eth1/30 (Po5) Vnid: 11470
2019-10-01 16:12:09,952 INFO     ftriage:   pktrec:490  a-leaf101: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:12:30,991 INFO     ftriage:     nxos:1404 a-leaf101: nxos matching rule id:4659 scope:84 filter:65534
2019-10-01 16:12:32,327 INFO     ftriage:     main:522  Computed egress encap string vlan-1075
2019-10-01 16:12:32,333 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-01 16:12:34,559 INFO     ftriage:     main:331  Egress Ctx Prod:Vrf1
2019-10-01 16:12:34,560 INFO     ftriage:     main:332  Egress BD(s): Prod:Bd1
2019-10-01 16:12:37,704 INFO     ftriage:  unicast:1252 a-leaf101: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:12:37,705 INFO     ftriage:  unicast:1257 a-leaf101: dbg_sub_nexthop invokes dbg_sub_eg for ptep
2019-10-01 16:12:37,705 INFO     ftriage:  unicast:1784 a-leaf101: <- is egress node
2019-10-01 16:12:37,911 INFO     ftriage:  unicast:1833 a-leaf101: Dst EP is local
2019-10-01 16:12:37,912 INFO     ftriage:     misc:657  a-leaf101: EP if(Po5) same as egr if(Po5)
2019-10-01 16:12:38,172 INFO     ftriage:     misc:657  a-leaf101: Dst IP is present in SUG L3 tbl
2019-10-01 16:12:38,564 INFO     ftriage:     misc:657  a-leaf101: RW seg_id:11470 in SUG same as EP segid:11470
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "Idle", "pid": "0", "apicId": "0", "id": "0"}}}
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "Idle", "pid": "0", "apicId": "0", "id": "0"}}}

Er is een grote hoeveelheid gegevens in de fTriage. Enkele van de belangrijkste gebieden worden benadrukt. Merk op dat het pad van het pakket was 'leaf205 (Pod 2) > spine3 (Pod 2) > spine2 (Pod 1) > leaf101 (Pod 1)'. Alle verzendbeslissingen en contractopzoekingen die onderweg zijn gemaakt, zijn ook zichtbaar.

Merk op dat als dit een Layer 2-stroom was, de syntaxis van de fTriage moet worden ingesteld op iets als:

ftriage bridge -ii LEAF:205 -dmac 00:00:11:11:22:22

Verwante verzoeken wanneer het EP niet in COOP is

Alvorens specifieke mislukkingsscenario's te overwegen, is er nog één te bespreken met betrekking tot unicast het door:sturen over Multi-Pod. Wat gebeurt er als het eindpunt van de bestemming onbekend is, het verzoek wordt benaderd en het eindpunt niet in COOP staat?

In dit scenario wordt het pakket/frame naar de wervelkolom verzonden en wordt een glean request gegenereerd.

Wanneer de ruggengraat een glean request genereert, blijft het originele pakket behouden in het request, maar het pakket ontvangt ethertype 0xfff2 dat een Custom Ethertype gereserveerd voor gleans is. Om deze reden, zal het niet gemakkelijk zijn om deze berichten in de hulpmiddelen van de pakketopname zoals Wireshark te interpreteren.

De buitenste Layer 3-bestemming is ook ingesteld op 239.255.255.240, wat een gereserveerde multicast groep is voor glean-berichten. Deze zouden over de stof moeten worden overstroomd en om het even welke switches van het uitgangsblad die bestemmingsSubnet van het opgestelde glean verzoek hebben zullen een ARP verzoek produceren om de bestemming op te lossen. Deze ARP's worden verzonden vanaf het geconfigureerde BD Subnet IP-adres (daarom kunnen proxy-verzoeken de locatie van Silent/Unknown endpoints niet oplossen als Unicast Routing is uitgeschakeld in een Bridge Domain).

De ontvangst van het glean-bericht op het uitgangsblad en de vervolgens gegenereerde ARP- en ontvangen ARP-respons kan worden geverifieerd via de volgende opdracht:

Glean ARP-verificatie

a-leaf205# show ip arp internal event-history event | grep -F -B 1 192.168.21.11 
...
73) Event:E_DEBUG_DSF, length:127, at 316928 usecs after Wed May  1 08:31:53 2019
Updating epm ifidx: 1a01e000 vlan: 105 ip: 192.168.21.11, ifMode: 128 mac: 8c60.4f02.88fc   <<< Endpoint is learned
75) Event:E_DEBUG_DSF, length:152, at 316420 usecs after Wed May  1 08:31:53 2019
log_collect_arp_pkt; sip = 192.168.21.11; dip = 192.168.21.254; interface = Vlan104;info = Garp Check adj:(nil)  <<< Response received
77) Event:E_DEBUG_DSF, length:142, at 131918 usecs after Wed May  1 08:28:36 2019
log_collect_arp_pkt; dip = 192.168.21.11; interface = Vlan104;iod = 138; Info = Internal Request Done   <<< ARP request is generated by leaf
78) Event:E_DEBUG_DSF, length:136, at 131757 usecs after Wed May  1 08:28:36 2019   <<< Glean received, Dst IP is in BD subnet
log_collect_arp_glean;dip = 192.168.21.11;interface = Vlan104;info = Received pkt Fabric-Glean: 1
79) Event:E_DEBUG_DSF, length:174, at 131748 usecs after Wed May  1 08:28:36 2019
log_collect_arp_glean; dip = 192.168.21.11; interface = Vlan104; vrf = CiscoLive2019:vrf1; info = Address in PSVI subnet or special VIP   <<< Glean Received, Dst IP is in BD subnet

Bij wijze van referentie worden glean berichten verzonden naar 239.255.255.240 is de reden waarom deze groep moet worden opgenomen in het Bidirectionele PIM-groepsbereik op het IPN.

Scenario-#1 voor probleemoplossing met meerdere poorts (Unicast)

In de volgende topologie kan EP B niet communiceren met EP A.

topologie voor probleemoplossing

Merk op dat veel van de problemen die gezien worden bij Multi-Pod doorsturen identiek zijn aan problemen die gezien worden in een Single Pod. Om deze reden zijn de problemen die specifiek zijn voor Multi-Pod gericht op.

Terwijl het volgen van de eerder beschreven unicast het oplossen van problemen werkschema, merk op dat het verzoek proxied is maar de wervelknooppunten in Peul 2 hebben niet de bestemming IP in COOP.

Oorzaak: Endpoint ontbreekt in COOP

Zoals eerder besproken, worden COOP-vermeldingen voor externe Pod-endpoints ingevuld op basis van BGP EVPN-informatie. Daarom is het belangrijk te bepalen:

a) Heeft de bronpod (Pod 2) ruggengraat het in EVPN?

a-spine4# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
<no output>

b.) Heeft de externe pod (Pod 1) ruggengraat het in EVPN?

a-spine1# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
Route Distinguisher: 1:16777199    (L2VNI 1)
BGP routing table entry for [2]:[0]:[15728642]:[48]:[0050.5681.3ee6]:[32]:[10.0.1.100]/272, version 11751 dest ptr 0xafbf8192
Paths: (1 available, best #1)
Flags: (0x00010a 00000000) on xmit-list, is not in rib/evpn
Multipath: eBGP iBGP

 Advertised path-id 1
 Path type: local 0x4000008c 0x0 ref 0 adv path ref 1, path is valid, is best path
 AS-Path: NONE, path locally originated
   0.0.0.0 (metric 0) from 0.0.0.0 (192.168.1.101)
     Origin IGP, MED not set, localpref 100, weight 32768
     Received label 15728642 2392068
     Extcommunity:
         RT:5:16
         
           Path-id 1 advertised to peers:

De Pod 1 spine heeft het en de volgende-hop IP is 0.0.0.0; dit betekent dat het product plaatselijk van COOP werd uitgevoerd. Merk echter op dat de sectie 'Adverted to peers' niet de Pod 2 wervelkolom knooppunten omvat.

c.) Is BGP-EVPN tussen Pods?

a-spine4# show bgp l2vpn evpn summ vrf overlay-1

Neighbor            V      AS   MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.101   4 65000       57380    66362            0     0      0  00:00:21  Active
192.168.1.102   4 65000       57568    66357            0     0      0  00:00:22  Active

Merk in de bovenstaande output op dat de BGP EVPN-peerings zijn omlaag tussen Pods. Om het even wat naast een numerieke waarde in de kolom van de Staat/PfxRcd wijst erop dat de nabijheid niet omhoog is. Pod 1 EP's worden niet geleerd door EVPN en worden niet geïmporteerd in COOP.

Als dit probleem wordt gezien, controleert u het volgende:

1. Is OSPF beschikbaar tussen de wervelkolomknooppunten en de aangesloten IPN’s?
2. Hebben de wervelkolomknooppunten routes die door OSPF voor de externe wervelkolom IP's zijn geleerd?
3. Steunt de volledige weg over IPN jumbo MTU?
4. Zijn alle protocolnabijheid stabiel?

Andere mogelijke oorzaken

Als het eindpunt niet in de COOP-database van een pod staat en het doelapparaat een stille host is (niet aangeleerd op een switch in de stof), moet u controleren of het proces voor het draaien van de stof correct werkt. Dit werkt als volgt:

• Unicast Routing moet zijn ingeschakeld op de BD.
• De bestemming moet in een BD-subnet zijn.
• IPN moet multicast routing service bieden voor de 239.255.255.240-groep.

Het multicast gedeelte wordt meer behandeld in de volgende sectie.

Multi-Pod broadcast, onbekende unicast en multicast (BUM) doorsturen overzicht

In ACI wordt verkeer overspoeld via overlay multicast groepen in vele verschillende scenario's. Er is bijvoorbeeld overstroming voor:

• Multicast- en broadcast-verkeer.
• Onbekende unicast die overstroomd moet worden.
• Fabric ARP-glimlaanse berichten.
• EP kondigt berichten aan.

Veel functies en functionaliteit zijn afhankelijk van BUM-doorsturen.

Binnen ACI krijgen alle Bridge Domains een multicast-adres toegewezen dat bekend staat als een Group IP Outer- (of GIPo-) adres. Al het verkeer dat binnen een Bridge Domain moet worden overstroomd, wordt op deze GIPo overstroomd.

BD GIPo in GUI

Het object kan direct worden opgevraagd op een van de APIC's.

BD GIPo in Moquery

a-apic1# moquery -c fvBD -f 'fv.BD.name=="Bd1"'
Total Objects shown: 1

# fv.BD
name                     : Bd1
OptimizeWanBandwidth     : no
annotation               :
arpFlood                 : yes
bcastP                   : 225.1.53.64
childAction              :
configIssues             :
descr                    :
dn                       : uni/tn-Prod/BD-Bd1
epClear                  : no
epMoveDetectMode         :
extMngdBy                :
hostBasedRouting         : no
intersiteBumTrafficAllow : no
intersiteL2Stretch       : no
ipLearning               : yes
ipv6McastAllow           : no
lcOwn                    : local
limitIpLearnToSubnets    : yes
llAddr                   : ::
mac                      : 00:22:BD:F8:19:FF
mcastAllow               : no
modTs                    : 2019-09-30T20:12:01.339-04:00
monPolDn                 : uni/tn-common/monepg-default
mtu                      : inherit
multiDstPktAct           : bd-flood
nameAlias                :
ownerKey                 :
ownerTag                 :
pcTag                    : 16387
rn                       : BD-Bd1
scope                    : 2392068
seg                      : 15728642
status                   :
type                     : regular
uid                      : 16011
unicastRoute             : yes
unkMacUcastAct           : proxy
unkMcastAct              : flood
v6unkMcastAct            : flood
vmac                     : not-applicable

De bovenstaande informatie over GIPo overstroming is waar ongeacht of Multi-Pod wordt gebruikt of niet. Het extra deel van dit dat betrekking heeft op Multi-Pod is de multicast routing op het IPN.

IP-multicast routing omvat het volgende:

• Spineknooppunten fungeren als multicasthosts (alleen IGMP). Ze voeren geen PIM uit.
• Als een BD in een Pod wordt opgesteld, dan zal één wervelkolom van die peul een IGMP verzenden toetreden op één van zijn IPN-Gezichtsinterfaces. Deze functionaliteit is verdeeld over alle wervelkolomknooppunten en IPN-gerichte interface over vele groepen.
• De IPN's ontvangen deze toetredingen en sturen PIM-toetredingen naar de Bidirectionele PIM RP.
• Omdat PIM Bidir wordt gebruikt, zijn er geen (S,G) bomen. Alleen (*,G) bomen worden gebruikt in PIM Bidir.
• Al dataplane verkeer naar de GIPo gaat door de RP.

IPN-multicast regelvlak

IPN multicast dataplane

De enige manier van RP-redundantie met PIM Bidir is het gebruik van Phantom. Dit wordt in detail behandeld binnen het gedeelte Multi-Pod Discovery van dit boek. Als een snelle samenvatting, merk op dat met Phantom RP:

• Alle IPN's moeten worden geconfigureerd met hetzelfde RP-adres.
• Het exacte RP-adres mag op geen enkel apparaat bestaan.
• Meervoudige apparaten adverteren bereikbaarheid aan het subnetje dat het Phantom RP IP adres bevat. De geadverteerde subnetten moeten variëren in subnetlengte zodat alle routers het eens worden over wie de beste weg voor de RP adverteert. Als dit pad verloren gaat, is convergentie afhankelijk van de IGP.

Phantom RP-configuratie

Multi-Pod uitzending, onbekende unicast, en multicast (BUM) het oplossen van probleemoplossing werkschema

1. Bevestig eerst of de stroom door de stof werkelijk wordt behandeld als multi-destroom.

De stroom zal in BD in deze gemeenschappelijke voorbeelden worden overstroomd:

• Het kader is een ARP-uitzending en ARP-overstroming is ingeschakeld op de BD.
• Het frame is bestemd voor een multicast groep. Merk op dat zelfs als IGMP-snooping is ingeschakeld, het verkeer nog steeds overstroomd is naar de stof op de GIPo.
• Het verkeer is bestemd voor een multicast groep waarvoor ACI multicast-routingservices levert.
• De stroom is een Layer 2 (overbrugde stroom) en het MAC-adres van de bestemming is onbekend en het onbekende unicastgedrag op de BD is ingesteld op 'Flood'.

De gemakkelijkste manier om te bepalen welk toezendingsbesluit zal worden genomen is met een ELAM.

2. Identificeer het BD GIPo.

Verwijs naar het gedeelte eerder in dit hoofdstuk dat hierover spreekt. Spine ELAM's kunnen ook via de ELAM Assistant-app worden uitgevoerd om te controleren of het overstroomde verkeer wordt ontvangen.

3. Controleer de multicast routingtabellen op het IPN voor dat GIPo.

De output hiervan zou variëren afhankelijk van het gebruikte IPN-platform, maar op een hoog niveau:

• Alle IPN-routers moeten het eens worden over de RP en de RPF voor deze GIPo moet naar deze boom wijzen.
• Eén IPN router aangesloten op elke Pod moet een IGMP krijgen voor de groep.

Scenario-#2 voor probleemoplossing met meerdere poorts (BUM Flow)

Dit scenario zou om het even welk scenario behandelen dat ARP impliceert die niet over multi-Pod of BUM scenario's worden opgelost (onbekende unicast, enz.).

Er zijn hier verschillende veel voorkomende mogelijke oorzaken.

Mogelijke oorzaak 1: Meervoudige routers bezitten het PIM RP-adres

Met dit scenario, de ingangsblad overstromingen het verkeer (verifiëren met ELAM), ontvangt de bron Pod en overstroomt het verkeer, maar de afstandsbediening krijgt het niet. Voor sommige BD's werkt overstroming, maar voor anderen niet.

Voer in het IPN 'show ip route <GIPo address>' uit om te zien dat de RPF-structuur naar meerdere, verschillende routers wijst.

Als dit het geval is, controleert u het volgende:

• Controleer of het eigenlijke PIM RP-adres niet ergens geconfigureerd is. Elk apparaat dat dat echte RP-adres bezit zou een lokale /32 route voor het zien.
• Controleer dat meerdere IPN-routers niet dezelfde prefixlengte voor de RP adverteren in het Phantom RP-scenario.

Mogelijke oorzaak 2: IPN-routers leren geen routes voor het RP-adres

Net als bij de eerste mogelijke oorzaak is hier het overstroomde verkeer niet in staat om het IPN te verlaten. De output van 'toon ip route <rp address>' op elke IPN router zou de lokaal geconfigureerde prefix-lengte alleen tonen in plaats van wat de andere routers adverteren.

Het resultaat hiervan is dat elk apparaat denkt dat het de RP is, ook al is het echte IP-adres van RP niet ergens geconfigureerd.

Als dit het geval is. controleer het volgende:

• Controleer of de routeringsnabijheid tussen IPN-routers aanwezig is. Verifieer dat de route in het daadwerkelijke protocolgegevensbestand (zoals het OSPF- gegevensbestand) is.
• Controleer dat alle loopbacks die kandidaat-RP's zouden moeten zijn, zijn geconfigureerd als OSPF point-to-point netwerktypen. Als dit netwerktype niet is geconfigureerd zal elke router altijd een /32 prefix-lengte adverteren, ongeacht wat er daadwerkelijk is geconfigureerd.

Mogelijke oorzaak 3: IPN-routers installeren de GIPo-route of de RPF-punten naar ACI niet

Zoals eerder vermeld, voert ACI geen PIM uit op zijn met IPN gerichte verbindingen. Dit betekent dat de beste route van het IPN naar de referentieprijs nooit op ACI mag wijzen. Het scenario waar dit zou kunnen gebeuren is als meerdere IPN routers zijn verbonden met dezelfde ruggengraat en een betere OSPF metriek wordt gezien door de ruggengraat dan direct tussen IPN routers.

RPF-interface naar ACI

U lost dit probleem als volgt op:

• Zorg ervoor dat de routeringsprotocolnabijheid tussen IPN-routers omhoog is.
• Verhoog de OSPF-kostenmaatstaven voor de IPN-gerichte koppelingen op de wervelkolomknooppunten naar een waarde die die metriek minder de voorkeur geeft dan de IPN-naar-IPN-koppelingen.

Andere referenties

Voorafgaand aan ACI software 4.0, werden sommige uitdagingen ervaren betreffende het gebruik van COS 6 door externe apparaten. De meeste van deze problemen zijn opgelost door verbeteringen met 4.0, maar voor meer informatie, raadpleeg de CiscoLive-sessie "BRKACI-2934 - Problemen oplossen Multi-Pod" en de sectie "Quality of Service".