Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit la prise en charge des VLAN privés (PVLAN) pour Cisco Unified Computing System (UCS) dans la version 2.2(2c) et les versions ultérieures.
Attention : Il y a un changement de comportement à partir de la version 3.1(3a) du micrologiciel UCS, comme décrit dans la section Changement de comportement avec UCS version 3.1(3) et ultérieure.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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. If your network is live, make sure that you understand the potential impact of any command.
Un VLAN privé est un VLAN configuré pour l'isolation de couche 2 par rapport aux autres ports du même VLAN privé. Les ports qui appartiennent à un PVLAN sont associés à un ensemble commun de VLAN de support, qui sont utilisés pour créer la structure PVLAN.
Il y a trois types de ports PVLAN :
Référez-vous à RFC 5517, VLAN privés de Cisco Systems : Sécurité évolutive dans un environnement multiclient afin de comprendre la théorie, le fonctionnement et les concepts des PVLAN.
Avec Nexus 1000v ou VMware DVS
Note: Cet exemple utilise le VLAN 1750 comme principal, 1785 comme isolé et 1786 comme VLAN de communauté.
2. Créez des VLAN isolés et communautaires en conséquence, comme indiqué dans les images. Aucun de ces VLAN ne doit être un VLAN natif.
3. La carte d'interface réseau virtuelle (vNIC) sur le profil de service transporte des VLAN ordinaires ainsi que des PVLAN, comme le montre l'image.
4. Le canal de port de liaison ascendante sur UCS transporte des VLAN ordinaires ainsi que des PVLAN :
interface port-channel1 description U: Uplink switchport mode trunk pinning border switchport trunk allowed vlan 1,121,221,321,1750,1785-1786 speed 10000 F240-01-09-UCS4-A(nxos)# F240-01-09-UCS4-A(nxos)# show vlan private-vlan Primary Secondary Type Ports ------- --------- --------------- ------------------------------------------- 1750 1785 isolated 1750 1786 community
feature private-vlan vlan 1750 private-vlan primary private-vlan association 1785-1786 vlan 1785 private-vlan isolated vlan 1786 private-vlan community interface Vlan1750 ip address 10.10.175.252/24 private-vlan mapping 1785-1786 no shutdown interface port-channel114 Description To UCS switchport mode trunk switchport trunk allowed vlan 1,121,154,169,221,269,321,369,1750,1785-1786 spanning-tree port type edge spanning-tree bpduguard enable spanning-tree bpdufilter enable vpc 114 <=== if there is a 5k pair in vPC configuration only then add this line to both N5k
Avant UCS version 3.1(3), une machine virtuelle dans le VLAN de communauté peut communiquer avec une machine virtuelle dans le VLAN principal sur le DVS VMware, où la machine virtuelle du VLAN principal réside à l'intérieur de l'UCS. Ce comportement était incorrect, car la machine virtuelle principale doit toujours être orientée vers le nord ou en dehors d'UCS. Ce comportement est documenté via l'ID de défaut CSCvh87378 .
À partir de la version 2.2(2) d'UCS, en raison d'un défaut dans le code, le VLAN de communauté a pu communiquer avec le VLAN principal qui était présent derrière l'IF. Mais Isolated ne pouvait jamais communiquer avec le principal derrière l'IF. Les machines virtuelles (isolées et communautaires) sont toujours en mesure de communiquer avec le principal à l'extérieur de l'IF.
À partir de la version 3.1(3), ce défaut permet à la communauté de communiquer avec le principal derrière l'FI, a été corrigé et par conséquent les machines virtuelles communautaires ne pourront pas communiquer avec une machine virtuelle dans le VLAN principal qui réside dans UCS.
Pour résoudre cette situation, la machine virtuelle principale doit être déplacée (vers le nord) en dehors d'UCS. Si ce n'est pas possible, la machine virtuelle principale doit être déplacée vers un autre VLAN qui est un VLAN normal et non un VLAN privé.
Par exemple, avant le microprogramme 3.1(3), une machine virtuelle du VLAN 1786 de la communauté pouvait communiquer à une machine virtuelle du VLAN 1750 principal qui réside dans UCS, mais cette communication romprait le microprogramme 3.1(3) et ultérieur, comme l'illustre l'image.
NOTE:
—
CSCvh87378 a été traité dans les versions 3.2(3l) et 4.0.4e et ultérieures pour que nous puissions avoir un Vlan principal derrière UCS. Cependant, notez que le VLAN isolé dans UCS ne pourra pas parler au VLAN principal dans UCS. Seul le VLAN de communauté et le VLAN principal peuvent communiquer entre eux lorsque les deux sont derrière UCS.
Note: Dans cet exemple, 4900 est une interface de couche 3 vers un réseau externe. Si votre topologie pour L3 est différente, apportez les modifications nécessaires
Sur le commutateur 4900, procédez comme suit et configurez le port de promiscuité. Le PVLAN se termine par le port proche.
Switch(config-if)#switchport mode trunk
switchport private-vlan mapping 1785-1786
switchport mode private-vlan promiscuous
Sur le routeur en amont, créez une sous-interface pour le VLAN 1750 uniquement. À ce niveau, les exigences dépendent de la configuration réseau que vous utilisez :
interface GigabitEthernet0/1.1 encapsulation dot1Q 1750 IP address10.10.175.254/24
Aucune procédure de vérification n'est disponible pour cette configuration.
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Cette procédure décrit comment tester la configuration de VMware DVS avec l'utilisation de PVLAN.
1. Exécutez des requêtes ping vers d’autres systèmes configurés dans le groupe de ports, ainsi que vers le routeur ou un autre périphérique au niveau du port proche. Les requêtes ping envoyées au périphérique au-delà du port proche doivent fonctionner, tandis que celles envoyées aux autres périphériques du VLAN isolé doivent échouer, comme le montrent les images.
Vérifiez les tables d'adresses MAC afin de voir où votre adresse MAC est apprise. Sur tous les commutateurs, l'adresse MAC doit se trouver dans le VLAN isolé, sauf sur le commutateur avec le port proche. Sur le commutateur proche, l’adresse MAC doit se trouver dans le VLAN principal.
2. UCS comme l'illustre l'image.
3. Vérifiez que la sortie n5k en amont est identique à celle de la sortie précédente sur n5k et comme le montre l'image.
La configuration UCS (qui inclut la configuration vNIC du profil de service) reste la même que dans l'exemple de VMware DVS.
feature private-vlan vlan 1750 private-vlan primary private-vlan association 1785-1786 vlan 1785 private-vlan isolated vlan 1786 private-vlan community same uplink port-profile is being used for regular vlans & pvlans. In this example vlan 121 & 221 are regular vlans but you can change them accordingly port-profile type ethernet pvlan-uplink-no-prom switchport mode trunk mtu 9000 switchport trunk allowed vlan 121,221,1750,1785-1786 channel-group auto mode on mac-pinning system vlan 121 no shutdown state enabled vmware port-group port-profile type vethernet pvlan_1785 switchport mode private-vlan host switchport private-vlan host-association 1750 1785 switchport access vlan 1785 no shutdown state enabled vmware port-group port-profile type vethernet pvlan_1786 switchport mode private-vlan host switchport access vlan 1786 switchport private-vlan host-association 1750 1786 no shutdown state enabled vmware port-group
Cette procédure décrit comment tester la configuration.
1. Exécutez des requêtes ping vers d’autres systèmes configurés dans le groupe de ports, ainsi que vers le routeur ou un autre périphérique au niveau du port proche. Les requêtes ping envoyées au périphérique au-delà du port proche doivent fonctionner, tandis que celles envoyées aux autres périphériques du VLAN isolé doivent échouer, comme indiqué dans la section précédente et dans les images.
2. Sur la N1K, les machines virtuelles sont répertoriées sur le VLAN principal ; cela se produit parce que vous êtes dans des ports hôtes PVLAN qui sont associés au PVLAN comme indiqué dans l'image.
Vérifiez les tables d'adresses MAC afin de voir où votre adresse MAC est apprise. Sur tous les commutateurs, l'adresse MAC doit se trouver dans le VLAN isolé, sauf sur le commutateur avec le port proche. Sur le commutateur proche, l’adresse MAC doit se trouver dans le VLAN principal.
3. Sur le système UCS, vous devez apprendre tous les MAC de leurs VLAN privés respectifs, comme l'illustre l'image.
4. Vérifiez que la sortie n5k en amont est identique à celle de la sortie précédente sur n5k, comme le montre l'image.
Puisque PVLAN se termine au port proche, dans cette configuration, vous contenez le trafic PVLAN vers N1K avec uniquement le VLAN principal utilisé en amont. Par conséquent, UCS et les périphériques en amont ne connaissent aucun PVLAN.
Cette procédure décrit comment ajouter le VLAN principal à la vNIC. Il n'est pas nécessaire de configurer PVLAN car vous n'avez besoin que du VLAN principal.
Note: Cet exemple utilise 1750 comme réseau principal, 1785 comme réseau isolé et 1786 comme réseau local virtuel, comme le montre également l'image.
Ces procédures décrivent comment configurer les périphériques en amont. Dans ce cas, les commutateurs en amont n’ont besoin que de ports agrégés et ils n’ont besoin que de trunk VLAN 1750, car il s’agit du seul VLAN que les commutateurs en amont voient.
Sur le Nexus 5K, exécutez ces commandes et vérifiez la configuration de la liaison ascendante :
Nexus5000-5(config-vlan)# vlan 1750
Cette procédure décrit comment configurer le N1K :
feature private-vlan vlan 1750 private-vlan primary private-vlan association 1785-1786 vlan 1785 private-vlan isolated vlan 1786 private-vlan community same uplink port-profile is being used for regular vlans & pvlans. In this example vlan 121 & 221 are regular vlans but you can change them accordingly port-profile type ethernet pvlan-uplink switchport mode private-vlan trunk promiscuous switchport trunk allowed vlan 121,221,1750 switchport private-vlan trunk allowed vlan 121,221,1750 <== Only need to allow Primary VLAN switchport private-vlan mapping trunk 1750 1785-1786 <=== PVLANs must be mapped at this stage mtu 9000 channel-group auto mode on mac-pinning no shutdown system vlan 121 state enabled vmware port-group port-profile type vethernet pvlan_1785 switchport mode private-vlan host switchport private-vlan host-association 1750 1785 switchport access vlan 1785 no shutdown state enabled vmware port-group port-profile type vethernet pvlan_1786 switchport mode private-vlan host switchport access vlan 1786 switchport private-vlan host-association 1750 1786 no shutdown state enabled vmware port-group
Le PVLAN doit se terminer à un port proche sur le profil de port de liaison ascendante pour n1k et UCS et par la suite tous les périphériques en amont doivent voir ces machines virtuelles dans les VLAN principaux. Voici l'instantané de N5k et UCS en amont.
Peu de choses à retenir :
La commande private-vlan mapping trunk ne décide pas ou ne remplace pas la configuration de l'agrégation d'un port.