DANE per Email Security Appliance

Opzioni per il download

  • PDF     (835.0 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (690.8 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (378.1 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:26 agosto 2019
ID documento:214794

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    Questo documento descrive l'implementazione DANE per il flusso di posta in uscita ESA.

    Prerequisiti

    Conoscenza generale dei concetti e della configurazione ESA.

    Requisiti per implementare DANE:

    • Sistema di risoluzione DNS compatibile con DNSSEC
    • ESA con AsyncOS 12.0 o versione successiva

    Premesse

    Il DANE è stato introdotto nel SEC 12 per la convalida della posta in uscita.

    Autenticazione basata su DNS di entità denominate (DANE).

    • DANE è un protocollo di sicurezza Internet che consente di associare certificati digitali X.509 a nomi di dominio tramite DNSSEC. (RFC 6698)
    • DNSSEC è un insieme di specifiche IETF per la protezione dei record DNS tramite l'utilizzo della crittografia a chiave pubblica. (Spiegazione molto elementare. RFC 4033, RFC 4034 e RFC 4035)

    Considerazioni per l'implementazione

    Verificare che l'ESA utilizzi un sistema di risoluzione DNS compatibile con dnssec.

    Per implementare DANE è necessaria la funzionalità DNS per eseguire query dnssec/DANE.

    Per verificare la funzionalità DANE DNS dell'ESA è possibile eseguire un semplice test dall'accesso all'interfaccia CLI dell'ESA.

    Il comando CLI 'daneverify' eseguirà le query complesse per verificare se un dominio è in grado di passare la verifica DANE.

    Lo stesso comando può essere utilizzato con un dominio sicuramente funzionante per confermare la capacità dell'ESA di risolvere le query dnssec.

    'ietf.org' è un'origine nota a livello globale. L'esecuzione del comando cli 'daneverify' consente di verificare se il sistema di risoluzione DNS supporta o meno DANE.

    PASSAGGIO VALIDO: RISULTATI "DANE SUCCESS" DEL SERVER DNS CON SUPPORTO DANE PER 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.

    ERRORE NON VALIDO: RISULTATI "BOGUS" DEL SERVER DNS NON DANE PER ietf.org

    > daneverify ietf.org

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

    ERRORE VALIDO: daneverify cisco.com > cisco non ha implementato DANE. Questo è il risultato previsto da un resolver che supporta 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.

    Se le prove di cui sopra funzionano in modo "VALIDO":

    • Un approccio prudente consiste nel testare ogni dominio prima di aggiungere un profilo per il dominio stesso.
    • Un approccio più aggressivo sarebbe quello di configurare DANE sul profilo dei controlli di destinazione di default e vedere chi supera/non supera i controlli.

    Direzione posta determina se DANE verificherà.

    I criteri di flusso del gruppo di mittenti/posta per i quali è configurata l'azione "INOLTRA" eseguiranno la verifica DANE.

    I criteri di flusso del gruppo di mittenti/posta per i quali è configurata l'azione "ACCETTO" NON eseguiranno la verifica DANE.

    Attenzione: se l'ESA ha abilitato i controlli di destinazione "DANE" sulla politica predefinita, vi è il rischio di mancata consegna.  Se un dominio di proprietà interna, ad esempio quelli elencati nell'RAT, passa attraverso i criteri di flusso di posta RELAY e ACCEPT, insieme alla presenza di una route SMTP per il dominio.

    Route SMTP

    DANE non riuscirà sulle route SMTP a meno che "Host di destinazione" non sia configurato su "USEDNS".

    DANE Opportunistic non recapita i messaggi che li contengono nella coda di recapito fino alla scadenza del timer del profilo di rimbalzo.

    Perché? La verifica DANE viene ignorata perché una route SMTP rappresenterebbe una modifica della destinazione effettiva e potrebbe non utilizzare correttamente il DNS.

    Soluzione: creare profili di controllo di destinazione per disabilitare in modo esplicito la verifica DANE per i domini contenenti route SMTP

    DANE Opportunistico o DANE Obbligatorio

    Le seguenti ricerche vengono eseguite durante la verifica DANE.

    Ogni verifica alimenta il contenuto per eseguire la verifica successiva.

    • La ricerca dei record MX verifica se >>> è sicura, non sicura e falsa
    • Una ricerca di record verifica se >>> Sicuro non sicuro > Falso
    • La ricerca dei record TLSA verifica se >>> Secure, Insecure, Bogus, NXDOMAIN
    • Verifica certificato >> Riuscita, non riuscita

    Sicuro:

    • Il DNS ha verificato la presenza di un record sicuro contenente un DS RRSIG convalidato e firmato e DNSKEY, in tutta la catena di attendibilità.

    Non sicuro:

    • Il DNS determina che nel dominio non sono presenti record abilitati per dnssec. 

    Falso:

    • Incompleto, ma la verifica delle voci dnssec correnti potrebbe non riuscire.
    • Record non validi. Chiave scaduta.
    • Record o chiave mancante nella catena di attendibilità.

    NXDOMAIN

    • Nessun record trovato nel DNS.

    Una combinazione del controllo dei record di cui sopra e dei risultati della verifica determinerà il successo di DANE | DANE Fail | DANE fallback su TLS."

    Ad esempio, se non è stato inviato alcun RRSIG per il record MX di example.com, la zona padre (.com) viene controllata per verificare se example.com ha un record DNSKEY, indicando che example.com deve firmare i propri record. Questa convalida prosegue lungo la catena di attendibilità fino a raggiungere la verifica della chiave della zona radice (.) e le chiavi della zona radice corrispondono a quanto previsto dall'ESA (valori hardcoded sull'ESA, che viene aggiornato automaticamente in base a RFC5011).

    DANE OBBLIGATORIO

    DANE OBBLIGATORIO

    Nota: DANE OPPORTUNISTIC NON SI COMPORTA COME TLS PREFERITO. La parte ACTION del grafico riportato di seguito restituisce DANE FAIL, che non viene consegnato per Obbligatorio o Opportunistico. I messaggi rimarranno nella coda di recapito fino alla scadenza del timer, quindi il recapito terminerà.

    DANE OPPORTUNISTA

    DANE OPPORTUNISTA

    Abilitazione di DANE in ambienti con più appliance

    Nella figura seguente viene illustrato il flusso di lavoro quando si attiva DANE in un ambiente con più accessori.

    Se nell'ambiente sono presenti più livelli di appliance ESA, uno per la scansione e l'altro per la trasmissione dei messaggi. Assicurarsi che DANE venga configurato solo sull'appliance che si connette direttamente alle destinazioni esterne.

    Design Multi-ESA. DANE configurato sull'ESA di consegna

    Gestione di più resolver DNS

    Se per un'ESA sono configurati più resolver DNS, alcuni che supportano DNSSEC altri che non supportano DNSSEC, Cisco consiglia di configurare i resolver compatibili con DNSSEC con una priorità più alta (valore numerico inferiore), per evitare incoerenze.

    In questo modo il resolver non DNSSEC non è in grado di classificare il dominio di destinazione che supporta DANE come 'Bogus'.

    Gestione del server DNS secondario

    Quando il resolver DNS non è raggiungibile, il DNS torna al server DNS secondario. Se non si configura DNSSEC sul server DNS secondario, i record MX per i domini di destinazione compatibili con DANE vengono classificati come "Bogus". Ciò influisce sul recapito del messaggio indipendentemente dalle impostazioni DANE (Opportunistica o Obbligatoria). Cisco consiglia di utilizzare un sistema di risoluzione DNSSEC secondario.

    Configurazione

    Configurare DANE per il flusso di posta in uscita.

    1. Webui Selezionare > Mail Policies > Destination Controls > Add Destination
    2. Completare la parte superiore del profilo in base alle proprie preferenze.
    3. Supporto TLS: deve essere impostato su "TLS Preferred | Preferito - Verifica | Obbligatorio | Obbligatorio - Verifica| Obbligatorio - Verificare il dominio ospitato."
    4. Una volta attivato il supporto TLS, il supporto DANE: il menu a discesa diventa attivo.
    5. Supporto DANE: le opzioni includono "Nessuno | Opportunistico | Obbligatorio.
    6. Una volta completata l'opzione di supporto DANE, inviare e confermare le modifiche.

    Profilo di controllo destinazione - Verifica DANE

    Verifica riuscita DANE

    Stato consegna

    Monitorare il report WebUI sullo stato di recapito per individuare eventuali creazioni non intenzionali dei domini di destinazione, potenzialmente dovute a errori DANE.

    Eseguire questa operazione prima di attivare il servizio, quindi periodicamente per diversi giorni per garantire il successo continuo.

    ESA WebUI > Monitor > Stato consegna > controllare la colonna "Destinatari attivi".

    Log di posta

    Log di posta predefiniti a livello informativo per il log.

    I log di posta mostrano indicatori molto sottili per i messaggi DANE negoziati correttamente.

    La negoziazione TLS finale in uscita includerà un output leggermente modificato in modo da includere il dominio alla fine della voce del log.

    La voce registrata nel log include "TLS success protocol" seguito da TLS version/cipher "for domain.com".

    La magia sta nel "for":

    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

    Debug dei log di posta

    I log di posta personalizzati a livello di debug visualizzano le ricerche DANE e dnssec complete, le negoziazioni previste, le parti del controllo superate/non riuscite e un indicatore di riuscita.

    Nota: i log di posta configurati per la registrazione a livello di debug possono consumare risorse eccessive su un'ESA a seconda del carico e della configurazione del sistema.

    I log di posta configurati per la registrazione a livello di debug possono consumare risorse eccessive su un'ESA, a seconda del carico del sistema e della configurazione.

    I log di posta in genere NON vengono gestiti a livello di debug per lunghi periodi di tempo.

    I registri a livello di debug possono generare un enorme volume di log di posta in un breve periodo di tempo.

    Una procedura frequente consiste nel creare una sottoscrizione di log aggiuntiva per mail_logs_d e impostare la registrazione per DEBUG.

    L'azione impedisce l'impatto sui mail_logs esistenti e consente la modifica del volume dei log gestiti per la sottoscrizione.

    Per controllare il volume dei log creati, limitare il numero di file da mantenere a un numero inferiore, ad esempio 2-4 file.

    Al termine del monitoraggio, del periodo di prova o della risoluzione dei problemi, disabilitare il registro.

    I log di posta impostati per il livello di debug mostrano un output DANE molto dettagliato:

    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)

    Informazioni correlate

    Cronologia delle revisioni

    Revisione Data di pubblicazione Commenti
    1.0
    26-Aug-2019
    Versione iniziale
    TAC Authored

    Contributo dei tecnici Cisco

    • Guru Narala
      Cisco TAC Engineer
    • Chris Arellano
      Cisco Tac Engineer

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci

    Questo documento si applica a questi prodotti