Vérification de l'ACI Shared Services - Shared Service Consumer PcTag 14
Table des matières
Introduction
Ce document décrit les étapes de configuration et de vérification de la configuration de Shared Services avec Shared BD dans l'ACI.
Informations générales
Une configuration Shared Services permet la communication entre les groupes de terminaux sur différents VRF au sein d'un fabric ACI.
Shared Services tire pleinement parti des 3 catégories PcTag :
| Nom de catégorie | Plage PcTag |
| système | 1 - 15 |
| Global | 16 - 16385 |
| Municipal | 16386 - 65535 |
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Configurer
Diagramme du réseau
Points forts de la configuration
- L'étendue de sous-réseau « Partagé entre VRF » est requise sur le sous-réseau à fuiter,192.168.10.1/24
- Le contrat doit avoir au moins la portée « locataire » puisque les groupes de terminaux sont dans le même locataire.
- Si les EPG se trouvent dans des locataires différents, le contrat doit avoir une portée « globale »
- Si le sous-réseau partagé est défini dans l'EPG du fournisseur, le contrat ne doit être fourni que sur l'EPG à partager et consommé sur l'EPG à consommer.
OU
- Si le sous-réseau partagé est défini dans le BD du fournisseur, le contrat doit être fourni par les deux EPG et consommé par les deux EPG et les sous-réseaux du BD uniquement. Cela utilise plus d'espace TCAM à mesure que davantage de règles de zonage sont programmées.
Vérifier
Scénario 1 - EPG à EPG : sous-réseau partagé défini dans l'EPG du fournisseur
Dans cet exemple, le sous-réseau partagé est configuré sous EPG-2.
Cette option optimise l'utilisation de TCAM et permet d'effectuer la configuration Shared Services. TCAM est optimisé car les règles de zonage doivent uniquement être programmées dans le VRF client. Dans ce scénario, le VRF consommateur est uniquement sur le Leaf 101.
Suivi de flux EPG-1 à EPG-2
Feuille client 101
Les informations de route sur le VRF consommateur Leaf 101 PJ : VRF-1 indiquent la route pour 192.168.10.10 via le VNID 2260992, qui est Provider VRF PJ : VRF-2 :
leaf101# show ip route 192.168.10.10 vrf PJ:VRF-1 IP Route Table for VRF "PJ:VRF-1" '*' denotes best ucast next-hop '**' denotes best mcast next-hop '[x/y]' denotes [preference/metric] '%' in via output denotes VRF
192.168.10.0/24, ubest/mbest: 1/0, attached, direct, pervasive *via 10.0.240.33%overlay-1, [1/0], 23:06:11, static, tag 4294967294, rwVnid: vxlan-2260992 recursive next hop: 10.0.240.33/32%overlay-1
Le flux de trafic peut être validé à l’aide d’un module ELAM sur la feuille client 101 par rapport à la requête ICMP de la source 10.10.10.10 à la destination 192.168.10.1
leaf101# vsh_lc
module-1# trigger reset
module-1# trigger init in-select 6 out-select 1
module-1# set outer ipv4 src_ip 10.10.10.10 dst_ip 192.168.10.10
module-1# start
module-1# ereport
...
-----------------------------------------------------------------------------------------------------------------------------------
Outer L3 Header
-----------------------------------------------------------------------------------------------------------------------------------
...
IP Protocol Number : ICMP
IP CheckSum : 37262( 0x918E )
Destination IP : 192.168.10.10
Source IP : 10.10.10.10
-----------------------------------------------------------------------------------------------------------------------------------
Contract Lookup Key
-----------------------------------------------------------------------------------------------------------------------------------
IP Protocol : ICMP( 0x1 )
L4 Src Port : 2048( 0x800 )
L4 Dst Port : 16568( 0x40B8 )
sclass (src pcTag) : 16388( 0x4004 )
dclass (dst pcTag) : 10930( 0x2AB2 )
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
-----------------------------------------------------------------------------------------------------------------------------------
Contract Result
-----------------------------------------------------------------------------------------------------------------------------------
Contract Drop : no
Contract Logging : no
Contract Applied : yes
Contract Hit : yes
Contract Aclqos Stats Index : 81874
( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81874" )
Le rapport montre que le Contrat est appliqué sur le Consommateur Leaf 101 et que Src pcTag 16388 (EPG-1) et Dst PcTAG 10930 (EPG-2) ont été attribués.
Ces valeurs peuvent être comparées aux règles de zonage programmées dans Consumer VRF PJ : VRF-1 (VNID 3080192) afin d'identifier les ID de règle qui ont été atteints :
leaf101# show zoning-rule scope 3080192 +---------+--------+--------+----------+----------------+---------+---------+--------------+----------+------------------------+ | Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority | +---------+--------+--------+----------+----------------+---------+---------+--------------+----------+------------------------+ | 4117 | 10930 | 0 | implicit | uni-dir | enabled | 3080192 | | deny,log | shsrc_any_any_deny(12) | | 4108 | 10930 | 16388 | 8 | uni-dir-ignore | enabled | 3080192 | PJ:EPG1-EPG2 | permit | fully_qual(7) | | 4118 | 16388 | 10930 | 8 | bi-dir | enabled | 3080192 | PJ:EPG1-EPG2 | permit | fully_qual(7) | +---------+--------+--------+----------+----------------+---------+---------+--------------+----------+------------------------+
Suivi de flux EPG-2 à EPG-1
Feuille fournisseur 102
Les informations de route sur le Leaf 102 pour le fournisseur VRF PJ : VRF-2 indiquent la route pour 10.10.10.10 via le VNID 3080192, qui est le consommateur VRF PJ : VRF-1 :
leaf102# show ip route 10.10.10.10 vrf PJ:VRF-2
IP Route Table for VRF "PJ:VRF-2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF
10.10.10.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.0.240.33%overlay-1, [1/0], 1d22h, static, tag 4294967294, rwVnid: vxlan-3080192
recursive next hop: 10.0.240.33/32%overlay-1
Le flux de trafic peut être validé avec un ELAM sur Provider Leaf 101 par rapport à la requête ICMP de la source 192.168.10.10 à la destination 10.10.10.10 :
leaf102# trigger reset
module-1# trigger init in-select 6 out-select 1
module-1# set outer ipv4 src_ip 192.168.10.10 dst_ip 10.10.10.10
module-1# start
module-1# ereport
... ----------------------------------------------------------------------------------------------------------------------------------- Outer L3 Header ----------------------------------------------------------------------------------------------------------------------------------- ... IP Protocol Number : ICMP IP CheckSum : 37262( 0x918E ) Destination IP : 10.10.10.10 Source IP : 192.168.10.10 ----------------------------------------------------------------------------------------------------------------------------------- Contract Lookup Key ----------------------------------------------------------------------------------------------------------------------------------- IP Protocol : ICMP( 0x1 ) L4 Src Port : 0( 0x0 ) L4 Dst Port : 18616( 0x48B8 ) sclass (src pcTag) : 10930( 0x2AB2 ) dclass (dst pcTag) : 14( 0xE ) 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 ----------------------------------------------------------------------------------------------------------------------------------- Contract Result ----------------------------------------------------------------------------------------------------------------------------------- Contract Drop : no Contract Logging : no Contract Applied : no Contract Hit : yes Contract Aclqos Stats Index : 81873 ( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81873" )
Dans ce rapport, notez que sclass et dclass sont toutes deux des valeurs non locales.
EPG-2, le fournisseur de services partagés, génère désormais un PcTag global de 10930.
La dclass attribuée à ce paquet est Shared Service Consumer PcTag 14. PcTag 14 est le PcTag système réservé au trafic inter-VRF.
Observez qu'une règle de zonage spéciale est programmée sur Provider Leaf 102 entre Provider EPG2 PcTag 10930 et Shared Service Consumer System PcTag 14 avec la valeur « Action » définie sur « permit_override ». Cette règle permet aux flux mis en correspondance d'être transférés vers le Consumer Leaf pour la recherche de stratégie finale :
leaf102# show zoning-rule +---------+--------+--------+----------+---------+---------+----------+------+-----------------+----------------------+ | Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority | +---------+--------+--------+----------+---------+---------+----------+------+-----------------+----------------------+ | 4113 | 10930 | 14 | implicit | uni-dir | enabled | 2260992 | | permit_override | src_dst_any(9) | +---------+--------+--------+----------+---------+---------+----------+------+-----------------+----------------------+
Scénario 2 - BD-to-BD : sous-réseau partagé défini dans le BD du fournisseur.
Dans cet exemple de scénario, le sous-réseau partagé est uniquement configuré dans BD-2.
Pour compléter la configuration Shared Services, les contrats doivent être consommés et fournis sur les deux EPG, EPG-1 et EPG-2.
Suivi de flux EPG-1 à EPG-2
Comme un contrat de service partagé est fourni et consommé sur les deux EPG, un flux de paquets entre EPG-1 (Leaf 101) et EPG-2 (Leaf 102) observe ces propriétés :
- EPG-1 est considéré comme le fournisseur
- EPG-2 est considéré comme le consommateur
- La feuille 102 est la feuille du consommateur, et donc la politique finale est appliquée ici.
Les informations de route sont identiques à celles du scénario 1.
Feuille 101 « Fournisseur » :
Leaf101# vsh_lc
module-1# trigger reset
module-1# trigger init in-select 6 out-select 1
module-1# set outer ipv4 src_ip 10.10.10.10 dst_ip 192.168.10.10
module-1# start
module-1# status
module-1# ereport
... ----------------------------------------------------------------------------------------------------------------------------------- Outer L3 Header ----------------------------------------------------------------------------------------------------------------------------------- ... IP Protocol Number : ICMP IP CheckSum : 23304( 0x5B08 ) Destination IP : 192.168.10.10 Source IP : 10.10.10.10 ----------------------------------------------------------------------------------------------------------------------------------- Contract Lookup Key ----------------------------------------------------------------------------------------------------------------------------------- IP Protocol : ICMP( 0x1 ) L4 Src Port : 2048( 0x800 ) L4 Dst Port : 59074( 0xE6C2 ) sclass (src pcTag) : 18( 0x12 ) dclass (dst pcTag) : 14( 0xE ) 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 ----------------------------------------------------------------------------------------------------------------------------------- Contract Result ----------------------------------------------------------------------------------------------------------------------------------- Contract Drop : no Contract Logging : no Contract Applied : no Contract Hit : yes Contract Aclqos Stats Index : 81873 ( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81873" )
Notez que dclass 14 est attribué. Cela signifie que le trafic est autorisé à continuer via la règle « permit_override » afin que le Consumer Leaf puisse conduire la recherche de stratégie finale.
Feuille « grand public » 102
Leaf102# vsh_lc
module-1# trigger reset
module-1# trigger init in-select 14 out-select 1
module-1# set inner ipv4 src_ip 10.10.10.10 dst_ip 192.168.10.10
module-1# start
module-1# ereport
...
----------------------------------------------------------------------------------------------------------------------------------- Inner L3 Header ----------------------------------------------------------------------------------------------------------------------------------- ... IP Protocol Number : ICMP Destination IP : 192.168.10.10 Source IP : 10.10.10.10 ----------------------------------------------------------------------------------------------------------------------------------- Contract Lookup Key ----------------------------------------------------------------------------------------------------------------------------------- IP Protocol : ICMP( 0x1 ) L4 Src Port : 2048( 0x800 ) L4 Dst Port : 26203( 0x665B ) sclass (src pcTag) : 18( 0x12 ) dclass (dst pcTag) : 10930( 0x2AB2 ) 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 ----------------------------------------------------------------------------------------------------------------------------------- Contract Result ----------------------------------------------------------------------------------------------------------------------------------- Contract Drop : no Contract Logging : no Contract Applied : yes Contract Hit : yes Contract Aclqos Stats Index : 81874 ( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81874" )
Notez que les EPG-1 et EPG-2 ont désormais des PcTags globaux ; EPG-1 est PcTag 18 et EPG-2 est PcTag 10938.
Suivi de flux EPG-2 à EPG-1
Comme un contrat de service partagé est fourni et consommé sur les deux EPG, un flux de paquets entre EPG-2 (Leaf 102) et EPG-1 (Leaf 101) observe ces propriétés :
- EPG-2 est considéré comme le fournisseur
- EPG-1 est considéré comme le consommateur
- La feuille 101 est la feuille du consommateur, et donc la politique finale est appliquée ici.
Les informations de route sont identiques à celles du scénario 1.
Feuille « Fournisseur » 102
Leaf102# vsh_lc
module-1# trigger reset
module-1# trigger init in-select 6 out-select 1
module-1# set outer ipv4 src_ip 192.168.10.10 dst_ip 10.10.10.10
module-1# start
module-1# ereport
... ----------------------------------------------------------------------------------------------------------------------------------- Outer L3 Header ----------------------------------------------------------------------------------------------------------------------------------- ... IP Protocol Number : ICMP IP CheckSum : 23308( 0x5B0C ) Destination IP : 10.10.10.10 Source IP : 192.168.10.10 ----------------------------------------------------------------------------------------------------------------------------------- Contract Lookup Key ----------------------------------------------------------------------------------------------------------------------------------- IP Protocol : ICMP( 0x1 ) L4 Src Port : 0( 0x0 ) L4 Dst Port : 56682( 0xDD6A ) sclass (src pcTag) : 10930( 0x2AB2 ) dclass (dst pcTag) : 14( 0xE ) 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 ----------------------------------------------------------------------------------------------------------------------------------- Contract Result ----------------------------------------------------------------------------------------------------------------------------------- Contract Drop : no Contract Logging : no Contract Applied : no Contract Hit : yes Contract Aclqos Stats Index : 81873 ( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81873" )
Notez que dclass 14 est attribué. Cela signifie que le trafic est autorisé à continuer via la règle « permit_override » afin que le Consumer Leaf puisse conduire la recherche de stratégie finale.
Feuille « grand public » 101
Leaf101# vsh_lc
module-1# trigger reset
module-1# trigger init in-select 6 out-select 1
module-1# set outer ipv4 src_ip 192.168.10.10 dst_ip 10.10.10.10
module-1# start
module-1# ereport
----------------------------------------------------------------------------------------------------------------------------------- Inner L3 Header ----------------------------------------------------------------------------------------------------------------------------------- L3 Type : IPv4 DSCP : 0 Don't Fragment Bit : 0x0 TTL : 254 IP Protocol Number : ICMP Destination IP : 10.10.10.10 Source IP : 192.168.10.10 ----------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------- Contract Lookup Key ----------------------------------------------------------------------------------------------------------------------------------- IP Protocol : ICMP( 0x1 ) L4 Src Port : 0( 0x0 ) L4 Dst Port : 22874( 0x595A ) sclass (src pcTag) : 10930( 0x2AB2 ) dclass (dst pcTag) : 18( 0x12 ) 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 ----------------------------------------------------------------------------------------------------------------------------------- Contract Result ----------------------------------------------------------------------------------------------------------------------------------- Contract Drop : no Contract Logging : no Contract Applied : yes Contract Hit : yes Contract Aclqos Stats Index : 81874 ( show sys int aclqos zoning-rules | grep -B 9 "Idx: 81874" )
TCAM Usage - Synthèse
Dans le scénario BD-to-BD, notez que les règles de zonage ont doublé puisque les groupes EPG-1 et EPG-2 sont des consommateurs de contrats de services partagés :
Leaf101# show zoning-rule scope 3080192 +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+ | Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority | +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+ | 4117 | 10930 | 0 | implicit | uni-dir | enabled | 3080192 | | deny,log | shsrc_any_any_deny(12) | | 4129 | 18 | 14 | implicit | uni-dir | enabled | 3080192 | | permit_override | src_dst_any(9) | | 4128 | 10930 | 18 | 8 | bi-dir | enabled | 3080192 | PJ:EPG1-EPG2 | permit | fully_qual(7) | | 4127 | 18 | 10930 | 8 | uni-dir-ignore | enabled | 3080192 | PJ:EPG1-EPG2 | permit | fully_qual(7) | +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+
Leaf102# show zoning-rule scope 2260992 +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+ | Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority | +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+ | 4113 | 10930 | 14 | implicit | uni-dir | enabled | 2260992 | | permit_override | src_dst_any(9) | | 4123 | 18 | 10930 | 8 | bi-dir | enabled | 2260992 | PJ:EPG1-EPG2 | permit | fully_qual(7) | | 4124 | 18 | 0 | implicit | uni-dir | enabled | 2260992 | | deny,log | shsrc_any_any_deny(12) | | 4122 | 10930 | 18 | 8 | uni-dir-ignore | enabled | 2260992 | PJ:EPG1-EPG2 | permit | fully_qual(7) | +---------+--------+--------+----------+----------------+---------+---------+--------------+-----------------+------------------------+
Conclusion
Les deux scénarios de configuration permettent d'exécuter la fonctionnalité Shared Services, mais la méthode BD-to-BD est proposée au prix d'une consommation TCAM supplémentaire.
Références et liens utiles
Comprendre et dépanner les services partagés ACI - DGTL-TSCDCN-305
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
19-Oct-2022 |
Lien Cisco Live fixe |
1.0 |
13-Sep-2022 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)