Fehlerbehebung bei PBR in der ACI
Einleitung
In diesem Dokument wird die Fehlerbehebung in Application Centric Infrastructure (ACI)-Umgebungen mit Policy-Based Redirect (PBR) in einer einzigen Pod-Fabric beschrieben.
Voraussetzungen
Anforderungen
Für diesen Artikel wird empfohlen, dass Sie allgemeine Kenntnisse über diese Themen haben:
- ACI-Konzepte: Zugriffsrichtlinien, Endgeräte-Schulungen, Verträge und L3out
Verwendete Komponenten
Diese Fehlerbehebung wurde in ACI-Version 6.0(8f) mit Nexus Switches der zweiten Generation N9K-C93180YC-EX und N9K-C93240YC-FX2 durchgeführt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Abkürzungen
- BD: Bridge-Domäne
- EPG: Endpunktgruppe
- Klassen-ID: Tag, das eine EPG identifiziert
- PBR-Knoten: L4-L7-Gerät, das für ein PBR-Ziel verwendet wird
- Verbraucheranschluss: PBR-Knotenschnittstelle auf der Verbraucherseite
- Provider Connector: Anbieterseitige PBR-Knotenschnittstelle
PBR-Verlauf
| Version | Wichtigste Funktionen |
|
2,0 (1 m) |
|
|
3.x und frühere Versionen |
|
|
3,2(x) |
|
|
4,0(x) |
|
|
4.2(1) |
|
|
4.2(3) |
|
|
5.0(1) |
|
|
5.2(1) |
|
|
6.0(1) |
|
Überlegungen zum Netzwerkdesign
- PBR funktioniert mit physischen und virtuellen Appliances
- PBR kann zwischen L3Out-EPGs und EPGs, zwischen EPGs und zwischen L3Out-EPGs verwendet werden. PBR wird nicht unterstützt, wenn die L2Out-EPG Teil des Vertrags ist
- PBR wird in Cisco ACI Multi-Pod-, Multi-Site- und Remote Leaf-Umgebungen unterstützt.
- Die Cisco ACI-Fabric muss das Gateway für die Server und für den PBR-Knoten sein.
- Das L4-L7-Gerät muss im Go-To-Modus (gerouteter Modus) bereitgestellt werden.
- PBR-Knoten wird auf FEX-Switches nicht unterstützt
- Für den PBR-Knoten wird eine dedizierte Bridge-Domäne benötigt.
- Dynamische MAC-Adressen für den PBR-Knoten werden jetzt mithilfe von Integritätsgruppen unterstützt.
- Es wird empfohlen, die GARP-basierte Erkennung in der PBR-Knoten-Bridge-Domäne zu aktivieren.
- Für PBR darf kein allgemeiner Standardfilter verwendet werden, der ARP, Ethernet-Datenverkehr und anderen Datenverkehr ohne IP-Adresse umfasst.
- Der PBR-Knoten kann sich zwischen VRF-Instanzen oder innerhalb einer der VRF-Instanzen befinden. Für diese Topologie wird ein PBR-Knoten auf einer dritten VRF-Instanz nicht unterstützt. Der PBR-Knoten muss entweder im VRF des Verbrauchers oder des Anbieters konfiguriert werden.
Hintergrundinformationen
Ausführlichere Erläuterungen zu ELAM und Ftriage finden Sie in der CiscoLive On-Demand-Bibliothek in der Sitzung BRKDCN-3900b.
Alle Konfigurationsrichtlinien sind im Cisco Application Centric Infrastructure Policy-Based Redirect Service Graph Design Whitepaper beschrieben.
Szenario: Einzelne VRF-Instanz in einer einzelnen Pod-Struktur
Netzwerkdiagramm
Physische Topologie:
Fehlerbehebung
Schritt 1: Fehler
Die ACI löst einen Fehler aus, wenn ein Problem mit der Konfiguration oder den Richtlinieninteraktionen auftritt. Für den PBR-Renderingprozess wurden bei einem Ausfall bestimmte Fehler identifiziert:
F1690: Konfiguration ist ungültig aufgrund von:
- Fehler bei der ID-Zuweisung
Dieser Fehler bedeutet, dass das gekapselte VLAN für den Serviceknoten nicht verfügbar ist. Beispielsweise könnte im VLAN-Pool, der der vom logischen Gerät verwendeten Virtual Machine Manager (VMM)-Domäne zugeordnet ist, kein dynamisches VLAN verfügbar sein.
Auflösung: Überprüfen Sie den VLAN-Pool in der vom logischen Gerät verwendeten Domäne. Wenn sich die Schnittstelle für logisches Gerät in einer physischen Domäne befindet, überprüfen Sie auch die gekapselte VLAN-Konfiguration. Diese Einstellungen finden Sie unter Tenant > Services > L4-L7 > Devices and Fabric > Access Policies > Pools > VLAN.
Wenn sich die Schnittstelle für logische Geräte in einer virtuellen Domäne befindet und über eine Trunk-Schnittstelle mit Ihren ESXi-Hosts verbunden ist, stellen Sie andererseits sicher, dass die Option für den Trunking-Port aktiviert ist.
- Kein Gerätekontext für LDev gefunden
Dieser Fehler zeigt an, dass das logische Gerät nicht für das Servicediagramm-Rendering lokalisiert werden kann. Es kann beispielsweise keine Richtlinie für die Geräteauswahl geben, die mit dem Vertrag übereinstimmt, der dem Servicediagramm zugeordnet ist.
Auflösung: Überprüfen der Definition einer Richtlinie zur Geräteauswahl Die Richtlinie zur Geräteauswahl legt Auswahlkriterien für ein Service-Gerät und dessen Konnektoren fest, die auf dem Vertragsnamen, dem Servicediagrammnamen und dem Knotennamen im Servicediagramm basieren. Diese finden Sie unter Tenant > Services > L4-L7 > Device Selection Policy.
Anmerkung: Wenn Sie eine Servicediagrammvorlage bereitstellen, wählt die ACI die Bridge-Domäne für die Quell-EPG im Voraus aus. Sie müssen diese Bridge-Domäne für den PBR-Consumeranschluss ändern. Dasselbe gilt für den Provider Connector.
- Kein BD gefunden
Dieser Fehler zeigt an, dass die Bridge-Domäne (BD) für den Serviceknoten nicht gefunden werden kann. Der BD ist beispielsweise in der Richtlinie zur Geräteauswahl nicht angegeben.
Auflösung: Stellen Sie sicher, dass der BD in der Richtlinie zur Geräteauswahl angegeben ist und dass der Connectorname richtig ist. Diese Konfiguration befindet sich unter Tenant > Services > L4-L7 > Devices Selection Policy > [ Contract + SG ] > [ Consumer | Anbieter ].
- LIf hat keine Beziehung zu CIf und LIf hat eine ungültige CIf
- Keine Cluster-Schnittstelle gefunden
Diese Fehler weisen darauf hin, dass das Gerät in keiner Beziehung zu den Cluster-Schnittstellen steht.
Auflösung: Stellen Sie sicher, dass die Layer-4-zu-Layer-7-Gerätekonfiguration (L4-L7) eine konkrete Schnittstellenauswahl enthält. Diese Konfiguration befindet sich unter Tenant > Services > L4-L7 > Devices > [ Device ] > Cluster Interfaces (Tenant > Dienste > L4-L7 > Geräte > [ Gerät ] > Cluster Interfaces (Cluster-Schnittstellen).
- Ungültige Richtlinie für die Serviceumleitung
Dieser Fehler bedeutet, dass die PBR-Richtlinie nicht angewendet wurde, obwohl die Umleitung für die Servicefunktion im Servicediagramm aktiviert wurde.
Auflösung: Stellen Sie sicher, dass die PBR-Richtlinie in den Einstellungen der Geräteauswahlrichtlinie konfiguriert wurde. Diese Konfiguration befindet sich unter Tenant > Services > L4-L7 > Devices Selection Policy > [ Contract + SG ] > [ Consumer | Anbieter ].
F0759: graph-rendering-failure - "Servicediagramm für Tenant < Tenant > konnte nicht instanziiert werden. Die Konfiguration des Funktionsknotens ist ungültig."
Das Dienstdiagramm für den angegebenen Tenant konnte aufgrund einer ungültigen Konfiguration des Funktionsknotennamens nicht instanziiert werden.
Dieser Fehler deutet auf Konfigurationsprobleme in Zusammenhang mit den oben genannten Bedingungen hin.
Zudem kann es bei Erstbereitstellungen vorübergehend zu diesem Fehler kommen, der dann zeitnah behoben werden kann. Dies ist auf den Renderingprozess zurückzuführen, dem die ACI zur Bereitstellung aller Richtlinien unterzogen wird.
Auflösung: Prüfen Sie alle zusätzlich gemeldeten Fehler, und beheben Sie sie entsprechend.
F0764: configuration-failed - "L4-L7-Gerätekonfiguration < Gerät > für Tenant < Tenant > ist ungültig."
Das Servicediagramm für den angegebenen Tenant konnte aufgrund einer ungültigen Konfiguration der PBR-Geräterichtlinie nicht instanziiert werden.
Dieser Fehler deutet auf Konfigurationsprobleme in Zusammenhang mit den oben genannten Bedingungen hin.
Auflösung: Prüfen Sie alle zusätzlich gemeldeten Fehler, und beheben Sie sie entsprechend.
F0772 configuration-failed - "LIf-Konfiguration < Cluster > für L4-L7-Geräte < Device > für Tenant < Tenant > ist ungültig."
Das Servicediagramm für den angegebenen Tenant konnte aufgrund einer ungültigen Konfiguration der Schnittstellenauswahl des PBR-Geräteclusters nicht instanziiert werden.
Dieser Fehler deutet auf Konfigurationsprobleme in Zusammenhang mit den oben genannten Bedingungen hin.
Auflösung: Prüfen Sie alle zusätzlich gemeldeten Fehler, und beheben Sie sie entsprechend.
Phase 2: Lernen von Quell- und Zielendgeräten
Stellen Sie sicher, dass Ihre Quell- und Zielendpunkte innerhalb der Fabric erkannt werden. Dies erfordert eine grundlegende Konfiguration:
- Ein VRF-Objekt (Virtual Routing and Forwarding).
- Ein Bridge Domain (BD)-Objekt mit aktiviertem Unicast-Routing. Das Erlernen der IP-Datenebene wird zwar als Best Practice erachtet, ist jedoch nicht obligatorisch.
- Ein Endpoint Group (EPG)-Objekt, das sowohl für virtuelle als auch für physische Domänen gilt.
- Zugriffsrichtlinien: Stellen Sie sicher, dass die Konfigurationskette für die Zugriffsrichtlinie abgeschlossen ist und keine Fehler in der EPG gemeldet werden.
Führen Sie diesen Befehl auf dem Leaf aus, auf dem der Endpunkt gelernt wird, auch als Compute Leaf bezeichnet, um zu bestätigen, dass der Endpunkt die richtige EPG und Schnittstelle verwendet:
show system internal epm endpoint [ ip | mac ] [ x.x.x.x | eeee.eeee.eeee ]
Leaf101# show system internal epm endpoint ip 10.10.100.10
MAC : aaaa.aaaa.aaaa ::: Num IPs : 1
IP# 0 : 10.10.100.10 ::: IP# 0 flags : ::: l3-sw-hit: No
Vlan id : 57 ::: Vlan vnid : 10865 ::: VRF name : TZ:Prod
BD vnid : 16056291 ::: VRF vnid : 2162692
Phy If : 0x16000008 ::: Tunnel If : 0
Interface : port-channel9
Flags : 0x80004c05 ::: sclass : 49155 ::: Ref count : 5
EP Create Timestamp : 02/18/2025 15:00:18.767228
EP Update Timestamp : 02/18/2025 15:04:57.908343
EP Flags : local|VPC|IP|MAC|sclass|timer|
::::
Leaf101#
Mit diesem Befehl können Sie das pcTag (class) identifizieren, das der EPG zugeordnet ist, in der der Endpunkt klassifiziert ist, und Informationen zu Schnittstelle, VRF-Bereich und MAC-Adresse abrufen.
Wenn Sie den Standort des Quell- oder Zielendpunkts nicht kennen, können Sie sich jederzeit mit diesem Befehl im APIC unterstützen:
show endpoint [ ip | mac ] [ x.x.x.x | eeee.eeee.eeee ]
APIC# show endpoint ip 10.10.100.10
Legends:
(P):Primary VLAN
(S):Secondary VLAN
Dynamic Endpoints:
Tenant : TZ
Application : TZ
AEPg : Prod-Consumer
End Point MAC IP Address Source Node Interface Encap Multicast Address Create TS
----------------- ---------------------------------------- ------------ ---------- ------------------------------ --------------- --------------- --------------------
AA:AA:AA:AA:AA:AA 10.10.100.10 learned,vmm 101 102 vpc VPC-ESX-169 vlan-2673 not-applicable 2025-02-18T15:16:40.
565-06:00
Total Dynamic Endpoints: 1
Total Static Endpoints: 0
APIC#
In der GUI kann auf die Funktion EP Tracker zugegriffen werden. Sie navigieren zu Operations > EP Tracker für Endpunktüberwachung und -verwaltung.
Mithilfe der Informationen, die von den Quell- und Zielendpunkten gesammelt wurden, können Sie sich jetzt auf die Bereitstellung von PBR-Richtlinien konzentrieren.
Schritt 3: Vertrag umleiten
PBR ist in das Service Graph Framework integriert. Daher muss eine Servicediagrammvorlage auf dem Quell- und Zielswitch vertragsgemäß bereitgestellt und konfiguriert werden. Mithilfe der im vorherigen Schritt gesammelten pcTags-Informationen können Sie feststellen, ob eine Endpunktgruppe (EPG) an eine Servicediagrammgruppe umgeleitet wird, indem Sie diesen Befehl ausführen.
show zoning-rule scope [ vrf_scope ]
In den Zonenregeln müssen diese Regeln berücksichtigt werden:
- Quell-EPG zu Ziel-EPG mit zugehöriger Umleitungsgruppe
- Quell-PBR-Knoten-Schatten-EPG zu Quell-EPG
- Ziel-EPG zu Quell-EPG mit zugehöriger Umleitungsgruppe. Diese Gruppe kann mit der vorherigen Konfiguration identisch oder von dieser abweichen.
- Ziel-PBR-Knoten-Schatten-EPG zu Ziel-EPG
Leaf101# show zoning-rule scope 2162692
+---------+--------+--------+----------+----------------+---------+---------+------+------------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority |
+---------+--------+--------+----------+----------------+---------+---------+------+------------------+----------------------+
| 4565 | 49155 | 49156 | default | bi-dir | enabled | 2162692 | | redir(destgrp-8) | src_dst_any(9) |
| 4565 | 49156 | 49155 | default | uni-dir-ignore | enabled | 2162692 | | redir(destgrp-9) | src_dst_any(9) |
| 4973 | 16387 | 49155 | default | uni-dir | enabled | 2162692 | | permit | src_dst_any(9) |
| 4564 | 49157 | 49156 | default | uni-dir | enabled | 2162692 | | permit | src_dst_any(9) |
+---------+--------+--------+----------+----------------+---------+---------+------+------------------+----------------------+
Leaf101#
Um das pcTag der Shadow-EPGs zu überprüfen, die während des PBR-Bereitstellungsprozesses erstellt wurden, navigieren Sie zu Tenants > [ TENANT_NAME ] > Services > L4-L7 > Deployed Graph Instance > [ SG_NAME ] > Function Node - N1.
- Vertrags-Parser
Das Skript korreliert Zoning-Regeln, Filter, Statistiken und EPG-Namen. Sie können dieses Skript sicher direkt auf einem ACI-Leaf oder APIC ausführen. Bei Ausführung auf dem APIC werden auf allen Leaf-Switches konkrete Objekte gesammelt, was bei umfangreichen Richtlinienbereitstellungen einige Minuten dauern kann.
Ab der ACI-Version 3.2 ist der contract_parser im Image gebündelt und auf dem Leaf verfügbar. Geben Sie einfach contract_parser.py aus der iBash-Shell ein.
Leaf101# contract_parser.py --sepg 49155
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]
[7:4999] [vrf:TZ:Prod] log,redir ip tn-TZ/ap-TZ/epg-Prod-Consumer(49155) tn-TZ/ap-TZ/epg-Prod-Provideer(49156) [contract:uni/tn-TZ/brc-TZ-PBR-Contract] [hit=81]
destgrp-8 vrf:TZ:Prod ip:192.168.100.10 mac:00:50:56:B7:D0:5D bd:uni/tn-TZ/BD-Cons-Connector
Leaf101#
Dieser Befehl stellt Details wie die Vertragsaktion, die Quell- und Ziel-EPGs, den verwendeten Vertragsnamen und die Trefferanzahl bereit.
Schritt 4: Umleitungsgruppe
Nachdem die Umleitungsgruppe anhand des Vertrags identifiziert wurde, der auf die Zoning-Regeln angewendet wird, besteht der nächste Schritt darin, die IP- und MAC-Adressen der für die Umleitung bestimmten Geräte zu bestimmen. Führen Sie dazu den folgenden Befehl aus:
show service redir info group [ destgrp_ID ]
Leaf101# show service redir info group 8
===============================================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency | W: Weight
===============================================================================================================================================================
GrpID Name destination HG-name BAC W operSt operStQual TL TH HP TRA RES
===== ==== =========== ============== === === ======= ============ === === === === ===
8 destgrp-8 dest-[192.168.100.10]-[vxlan-2162692] Not attached N 1 enabled no-oper-grp 0 0 sym no no
Leaf101#
Leaf101# show service redir info group 9
===============================================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency | W: Weight
===============================================================================================================================================================
GrpID Name destination HG-name BAC W operSt operStQual TL TH HP TRA RES
===== ==== =========== ============== === === ======= ============ === === === === ===
9 destgrp-9 dest-[192.168.200.20]-[vxlan-2162692] Not attached N 1 enabled no-oper-grp 0 0 sym no no
Leaf101#
Mit diesem Befehl können wir den Betriebsstatus (OperSt) unserer Umleitungsgruppe, die im L4-L7-PBR-Abschnitt konfigurierte IP-Adresse und die VNID der VRF-Instanz ermitteln, die den PBR-Knoten-Bridge-Domänen zugeordnet ist. Sie müssen nun die konfigurierte MAC-Adresse ermitteln:
show service redir info destinations ip [ PBR-node IP ] vnid [ VRF_VNID ]
Leaf101# show service redir info destination ip 192.168.100.10 vnid 2162692
===============================================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency | W: Weight
===============================================================================================================================================================
Name bdVnid vMac vrf operSt operStQual HG-name
==== ====== ==== ==== ===== ========= =======
dest-[192.168.100.10]-[vxlan-2162692] vxlan-15826939 00:50:56:B7:D0:5D TZ:Prod enabled no-oper-dest Not attached
Leaf101#
Leaf101# show service redir info destination ip 192.168.200.20 vnid 2162692
===============================================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency | W: Weight
===============================================================================================================================================================
Name bdVnid vMac vrf operSt operStQual HG-name
==== ====== ==== ==== ===== ========= =======
dest-[192.168.200.20]-[vxlan-2162692] vxlan-16646036 00:50:56:B7:BF:94 TZ:Prod enabled no-oper-dest Not attached
Leaf101#
Zusätzlich zu den zuvor genannten Details bietet dieser Befehl nützliche Informationen wie den VRF-Namen, die BD VNID und die konfigurierte MAC-Adresse des PBR-Knotens.
Anmerkung: Es ist wichtig zu beachten, dass zu diesem Zeitpunkt sowohl die IP- als auch die MAC-Adresse vom Benutzer konfiguriert werden. Das bedeutet, dass während der Definition des richtlinienbasierten L4-L7-Routings typografische Fehler auftreten können.
Schritt 5: PBR-Knoten empfängt keinen Datenverkehr.
Ein häufiges Problem bei der PBR-Weiterleitung ist die Abwesenheit von Datenverkehr, der den PBR-Knoten erreicht. Häufig liegt eine falsch angegebene MAC-Adresse in der L4-L7-Konfiguration für richtlinienbasiertes Routing vor.
Um die Richtigkeit der im richtlinienbasierten L4-L7-Routing konfigurierten MAC-Adresse zu überprüfen, führen Sie den zuvor verwendeten Befehl aus Schritt 2 aus. Dieser Befehl kann auf dem Leaf-Switch ausgeführt werden, der als Service-Leaf festgelegt ist, auf dem der Knoten voraussichtlich abgelegt wird.
show system internal epm endpoint [ ip | mac ] [ x.x.x.x | eeee.eeee.eeee ]
Leaf103# show system internal epm endpoint ip 192.168.100.10
MAC : 0050.56b7.d05d ::: Num IPs : 1
IP# 0 : 192.168.100.10 ::: IP# 0 flags : ::: l3-sw-hit: Yes ::: flags2 : dp-lrn-dis
Vlan id : 71 ::: Vlan vnid : 10867 ::: VRF name : TZ:Prod
BD vnid : 15826939 ::: VRF vnid : 2162692
Phy If : 0x16000008 ::: Tunnel If : 0
Interface : port-channel19
Flags : 0x80004c25 ::: sclass : 16387 ::: Ref count : 5
EP Create Timestamp : 02/19/2025 12:07:44.065032
EP Update Timestamp : 02/19/2025 15:27:03.400086
EP Flags : local|vPC|peer-aged|IP|MAC|sclass|timer|
::::
Leaf103#
•••••
Leaf103# show system internal epm endpoint ip 192.168.200.20
MAC : 0050.56b7.bf94 ::: Num IPs : 1
IP# 0 : 192.168.200.20 ::: IP# 0 flags : ::: l3-sw-hit: Yes ::: flags2 : dp-lrn-dis
Vlan id : 60 ::: Vlan vnid : 10866 ::: VRF name : TZ:Prod
BD vnid : 16646036 ::: VRF vnid : 2162692
Phy If : 0x16000008 ::: Tunnel If : 0
Interface : port-channel19
Flags : 0x80004c25 ::: sclass : 49157 ::: Ref count : 5
EP Create Timestamp : 02/19/2025 13:51:03.377942
EP Update Timestamp : 02/19/2025 15:28:34.151877
EP Flags : local|vPC|peer-aged|IP|MAC|sclass|timer|
::::
Leaf103#
Überprüfen Sie, ob die in der EPM-Tabelle aufgezeichnete MAC-Adresse mit der in der Service-Umleitungsgruppe konfigurierten Adresse übereinstimmt. Selbst geringfügige typografische Fehler müssen behoben werden, um eine ordnungsgemäße Weiterleitung des Datenverkehrs an das Ziel des PBR-Knotens zu gewährleisten.
Schritt 6: Datenverkehrsfluss.
- FRIAGE
Ein CLI-Tool für den APIC zur Automatisierung der Konfiguration und Interpretation von End-to-End-ELAM-Prozessen. Mit diesem Tool können Benutzer einen bestimmten Datenfluss und den Leaf-Switch angeben, von dem der Datenfluss stammt. Er führt sequenziell ELAMs auf jedem Knoten aus, um den Weiterleitungspfad des Datenflusses zu analysieren. Dieses Tool ist besonders in komplexen Topologien nützlich, in denen der Paketpfad nicht leicht zu erkennen ist.
APIC # ftriage -user admin route -sip 10.10.100.10 -dip 10.20.200.20 -ii LEAF:101,102
Starting ftriage
Log file name for the current run is: ftlog_2025-02-25-10-26-05-108.txt
2025-02-25 10:26:05,116 INFO /controller/bin/ftriage -user admin route -sip 10.10.100.10 -dip 10.20.200.20 -ii LEAF:101,102
Request password info for username: admin
Password:
2025-02-25 10:26:31,759 INFO ftriage: main:2505 Invoking ftriage with username: admin
2025-02-25 10:26:34,188 INFO ftriage: main:1546 Enable Async parellel ELAM with 2 nodes
2025-02-25 10:26:57,927 INFO ftriage: fcls:2510 LEAF101: Valid ELAM for asic:0 slice:0 srcid:64 pktid:1913
2025-02-25 10:26:59,120 INFO ftriage: fcls:2863 LEAF101: Signal ELAM found for Async lookup
2025-02-25 10:27:00,620 INFO ftriage: main:1317 L3 packet Seen on LEAF101 Ingress: Eth1/45 (Po9) Egress: Eth1/52 Vnid: 2673
2025-02-25 10:27:00,632 INFO ftriage: main:1372 LEAF101: Incoming Packet captured with [SIP:10.10.100.10, DIP:10.20.200.20]
•••
2025-02-25 10:27:08,665 INFO ftriage: main:480 Ingress BD(s) TZ:Prod-Consumer
2025-02-25 10:27:08,666 INFO ftriage: main:491 Ingress Ctx: TZ:Prod Vnid: 2162692
•••
2025-02-25 10:27:45,337 INFO ftriage: pktrec:367 LEAF101: traffic is redirected
•••
2025-02-25 10:28:10,701 INFO ftriage: unicast:1550 LEAF101: traffic is redirected to vnid:15826939 mac:00:50:56:B7:D0:5D via tenant:TZ graph:TZ-PBR-SG contract: TZ-PBR-Contract
•••
2025-02-25 10:28:20,339 INFO ftriage: main:975 Found peer-node SPINE1001 and IF: Eth1/1 in candidate list
•••
2025-02-25 10:28:39,471 INFO ftriage: main:1366 SPINE1001: Incoming Packet captured with Outer [SIP:10.2.200.64, DIP:10.2.64.97] .... Inner [SIP:10.10.100.10, DIP:10.20.200.20]
2025-02-25 10:28:39,472 INFO ftriage: main:1408 SPINE1001: Outgoing packet's Vnid: 15826939
2025-02-25 10:28:58,469 INFO ftriage: fib:524 SPINE1001: Proxy in spine
•••
2025-02-25 10:29:07,898 INFO ftriage: main:975 Found peer-node LEAF103. and IF: Eth1/50 in candidate list
•••
2025-02-25 10:29:35,331 INFO ftriage: main:1366 LEAF103: Incoming Packet captured with Outer [SIP:10.2.200.64, DIP:10.2.200.64] .... Inner [SIP:10.10.100.10, DIP:10.20.200.20]
•••
2025-02-25 10:29:50,277 INFO ftriage: ep:128 LEAF103: pbr traffic with dmac: 00:50:56:B7:D0:5D
2025-02-25 10:30:07,374 INFO ftriage: main:800 Computed egress encap string vlan-2676
2025-02-25 10:30:13,326 INFO ftriage: main:535 Egress Ctx TZ:Prod
2025-02-25 10:30:13,326 INFO ftriage: main:536 Egress BD(s): TZ:Cons-Connector
•••
2025-02-25 10:30:18,812 INFO ftriage: misc:908 LEAF103: caller unicast:581 EP if(Po19) same as egr if(Po19)
2025-02-25 10:30:18,812 INFO ftriage: misc:910 LEAF103: L3 packet caller unicast:668 getting bridged in SUG
2025-02-25 10:30:18,813 INFO ftriage: main:1822 dbg_sub_nexthop function returned values on node LEAF103 done True, nxt_nifs None, nxt_dbg_f_n , nxt_inst , eg_ifs Eth1/45, Vnid: 2676
2025-02-25 10:30:19,378 INFO ftriage: acigraph:794 : Ftriage Completed with hunch: matching service device not found
APIC #
- ELAM:
Das Embedded Logic Analyzer Module (ELAM) ist ein Diagnosetool, mit dem Benutzer spezifische Hardwarebedingungen festlegen können, um das ursprüngliche Paket oder Frame zu erfassen, das diese Kriterien erfüllt. Wenn eine Erfassung erfolgreich ist, wird der ELAM-Status als ausgelöst angezeigt. Nach dem Auslösen wird das ELAM deaktiviert, sodass ein Daten-Dump erfasst werden kann, der die Analyse der zahlreichen Weiterleitungsentscheidungen erleichtert, die vom ASIC des Switches für dieses Paket oder diesen Frame ausgeführt werden. ELAM arbeitet auf ASIC-Ebene und stellt sicher, dass die CPU oder andere Ressourcen des Switches nicht beeinträchtigt werden.
Struktur der Befehlssyntax. Diese Struktur wurde aus dem Buch Troubleshoot ACI Intra-Fabric Forwarding Tools erfasst.
vsh_lc [This command enters the line card shell where ELAMs are run]
debug platform internal <asic> elam asic 0 [refer to the ASICs table]
Auslösungsbedingungen festlegen
trigger reset [ensures no existing triggers are running]
trigger init in-select <number> out-select <number> [determines what information about a packet is displayed and which conditions can be set]
set outer/inner [sets conditions]
start [starts the trigger]
status [checks if a packet is captured]
Generieren Sie den Dump, der die Paketanalyse enthält.
ereport [display detailed forwarding decision for the packet]
- Datenverkehrsfluss
Es ist wichtig, den Datenverkehrsfluss über alle fraglichen Geräte zu kennen. Das Ftriage-Tool bietet eine hervorragende Zusammenfassung dieses Ablaufs. Für eine detaillierte schrittweise Validierung und um tiefere Einblicke in den Paketempfangsvorgang zu erhalten, können Sie jedoch das Embedded Logic Analyzer Module (ELAM) an jedem Punkt innerhalb der Netzwerktopologie ausführen.
1. Eingangsdatenverkehr erfolgt auf dem Computing-Leaf, auf dem der Quellserver erfasst wird. In diesem speziellen Szenario muss ELAM auf den vPC-Peers konfiguriert werden, da sich die Quelle hinter einer vPC-Schnittstelle befindet. Dies ist erforderlich, da die vom Hash-Algorithmus ausgewählte physische Schnittstelle unbestimmt ist.
LEAF101# vsh_lc
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)# reset
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.10.100.10 dst_ip 10.20.200.20
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
Asic 0 Slice 1 Status Armed
module-1(DBG-elam-insel6)# ereport
======================================================================================================
Trigger/Basic Information
======================================================================================================
•••
Incoming Interface : 0x40( 0x40 ) >>> Eth1/45
•••
-------------------------------------------------------------------------------------------------------
Outer L2 Header
-------------------------------------------------------------------------------------------------------
Destination MAC : 0022.BDF8.19FF >>> Bridge-domain MAC address
Source MAC : AAAA.AAAA.AAAA
802.1Q tag is valid : yes( 0x1 )
CoS : 0( 0x0 )
Access Encap VLAN : 2673( 0xA71 )
-------------------------------------------------------------------------------------------------------
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 : set
TTL : 64
IP Protocol Number : ICMP
IP CheckSum : 6465( 0x1941 )
Destination IP : 10.20.200.20
Source IP : 10.10.100.10
-------------------------------------------------------------------------------------------------------
Contract Lookup Key
-------------------------------------------------------------------------------------------------------
IP Protocol : ICMP( 0x1 )
L4 Src Port : 2048( 0x800 )
L4 Dst Port : 7345( 0x1CB1 )
sclass (src pcTag) : 49155( 0xC003 ) >>> Prod-Consumer EPG
dclass (dst pcTag) : 49156( 0xC004 ) >>> Prod-Provider EPG
src pcTag is from local table : yes >>> EPGs are known locally
derived from a local table on this node by the lookup of src IP or MAC
Unknown Unicast / Flood Packet : no
If yes, Contract is not applied here because it is flooded
-------------------------------------------------------------------------------------------------------
Sideband Information
-------------------------------------------------------------------------------------------------------
ovector : 176( 0xB0 ) >>> Eth1/52
Ovec in "show plat int hal l2 port gpd"
Opcode : OPCODE_UC
-------------------------------------------------------------------------------------------------------
sug_luc_latch_results_vec.luc3_0.service_redir: 0x1 >>> Service Redir 0x1 = PBR was applied
------------------------------------------------------------------------------------------------------
Aus den bereitgestellten Informationen geht hervor, dass das Paket über richtlinienbasiertes Routing (Policy-Based Routing, PBR) umgeleitet wird, da die Option service_redir aktiviert ist. Außerdem rufen Sie die Klassen- und Klassenwerte ab. In diesem speziellen Szenario erkennt der Switch die Klasse. Wenn der Zielendpunkt jedoch nicht in der EPM-Tabelle vorhanden ist, wird der Klassenwert auf den Standardwert 1 zurückgesetzt.
Weiterhin wird die Eingangsschnittstelle durch die SRCID bestimmt und die Ausgangsschnittstelle durch die Vektorwerte identifiziert. Diese Werte können durch Ausführen des folgenden Befehls auf der Ebene vsh_lc in einen Front-Port übersetzt werden:
show platform internal hal l2 port gpd
2. Im nächsten Schritt des Datenflusses muss der Spine-Switch erreicht werden, um die MAC-Zieladresse dem PBR-Knoten zuzuordnen. Da der Datenverkehr in VXLAN-Headern gekapselt ist, muss zur Ausführung von ELAM auf einem Spine- oder Remote-Leaf in Select 14 verwendet werden, um die Kapselung ordnungsgemäß zu dekodieren.
SPINE1001# vsh_lc
module-1# debug platform internal roc elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 14 out-selec 0
module-1(DBG-elam-insel14)# reset
module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.10.100.10 dst_ip 10.20.200.20
module-1(DBG-elam-insel14)# start
module-1(DBG-elam-insel14)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Armed
Asic 0 Slice 2 Status Triggered
Asic 0 Slice 3 Status Armed
module-1(DBG-elam-insel14)# ereport
======================================================================================================
Trigger/Basic Information
======================================================================================================
Incoming Interface : 0x48( 0x48 ) >>> Eth1/1
( Slice Source ID(Ss) in "show plat int hal l2 port gpd" )
Packet from vPC peer LEAF : yes
Packet from tunnel (remote leaf/avs) : yes
-------------------------------------------------------------------------------------------------------
Outer L2 Header
-------------------------------------------------------------------------------------------------------
Destination MAC : 000D.0D0D.0D0D
Source MAC : 000C.0C0C.0C0C
-------------------------------------------------------------------------------------------------------
Inner L2 Header
-------------------------------------------------------------------------------------------------------
Inner Destination MAC : 0050.56B7.D05D >>> Firewall MAC
Source MAC : AAAA.AAAA.AAAA
-------------------------------------------------------------------------------------------------------
Outer L3 Header
-------------------------------------------------------------------------------------------------------
L3 Type : IPv4
DSCP : 0
Don't Fragment Bit : 0x0
TTL : 32
IP Protocol Number : UDP
Destination IP : 10.2.64.97
Source IP : 10.2.200.64
-------------------------------------------------------------------------------------------------------
Inner L3 Header
-------------------------------------------------------------------------------------------------------
L3 Type : IPv4
DSCP : 0
Don't Fragment Bit : 0x1
TTL : 63
IP Protocol Number : ICMP
Destination IP : 10.20.200.20
Source IP : 10.10.100.10
-------------------------------------------------------------------------------------------------------
Outer L4 Header
-------------------------------------------------------------------------------------------------------
L4 Type : iVxLAN
Don't Learn Bit : 1
Src Policy Applied Bit : 1
Dst Policy Applied Bit : 1
sclass (src pcTag) : 0xc003 >>> pcTag 49155 (Prod-Consumer)
VRF or BD VNID : 15826939( 0xF17FFB ) >>> BD: Prod-Consumer
-------------------------------------------------------------------------------------------------------
Sideband Information
-------------------------------------------------------------------------------------------------------
Opcode : OPCODE_UC
-------------------------------------------------------------------------------------------------------
bky_elam_out_sidebnd_no_spare_vec.ovector_idx: 0x1F0 >>> Eth1/10
-------------------------------------------------------------------------------------------------------
Aus der vorherigen Ausgabe geht hervor, dass die Ziel-MAC-Adresse in die MAC-Adresse der Firewall neu geschrieben wird. Anschließend wird eine COOP-Suche durchgeführt, um den Ziel-Publisher der MAC-Adresse zu identifizieren, und das Paket wird dann an die entsprechende Schnittstelle des Switches weitergeleitet.
Sie können diese Suche auf dem Spine simulieren, indem Sie diesen Befehl ausführen und die Bridge-Domänen-VNID und die MAC-Adresse der Firewall verwenden:
SPINE1001# show coop internal info repo ep key 15826939 0050.56B7.D05D | egrep "Tunnel|EP" | head -n 3
EP bd vnid : 15826939
EP mac : 00:50:56:B7:D0:5D
Tunnel nh : 10.2.200.66
SPINE1001#
3. Der Datenverkehr erreicht das Service-Leaf, auf dem die MAC-Adresse der Firewall erkannt und anschließend an den PBR-Knoten weitergeleitet wird.
MXS2-LF101# vsh_lc
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)# reset
module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.10.100.10 dst_ip 10.20.200.20
module-1(DBG-elam-insel14)# start
module-1(DBG-elam-insel14)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Triggered
module-1(DBG-elam-insel14)# ereport
======================================================================================================
Trigger/Basic Information
======================================================================================================
Incoming Interface : 0x0( 0x0 ) >>> Eth1/17
( Slice Source ID(Ss) in "show plat int hal l2 port gpd" )
Packet from vPC peer LEAF : yes
Packet from tunnel (remote leaf/avs) : yes
-------------------------------------------------------------------------------------------------------
Outer L2 Header
-------------------------------------------------------------------------------------------------------
Destination MAC : 000D.0D0D.0D0D
Source MAC : 000C.0C0C.0C0C
-------------------------------------------------------------------------------------------------------
Inner L2 Header
-------------------------------------------------------------------------------------------------------
Inner Destination MAC : 0050.56B7.D05D >>> Firewall MAC
Source MAC : AAAA.AAAA.AAAA
-------------------------------------------------------------------------------------------------------
Outer L3 Header
-------------------------------------------------------------------------------------------------------
L3 Type : IPv4
DSCP : 0
Don't Fragment Bit : 0x0
TTL : 32
IP Protocol Number : UDP
Destination IP : 10.2.200.66
Source IP : 10.2.200.64
-------------------------------------------------------------------------------------------------------
Inner L3 Header
-------------------------------------------------------------------------------------------------------
L3 Type : IPv4
DSCP : 0
Don't Fragment Bit : 0x1
TTL : 63
IP Protocol Number : ICMP
Destination IP : 10.20.200.20
Source IP : 10.10.100.10
-------------------------------------------------------------------------------------------------------
Outer L4 Header
-------------------------------------------------------------------------------------------------------
L4 Type : iVxLAN
Don't Learn Bit : 1
Src Policy Applied Bit : 1
Dst Policy Applied Bit : 1
sclass (src pcTag) : 0xc003 >>> pcTag 49155 (Prod-Consumer)
VRF or BD VNID : 15826939( 0xF17FFB ) >>> BD: Prod-Consumer
-------------------------------------------------------------------------------------------------------
Contract Lookup Key
-------------------------------------------------------------------------------------------------------
IP Protocol : ICMP( 0x1 )
L4 Src Port : 2048( 0x800 )
L4 Dst Port : 50664( 0xC5E8 )
sclass (src pcTag) : 49155( 0xC003 ) >>> Prod-Consumer EPG
dclass (dst pcTag) : 16387( 0x4003 ) >>> Consumer connector EPG
src pcTag is from local table : no
derived from group-id in iVxLAN header of incoming packet
Unknown Unicast / Flood Packet : no
If yes, Contract is not applied here because it is flooded
-------------------------------------------------------------------------------------------------------
Sideband Information
-------------------------------------------------------------------------------------------------------
ovector : 64( 0x40 ) >>> Eth1/45
Ovec in "show plat int hal l2 port gpd"
Opcode : OPCODE_UC
4. Für den vom PBR-Knoten zurückgegebenen Packer muss dieser zunächst seine eigene Sorgfalt walten lassen und die VRF-Instanz, die Schnittstelle oder das VLAN ändern. Das Paket wird dann an die ACI am Provider Connector zurückgeleitet:
LEAF103# vsh_lc
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)# reset
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.10.100.10 dst_ip 10.20.200.20
module-1(DBG-elam-insel6)# set outer l2 src_mac 0050.56b7.bf94
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# stat
ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
Asic 0 Slice 1 Status Armed
module-1(DBG-elam-insel6)# ereport
======================================================================================================
Trigger/Basic Information
======================================================================================================
•••
Incoming Interface : 0x40( 0x40 ) >>> Eth1/45
•••
-------------------------------------------------------------------------------------------------------
Outer L2 Header
-------------------------------------------------------------------------------------------------------
Destination MAC : 0022.BDF8.19FF
Source MAC : 0050.56B7.BF94
802.1Q tag is valid : yes( 0x1 )
CoS : 0( 0x0 )
Access Encap VLAN : 2006( 0x7D6 )
-------------------------------------------------------------------------------------------------------
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 : set
TTL : 62
IP Protocol Number : ICMP
IP CheckSum : 46178( 0xB462 )
Destination IP : 10.20.200.20
Source IP : 10.10.100.10
-------------------------------------------------------------------------------------------------------
Contract Lookup Key
-------------------------------------------------------------------------------------------------------
IP Protocol : ICMP( 0x1 )
L4 Src Port : 2048( 0x800 )
L4 Dst Port : 37489( 0x9271 )
sclass (src pcTag) : 49157( 0xC005 ) >>> Provider connector EPG
dclass (dst pcTag) : 49156( 0xC004 ) >>> Prod-Provider EPG
src pcTag is from local table : yes
derived from a local table on this node by the lookup of src IP or MAC
Unknown Unicast / Flood Packet : no
If yes, Contract is not applied here because it is flooded
-------------------------------------------------------------------------------------------------------
Sideband Information
-------------------------------------------------------------------------------------------------------
ovector : 176( 0xB0 ) >>> Eth1/52
Ovec in "show plat int hal l2 port gpd"
Opcode : OPCODE_UC
-------------------------------------------------------------------------------------------------------
sug_luc_latch_results_vec.luc3_0.service_redir: 0x0
-------------------------------------------------------------------------------------------------------
5. Der verbleibende Netzwerkverkehr entspricht den bisher beschriebenen etablierten Schritten, bei denen Pakete an die Spine-Switches zurückgeleitet werden, um das endgültige Serverziel auf Basis der Coop-Suche zu bestimmen. Anschließend werden Pakete an den Rechner-Leaf-Switch weitergeleitet, der das lokale Lern-Flag hat, und diese Informationen an die COOP-Tabelle auf den Spines weitergegeben. Die ELAM-Ausführung für die Schritte 2 und 3 ist für die Verteilung des Pakets an sein endgültiges Ziel konsistent. Um eine korrekte Übermittlung zu gewährleisten, müssen diese Angaben auf dem Ziel-EPG-pcTag und der Ausgangsschnittstelle validiert werden.
IP-SLA
IP SLA wird verwendet, um den Betriebsstatus und die Leistung von Netzwerkpfaden zu bewerten. Auf diese Weise wird sichergestellt, dass der Datenverkehr entsprechend der definierten Richtlinien und auf Basis der Netzwerkbedingungen in Echtzeit effizient geroutet wird. Bei der ACI nutzt das PBR IP SLA, um fundierte Routing-Entscheidungen zu treffen. Wenn die IP SLA-Kennzahlen erkennen lassen, dass ein Pfad zu langsam ist, kann das PBR den Datenverkehr über alternative Pfade umleiten, die die erforderlichen Leistungskriterien erfüllen.
Ab Version 5.2(1) können Sie die dynamische MAC-Nachverfolgung für IP SLA aktivieren. Dies ist nützlich für Szenarien, in denen ein PBR-Knoten ausfällt und die MAC-Adresse für dieselbe IP-Adresse ändert. In statischen Bereitstellungen muss eine Änderung der Policy-Based Redirect-Richtlinie jedes Mal vorgenommen werden, wenn der PBR-Knoten seine MAC-Adresse ändert, um weiterhin Datenverkehr zu senden. Bei IP SLA wird die in dieser Richtlinie verwendete MAC-Adresse an die Antwort des Diagnosetests weitergeleitet. Verschiedene Tests können verwendet werden, um festzustellen, ob der PBR-Knoten fehlerfrei ist. Zum Zeitpunkt der Erstellung dieses Dokuments sind dies: ICMP, TCP, L2Ping und HTTP.
Die allgemeine Konfiguration einer IP SLA-Richtlinie muss wie folgt aussehen:
Die IP SLA-Richtlinie muss mithilfe einer Integritätsgruppe der PBR-Knoten-IP zugeordnet werden.
Wenn ein IP SLA zur dynamischen Erkennung der MAC-Adresse verwendet wird, darf dieses Feld nicht leer sein, sondern muss auf 0 gesetzt werden:
Sobald eine Integritätsgruppe über das L3-Ziel in der L4-L7 Policy Based Redirect-Richtlinie eine Verbindung mit der PBR-Knoten-IP herstellt, legen Sie Grenzwerte fest, um das IP SLA-Verhalten bei Unerreichbarkeit zu definieren. Geben Sie eine Mindestanzahl aktiver L3-Ziele an, die zur Aufrechterhaltung der Umleitung erforderlich sind. Wenn die Anzahl der aktiven PBR-Knoten unter oder über dem Schwellenwert-Prozentsatz liegt, ist die gesamte Gruppe von der ausgewählten Aktion "Schwellenwert herunterfahren" betroffen, wodurch die Neuverteilung gestoppt wird. Dieser Ansatz unterstützt die Umgehung des PBR-Knotens während der Fehlerbehebung, ohne den Datenverkehrsfluss zu beeinträchtigen.
Integritätsgruppen binden alle IPs, die in L3-Zielen einer einzelnen L4-L7-Policy Base-Umleitungsrichtlinie oder mehreren L4-L7-Policy Base-Umleitungsrichtlinien definiert sind, zusammen, solange dieselbe Health Group-Richtlinie verwendet wird.
Leaf101# show service redir info health-group aperezos::tz-HG
===============================================================================================================================================================
LEGEND
TL: Threshold(Low) | TH: Threshold(High) | HP: HashProfile | HG: HealthGrp | BAC: Backup-Dest | TRA: Tracking | RES: Resiliency | W: Weight
===============================================================================================================================================================
HG-Name HG-OperSt HG-Dest HG-Dest-OperSt
======= ========= ======= ==============
aperezos::tz-HG enabled dest-[192.168.100.10]-[vxlan-2162692]] up
dest-[192.168.200.20]-[vxlan-2162692]] up
Leaf1011#
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
17-Sep-2025
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)