Probleemoplossing voor ACI op beleid gebaseerde omleiding

Inleiding

Dit document beschrijft stappen om een ACI-scenario (PBR) op basis van beleid te begrijpen en problemen op te lossen.

Achtergrondinformatie

Het materiaal van dit document is afgeleid uit het boek Problemen oplossen van Cisco Application Centric Infrastructure, Second Edition, met name het Policy-Based Redirect - Overview, Policy-Based Redirect - Service Graph Implementation, Policy-Based Redirect - Forwarding en Policy-Based Redirect - Andere hoofdstukken met verkeersstromen.

Beleidsgebaseerde omleiding - Overzicht

Dit hoofdstuk verklaart het oplossen van problemen voor unmanaged mode Service Graph met op beleid gebaseerde Redirect (PBR).

Het volgende is de typische stappen voor probleemoplossing. In dit hoofdstuk wordt uitgelegd hoe u stap 2 en 3 kunt verifiëren, die specifiek zijn voor PBR. Raadpleeg voor stap 1 en 4 de hoofdstukken "Intra-Fabric Forwarding", "Externe Forwarding" en "Beveiligingsbeleid".

1. Controleer het verkeer zonder PBR-servicegrafiek:
   • De eindpunten van de consument en van de leverancier worden geleerd.
   • De eindpunten van de consument en van de leverancier kunnen communiceren.
2. Controleer of de servicegrafiek is geïmplementeerd:
   • Geïmplementeerde grafiekinstanties hebben geen fout.
   • VLAN’s en class ID’s voor serviceknooppunten worden geïmplementeerd.
   • De eindpunten van de serviceknooppunten worden geleerd.
3. Controleer het verzendpad:
   • Het controlebeleid is geprogrammeerd op de bladknooppunten.
   • Leg het verkeer op het serviceknooppunt vast om te bevestigen of het verkeer wordt omgeleid.
   • Leg het verkeer op het ACI-blad vast om te bevestigen of het verkeer na PBR naar de ACI-structuur terugkeert.
4. Controleer of het verkeer op het eindpunt van de consument en de provider aankomt en of het eindpunt het retourverkeer genereert.

Dit document heeft geen betrekking op ontwerp- of configuratieopties. Zie voor deze informatie het "ACI PBR White Paper" op Cisco.com

In dit hoofdstuk impliceren serviceknooppunt en serviceknooppunt het volgende:

• Service-knooppunt — een extern knooppunt waarnaar PBR het verkeer omleidt, zoals een firewall of taakverdeling.
• Serviceblad — een ACI-blad dat is verbonden met een serviceknooppunt.

Implementatie van servicegrafiek voor probleemoplossing

In dit hoofdstuk wordt een voorbeeld van probleemoplossing uitgelegd waarbij geen servicegrafiek wordt geïmplementeerd.

Nadat een beleid voor servicegrafiek is gedefinieerd en op een contractonderwerp is toegepast, moet er een geïmplementeerd grafiekvoorbeeld op de ACI GUI staan. In de onderstaande afbeelding ziet u het scenario voor probleemoplossing waarbij de servicegrafiek niet wordt weergegeven zoals geïmplementeerd.

Service Graph wordt niet weergegeven als een geïmplementeerde grafische instantie.

1. Controleer de configuratiestappen en de fout

De eerste stap van het oplossen van problemen is te controleren de noodzakelijke componenten zijn geconfigureerd zonder enige fout. Er wordt van uitgegaan dat onderstaande algemene configuraties al zijn uitgevoerd:

• VRF en BD’s voor consumenten-EPG, provider-EPG en serviceknooppunt
• De consument en leverancier EPG.
• Het contract en de filters.

Het is de moeite waard om te vermelden dat een EPG voor het serviceknooppunt niet handmatig hoeft te worden gemaakt. Het wordt gemaakt via Service Graph-implementatie.

De stappen voor de servicegrafiek met PBR-configuratie zijn als volgt:

• Maak het L4-L7 apparaat (logisch apparaat).
• Maak de servicegrafiek.
• Maak het PBR beleid.
• Maak het apparaatselectiebeleid.
• Koppel de servicegrafiek aan het contractonderwerp.

2. Controleer de implementatie van een servicegrafiek in de gebruikersinterface

Nadat een servicegrafiek is gekoppeld aan het contractonderwerp, moet voor elk contract met Service Graph een geïmplementeerd grafiekexemplaar worden weergegeven (zie onderstaande afbeelding).

De locatie is 'Huurder > Diensten > L4-L7 > Gebruikte Grafische Instanties'

Geïmplementeerd grafiekexemplaar

Als een geïmplementeerde grafische instantie niet verschijnt, is er iets mis met de contractconfiguratie. De belangrijkste redenen kunnen zijn:

• Het contract heeft geen consument of leverancier EPG.
• De contractant heeft geen filter.
• Het contractwerkingsgebied is VRF alhoewel het voor de communicatie tussen VRF of inter-tenant EPG is.

Als de Service Graph-instantiatie mislukt, worden fouten in de geïmplementeerde graph-instantie verhoogd, wat betekent dat er iets mis is met de configuratie van de Service Graph. De typische die fouten door configuratie worden veroorzaakt zijn de volgende:

F1690: configuratie is ongeldig vanwege fout bij toewijzing van id

Deze fout geeft aan dat het ingesloten VLAN voor het serviceknooppunt niet beschikbaar is. Er is bijvoorbeeld geen beschikbaar dynamisch VLAN in de VLAN-pool die is gekoppeld aan het VMM-domein dat wordt gebruikt in het logische apparaat.

Resolutie: Controleer de VLAN-pool in het domein dat wordt gebruikt voor het logische apparaat. Controleer ingesloten VLAN in de interface van het logische apparaat als het zich in een fysiek domein bevindt. De locaties zijn 'Huurder > Diensten > L4-L7 > Apparaten en Fabric > Toegangsbeleid > Pools > VLAN'.

F1690: Configuratie is ongeldig vanwege geen apparaatcontext gevonden voor LDev

Deze fout geeft aan dat het logische apparaat niet kan worden gevonden voor de Service Graph-rendering. Er is bijvoorbeeld geen beleid voor apparaatselectie dat voor het contract is afgestemd op de servicegrafiek.

Resolutie: Controleer of het selectiebeleid voor apparaten is gedefinieerd. Het Beleid van de Selectie van het apparaat verstrekt een selectiecriterium voor een de dienstapparaat en zijn connectors. De criteria zijn gebaseerd op een contractnaam, een Service Graph-naam en een knooppunt in de Service Graph. De locatie is 'Huurder > Diensten > L4-L7 > Apparaatselectiebeleid'.

Beleid voor apparaatselectie controleren

F1690: configuratie is ongeldig omdat er geen clusterinterface is gevonden

Deze fout geeft aan dat de clusterinterface voor het serviceknooppunt niet kan worden gevonden. De clusterinterface wordt bijvoorbeeld niet gespecificeerd in het beleid voor apparaatselectie.

Resolutie: Controleer of de clusterinterface in het selectiebeleid voor apparaten is gespecificeerd en of de naam van de connector correct is (afbeelding hieronder).

F1690: Configuratie is ongeldig omdat er geen BD is gevonden

Deze fout geeft aan dat de BD voor het serviceknooppunt niet kan worden gevonden. De BD wordt bijvoorbeeld niet gespecificeerd in het beleid voor apparaatselectie.

Resolutie: Controleer de BD in het selectiebeleid voor apparaten is gespecificeerd en de naam van de connector correct is (afbeelding hieronder).

F1690: configuratie is ongeldig vanwege ongeldig beleid voor omleiding van services

Deze fout geeft aan dat het PBR-beleid niet is geselecteerd, ook al is redirect ingeschakeld voor de servicefunctie in de Servicegrafiek.

Resolutie: Selecteer PBR-beleid in het selectiebeleid voor apparaten (afbeelding hieronder).

Logische interfaceconfiguratie in beleid voor apparaatselectie

Doorsturen van PBR voor probleemoplossing

Dit hoofdstuk legt de stappen voor probleemoplossing uit voor het PBR-verzendpad.

1. Controleer VLAN’s worden geïmplementeerd en endpoints worden geleerd op het bladknooppunt

Zodra een servicegrafiek zonder enige fout is geïmplementeerd, worden EPG’s en BD’s voor een serviceknooppunt gemaakt. De onderstaande afbeelding toont waar de ingekapselde VLAN-ID’s en klasse-ID’s van serviceknoopinterfaces (Service EPG’s) moeten worden gevonden. In dit voorbeeld, is de kant van de consument van een firewall klasse-ID 16386 met VLAN-encap 1000 en is de leverancierskant van een firewall klasse-ID 49157 met VLAN-encap 1102.

De locatie is 'Huurder > Diensten > L4-L7 > Geïmplementeerde Grafiek instanties > Functie knooppunten'.

Service-knooppunt

ID voor interfaceklasse-id voor serviceknooppunt

Deze VLAN’s worden geïmplementeerd op de interfaces van de servicelaag waar de serviceknooppunten zijn aangesloten. De plaatsing van VLAN en eindpunt het leren status kunnen worden gecontroleerd door "uitgebreid tonen VLAN"en "tonen eindpunt"op de de dienstbladknoop CLI te gebruiken.

Pod1-Leaf1# show endpoint vrf Prod:VRF1
Legend: 
s - arp              H - vtep             V - vpc-attached     p - peer-aged       
R - peer-attached-rl B - bounce           S - static           M - span            
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr         
L - local            E - shared-service 
+-----------------------------------+---------------+-----------------+--------------+-------------+ 
      VLAN/                           Encap           MAC Address       MAC Info/       Interface 
      Domain                          VLAN            IP Address        IP Info 
+-----------------------------------+---------------+-----------------+--------------+-------------+  
53                                        vlan-1000    0050.56af.3c60 LV                        po1 
Prod:VRF1                                 vlan-1000   192.168.101.100 LV                        po1 
59                                        vlan-1102    0050.56af.1c44 LV                        po1 
Prod:VRF1                                 vlan-1102   192.168.102.100 LV                        po1

Als IP-eindpunten van de serviceknooppunten niet worden geleerd als eindpunten in de ACI-fabric, is het waarschijnlijk dat er een connectiviteits- of configuratieprobleem is tussen het servicelaag en het serviceknooppunt. Controleer de volgende statussen:

• Het serviceknooppunt is verbonden met de juiste bladneerwaartse poort.
  • Als het serviceknooppunt zich in een fysiek domein bevindt, moet de leaf statische path end encap VLAN worden gedefinieerd in het logische apparaat.
  • Als het serviceknooppunt zich in een VMM-domein bevindt, controleer dan of het VMM-domein werkt en of de poortgroep die via Service Graph is gemaakt, correct aan de serviceknooppunt VM is gekoppeld.
• De bladeserverpoort die is aangesloten op het serviceknooppunt of de hypervisor waar de serviceknooppunt VM zich bevindt, is UP.
• Het serviceknooppunt heeft het juiste VLAN- en IP-adres.
• De intermediaire switch tussen het de dienstblad en de de dienstknoop heeft de correcte configuratie van VLAN.

2. Controleer de verwachte verkeerspaden

Als het verkeer van begin tot eind ophoudt met werken zodra PBR is ingeschakeld, zelfs als de serviceknooppunten in de ACI-fabric zijn geleerd, is de volgende stap van probleemoplossing om te controleren wat de verwachte verkeerspaden zijn.

Cijfers 'PBR Forwarding Path Voorbeeld - Consumer to Provider' en 'PBR Forwarding Path Voorbeeld - Provider to Consumer' illustreren een voorbeeld van een doorsturen pad van het invoegen van een firewall met PBR tussen een consumenteneindpunt en een provider-eindpunt. De veronderstelling is dat de eindpunten reeds op bladknooppunten worden geleerd.

PBR-voorbeeld van doorsturen pad - consument naar provider

Opmerking: omdat de bron-MAC niet is gewijzigd in ACI-bladMAC, mag de PBR-knooppunt geen op MAC gebaseerde brondoorgifte gebruiken als het eindpunt voor consumenten en de PBR-knooppunt niet in dezelfde BD staan

PBR-voorbeeld van doorsturen van pad - provider naar consument

Opmerking: Het is vermeldenswaard dat het PBR-beleid wordt afgedwongen op consumenten- of leveranciersblad en wat ACI PBR doet is het herschrijven van de bestemmings-MAC zoals getoond in cijfers 'PBR-doorsturen pad voorbeeld - consument naar provider' en 'PBR-doorsturen pad voorbeeld - provider naar consument'. Het bereiken van de PBR-bestemming MAC gebruikt altijd een spinproxy, zelfs als het broneindpunt en de PBR-bestemming MAC onder hetzelfde blad liggen.

Hoewel de cijfers 'PBR die wegvoorbeeld door:sturen - consument aan leverancier' en 'PBR die wegvoorbeeld door:sturen - leverancier aan consument' een voorbeeld tonen van waar het verkeer zou worden opnieuw gericht, waar het beleid wordt afgedwongen afhankelijk van contractconfiguratie en eindpunt het leren status. De tabel "Waar beleid wordt afgedwongen" vat samen waar beleid wordt afgedwongen één ACI-site. Waar beleid wordt afgedwongen in Multi-Site is anders.

Waar wordt het beleid uitgevoerd?

scenario	VRF-afdwingingsmodus	Consument	Provider	Gedwongen beleid
Intra-VRF	Ingang/uitgang	EPG	EPG	· Als eindpunt van bestemming is aangeleerd: · Als eindpunt van bestemming niet wordt geleerd: uitgangsblad
	Ingress	EPG	L3Out-EPG	Consumentenblad (niet-grensblad)
	Ingress	L3Out-EPG	EPG	Dienstverlenersblad (niet-grensblad)
	uitgang	EPG	L3Out-EPG	Grensblad -> niet-grensverkeer · Als eindpunt van bestemming wordt geleerd: grensblad · Als eindpunt van bestemming niet wordt geleerd: niet-grensblad Buitengrensblad-> grensbladverkeer · Grensblad
	uitgang	L3Out-EPG	EPG
	Ingang/uitgang	L3Out-EPG	L3Out-EPG	Ingress leaf*
Inter-VRF	Ingang/uitgang	EPG	EPG	Consumentenblad
	Ingang/uitgang	EPG	L3Out-EPG	Consumentenblad (niet-grensblad)
	Ingang/uitgang	L3Out-EPG	EPG	Ingress leaf*
	Ingang/uitgang	L3Out-EPG	L3Out-EPG	Ingress leaf*

*Beleidshandhaving wordt toegepast op het eerste blad dat door het pakket wordt geraakt.

Dit zijn voorbeelden:

• Als een extern eindpunt in L3Out EPG in VRF1 probeert om toegang te krijgen tot een eindpunt in Web EPG in VRF1 en VRF1 is geconfigureerd voor de toegangscontrolemodus, wordt verkeer omgeleid door het blad waar het eindpunt in Web EPG zich bevindt, ongeacht de contractrichting.
• Als een eindpunt in het consumentenweb EPG in VRF1 probeert om toegang te krijgen tot een eindpunt in de provider App EPG in VRF1, en de eindpunten worden geleerd op consumenten- en leveranciersbladknooppunten, wordt het verkeer omgeleid door het toegangsblad.
• Als een eindpunt in het consumentenweb EPG in VRF1 probeert toegang te krijgen tot een eindpunt in de provider App EPG in VRF2, wordt het verkeer omgeleid door het consumentenblad waar het eindpunt van de consument zich bevindt, ongeacht de VRF-afdwingingsmodus.

3. Controleer of verkeer wordt omgeleid naar het serviceknooppunt

Zodra het verwachte doorsturen pad duidelijk is, kan ELAM worden gebruikt om te controleren of het verkeer op de switch knooppunten aankomt en de doorsturen beslissing op de switch knooppunten te controleren. Raadpleeg de sectie "Tools" in het hoofdstuk "Intra-Fabric Forwarding" voor instructies over het gebruik van ELAM.

Bijvoorbeeld, om de verkeersstroom in het cijfer "PBR die weg door:sturen voorbeeld - consument aan leverancier"te vinden, kunnen deze worden gevangen om te bevestigen als de consument aan provider verkeer wordt opnieuw gericht.

• Downlink poort op consumentenblad om 1 en 2 te controleren (het verkeer komt aan op het consumentenblad en PBR wordt afgedwongen).
• Fabric-poort op wervelkolomknooppunten om 3 te controleren (Traffic gaat naar wervelkolomproxy).
• Fabric-poort op servicesblad om 4 te controleren (verkeer komt aan op het servicesblad).

Vervolgens kunnen deze worden opgenomen om te bevestigen dat verkeer dat terugkomt van het serviceknooppunt naar de provider gaat.

• Downlink poort op het servicelabel om 5 en 6 te controleren (verkeer komt terug van het serviceknooppunt en is toegestaan).
• Fabric poort op wervelkolom knooppunten om te controleren 7 (Traffic gaat naar provider blad via wervelkolom).
• Fabric poort op provider blad om 8 te controleren (Traffic komt op de service blad en gaat naar de provider endpoint).

Opmerking: Als de klant- en serviceknooppunt onder hetzelfde blad staan, geef dan een interface of bron-MAC op naast de bron/bestemming-IP om ELAM te nemen om 1 of 5 te controleren in het getal 'PBR-doorsturen pad voorbeeld - consument naar provider' specifiek omdat beide dezelfde bron-IP en bestemming-IP gebruiken.

Als de consument naar provider-verkeer wordt omgeleid naar het serviceknooppunt, maar niet terugkeert naar het servicelefblad, controleer dan het volgende omdat het vaak voorkomende fouten zijn:

• De routertabel voor serviceknooppunten bereikt het providersubnetje.
• Beveiligingsbeleid voor serviceknooppunten, zoals ACL, maakt verkeer mogelijk.

Als het verkeer wordt omgeleid en op de provider aankomt, controleer dan op dezelfde manier het retourverkeer van provider naar consument.

4. Controleer het op de bladknooppunten geprogrammeerde beleid

Als er geen verkeer wordt doorgestuurd of doorgestuurd, is de volgende stap voor probleemoplossing om het beleid te controleren dat op de bladknooppunten is geprogrammeerd. Deze paragraaf laat regels voor zonering en contract_parser als voorbeelden zien. Zie voor meer informatie over het controleren van de regels voor indeling in zones de sectie "Tools" in het hoofdstuk "Beveiligingsbeleid".

Opmerking: het beleid is geprogrammeerd op basis van de EPG-implementatiestatus op het blad. De output van het showbevel in deze sectie gebruikt het blad dat consument EPG, leverancier EPG, en EPGs voor het de dienstknooppunt heeft.

Gebruik van de opdracht "show zoning-rule"

Het cijfer en de 'toon zoning-regel'-uitvoer hieronder beschrijft de zonering-regels vóór de implementatie van de servicegrafiek.

VRF scope id kan worden gevonden in 'Huurder > Netwerken > VRF'.

Pod1-Leaf1# show zoning-rule scope 2752513
+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |    Name    |  Action  |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+
|   4237  | 32772  | 32773  |    8     |     bi-dir     | enabled | 2752513 | web-to-app |  permit  |    fully_qual(7)     |
|   4172  | 32773  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 | web-to-app |  permit  |    fully_qual(7)     |
+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+

Zodra de Service Graph is geïmplementeerd, worden EPG’s voor het serviceknooppunt gemaakt en wordt het beleid bijgewerkt om verkeer tussen de consument en de provider-EPG’s om te leiden. In de onderstaande afbeelding en de 'toon zonering-regel'-uitvoer hieronder worden de zoneregels na de implementatie van de servicegrafiek beschreven. In dit voorbeeld wordt het verkeer van pcTag 32772 (Web) naar pcTag 32773 (App) omgeleid naar 'destgrp-27' (consumentenkant van het serviceknooppunt) en het verkeer van pcTag 32773 (App) naar pcTag 32772 (Web) wordt omgeleid naar 'destgrp-28' (leverancierskant van het serviceknooppunt).

Zones-regels na implementatie van Service Graph

Pod1-Leaf1# show zoning-rule scope 2752513 
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
...
|   4213  | 16386  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
|   4249  | 49157  | 32773  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
|   4237  | 32772  | 32773  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-27) |    fully_qual(7)     |
|   4172  | 32773  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-28) |    fully_qual(7)     |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

De doelinformatie van elke destgrp kan worden gevonden met behulp van de 'show service redir info' opdracht.

Pod1-Leaf1# show service redir info
============================================================================================ 
LEGEND 
TL: Threshold(Low)  |  TH: Threshold(High) |  HP: HashProfile  |  HG: HealthGrp  | BAC: Backup-Dest |  TRA: Tracking  | RES: Resiliency 
============================================================================================ 
List of Dest Groups 
GrpID Name            destination                                 HG-name           BAC  operSt     operStQual      TL   TH   HP   TRAC RES  
===== ====            ===========                                 ==============    ===  =======    ============    ===  ===  ===  ===  ===  
28    destgrp-28      dest-[192.168.102.100]-[vxlan-2752513]      Not attached      N    enabled    no-oper-grp     0    0    sym  no   no  
27    destgrp-27      dest-[192.168.101.100]-[vxlan-2752513]      Not attached      N    enabled    no-oper-grp     0    0    sym  no   no  

List of destinations
Name                                          bdVnid             vMac                    vrf         operSt     operStQual      HG-name                          
====                                          ======             ====                    ====        =====      =========       =======                          
dest-[192.168.102.100]-[vxlan-2752513]        vxlan-16023499     00:50:56:AF:1C:44       Prod:VRF1   enabled    no-oper-dest    Not attached                     
dest-[192.168.101.100]-[vxlan-2752513]        vxlan-16121792     00:50:56:AF:3C:60       Prod:VRF1   enabled    no-oper-dest    Not attached                     
...

Als de zoneringsregels dienovereenkomstig worden geprogrammeerd, maar het verkeer niet dienovereenkomstig wordt omgeleid of doorgestuurd, controleer dan het volgende, aangezien het vaak voorkomende fouten zijn:

• Controleer of de bron- of doelklasse-ID is opgelost zoals verwacht met ELAM. Als dit niet het geval is, controleer dan wat de verkeerde klasse-ID is en de EPG-afleidingscriteria zoals path en encap VLAN.
• Zelfs als de bron en bestemmingsklasse IDs dienovereenkomstig worden opgelost, en het beleid PBR wordt toegepast maar het verkeer komt niet op de PBR knoop aan, te controleren gelieve IP, MAC, en VRF van het destgrp in de herhalingsactie ("toon de dienst herhalingsinfo") correct zijn.

Standaard zijn de vergunningsregels voor een consument-EPG naar een serviceknooppunt (consumentenzijde) en een provider-EPG naar een serviceknooppunt (leverancierskant) niet geprogrammeerd als PBR is ingeschakeld. Aldus, kan een eindpunt van de consument of van de leverancier niet direct aan het de dienstknooppunt door gebrek communiceren. Om dit verkeer toe te laten, moet de optie Direct Connect zijn ingeschakeld. Het gebruik wordt uitgelegd in de sectie "Andere voorbeelden van verkeersstromen".

Gebruik van contract_parser

Het contract_parser hulpmiddel kan ook helpen om het beleid te verifiëren. C-consumer is de consumentenkant van het serviceknooppunt en C-provider is de leverancierskant van het serviceknooppunt.

Pod1-Leaf1# contract_parser.py --vrf Prod:VRF1
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:4213] [vrf:Prod:VRF1] permit ip tcp tn-Prod/G-Prod-ASAv-VM1ctxVRF1/C-consumer(16386) eq 80 tn-Prod/ap-app1/epg-Web(32772)  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]
[7:4237] [vrf:Prod:VRF1] redir ip tcp tn-Prod/ap-app1/epg-Web(32772) tn-Prod/ap-app1/epg-App(32773) eq 80  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]
                               destgrp-27 vrf:Prod:VRF1 ip:192.168.101.100 mac:00:50:56:AF:3C:60 bd:uni/tn-Prod/BD-Service-BD1
[7:4172] [vrf:Prod:VRF1] redir ip tcp tn-Prod/ap-app1/epg-App(32773) eq 80 tn-Prod/ap-app1/epg-Web(32772)  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]
                               destgrp-28 vrf:Prod:VRF1 ip:192.168.102.100 mac:00:50:56:AF:1C:44 bd:uni/tn-Prod/BD-Service-BD2
[9:4249] [vrf:Prod:VRF1] permit any tn-Prod/G-Prod-ASAv-VM1ctxVRF1/C-provider(49157) tn-Prod/ap-app1/epg-App(32773) [contract:uni/tn-Prod/brc-web-to-app] [hit=15]

...

Andere voorbeelden van verkeersstromen

In deze sectie worden andere veelvoorkomende voorbeelden van verkeersstromen overwogen om de gewenste stromen voor probleemoplossing te identificeren. Raadpleeg het vorige hoofdstuk in deze sectie voor stappen voor probleemoplossing.

1. Taakverdeling zonder SNAT:
   • In dit voorbeeld hebben EPG Web en provider EPG App een contract met een load balancer Service Graph. Endpoints in App EPG zijn echte servers die gekoppeld zijn aan de VIP op de load balancer.
   • PBR to load balancer is ingeschakeld voor providers die de richting van consumentenverkeer bepalen.
2. Firewall en load balancer zonder SNAT:
   • In dit voorbeeld hebben EPG Web en provider EPG App een contract met een firewall en een load balancer Service Graph. Endpoints in App EPG zijn echte servers die gekoppeld zijn aan de VIP on load balancer.
   • PBR naar firewall is voor beide richtingen ingeschakeld.
   • PBR to load balancer is ingeschakeld voor providers die de richting van consumentenverkeer bepalen.
3. Gedeelde service (Inter-VRF-contract):
   • In dit voorbeeld hebben EPG Web en provider EPG App een contract met een firewall Service Graph. EPG Web en EPG App zijn in verschillende VRFs.
   • PBR naar firewall is voor beide richtingen ingeschakeld.
   • De firewall zit tussen VRF’s in.

1. Taakverdeling zonder SNAT

PBR kan worden ingezet als bidirectionele PBR of unidirectionele PBR. Eén gebruikscase voor unidirectionele PBR is de integratie van taakverdeling zonder bron-netwerkadresomzetting (NAT). Als de ladingsverdeler bron-NAT uitvoert, is PBR niet vereist.

Voorbeeld van verkeerspad

De onderstaande afbeelding illustreert een voorbeeld van een inkomende verkeersstroom van het EPG-web van de consument naar de EPG-app van de provider met twee verbindingen: de ene is van een eindpunt in het EPG-web van de consument naar de VIP-load balancer en de andere is van de load balancer naar een eindpunt in de EPG-app van de provider. Omdat het inkomende verkeer bestemd is voor de VIP, zal het verkeer de load balancer zonder PBR bereiken als de VIP bereikbaar is. De load balancer verandert de bestemming IP in een van de eindpunten in EPG App gekoppeld aan de VIP maar vertaalt de bron IP niet. Dienovereenkomstig, gaat het verkeer naar het leverancierseindpunt.

Laadverdeler zonder SNAT-routevoorbeeld — consument naar VIP en ladingsverdeler naar provider zonder PBR

De onderstaande figuur illustreert de terugkeerverkeersstroom van provider EPG App naar consument EPG Web. Omdat het terugkeerverkeer bestemd is voor de oorspronkelijke IP-bron, moet PBR het terugkeerverkeer maken om terug te gaan naar de taakverdeling. Anders ontvangt het eindpunt van de consument het verkeer waar de bron IP het leverancierseindpunt in plaats van VIP is. Zulk verkeer zal worden gelaten vallen omdat het eindpunt van de consument geen verkeer aan het leverancierseindpunt in werking stelde zelfs als het middennetwerk zoals de stof ACI het pakket terug naar het eindpunt van de consument door:sturen.

Nadat het verkeer van het leverancierseindpunt naar het consumentendpoint is omgeleid naar de lastverdeler, verandert de lastverdeler de bron IP in de VIP. Dan, komt het verkeer terug van de ladingsstabilisator en het verkeer gaat terug naar het eindpunt van de consument.

Laadverdeler zonder SNAT-voorbeeld voor doorsturen van pad - leverancier aan consument met PBR

Het geprogrammeerde beleid op de bladknooppunten.

In de onderstaande figuur en de 'toon zoning-regel'-uitvoer hieronder worden de zoneregels na de implementatie van de servicegrafiek beschreven. In dit voorbeeld is het verkeer van pcTag 32772 (Web) naar pcTag 16389 (Service-LB) toegestaan, is het verkeer van pcTag 16389 (Service-LB) naar pcTag 32773 (App) toegestaan en wordt het verkeer van pcTag 32773 (App) naar pcTag 32772 (Web) omgeleid naar 'destgrp-31' (taakverdeling).

Zones-regels na implementatie van Service Graph - load balancer zonder SNAT

Pod1-Leaf1# show zoning-rule scope 2752513
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
|   4248  | 16389  | 32773  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-31) |    fully_qual(7)     |
|   4234  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
|   4133  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
...

Standaard is er geen regel voor de vergunning van de provider EPG (pcTag 32773) naar Service-LB (pcTag 16389). Om bi-directionele communicatie tussen hen toe te staan voor gezondheidscontroles van de lastverdeler aan leverancierseindpunten, moet de Direct Connect optie op de verbinding aan Waar worden geplaatst. De locatie is 'huurder > L4-L7 > Service Graph Templates > Policy'. De standaardwaarde is Vals.

Direct Connect-optie instellen

Het voegt een vergunningsregel voor leverancier EPG(32773) aan Service-LB(16389) toe zoals hieronder.

Pod1-Leaf1# show zoning-rule scope 2752513
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
|   4248  | 16389  | 32773  | default  |     bi-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-31) |    fully_qual(7)     |
|   4234  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
|   4133  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
|   4214  | 32773  | 16389  | default  | uni-dir-ignore | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

2. Traffic flow-voorbeeld - firewall en taakverdeling zonder SNAT

PBR kan worden geïmplementeerd met meerdere servicefuncties in een servicegrafiek zoals firewall als eerste knooppunt en taakverdeling als tweede knooppunt.

Voorbeeld van verkeerspad

De onderstaande afbeelding illustreert een voorbeeld van een inkomende verkeersstroom van het EPG-web van de consument naar de EPG-app van de provider met twee verbindingen: de ene is van een eindpunt in het EPG-web van de consument naar de VIP van de taakverdeler via de firewall en de andere is van de taakverdeler naar een eindpunt in de EPG-app van de provider. Het inkomende verkeer dat voor de VIP bestemd is, wordt omgeleid naar de firewall en gaat dan naar de load balancer zonder PBR. De load balancer verandert de bestemming IP in een van de eindpunten in App EPG gekoppeld aan de VIP maar vertaalt de bron IP niet. Vervolgens gaat het verkeer naar het provider-endpoint.

Firewall en load balancer zonder SNAT doorsturen pad voorbeeld - consument naar VIP en load balancer naar provider

Firewall en load balancer zonder SNAT doorsturen pad voorbeeld - consument naar VIP en load balancer naar provider (vervolg)

De onderstaande figuur illustreert de terugkeerverkeersstroom van provider EPG App naar consument EPG Web. Omdat het terugkeerverkeer bestemd is voor oorspronkelijke IP-bron, moet PBR het terugkeerverkeer terugsturen naar de taakverdeling.

Nadat het verkeer van het leverancierseindpunt naar het consumentendpoint is omgeleid naar de lastverdeler, verandert de lastverdeler de bron IP in de VIP. Het verkeer wordt via de taakverdeling teruggestuurd naar de firewall. Dan, komt het verkeer terug van de firewall en gaat terug naar het eindpunt van de consument.

Firewall en load balancer zonder SNAT-voorbeeld voor doorsturen van pad - provider naar consument

Het geprogrammeerde beleid op de bladknooppunten

De onderstaande figuur en de 'show zoning-rule'-output beschrijven de zoning-regels na de implementatie van de Service Graph. In dit voorbeeld wordt het verkeer van pcTag 32772 (Web) naar pcTag 16389 (Service-LB) omgeleid naar 'destgrp-32' (consumentenkant van de firewall), het verkeer van pcTag 32773 (App) naar pcTag 32772 (Web) wordt omgeleid naar 'destgrp-33' (load balancer), en het verkeer van pcTag 16389 (Service-LB) naar pcTag 32772 (Web) wordt omgeleid naar 'destgrp-34' (provider kant van de firewall).

Zones-regels na implementatie van Service Graph - firewall en taakverdeling zonder SNAT

Pod1-Leaf1# show zoning-rule scope 2752513
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+
|   4236  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-32) |    fully_qual(7)     |
|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-33) |    fully_qual(7)     |
|   4171  | 16389  | 32773  | default  |     bi-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
|   4248  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-34) |    fully_qual(7)     |
|   4214  | 32774  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |
|   4244  | 32775  | 16389  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
|   4153  | 32773  | 16389  | default  | uni-dir-ignore | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

In het bovenstaande voorbeeld is de optie Direct Connect ingesteld op 'True' op de verbinding tussen de aanbodzijde van de taakverdeling en de provider EPG. Het moet ingeschakeld zijn voor een gezondheidscontrole, van de taakverdeling tot de providerendpoints. De locatie is 'huurder > L4-L7 > Service Graph Templates >Policy'. Raadpleeg de afbeelding 'Direct Connect optie instellen'.

3. Gedeelde service (Inter-VRF-contract)

PBR kan worden ingeschakeld in een inter-VRF-contract. In dit deel wordt uitgelegd hoe de zoningregels worden geprogrammeerd in het geval van EPG tot EPG inter-VRF-contract.

Het geprogrammeerde beleid op de bladknooppunten

In het geval van EPG tot EPG inter-VRF contract, wordt het beleid altijd afgedwongen in consument VRF. Op deze manier vindt omleiding plaats op de VRF voor consumenten. Raadpleeg voor andere combinaties de tabel "Waar wordt het beleid afgedwongen?" in de sectie "Doorsturen".

In de onderstaande afbeelding en de 'toon zonering-regel'-uitvoer hieronder worden de zoneregels na de implementatie van de servicegrafiek beschreven. In dit voorbeeld wordt het verkeer van pcTag 32772 (Web) naar pcTag 10936 (App) omgeleid naar 'destgrp-36' (consumentenkant van het serviceknooppunt) en het verkeer van pcTag 10936 (App) naar pcTag 32772 (Web) wordt omgeleid naar 'destgrp-35' (leverancierskant van het serviceknooppunt). Beiden worden afgedwongen in VRF1 die consument VRF is. Het verkeer van pcTag 32776 (consumentenzijde van de firewall) naar pcTag 32772 (Web) is toegestaan in VRF1.

Zones-regels na implementatie van Service Graph - inter-VRF-contract

Pod1-Leaf1# show zoning-rule scope 2752513
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |        Priority        |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+
|   4191  | 32776  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |     fully_qual(7)      |
|   4143  | 10936  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-35) |     fully_qual(7)      |
|   4136  | 32772  | 10936  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-36) |     fully_qual(7)      |
+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+

Het verkeer van pcTag 49157 (provider-kant van de firewall) naar pcTag 10936 (App) is toegestaan in VRF2 omdat beide in VRF2 zijn.

Pod1-Leaf1# show zoning-rule scope 2555904
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  | Name |  Action  |       Priority       |
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+
|   4249  | 49157  | 10936  | default  | uni-dir | enabled | 2555904 |      |  permit  |    src_dst_any(9)    |
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+