DANE pour appliance de sécurité de la messagerie

Options de téléchargement

  • PDF     (835.5 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (692.6 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (380.7 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:26 août 2019
ID du document:214794

Langage exempt de préjugés

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.

À propos de cette traduction

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.

    Introduction

    Ce document décrit l'implémentation DANE pour le flux de messages sortants ESA.

    Conditions préalables

    Connaissance générale des concepts et de la configuration ESA.

    Exigences relatives à la mise en oeuvre du DANE :

    • Résolveur DNS compatible DNSSEC
    • ESA avec AsyncOS 12.0 ou version ultérieure

    Informations générales

    DANE a été introduit dans ESA 12 pour la validation du courrier sortant.

    Authentification DNS des entités nommées (DANE).

    • DANE est un protocole de sécurité Internet qui permet de lier des certificats numériques X.509 à des noms de domaine à l'aide de DNSSEC. (RFC 6698)
    • DNSSEC est un ensemble de spécifications IETF pour la sécurisation des enregistrements DNS à l'aide de la cryptographie à clé publique. (Explication très élémentaire. RFC 4033, RFC 4034 et RFC 4035)

    Considérations relatives à la mise en oeuvre

    Vérifiez que l'ESA utilise un résolveur DNS compatible dnssec.

    La capacité DNS à exécuter des requêtes DNSSEC/DANE est requise pour implémenter DANE.

    Pour tester la fonctionnalité ESA DNS DANE, un test simple peut être effectué à partir de la connexion à l'interface de ligne de commande ESA.

    La commande CLI « daneverify » exécute les requêtes complexes pour vérifier si un domaine est capable de passer la vérification DANE.

    La même commande peut être utilisée avec un domaine valide connu pour confirmer la capacité de l'ESA à résoudre les requêtes dnssec.

    'ietf.org' est une source mondialement connue. L'exécution de la commande cli « daneverify » permet de vérifier si le résolveur DNS est compatible DANE ou non.

    RÉUSSITE VALIDE : RÉSULTATS « DANE SUCCESS » DU SERVEUR DNS COMPATIBLE DANE POUR ietf.org

    > daneverify ietf.org

    SECURE MX record(mail.ietf.org) found for ietf.org
    SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
    Connecting to 4.31.198.44 on port 25.
    Connected to 4.31.198.44 from interface 216.71.133.161.
    SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
    Checking TLS connection.
    TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
    Certificate verification successful
    TLS connection succeeded ietf.org.
    DANE SUCCESS for ietf.org
    DANE verification completed.

    ÉCHEC NON VALIDE : RÉSULTATS « FAUX » DE SERVEUR DNS NON DANOIS POUR ietf.org

    > daneverify ietf.org

    BOGUS MX record found for ietf.org
    DANE FAILED for ietf.org
    DANE verification completed.

    ECHEC VALIDE : daneverify cisco.com > cisco n'a pas implémenté DANE. Il s'agit du résultat attendu d'un résolveur compatible dnssec.

    > daneverify cisco.com

    INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
    Trying next MX record in cisco.com
    INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
    Trying next MX record in cisco.com
    INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
    DANE FAILED for cisco.com
    DANE verification completed.

    Si les tests ci-dessus "VALIDE" fonctionnent :

    • Une approche prudente consisterait à tester chaque domaine avant d'ajouter un profil pour le domaine.
    • Une approche plus agressive serait de configurer DANE sur le profil de contrôle de la destination par défaut et de voir qui réussit/échoue.

    La direction du courrier détermine si le DANE vérifiera.

    Les stratégies de groupe d'expéditeurs/de flux de messages pour lesquelles l'action « RELAIS » est configurée effectueront une vérification DANE.

    Les stratégies de groupe d'expéditeurs/de flux de messagerie dont l'action « ACCEPT » est configurée n'attendront PAS la vérification DANE.

    Attention : si le contrôle de destination DANE est activé sur la stratégie par défaut de l'ESA, il existe un risque d'échec de livraison.  Si un domaine interne, tel que ceux répertoriés dans le TAD, passe par les politiques de flux de messages RELAY et ACCEPT, associées à la présence d'une route SMTP pour le domaine.

    Routes SMTP

    DANE échouera sur les routes SMTP à moins que l'hôte de destination ne soit configuré sur USEDNS.

    DANE Opportunistic ne remettra pas les messages, les contenant dans la file d'attente de remise jusqu'à l'expiration du minuteur de profil de renvoi.

    Pourquoi ? La vérification DANE est ignorée car une route SMTP serait une modification de la destination réelle et pourrait ne pas utiliser correctement DNS.

    Solution : créez des profils de contrôle de destination pour désactiver explicitement la vérification DANE pour les domaines contenant des routes SMTP

    DANE Opportuniste ou DANE Obligatoire

    Les recherches suivantes sont effectuées lors de la vérification DANE.

    Chaque vérification alimente le contenu pour effectuer la vérification suivante.

    • La recherche d'enregistrement MX vérifie si >>> est sécurisé, non sécurisé, faux
    • Une recherche d'enregistrement vérifie si >>> Secure Insecure > Bogus
    • La recherche d'enregistrements TLSA vérifie si >>> est sécurisé, non sécurisé, faux, NXDOMAIN
    • Vérification du certificat >> Réussite, Échec

    Sécurisé :

    • DNS a vérifié la présence d'un enregistrement sécurisé contenant un DNS et une DNSKEY RRSIG validés et signés, en amont de la chaîne de confiance.

    Non sécurisé :

    • Le DNS détermine que le domaine n'a pas d'enregistrement activé dnssec présent. 

    Faux :

    • Les entrées dnssec présentes sont incomplètes, mais la vérification peut échouer.
    • Enregistrements non valides en raison d'une clé expirée.
    • Enregistrement ou clé manquant dans la chaîne d'approbation.

    NXDOMAIN

    • Aucun enregistrement trouvé dans DNS.

    Une combinaison de la vérification des dossiers ci-dessus et des résultats de la vérification déterminera le succès du DANE | DANE Fail | DANE revient à TLS."

    Par exemple : si aucun enregistrement RRSIG n'est envoyé pour l'enregistrement MX d'example.com, la zone parent (.com) est vérifiée pour voir si example.com a un enregistrement DNSKEY, indiquant que example.com devrait signer ses enregistrements. Cette validation se poursuit jusqu'à la fin de la chaîne de confiance avec la vérification de la clé de la zone racine (.). Les clés de la zone racine correspondent à ce que l'ESA attend (valeurs codées en dur sur l'ESA, qui est automatiquement mis à jour sur la base de RFC5011).

    DANOIS OBLIGATOIRE

    DANOIS OBLIGATOIRE

    Note : DANE OPPORTUNISTIC NE SE COMPORTE PAS COMME TLS PRÉFÉRÉ. La partie ACTION du tableau ci-dessous indique que DANE FAIL n'est pas disponible pour Obligatoire ou Opportuniste. Les messages resteront dans la file d'attente de remise jusqu'à l'expiration du minuteur, puis la remise se terminera.

    DANOIS OPPORTUNISTE

    DANOIS OPPORTUNISTE

    Activer DANE sur plusieurs environnements d'appareils

    La figure suivante illustre le workflow lorsque vous activez DANE dans un environnement à plusieurs appliances.

    Si l'environnement comporte plusieurs couches d'appliances ESA, une pour l'analyse et une autre pour la remise des messages. Assurez-vous que DANE n'est configuré que sur l'appliance qui se connecte directement aux destinations externes.

    Conception multi-ESA. DANE configuré sur l'ESA de livraison

    Gestion de plusieurs résolveurs DNS

    Si un ESA a plusieurs résolveurs DNS configurés, quelques-uns qui prennent en charge DNSSEC et quelques-uns qui ne prennent pas en charge DNSSEC, Cisco recommande de configurer les résolveurs compatibles DNSSEC avec une priorité plus élevée (valeur numérique inférieure), pour éviter les incohérences.

    Cela empêche le résolveur non DNSSEC de classer le domaine de destination prenant en charge DANE comme « faux ».

    Gestion du serveur DNS secondaire

    Lorsque le résolveur DNS n'est pas accessible, le serveur DNS revient au serveur DNS secondaire. Si vous ne configurez pas DNSSEC sur le serveur DNS secondaire, les enregistrements MX pour les domaines de destination compatibles DANE sont classés comme « faux ». Cela a un impact sur la remise des messages, quels que soient les paramètres DANE (Opportuniste ou Obligatoire). Cisco vous recommande d'utiliser un résolveur DNSSEC secondaire.

    Configuration

    Configurez DANE pour le flux de messages sortants.

    1. Webui Naviguez jusqu'à > Politiques de messagerie > Contrôles de la destination > Ajouter une destination
    2. Remplissez la partie supérieure du profil selon vos préférences.
    3. Prise en charge TLS : doit être définie sur « TLS Preferred » | Préféré - Vérifier | Requis | Obligatoire - Vérifier| Obligatoire - Vérifiez le domaine hébergé."
    4. Une fois le support TLS activé, le menu déroulant DANE Support (Support DANE) s'active.
    5. Assistance DANE : les options incluent « Aucun » | Opportuniste | Obligatoire.
    6. Une fois l'option DANE Support terminée, envoyez et validez les modifications.

    Profil de contrôle de la destination - Vérification DANE

    Vérification du succès du DANE

    État de livraison

    Surveillez le rapport WebUI « Delivery Status » pour détecter toute accumulation non intentionnelle de domaines de destination, potentiellement due à une défaillance DANE.

    Effectuez cette opération avant d'activer le service, puis régulièrement pendant plusieurs jours afin d'assurer une réussite continue.

    ESA WebUI > Monitor > Delivery Status > cochez la colonne « Active Recipients ».

    Journaux de messagerie

    Journaux de messagerie par défaut au niveau d'information pour le niveau de journal.

    Les journaux de messagerie affichent des indicateurs très subtils pour les messages négociés avec succès par DANE.

    La négociation TLS sortante finale inclura une sortie légèrement modifiée pour inclure le domaine à la fin de l'entrée de journal.

    L'entrée de journal inclura « TLS success protocol » suivi de TLS version/cipher « for domain.com ».

    La magie est dans le "pour" :

    myesa.local> grep "TLS success.*for" mail_logs

    Tue Feb  5 13:20:03 2019 Info: DCID 2322371 TLS success protocol TLSv1.2 cipher DHE-RSA-AES256-GCM-SHA384 for karakun.com

    Débogage des journaux de messagerie

    Les journaux de messagerie personnalisés au niveau du débogage affichent les recherches DANE et dnssec complètes, la négociation attendue, les parties de la vérification qui réussissent/échouent et un indicateur de réussite.

    Remarque : les journaux de messagerie configurés pour la journalisation de niveau de débogage peuvent consommer des ressources excessives sur un ESA en fonction de la charge et de la configuration du système.

    Les journaux de messagerie configurés pour la consignation au niveau du débogage peuvent consommer des ressources excessives sur un ESA en fonction de la charge et de la configuration du système.

    Les journaux de messagerie ne sont généralement PAS conservés au niveau de débogage pendant de longues périodes.

    Les journaux de niveau de débogage peuvent générer un volume considérable de journaux de messages en peu de temps.

    Il est fréquent de créer un abonnement de journal supplémentaire pour mail_logs_d et de définir la journalisation pour DEBUG.

    Cette action empêche l'impact sur les journaux de messagerie existants et permet la manipulation du volume de journaux conservés pour l'abonnement.

    Pour contrôler le volume des journaux créés, limitez le nombre de fichiers à gérer à un nombre inférieur, par exemple 2 à 4 fichiers.

    Lorsque la surveillance, la période d'essai ou le dépannage est terminé, désactivez le journal.

    Les journaux de messagerie définis pour le niveau de débogage affichent une sortie DANE très détaillée :

    Success sample daneverify
    daneverify ietf.org

    SECURE MX record(mail.ietf.org) found for ietf.org
    SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
    Connecting to 4.31.198.44 on port 25.
    Connected to 4.31.198.44 from interface 194.191.40.74.
    SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
    Checking TLS connection.
    TLS connection established: protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384.
    Certificate verification successful
    TLS connection succeeded ietf.org.
    DANE SUCCESS for ietf.org
    DANE verification completed.


    debug level mail logs during the above 'daneverify' exeuction.
    Sample output from the execution of the daneverify ietf.org will populate the dns lookups within the mail logs
    Mon Feb  4 20:08:47 2019 Debug: DNS query: Q('ietf.org', 'MX')
    Mon Feb  4 20:08:47 2019 Debug: DNS query: QN('ietf.org', 'MX', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:47 2019 Debug: DNS query: QIP  ('ietf.org','MX','194.191.40.84',60)
    Mon Feb  4 20:08:47 2019 Debug: DNS query: Q  ('ietf.org', 'MX', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([(0, 'mail.ietf.org.')], secure, 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: DNS encache (ietf.org, MX, [(8496573380345476L, 0, 'SECURE', (0, 'mail.ietf.org'))])
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'A')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'A', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','A','194.191.40.84',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'A', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data(['4.31.198.44'], secure, 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: DNS encache (mail.ietf.org, A, [(8496573380345476L, 0, 'SECURE', '4.31.198.44')])
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'AAAA')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'AAAA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','AAAA','194.191.40.84',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'AAAA', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Warning: Received an invalid DNSSEC Response: DNSSEC_Error('mail.ietf.org', 'AAAA', '194.191.40.84', 'DNSSEC Error for hostname mail.ietf.org (AAAA) while asking 194.191.40.84. Error was: Unsupported qtype') of qtype AAAA looking up mail.ietf.org
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'CNAME')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'CNAME', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','CNAME','194.191.40.83',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'CNAME', '194.191.40.83')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([], , 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: Received NODATA for domain mail.ietf.org type CNAME
    Mon Feb  4 20:08:48 2019 Debug: No CNAME record(NoError) found for domain(mail.ietf.org)

    Mon Feb  4 20:08:49 2019 Debug: DNS query: Q('_25._tcp.mail.ietf.org', 'TLSA')
    Mon Feb  4 20:08:49 2019 Debug: DNS query: QN('_25._tcp.mail.ietf.org', 'TLSA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:49 2019 Debug: DNS query: QIP  ('_25._tcp.mail.ietf.org','TLSA','194.191.40.83',60)
    Mon Feb  4 20:08:49 2019 Debug: DNS query: Q  ('_25._tcp.mail.ietf.org', 'TLSA', '194.191.40.83')
    Mon Feb  4 20:08:49 2019 Debug: DNSSEC Response data(['0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6'], secure, 0, 1800)
    Mon Feb  4 20:08:49 2019 Debug: DNS encache (_25._tcp.mail.ietf.org, TLSA, [(8496577312207991L, 0, 'SECURE', '0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6')])
    fail sample daneverify

    []> thinkbeyond.ch

    INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found for thinkbeyond.ch
    INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found. The command will still proceed.
    INSECURE A record (104.47.9.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    Trying next A record (104.47.10.36) for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    INSECURE A record (104.47.10.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    DANE FAILED for thinkbeyond.ch
    DANE verification completed.

    mail_logs
    Sample output from the execution of he danverify thinkbeyond.ch will populate the dns lookups within the mail logs
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond.ch', 'MX')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond.ch', 'MX', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond.ch','MX','194.191.40.84',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond.ch', 'MX', '194.191.40.84')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([(10, 'thinkbeyond-ch.mail.protection.outlook.com.')], insecure, 0, 3600)
    Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond.ch, MX, [(8502120882844461L, 0, 'INSECURE', (10, 'thinkbeyond-ch.mail.protection.outlook.com'))])
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'A')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'A', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','A','194.191.40.83',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'A', '194.191.40.83')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data(['104.47.9.36', '104.47.10.36'], insecure, 0, 10)
    Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond-ch.mail.protection.outlook.com, A, [(8497631700844461L, 0, 'INSECURE', '104.47.9.36'), (8497631700844461L, 0, 'INSECURE', '104.47.10.36')])
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','AAAA','194.191.40.84',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', '194.191.40.84')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([], , 0, 32768)
    Mon Feb  4 20:15:52 2019 Debug: Received NODATA for domain thinkbeyond-ch.mail.protection.outlook.com type AAAA
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.83',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.83')
    Mon Feb  4 20:15:53 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.83 looking up thinkbeyond-ch.mail.protection.outlook.com
    Mon Feb  4 20:15:53 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.84',60)
    Mon Feb  4 20:15:53 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.84')
    Mon Feb  4 20:15:54 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.84 looking up thinkbeyond-ch.mail.protection.outlook.com
    Mon Feb  4 20:15:54 2019 Debug: No CNAME record() found for domain(thinkbeyond-ch.mail.protection.outlook.com)

    Informations connexes

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    26-Aug-2019
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Guru Narala
      Ingénieur TAC Cisco
    • Chris Arellano
      Ingénieur Tac Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits