Fehlerbehebung bei L3Out-Subnetzklassifizierung in der ACI

Einleitung

Dieses Dokument beschreibt die Klassifizierung externer Subnetze innerhalb der L3Out-EPGs der Cisco ACI.

Abkürzungen

• BD: Bridge-Domäne
• EPG: Endpunktgruppe
• ExEPG: Externe Endpunktgruppe
• RIB: Routing Information Base
• VRF: Virtual Routing and Forwarding
• Klassen-ID: Tag, das eine EPG identifiziert

Externe EPG-Klassifizierung

Eine externe EPG in der Cisco ACI repräsentiert externe Netzwerke, die über L3Outs verbunden sind. Ähnlich wie eine reguläre EPG Endpunkte klassifiziert, klassifiziert eine externe EPG externe Subnetze auf VRF-Basis, d. h. jedes Subnetz muss innerhalb seines VRF-Kontexts eindeutig sein.

Ein weit verbreiteter Irrtum besteht darin, dass ein externes EPG-Subnetz nur Präfixe enthält, die über das dynamische Routing-Protokoll akzeptiert werden. Wenn jedoch ein L3Out erstellt wird, gibt es eine Standardroute-Map, die eingehende Ankündigungen filtert. Daher werden alle vom dynamischen Routing-Protokoll angekündigten Präfixe standardmäßig akzeptiert. Der Hauptzweck der Definition von Subnetzen unter einer ExEPG besteht in der Klassifizierung, nur um den in der ExEPG enthaltenen Subnetzen zur Vertragsdurchsetzung und Richtlinienanwendung ein eindeutiges pcTag zuzuweisen.

Diese Klassifizierung ermöglicht eine präzise Richtlinienkontrolle. So kann beispielsweise ein einzelner externer Nachbar der ACI ein Supernet ankündigen, das dann in mehrere ExEPGs segmentiert werden kann. Auf diese Weise können verschiedene Vertragsaktionen auf verschiedene Subnetze angewendet werden, z. B. indem bestimmte interne EPGs nur mit bestimmten externen Subnetzen kommunizieren können oder indem für bestimmte Präfixe vorgesehener Datenverkehr an einen PBR-Knoten umgeleitet wird, bevor er sein endgültiges Ziel erreicht.

Dieses Diagramm zeigt, wie die Cisco ACI externe Subnetze anhand externer EPGs klassifiziert, um eine präzise Segmentierung des Datenverkehrs und die Durchsetzung von Verträgen zu ermöglichen.

Externe EPG-Subnetzkennzeichen

Um externe Präfixe innerhalb einer ExEPG in der ACI zu klassifizieren und zu verwalten, werden beim Erstellen eines Subnetzpräfixes unter einer ExEPG spezifische Subnetzflags konfiguriert. In diesem Abschnitt werden die einzelnen Flaggen und ihre beabsichtigte Verwendung beschrieben:

• Externes Subnetz für externe EPG:
  Dieses Flag gibt an, dass sich das Subnetz außerhalb der ACI-Fabric befindet und nicht in einer Bridge-Domäne oder EPG konfiguriert ist. Sie darf nur verwendet werden, wenn das Präfix entweder von einem Routing-Nachbarn angekündigt oder statisch in die RIB eingespeist wird. Dieses Flag ist standardmäßig aktiviert.

• Subnetz für die Routensteuerung exportieren:
  Dieses Flag gibt an, dass das Subnetz dem Routing-Nachbarn über das dynamische Routing-Protokoll von der ACI angekündigt wird. Sie darf nicht gleichzeitig mit dem Flag External Subnet for External EPG aktiviert werden, da dies zu Layer-3-Routing-Schleifen führen kann. Da das Subnetz von der ACI als extern klassifiziert und auch zurückgemeldet wird, kann es trotz Mechanismen zur Vermeidung von Loops in Routing-Protokollen zu Routing-Inkonsistenzen kommen.

• Subnetz für gemeinsame Routensteuerung:
  Dieses Flag wird gesetzt, wenn das Subnetz-Präfix für mehrere VRFs gemeinsam genutzt werden soll, um ein Route Leaking zwischen den Kontexten zu ermöglichen.

• Subnetz für gemeinsamen Sicherheitsimport:
  In Verbindung mit dem Shared Route Control Subnet-Flag ermöglicht dies die gemeinsame Nutzung von Sicherheits-PC-Tags für externe Subnetze in verschiedenen VRFs und somit die konsistente Durchsetzung von Richtlinien.

• Subnetz für die Routensteuerung importieren:
  Dieses Flag ermöglicht eine präzise Kontrolle der Präfixe, die von Routing-Nachbarn empfangen werden. Standardmäßig akzeptiert die ACI alle eingehenden Routenankündigungen. Zum Aktivieren dieses Flags muss die Routenkontrollerzwingung aktiviert werden, um eingehende Präfixe zu filtern.

• Aggregierter Abschnitt:
  Dieser Abschnitt gilt nur für das Subnetz Quad-0 (0.0.0.0/0) und fasst alle Präfixe in der RIB für den Export oder Import zusammen. Werden Subnetze an andere VRFs weitergeleitet, werden sie als aggregierte gemeinsam genutzte Routen zusammengefasst, um Routing-Tabellen zu optimieren.

Befehle für Verifizierung und Fehlerbehebung

Routing

Die Route muss zunächst in der Routing-Tabelle der VRF-Instanz der Border Leaf-Switches vorhanden sein. Dieser Befehl zeigt beispielsweise eine BGP-Route in der VRF-Instanz tz:tz-VRF_1 an:

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

172.16.1.0/24, ubest/mbest: 1/0
*via 10.10.1.2%tz:tz-VRF_1, [20/0], 00:00:04, bgp-65002, external, tag 65003
Leaf101#

Damit wird bestätigt, dass die Route in der VRF-Routing-Tabelle installiert ist und für Weiterleitungsentscheidungen zur Verfügung steht.

Klassifizierung

Wenn die Route in der Routing-Tabelle vorhanden ist, bestimmt die Klassifizierung richtlinienbasiert, wie der Datenverkehr behandelt wird. In der ACI ist die Klassifizierung mit der ExEPG und den zugehörigen Subnetzen verknüpft.

Zur Validierung der Subnetzklassifizierung unter einer ExEPG kann der APIC nach der l3extInstP-Klasse abgefragt werden, die die externe EPG-Instanz darstellt. Ihre untergeordnete Klasse l3extSubnet listet die unter dieser ExEPG konfigurierten Subnetze auf. Beispiele:

moquery -c l3extInstP -f 'l3ext.InstP.dn*"[ tenant name ].*[ l3out name ]"' -x rsp-subtree=children rsp-subtree-class=l3extSubnet

APIC# moquery -c l3extInstP -f 'l3ext.InstP.dn*"tz.*l3out"' -x rsp-subtree=children rsp-subtree-class=l3extSubnet 
Total Objects shown: 1

# l3ext.InstP
name : tz-ExEPG_1
!-- cut for brevity --!
configSt : applied
descr : 
dn : uni/tn-tz/out-l3out/instP-tz-ExEPG_1
!-- cut for brevity --!
floodOnEncap : disabled
isSharedSrvMsiteEPg : no
lcOwn : local
matchT : AtleastOne
mcast : no
modTs : 2025-09-10T00:36:49.239+00:00
monPolDn : uni/tn-common/monepg-default
nameAlias : 
pcEnfPref : unenforced
pcTag : 32771
pcTagAllocSrc : idmanager
prefGrMemb : exclude
prio : unspecified
rn : instP-tz-ExEPG_1
scope : 3047430
status : modified
targetDscp : unspecified
triggerSt : triggerable
txId : 1152921504612318828
uid : 15374
userdom : :all:

# l3ext.Subnet
ip : 172.16.1.0/24
!-- cut for brevity --!
dn : uni/tn-tz/out-l3out/instP-tz-ExEPG_1/extsubnet-[172.16.1.0/24]
extMngdBy : 
lcOwn : local
modTs : 2025-09-10T01:05:13.249+00:00
monPolDn : uni/tn-common/monepg-default
!-- cut for brevity --!
rn : extsubnet-[172.16.1.0/24]
scope : import-security
status : 
uid : 15374
userdom : :all:

APIC#

Wenn keine Ausgabe für die l3extSubnet-Klasse zurückgegeben wird, bedeutet dies, dass keine Subnetze unter der externen EPG konfiguriert sind. Ohne konfigurierte Subnetze kann die ACI dem Subnetz für eingehenden Datenverkehr kein pcTag zuordnen. Der Datenverkehr wird daher trotz der in der Routing-Tabelle vorhandenen Route verworfen.

Ein weiterer wichtiger Aspekt ist der Umfang des Subnetzes. Hierbei handelt es sich um die für das betreffende Subnetz festgelegten Flags:

• Import-Sicherheit

Das Subnetz wurde mit dem externen Subnetz für die externe EPG markiert.

• export-rtctrl

Das Subnetz wurde mit "Export Route Control" (Routenkontrolle exportieren) markiert.

• import-rtctrl

Das Subnetz wurde mit Import Route Control (Routensteuerung importieren) markiert.

• Shared-Security

Das Subnetz wurde mit "Shared Security Import Subnet" markiert.

• shared-rtctrl

Das Subnetz wurde mit Shared Route Control markiert.

Die Routing-Protokolle und die Prozesse auf der Kontrollebene aktualisieren die Routing-Tabellen beim Empfang eines Präfix von einem erwähnten Nachbarn, die dann in die HAL L3-Weiterleitungstabellen programmiert werden. Die HAL L3-Routen repräsentieren die tatsächlichen Layer 3-Routen, die in die Hardware Forwarding Tables (ASICs) der Leaf-Switches programmiert wurden. Diese Routen werden von den Routing-Protokollen und den Berechnungen der Routing-Tabelle abgeleitet und für Weiterleitungsentscheidungen verwendet.

<-- When the prefix is not configured under the External EPG, a classification of 0xf is seen -->
Leaf101# vsh_lc -c 'show platform internal hal l3 routes vrf tz:tz-VRF_1' | egrep "Prefix/Len|172.16.1.0" | cut -d '|' -f 2,3,4,19,24 
VRF |   Prefix/Len  | RT|CLSS| Flags 
4675| 172.16.1.0/ 24| UC| f|spi,dpi
Leaf101# 

<-- When the prefix is configured under the External EPG, a classification of the pcTag in hexadecimal is seen -->
Leaf101# vsh_lc -c 'show platform internal hal l3 routes vrf tz:tz-VRF_1' | egrep "Prefix/Len|172.16.1.0" | cut -d '|' -f 2,3,4,19,24 
VRF |   Prefix/Len  | RT|CLSS| Flags 
4675| 172.16.1.0/ 24| UC|8003|spi,dpi
Leaf101# 

Leaf101# vsh_lc -c 'dec 0x8003'
32771
Leaf101#

Wenn anschließend ein Subnetz mit dem externen Subnetz für externe EPG-Flag in einer ExEPG konfiguriert wird, aktualisiert ein interner Prozess namens Policy Manager (policy-mgr) seine Prefix-to-pcTag-Zuordnungstabelle mit diesem Subnetzeintrag und dem zugehörigen pcTag. Der Policy Manager fungiert als zentrale Orchestrierungs-Engine für Fabric-Richtlinien, die allgemeine Richtliniendefinitionen in umsetzbare Konfigurationen in der gesamten ACI-Fabric übersetzt. Dadurch wird eine konsistente und sichere Anwendungskonnektivität und ein sicheres Netzwerkverhalten gewährleistet, indem die richtigen pcTags für die Klassifizierung des Datenverkehrs und Weiterleitungsentscheidungen basierend auf den konfigurierten externen Subnetzen durchgesetzt werden.

Leaf101# vsh -c 'show system internal policy-mgr prefix' | egrep "tz:tz-VRF_1"
3047430 36 0x80000024 Up tz:tz-VRF_1 ::/0 15 True True False False 
3047430 36 0x24 Up tz:tz-VRF_1 0.0.0.0/0 15 True True False False 
3047430 36 0x24 Up tz:tz-VRF_1 172.16.1.0/24 32771 True True False False 
Leaf101# 

Dies bestätigt, dass das Präfix 172.16.1.0/24 vom Nachbarn für den ACI Border Leaf-Switch angekündigt wird, und dass die ACI das Präfix wie folgt klassifiziert hat: pcTag 32771

Verträge

Eine Zoning-Regel ist der zugrunde liegende Prozess, der Vertragsrichtlinien zwischen EPGs (einschließlich ExEPGs) innerhalb der Fabric durchsetzt. Die VRF-VNID (Scope) und das pcTag der externen EPG können zum Definieren und Validieren der Kommunikationsregeln zwischen Quell- und Ziel-EPGs verwendet werden. Im Wesentlichen werden durch Zoning-Regeln allgemeine Vertragsbeziehungen in spezifische, durchsetzbare Regeln übersetzt, die auf den Leaf-Switches programmiert sind.

Ein wichtiger zu berücksichtigender Aspekt ist die Frage, wo der Vertrag in der Fabric installiert wird. Standardmäßig ist für die VRF-Instanz die Richtliniendurchsetzungsrichtung "Eingang" festgelegt. Diese Einstellung legt fest, dass die Zoning-Regel für einen bestimmten Vertrag auf dem Leaf-Switch installiert wird, auf dem sich der Quellendpunkt befindet.

Bei dieser Übung geht Datenverkehr von einem L3Out ein. Die Zoning-Regel wird auf dem Grenz-Leaf installiert, der mit diesem L3Out verbunden ist, da dieser Leaf als Quell-Leaf für den Datenverkehr fungiert, der in die Fabric eingeht.

Leaf101# show zoning-rule scope 3047430 | egrep "Rule|---|32771"
+---------+--------+--------+----------+----------------+---------+---------+-------------------+----------------------+------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       | operSt  |  Scope  |        Name       |        Action        |        Priority        |
+---------+--------+--------+----------+----------------+---------+---------+-------------------+----------------------+------------------------+
|  4441   | 49153  | 32771  |     5    |     bi-dir     | enabled | 3047430 |     tz:Contract   |        permit        |      fully_qual(7)     |
|  4500   | 32771  | 49153  |     5    | uni-dir-ignore | enabled | 3047430 |     tz:Contract   |        permit        |      fully_qual(7)     |
+---------+--------+--------+----------+----------------+---------+---------+-------------------+----------------------+------------------------+
Leaf101# 

Transit-Routing

Beim Transit-Routing kann die Fabric als Transit-Netzwerk fungieren, indem externe Routen angekündigt werden, die von einem L3Out zu einem anderen L3Out übertragen wurden. Um das Transit-Routing richtig zu konfigurieren, muss das eingehende Subnetz mit dem Flag Externes Subnetz für externe EPG markiert werden.

Gleichzeitig muss auf dem L3Out, das dieses Subnetz anderen externen Peers ankündigt, die Subnetzmarkierung "Route Control exportieren" für das entsprechende Subnetz aktiviert sein. Mit diesem Flag kann das Subnetz neu verteilt und über das für dieses L3Out konfigurierte Routing-Protokoll außerhalb der Fabric angekündigt werden.

Schließlich muss ein Vertrag zwischen dem empfangenen und dem exportierenden L3out konfiguriert werden, um die Verteilung der Route abzuschließen.

Häufige Probleme bei der externen Subnetz-EPG-Klassifizierung

pcTag 15

In diesem Dokument wurde bereits erwähnt, dass das ExEPG-Subnetz Ihnen aus Gründen der Richtliniendurchsetzung bei der Klassifizierung der Subnetze im richtigen pcTag hilft. Eine wichtige Ausnahme von dieser Klassifizierung ist das Quad-0-Subnetz (0.0.0.0/0), wenn es mit dem externen Subnetz für externe EPG-Flag konfiguriert ist. Diesem Subnetz wird immer der reservierte pcTag 15 zugewiesen, der quasi als Platzhalter für den gesamten externen Datenverkehr innerhalb einer VRF-Instanz fungiert.

Dieses Diagramm zeigt das Problem bei der Konfiguration von Quad-0 mit externem Subnetz für externe EPGs auf mehreren ExEPGs innerhalb derselben VRF-Instanz:

• Das Quad-0-Subnetz wird oft mit der Standardroute verwechselt. Dies trifft manchmal zu, z. B. wenn ein dynamischer Routing-Nachbar der ACI L3Out nur die Standardroute ankündigt. Die Rolle des Quad-0-Subnetzes in der ACI ist jedoch als catch-all-Klassifizierung weiter gefasst.
• Es ist gängige Praxis, mehrere ExEPGs mit dem Quad-0-Subnetz zu konfigurieren, um alle von einem Nachbarn angekündigten Präfixe zu akzeptieren. Obwohl dadurch das Ziel einer breiten Akzeptanz erreicht wird, kann es zu unerwartetem asymmetrischem Routing führen, wenn mehrere ExEPGs mit Quad-0 innerhalb derselben VRF-Instanz konfiguriert werden. Wenn mehrere ExEPGs innerhalb derselben VRF-Instanz mit Quad-0 als externem Subnetz konfiguriert werden, kann die ACI nicht deterministisch auswählen, welches L3Out für ein bestimmtes Ziel-Subnetz verwendet werden soll. Stattdessen wird ein L3Out beliebig ausgewählt.
• Dieses Verhalten kann zu asymmetrischem Routing, unterbrochenem Datenverkehr oder sogar zum Verwerfen von Datenverkehr führen, wenn das nach dem Zufallsprinzip ausgewählte L3Out nicht über die erforderlichen Verträge für die Kommunikation verfügt.

Überlappende Subnetze

Die Konfiguration identischer Subnetze über verschiedene ExEPGs ist nicht zulässig. Der Versuch löst den Fehler "F0467: Prefix Entry Already Used in Another EPG" (Präfixeintrag wird bereits in einer anderen EPG verwendet) und verhindert Subnetzduplizierung innerhalb einer VRF-Instanz.

Überlappende Subnetze können jedoch in verschiedenen VRFs vorhanden sein, da jede VRF-Instanz einen unabhängigen Kontext für die Routing-Tabelle aufrechterhält. Durch diese Trennung kann dasselbe Subnetz in ExEPGs konfiguriert werden, die zu verschiedenen VRFs gehören. Dennoch ist Vorsicht geboten, wenn VRF-Route-Leaking mit diesen überlappenden Subnetzen durchgeführt wird, da dies zu asymmetrischen Weiterleitungsentscheidungen aufgrund von Konflikten bei der Subnetzklassifizierung (pcTag) im Vergleich zu Routing-Informationen (RIB) führen kann.

Zu den wichtigsten Szenarien gehören:

• Route Leaking von zwei VRFs in eine dritte VRF:
  Wenn zwei VRF-Instanzen dasselbe Subnetz in eine dritte VRF-Instanz übergeben, installiert die empfangende VRF-Instanz das erste Subnetz, das sie empfängt, basierend auf der gemeinsam genutzten Richtlinie des APIC. Wenn der Leaf-Switch, der diese VRF-Instanz verarbeitet, neu startet oder sich die Routing-Auswahl ändert, kann die Routing-Tabelle auf ein anderes L3Out aktualisiert werden, was zu inkonsistentem Weiterleitungsverhalten führt.

• L3Out ExEPG von Local zu VRF, überlappend mit undichten Subnetzen:
  Bei Designs, bei denen ein Route Leaking verwendet wird, hat ein lokales L3Out ExEPG, wenn es mit demselben Subnetz konfiguriert ist wie ein ausgelaufenes Subnetz, immer der lokale Routing-Eintrag Vorrang vor den ausgelaufenen Routen.

Diese Situationen zeigen, dass die asymmetrischen Weiterleitungsprobleme auf der Entscheidungsebene für die Klassifizierung und Weiterleitung beruhen und nicht auf der Routingtabelle selbst. Während die Subnetzklassifizierung ein Subnetz einem bestimmten L3Out und ExEPG zur Richtliniendurchsetzung zuordnet, kann die Routing-Tabelle auf ein anderes L3Out-Ziel verweisen. Diese Diskrepanz kann dazu führen, dass Datenverkehr inkonsistent weitergeleitet wird, was zu Verbindungsproblemen oder Lücken bei der Richtliniendurchsetzung führen kann.

Änderung des Standardverhaltens der Routensteuerung importieren

Standardmäßig akzeptiert die ACI alle eingehenden Routenankündigungen von Nachbarn. Um zu steuern, welche Präfixe akzeptiert werden, müssen Sie die Durchsetzung der Routenkontrolle aktivieren: Eingehend auf dem L3Out-Stammobjekt:

Navigieren Sie zu Tenants > [ Tenant-Name ] > Networking > L3outs > [ L3out-Name ] .

Durch diese Aktion wird eine Route Map unter dem ausgewählten Routing-Protokoll erstellt.

Border Leaf# show ip bgp neighbors vrf tz:tz-VRF1 | egrep route-map
Outbound route-map configured is exp-l3out-ExEPG-peer-2981888, handle obtained
Inbound route-map configured is imp-l3out-ExEPG-peer-2981888, handle obtained

Border Leaf# show route-map imp-l3out-ExEPG-peer-2981888
route-map imp-l3out-ExEPG-peer-2981888, permit, sequence 15801 
Match clauses:
ip address prefix-lists: IPv4-peer49155-2981888-exc-ext-inferred-import-dst 
ipv6 address prefix-lists: IPv6-deny-all 
Set clauses:

Border Leaf# show ip prefix-list IPv4-peer49155-2981888-exc-ext-inferred-import-dst 
ip prefix-list IPv4-peer49155-2981888-exc-ext-inferred-import-dst: 1 entries
seq 1 permit 172.16.1.0/24 
Border Leaf# 

Diese Import-Route-Map lässt standardmäßig alle eingehenden Präfixe zu. So ändern Sie dieses Verhalten:

Navigieren Sie zu Tenants > [ Tenant-Name ] > Networking > L3outs > [ L3out-Name ] > Routenübersicht für die Import- und Exportroutensteuerung.

Wählen Sie die Standard-Import-Route-Map aus, oder erstellen Sie eine neue Route über das Zahnrad-Symbol oben rechts.

Erstellen Sie im Abschnitt Kontext eine neue zugeordnete zugeordnete zugeordnete Regel.

Navigieren Sie im Abschnitt Match Rules zu Match Prefix, und fügen Sie die Subnetze hinzu, die Sie steuern möchten.

Nach dem Senden der Richtlinien ändert sich die Aktion "route-map importieren" entsprechend, und die gewünschte Präfixfilterung wird erzwungen.

Border Leaf# show route-map imp-l3out-ExEPG-peer-2981888
route-map imp-l3out-ExEPG-peer-2981888, deny, sequence 8001 
Match clauses:
ip address prefix-lists: IPv4-peer49155-2981888-exc-ext-in-default-import2tz0tz-dst 
ipv6 address prefix-lists: IPv6-deny-all 
Set clauses:

Border Leaf#