ASAv en mode GoTo (L3) avec l'utilisation de la version AVS- ACI 1.2(x)
Introduction
Ce document décrit comment déployer un commutateur virtuel d'application (AVS) avec un pare-feu unique ASAv (Adaptive Security Virtual Appliance) en mode routé/GOTO en tant que graphique de services de couches 4 à 7 entre deux groupes de terminaux (EPG) pour établir une communication client-serveur à l'aide de la version ACI 1.2(x).
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Stratégies d'accès configurées et interfaces actives et en service
- EPG, domaine de pont (BD) et routage et transfert virtuels (VRF) déjà configurés
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Matériel et logiciels :
- UCS C220 - 2.0(6d)
- ESXi/vCenter - 5.5
- ASAv - asa-device-pkg-1.2.4.8
- AVS - 5.2.1.SV3.1.10
- APIC - 1.2(1i)
- Leaf/Spines - 11.2(1i)
- Paquets de périphériques *.zip déjà téléchargés
Caractéristiques :
- AVS
- ASAv
- EPG, BD, VRF
- Liste de contrôle d'accès (ACL)
- Graphique des services de couches 4 à 7
- vCenter
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
Comme l'illustre l'image,
Configurations
La configuration initiale d'AVS crée un domaine VMware vCenter (intégration VMM)2
- Vous pouvez créer plusieurs data centers et entrées DVS (Distributed Virtual Switch) dans un domaine unique. Cependant, vous ne pouvez attribuer qu'un seul Cisco AVS à chaque data center.
- Le déploiement de graphiques de services avec Cisco AVS est pris en charge à partir de la version 1.2(1i) de l'ACI Cisco avec la version 5.2(1)SV3(1.10) de Cisco AVS. La configuration complète du graphique de services est effectuée sur le contrôleur Cisco APIC (Application Policy Infrastructure Controller).
- Le déploiement de la machine virtuelle de service avec Cisco AVS est pris en charge uniquement sur les domaines Virtual Machine Manager (VMM) avec le mode d'encapsulation VLAN (Virtual Local Area Networks). Cependant, les machines virtuelles de calcul (les machines virtuelles du fournisseur et du consommateur) peuvent faire partie de domaines VMM avec un LAN extensible virtuel (VXLAN) ou une encapsulation VLAN.
- Notez également que si la commutation locale est utilisée, l'adresse de multidiffusion et le pool ne sont pas requis. Si aucune commutation locale n'est sélectionnée, le pool de multidiffusion doit être configuré et l'adresse de multidiffusion à l'échelle du fabric AVS ne doit pas faire partie du pool de multidiffusion. Tout le trafic provenant de l’AVS sera encapsulé dans un VLAN ou un VXLAN.
Naviguez jusqu'à VM Networking > VMWare > Create vCenter Domain, comme indiqué dans l'image :
Si vous utilisez Port-channel ou VPC (Virtual Port-channel), il est recommandé de définir les stratégies vSwitch pour utiliser l'épinglage Mac.
Après cela, APIC devrait pousser la configuration du commutateur AVS vers vCenter, comme indiqué dans l'image :
Sur l'APIC, vous pouvez remarquer qu'une adresse de point d'extrémité de tunnel VXLAN (VTEP) est attribuée au groupe de ports VTEP pour AVS. Cette adresse est attribuée quel que soit le mode de connectivité utilisé (VLAN ou VXLAN)
Installer le logiciel Cisco AVS dans vCenter
- Téléchargez l'offre groupée d'installation vSphere (VIB) depuis CCO en utilisant ce lien
Tableau 1 - Compatibilité des versions du logiciel hôte pour ESXi 6.0, 5.5, 5.1 et 5.0
Dans le fichier ZIP, il y a 3 fichiers VIB, un pour chacune des versions d'hôte ESXi, sélectionnez celui approprié pour ESX 5.5, comme illustré dans l'image :
- Copier le fichier VIB dans ESX Datastore : cette opération peut être effectuée via l'interface de ligne de commande ou directement depuis vCenter
esxcli software vib remove -n cross_cisco-vem-v197-5.2.1.3.1.5.0-3.2.1.vib
ou en parcourant directement le data store.
- Installez le logiciel AVS à l'aide de la commande suivante sur l'hôte ESXi :
esxcli software vib install -v /vmfs/volumes/datastore1/cross_cisco-vem-v250-5.2.1.3.1.10.0-3.2.1.vib —maintenance-mode —no-sig-check
- Une fois que le module Ethernet virtuel (VEM) est activé, vous pouvez ajouter des hôtes à votre AVS :
Dans la boîte de dialogue Ajouter un hôte au commutateur distribué vSphere, choisissez les ports de carte réseau virtuelle qui sont connectés au commutateur leaf (dans cet exemple, vous déplacez uniquement vmnic6), comme indiqué dans l'image :
- Cliquez sur Next (suivant).
- Dans la boîte de dialogue Connectivité réseau, cliquez sur Suivant
- Dans la boîte de dialogue Mise en réseau de la machine virtuelle, cliquez sur Suivant
- Dans la boîte de dialogue Prêt à terminer, cliquez sur Terminer
L'intégration d'AVS est désormais terminée et nous sommes prêts à poursuivre le déploiement d'ASAv de couches 4 à 7 :
Configuration initiale d'ASAv
- Téléchargez le package de périphérique Cisco ASAv et importez-le dans le contrôleur APIC :
Accédez à L4-L7 Services > Packages > Import Device Package, comme indiqué dans l'image :
- Si tout fonctionne correctement, vous pouvez voir le package de périphérique importé développer le dossier Types de périphériques de service de couches 4 à 7, comme illustré dans l'image :
Avant de continuer, vous devez déterminer quelques aspects de l'installation avant d'effectuer l'intégration réelle de couches 4 à 7 :
Il existe deux types de réseaux de gestion, la gestion intrabande et la gestion hors bande, qui peuvent être utilisés pour gérer des périphériques qui ne font pas partie de l'infrastructure axée sur les applications (ACI) de base (leaf, spines ou contrôleur apic) qui incluraient ASAv, des équilibreurs de charge, etc.
Dans ce cas, OOB pour ASAv est déployé avec l'utilisation de Standard vSwitch. Pour l'ASA sans système d'exploitation ou d'autres appareils et/ou serveurs de service, connectez le port de gestion OOB au commutateur OOB ou au réseau, comme illustré dans l'image.
La connexion de gestion de port OOB ASAv doit utiliser les ports de liaison ascendante ESXi pour communiquer avec le contrôleur APIC via OOB. Lors du mappage des interfaces vNIC, la carte réseau 1 correspond toujours à l'interface Management0/0 sur l'ASAv, et les autres interfaces de plan de données sont démarrées à partir de la carte réseau 2.
Le tableau 2 indique la concordance des ID d'adaptateur réseau et des ID d'interface ASAv :
Tableau 2
- Déployez la machine virtuelle ASAv via l'assistant à partir du modèle Fichier>Déployer OVF (Open Virtualization Format)
- Sélectionnez asav-esxi si vous souhaitez utiliser un serveur ESX autonome ou asav-vi pour vCenter. Dans ce cas, vCenter est utilisé.
- Accédez à l'Assistant d'installation, acceptez les conditions générales. Au milieu de l'Assistant, vous pouvez déterminer plusieurs options telles que le nom d'hôte, la gestion, l'adresse IP, le mode de pare-feu et d'autres informations spécifiques relatives à ASAv. N'oubliez pas d'utiliser la gestion OOB pour ASAv, car dans ce cas, vous devez conserver l'interface Management0/0 pendant que vous utilisez le réseau de VM (commutateur standard) et l'interface GigabitEthernet0-8 est le port réseau par défaut.
- Cliquez sur Finish et attendez la fin du déploiement d'ASAv
- Mettez votre machine virtuelle ASAv sous tension et connectez-vous via la console pour vérifier la configuration initiale
- Comme l'illustre l'image, une partie de la configuration de gestion est déjà transmise au pare-feu ASAv. Configurez le nom d'utilisateur et le mot de passe admin. Ce nom d'utilisateur et ce mot de passe sont utilisés par le contrôleur APIC pour se connecter et configurer l'ASA. L'ASA doit être connecté au réseau OOB et doit pouvoir atteindre le contrôleur APIC.
username admin password <device_password> crypté privilege 15
En outre, à partir du mode de configuration globale, activez http server :
http server enable
gestion http 0.0.0.0 0.0.0.0
L4-L7 pour l'intégration d'ASAv dans APIC :
- Connectez-vous à l'interface utilisateur graphique de l'ACI, cliquez sur le locataire sur lequel le graphique de service sera déployé. Développez les services de couches 4 à 7 en bas du volet de navigation, cliquez avec le bouton droit sur Périphériques de couches 4 à 7 et cliquez sur Créer des périphériques de couches 4 à 7 pour ouvrir l'assistant
-
Pour cette implémentation, les paramètres suivants seront appliqués :
- Mode géré
- Service de pare-feu
- Périphérique virtuel
- Connecté au domaine AVS avec un noeud unique
-Modèle ASAv
- Mode routé (GoTo)
-Adresse de gestion (doit correspondre à l'adresse précédemment attribuée à l'interface Mgmt0/0)
- Utiliser HTTPS comme APIC par défaut utilise le protocole le plus sécurisé pour communiquer avec ASAv
- La définition correcte des interfaces de périphériques et des interfaces de cluster est essentielle pour un déploiement réussi
Pour la première partie, utilisez le tableau 2 présenté dans la section précédente pour faire correspondre correctement les ID de carte réseau avec les ID d'interface ASAv que vous souhaitez utiliser. Le chemin fait référence au port physique, au port-channel ou au VPC qui permet d'entrer et de sortir des interfaces du pare-feu. Dans ce cas, ASA est situé sur un hôte ESX, où les entrées et les sorties sont identiques pour les deux interfaces. Dans une appliance physique, les ports physiques intérieurs et extérieurs au pare-feu (FW) sont différents.
Pour la deuxième partie, les interfaces Cluster doivent toujours être définies sans exception (même si Cluster HA n'est pas utilisé), car le modèle d'objet a une association entre l'interface mIf (méta interface sur le Device Package), l'interface LIf (interface leaf comme par exemple externe, interne, interne, etc.) et l'interface CIf (interface concrète). Les périphériques concrets de couches 4 à 7 doivent être configurés dans une configuration de cluster de périphériques et cette abstraction est appelée un périphérique logique. Le périphérique logique a des interfaces logiques qui sont mappées à des interfaces concrètes sur le périphérique concret.
Pour cet exemple, l'association suivante sera utilisée :
Gi0/0 = vmnic2 = ServerInt/provider/server > EPG1
Gi0/1 = vmnic3 = ClientInt/consommateur/client > EPG2
L'état du périphérique doit être Stable et vous devez être prêt à déployer le profil de fonction et le modèle de graphique de services
Temple de graphique de service
Tout d'abord, créez un profil de fonction pour ASAv, mais avant cela, vous devez créer un groupe de profils de fonction, puis un profil de fonction de services de couches 4 à 7 sous ce dossier, comme illustré dans l'image :
- Sélectionnez WebPolicyForRoutedMode Profile dans le menu déroulant et continuez à configurer les interfaces sur le pare-feu. À partir de là, les étapes sont facultatives et peuvent être mises en oeuvre/modifiées ultérieurement. Ces étapes peuvent être effectuées à différentes étapes du déploiement, selon la façon dont le graphique de services peut être réutilisable ou personnalisé.
Pour cet exercice, un pare-feu routé (mode GoTo) nécessite que chaque interface ait une adresse IP unique. La configuration ASA standard comporte également un niveau de sécurité d'interface (l'interface externe est moins sécurisée, l'interface interne est plus sécurisée). Vous pouvez également modifier le nom de l'interface selon vos besoins. Les valeurs par défaut sont utilisées dans cet exemple.
- Développez Interface Specific Configuration, ajoutez l'adresse IP et le niveau de sécurité pour ServerInt avec le format suivant pour l'adresse IP x.x.x.x/y.y.y.y ou x.x.x.x/yy. Répétez le processus pour l'interface ClientInt.
- Cliquez ensuite sur Envoyer
- À présent, créez le modèle de graphique de services
- Faites glisser et déposez le cluster de périphériques vers la droite pour établir la relation entre le consommateur et le fournisseur, sélectionnez Routed Mode (Mode routé) et le profil de fonction créé précédemment.
- Vérifier les erreurs du modèle. Les modèles sont créés pour être réutilisables, ils doivent ensuite être appliqués à des EPG particuliers, etc.
- Pour appliquer un modèle, cliquez avec le bouton droit de la souris et sélectionnez Appliquer un modèle de graphique de services de couches 4 à 7
- Définissez quel EPG sera du côté du consommateur et du côté du fournisseur. Dans cet exercice, AVS-EPG2 est le client et AVS-EPG1 est le fournisseur (serveur). N'oubliez pas qu'aucun filtre n'est appliqué, cela permettra au pare-feu d'effectuer tout le filtrage en fonction de la liste d'accès définie dans la dernière section de cet Assistant.
- Cliquez sur Next (suivant).
- Vérifiez les informations BD pour chacun des groupes de terminaux. Dans ce cas, EPG1 est le fournisseur sur la base de données IntBD et EPG2 est le consommateur sur la base de données ExtBD. EPG1 se connectera sur l'interface de pare-feu ServerInt et EPG2 sera connecté sur l'interface ClientInt. Les deux interfaces FW deviendront DG pour chacun des EPG, de sorte que le trafic est forcé de traverser le pare-feu à tout moment.
- Cliquez sur Next (suivant).
- Dans la section Config Parameters, cliquez sur All Parameters et vérifiez s'il y a des indicateurs ROUGES qui doivent être mis à jour/configurés. Dans la sortie, comme le montre l'image, on peut remarquer que l'ordre sur la liste d'accès est manqué. Cela équivaut à l'ordre des lignes que vous verrez dans une commande show ip access-list X.
- Vous pouvez également vérifier l'adressage IP attribué à partir du profil de fonction défini précédemment. Il est possible de modifier les informations si nécessaire. Une fois tous les paramètres définis, cliquez sur Finish, comme indiqué dans l'image :
- Si tout se passe bien, un nouveau périphérique déployé et une nouvelle instance de graphique doivent apparaître.
Vérifier
- Une chose importante à vérifier après la création du graphique de service est que la relation client/fournisseur a été créée avec le méta-connecteur approprié. Vérifiez sous les propriétés du connecteur de fonction.
- Maintenant, vous pouvez également vérifier les informations qui ont été envoyées à l'ASAv
- Un nouveau contrat est attribué dans le cadre des EPG. À partir de maintenant, si vous devez modifier quoi que ce soit sur la liste d'accès, la modification doit être effectuée à partir des paramètres de service de couches 4 à 7 de l'EPG fournisseur.
- Sur vCenter, vous pouvez également vérifier que les groupes de terminaux fantômes sont attribués à chacune des interfaces FW :
Pour ce test, j'avais les 2 EPG communiquant avec des contrats standard, ces 2 EPG se trouvent dans des domaines différents et des VRF différents, de sorte que la fuite de route entre eux a été précédemment configurée. Cela simplifie un peu après l'insertion du graphique de service, car le pare-feu configure le routage et le filtrage entre les 2 groupes de terminaux. Le DG précédemment configuré dans le cadre de l'EPG et du BD peut désormais être supprimé de la même manière que les contrats. Seul le contrat poussé par les couches 4 à 7 doit rester dans le cadre des groupes de terminaux.
À mesure que le contrat standard est supprimé, vous pouvez confirmer que le trafic circule désormais via l'ASAv. La commande show access-list doit afficher le nombre d'occurrences de la règle qui s'incrémente chaque fois que le client envoie une requête au serveur.
Sur le leaf, les terminaux doivent être appris pour les machines virtuelles client et serveur ainsi que pour les interfaces ASAv
voir les deux interfaces de pare-feu reliées au VEM.
ESX-1
ESX-2
Enfin, les règles de pare-feu peuvent également être vérifiées au niveau leaf si nous connaissons les balises PC pour les EPG source et de destination :
Les ID de filtre peuvent être mis en correspondance avec les balises PC sur le leaf pour vérifier les règles FW.
Et la communication entre le client et le serveur fonctionne.
Dépannage
L'adresse VTEP n'est pas attribuée
Vérifiez que le VLAN Infrastructure est vérifié sous l'AEP :
Version non prise en charge
Vérifiez que la version de VEM est correcte et prenez en charge le système VMware ESXi approprié.
~ # vem version Running esx version -1746974 x86_64 VEM Version: 5.2.1.3.1.10.0-3.2.1 OpFlex SDK Version: 1.2(1i) System Version: VMware ESXi 5.5.0 Releasebuild-1746974 ESX Version Update Level: 0
Communication VEM et fabric défaillante
- Check VEM status vem status - Try reloading or restating the VEM at the host: vem reload vem restart - Check if there’s connectivity towards the Fabric. You can try pinging 10.0.0.30 which is (infra:default) with 10.0.0.30 (shared address, for both Leafs) ~ # vmkping -I vmk1 10.0.0.30 PING 10.0.0.30 (10.0.0.30): 56 data bytes --- 10.0.0.30 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss If ping fails, check: - Check OpFlex status - The DPA (DataPathAgent) handles all the control traffic between AVS and APIC (talks to the immediate Leaf switch that is connecting to) using OpFlex (opflex client/agent).
All EPG communication will go thru this opflex connection. ~ # vemcmd show opflex Status: 0 (Discovering) Channel0: 0 (Discovering), Channel1: 0 (Discovering) Dvs name: comp/prov-VMware/ctrlr-[AVS]-vCenterController/sw-dvs-129 Remote IP: 10.0.0.30 Port: 8000 Infra vlan: 3967 FTEP IP: 10.0.0.32 Switching Mode: unknown Encap Type: unknown NS GIPO: 0.0.0.0 you can also check the status of the vmnics at the host level: ~ # esxcfg-vmknic -l Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type vmk0 Management Network IPv4 10.201.35.219 255.255.255.0 10.201.35.255 e4:aa:5d:ad:06:3e 1500 65535 true STATIC vmk0 Management Network IPv6 fe80::e6aa:5dff:fead:63e 64 e4:aa:5d:ad:06:3e 1500 65535 true STATIC, PREFERRED vmk1 160 IPv4 10.0.32.65 255.255.0.0 10.0.255.255 00:50:56:6b:ca:25 1500 65535 true STATIC vmk1 160 IPv6 fe80::250:56ff:fe6b:ca25 64 00:50:56:6b:ca:25 1500 65535 true STATIC, PREFERRED ~ # - Also on the host, verify if DHCP requests are sent back and forth: ~ # tcpdump-uw -i vmk1 tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode listening on vmk1, link-type EN10MB (Ethernet), capture size 96 bytes 12:46:08.818776 IP truncated-ip - 246 bytes missing! 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:56:6b:ca:25 (oui Unknown), length 300 12:46:13.002342 IP truncated-ip - 246 bytes missing! 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:56:6b:ca:25 (oui Unknown), length 300 12:46:21.002532 IP truncated-ip - 246 bytes missing! 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:56:6b:ca:25 (oui Unknown), length 300 12:46:30.002753 IP truncated-ip - 246 bytes missing! 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:56:6b:ca:25 (oui Unknown), length 300
À ce stade, il est possible de déterminer que la communication du fabric entre l'hôte ESXi et le leaf ne fonctionne pas correctement. Certaines commandes de vérification peuvent être vérifiées côté feuille pour déterminer la cause première.
leaf2# show cdp ne
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge
S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-Phone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute
Device-ID Local Intrfce Hldtme Capability Platform Port ID
AVS:localhost.localdomainmain
Eth1/5 169 S I s VMware ESXi vmnic4
AVS:localhost.localdomainmain
Eth1/6 169 S I s VMware ESXi vmnic5
N3K-2(FOC1938R02L)
Eth1/13 166 R S I s N3K-C3172PQ-1 Eth1/13
leaf2# show port-c sum
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
S - Switched R - Routed
U - Up (port-channel)
M - Not in use. Min-links not met
F - Configuration failed
-------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
-------------------------------------------------------------------------------
5 Po5(SU) Eth LACP Eth1/5(P) Eth1/6(P)Deux ports sont utilisés dans l'ESXi connecté via un Po5
leaf2# show vlan extended VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 13 infra:default active Eth1/1, Eth1/20 19 -- active Eth1/13 22 mgmt:inb active Eth1/1 26 -- active Eth1/5, Eth1/6, Po5 27 -- active Eth1/1 28 :: active Eth1/5, Eth1/6, Po5 36 common:pod6_BD active Eth1/5, Eth1/6, Po5 VLAN Type Vlan-mode Encap ---- ----- ---------- ------------------------------- 13 enet CE vxlan-16777209, vlan-3967 19 enet CE vxlan-14680064, vlan-150 22 enet CE vxlan-16383902 26 enet CE vxlan-15531929, vlan-200 27 enet CE vlan-11 28 enet CE vlan-14 36 enet CE vxlan-15662984D’après le résultat ci-dessus, il est possible de constater que le VLAN infrarouge n’est pas autorisé ou ne passe pas par les ports de liaisons ascendantes qui vont à l’hôte ESXi (1/5-6). Cela indique une mauvaise configuration avec la politique d'interface ou la politique de commutateur configurée sur le contrôleur APIC.
Vérifiez les deux :
Stratégies d'accès > Stratégies d'interface > Profils Stratégies d'accès > Stratégies de commutateur > Profils
Dans ce cas, les profils d'interface sont attachés au mauvais AEP (ancien AEP utilisé pour DVS), comme illustré dans l'image :
Après avoir défini l'AEP correct pour AVS, nous pouvons maintenant voir que le VLAN Infra est vu à travers les Unlinks appropriés au Leaf :
leaf2# show vlan extended
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
13 infra:default active Eth1/1, Eth1/5, Eth1/6,
Eth1/20, Po5
19 -- active Eth1/13
22 mgmt:inb active Eth1/1
26 -- active Eth1/5, Eth1/6, Po5
27 -- active Eth1/1
28 :: active Eth1/5, Eth1/6, Po5
36 common:pod6_BD active Eth1/5, Eth1/6, Po5
VLAN Type Vlan-mode Encap
---- ----- ---------- -------------------------------
13 enet CE vxlan-16777209, vlan-3967
19 enet CE vxlan-14680064, vlan-150
22 enet CE vxlan-16383902
26 enet CE vxlan-15531929, vlan-200
27 enet CE vlan-11
28 enet CE vlan-14
36 enet CE vxlan-15662984
and Opflex connection is restablised after restarting the VEM module:
~ # vem restart
stopDpa
VEM SwISCSI PID is
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.213997
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.213997
watchdog-vemdpa: Terminating watchdog process with PID 213974
~ # vemcmd show opflex
Status: 0 (Discovering)
Channel0: 14 (Connection attempt), Channel1: 0 (Discovering)
Dvs name: comp/prov-VMware/ctrlr-[AVS]-vCenterController/sw-dvs-129
Remote IP: 10.0.0.30 Port: 8000
Infra vlan: 3967
FTEP IP: 10.0.0.32
Switching Mode: unknown
Encap Type: unknown
NS GIPO: 0.0.0.0
~ # vemcmd show opflex
Status: 12 (Active)
Channel0: 12 (Active), Channel1: 0 (Discovering)
Dvs name: comp/prov-VMware/ctrlr-[AVS]-vCenterController/sw-dvs-129
Remote IP: 10.0.0.30 Port: 8000
Infra vlan: 3967
FTEP IP: 10.0.0.32
Switching Mode: LS
Encap Type: unknown
NS GIPO: 0.0.0.0
Informations connexes
Installation du commutateur virtuel d'application
Cisco Systems, Inc. Guide d'installation du commutateur virtuel d'application Cisco, version 5.2(1)SV3(1.2)Déploiement d'ASAv avec VMware
Livre blanc sur la conception de services graphiques avec l'infrastructure axée sur les applications Cisco
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
11-Apr-2016
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)