Configurazione del tunnel IOS XE ad accesso sicuro tramite BGP ed ECMP
Sommario
Introduzione
In questo documento viene descritto come configurare e risolvere i problemi relativi al tunnel VPN IPSec tra Cisco Secure Access e Cisco IOS XE con BGP e ECMP.
Esempio di rete
In questo esempio di laboratorio, la rete 192.168.150.0/24 ha un segmento LAN dietro il dispositivo Cisco IOS XE e la rete 192.168.200.0/24 ha un pool IP usato da RAVPN con utenti che si connettono all'headend di Secure Access.
L'obiettivo finale è quello di utilizzare il protocollo ECMP sui tunnel VPN tra il dispositivo Cisco IOS XE e l'headend Secure Access. Per una migliore comprensione della topologia, fare riferimento al diagramma:
Nota: Questo è un flusso di pacchetto di esempio in cui è possibile applicare gli stessi principi a qualsiasi altro flusso e alla subnet Secure Internet Access da 192.168.150.0/24 dietro un router Cisco IOS XE.
Prerequisiti
Requisiti
È consigliabile conoscere i seguenti argomenti:
- Configurazione e gestione della CLI di Cisco IOS XE
- Conoscenze base dei protocolli IKEv2 e IPSec
- Configurazione iniziale di Cisco IOS XE (indirizzo IP, SSH, licenza)
- Conoscenze base di BGP ed ECMP
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- C800V con versione software 17.9.4a
- PC Windows
- Cisco Secure Access Organization
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
I tunnel di rete in Secure Access hanno un limite di larghezza di banda di 1 Gbps per tunnel singolo. Se la larghezza di banda Internet a monte/a valle è superiore a 1 Gbps e si desidera utilizzarla completamente, è necessario configurare più tunnel utilizzando lo stesso centro dati ad accesso sicuro raggruppandoli in un unico gruppo ECMP.
Quando si terminano più tunnel con un unico gruppo di tunnel di rete (all'interno di un singolo controller di dominio ad accesso sicuro), per impostazione predefinita questi costituiscono un gruppo ECMP dal punto di vista dell'headend ad accesso sicuro. Dopo aver inviato il traffico verso il dispositivo VPN locale, l'headend Secure Access esegue il bilanciamento del carico tra i tunnel (presupponendo che i peer BGP ricevano le route corrette).
Per ottenere la stessa funzionalità con il dispositivo VPN locale, è necessario configurare più interfacce VTI su un singolo router e verificare che vengano applicate le configurazioni di routing corrette. In questo articolo vengono illustrati gli scenari con una spiegazione di ogni passaggio.
Configurazione
Configurazione accesso sicuro
Per formare un gruppo ECMP da più tunnel VPN con protocollo BGP, è necessario applicare configurazioni speciali sul lato dell'accesso sicuro.
Configurare il gruppo di tunnel di rete:
- Creare un nuovo gruppo tunnel di rete (o modificarne uno esistente):
- Specificare l'ID tunnel e la passphrase:
- Configurare le opzioni di instradamento, specificare l'instradamento dinamico e immettere il numero AS interno. In questo scenario di laboratorio, l'ASN è pari a 65000:
- Prendere nota dei dettagli del tunnel nella sezione Dati per impostazione tunnel.
Configurazione di Cisco IOS XE
Questa sezione descrive la configurazione CLI che deve essere applicata al router Cisco IOS XE. Per configurare correttamente i tunnel IKEv2, il protocollo BGP di prossimità e il bilanciamento del carico ECMP su interfacce del tunnel virtuale.
Ogni sezione viene spiegata e vengono indicate le avvertenze più comuni.
Parametri IKEv2 e IPsec
Configurare il criterio IKEv2 e la proposta IKEv2. Questi parametri definiscono gli algoritmi utilizzati per l'associazione di protezione IKE (fase 1):
crypto ikev2 proposal sse-proposal
encryption aes-gcm-256
prf sha256
group 19 20
crypto ikev2 policy sse-pol
proposal sse-proposal
Nota: Fare riferimento ai parametri consigliati e ottimali indicati in grassetto nella Guida SSE dei parametri IPSec supportati.
Definire il keyring IKEv2 che spiega l'indirizzo IP dell'headend e la chiave precondivisa utilizzata per l'autenticazione con l'headend SSE:
crypto ikev2 keyring sse-keyring
peer sse
address 35.179.86.116
pre-shared-key local <boring_generated_password>
pre-shared-key remote <boring_generated_password>
Configura coppia di profili IKEv2
In questo modo viene definito il tipo di identità IKE da utilizzare, che corrisponde al peer remoto e che identità IKE il router locale invia al peer. L'identità IKE dell'headend SSE è di tipo indirizzo IP ed è uguale all'IP pubblico dell'headend SSE.
Avviso: Per stabilire più tunnel con lo stesso Network Tunnel Group sul lato SSE, tutti devono utilizzare la stessa identità IKE locale. Cisco IOS XE non supporta scenari di questo tipo, in quanto richiede una coppia univoca di identità IKE locali e remote per tunnel. Per superare questo limite, l'headend SSE è stato migliorato per accettare l'ID IKE nel formato seguente: <id_tunnel>+<suffisso>@<org><hub>.sse.cisco.com
Come accennato nello scenario lab, l'ID del tunnel è stato definito come: cat8k-dmz. In uno scenario normale, è possibile configurare il router in modo che invii l'identità IKE locale come: cat8k-dmz@8195165-622405748-sse.cisco.com.
Tuttavia, per stabilire più tunnel con lo stesso Network Tunnel Group, utilizzare gli ID IKE locali: cat8k-dmz+tunnel1@8195165-622405748-sse.cisco.com e cat8k-dmz+tunnel2@8195165-622405748-sse.cisco.com.
Il suffisso aggiunto a ciascuna stringa: (tunnel1 e tunnel2).
Nota: Come accennato precedentemente. le identità IKE locali sono esempi utilizzati in questo scenario di laboratorio. È possibile definire qualsiasi suffisso desiderato, solo assicurarsi di soddisfare i requisiti.
crypto ikev2 profile sse-ikev2-profile-tunnel1
match identity remote address 35.179.86.116 255.255.255.255
identity local email cat8k-dmz+tunnel1@8195165-622405748-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
crypto ikev2 profile sse-ikev2-profile-tunnel2
match identity remote address 35.179.86.116 255.255.255.255
identity local email cat8k-dmz+tunnel2@8195165-622405748-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
Configurare il set di trasformazioni IPSec. Questa impostazione definisce gli algoritmi utilizzati per l'associazione di protezione IPSec (fase 2):
crypto ipsec transform-set sse-transform esp-gcm 256
mode tunnel
Configurare i profili IPSec che collegano i profili IKEv2 ai set di trasformazioni:
crypto ipsec profile sse-ipsec-profile-1
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel1
crypto ipsec profile sse-ipsec-profile-2
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel2
Interfacce tunnel virtuale
In questa sezione vengono illustrate le configurazioni delle interfacce tunnel virtuale e delle interfacce di loopback utilizzate come origini del tunnel. Nello scenario di laboratorio descritto in precedenza, è necessario stabilire due interfacce VTI con un singolo peer utilizzando lo stesso indirizzo IP pubblico. Inoltre, il dispositivo Cisco IOS XE ha solo un'interfaccia in uscita Gigabit Ethernet1. Cisco IOS XE non supporta configurazioni di più VTI con la stessa origine del tunnel e destinazione del tunnel.
Per superare questo limite, è possibile utilizzare le interfacce di loopback e definirle come origine del tunnel nella VTI corrispondente.
Esistono alcune opzioni per ottenere la connettività IP tra il loopback e un indirizzo IP pubblico SSE:
- Assegnare un indirizzo IP instradabile pubblicamente a un'interfaccia di loopback (richiede la proprietà di uno spazio di indirizzi IP pubblico).
- Assegnare un indirizzo IP privato a un'interfaccia di loopback e al traffico NAT dinamico con un'origine IP di loopback.
- Utilizzare l'interfaccia VASI (non supportata su molte piattaforme, complessa da configurare e risolvere).
In questo scenario, i passaggi successivi illustrano in dettaglio la seconda opzione.
Configurare due interfacce loopback e aggiungere il comando "ip nat inside" sotto ciascuna di esse.
interface Loopback1
ip address 10.1.1.38 255.255.255.255
ip nat inside
end
interface Loopback2
ip address 10.1.1.70 255.255.255.255
ip nat inside
end
Definire l'elenco di controllo di accesso NAT dinamico e l'istruzione NAT overload:
ip access-list extended NAT
10 permit ip 10.1.1.0 0.0.0.255 any
ip nat inside source list NAT interface GigabitEthernet1 overload
Configurare le interfacce del tunnel virtuale:
interface Tunnel1
ip address 169.254.0.10 255.255.255.252
tunnel source Loopback1
tunnel mode ipsec ipv4
tunnel destination 35.179.86.116
tunnel protection ipsec profile sse-ipsec-profile-1
end
!
interface Tunnel2
ip address 169.254.0.14 255.255.255.252
tunnel source Loopback2
tunnel mode ipsec ipv4
tunnel destination 35.179.86.116
tunnel protection ipsec profile sse-ipsec-profile-2
end
Nota: Come descritto nello scenario lab, gli indirizzi IP assegnati alle VTI provengono da subnet non sovrapposte di 169.254.0.0/24. È possibile utilizzare altri spazi di subnet, tuttavia esistono alcuni requisiti correlati a BGP, che richiedono lo spazio di indirizzi.
Routing BGP
In questa sezione vengono illustrati i passaggi di configurazione necessari per stabilire una relazione tra BGP e l'headend SSE. Il processo BGP sull'headend SSE è in ascolto su qualsiasi IP della subnet 169.254.0.0/24. Per stabilire il peering BGP su entrambe le VTI, occorre definire due router adiacenti" 169.254.0.9 (Tunnel1) e 169.254.0.13 (Tunnel2). È inoltre necessario specificare il valore AS remoto visualizzato nel dashboard SSE.
A partire da novembre 2025, tutte le organizzazioni Secure Access di nuova creazione devono utilizzare lo standard pubblico ASN 32644 per impostazione predefinita per il peering BGP nei gruppi di tunnel di rete. Le organizzazioni esistenti stabilite prima di novembre 2025 possono continuare a utilizzare il Private ASN 64512 che era precedentemente riservato per i peer Secure Access BGP.
router bgp 65000
bgp log-neighbor-changes
neighbor 169.254.0.9 remote-as 32644
neighbor 169.254.0.9 ebgp-multihop 255
neighbor 169.254.0.13 remote-as 32644
neighbor 169.254.0.13 ebgp-multihop 255
!
address-family ipv4
network 192.168.150.0
neighbor 169.254.0.9 activate
neighbor 169.254.0.13 activate
maximum-paths 2
Nota: Le route ricevute da entrambi i peer devono essere identiche. Per impostazione predefinita, il router ne installa solo uno nella tabella di routing. Per consentire l'installazione di più route duplicate nella tabella di routing (e abilitare ECMP), è necessario configurare "maximum-path <number of route>".
Verifica
Dashboard di accesso protetto
Nel dashboard SSE devono essere visualizzati due tunnel primari:
Cisco IOS XE Router
Verificare che entrambi i tunnel siano in stato READY dal lato Cisco IOS XE:
wbrzyszc-cat8k#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.1.1.70/4500 35.179.86.116/4500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/255 sec
CE id: 0, Session-id: 6097
Local spi: A15E8ACF919656C5 Remote spi: 644CFD102AAF270A
Tunnel-id Local Remote fvrf/ivrf Status
6 10.1.1.38/4500 35.179.86.116/4500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/11203 sec
CE id: 0, Session-id: 6096
Local spi: E18CBEE82674E780 Remote spi: 39239A7D09D5B972
Verificare che il protocollo di vicinato BGP sia ATTIVO con entrambi i peer:
wbrzyszc-cat8k#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.0.9 4 32644 17281 18846 160 0 0 5d23h 15
169.254.0.13 4 32644 17281 18845 160 0 0 5d23h 15
Verificare che il router apprenda le route corrette dal protocollo BGP (e che nella tabella di routing siano installati almeno due hop successivi):
wbrzyszc-cat8k#show ip route 192.168.200.0
Routing entry for 192.168.200.0/25, 2 known subnets
B 192.168.200.0 [20/0] via 169.254.0.13, 5d23h
[20/0] via 169.254.0.9, 5d23h
B 192.168.200.128 [20/0] via 169.254.0.13, 5d23h
[20/0] via 169.254.0.9, 5d23h
wbrzyszc-cat8k#show ip cef 192.168.200.0
192.168.200.0/25
nexthop 169.254.0.9 Tunnel1
nexthop 169.254.0.13 Tunnel2
Inizializzare il traffico e verificare che entrambi i tunnel siano utilizzati e che i contatori encaps e decaps siano in aumento per entrambi:
wbrzyszc-cat8k#show crypto ipsec sa | i peer|caps
current_peer 35.179.86.116 port 4500
#pkts encaps: 1881087, #pkts encrypt: 1881087, #pkts digest: 1881087
#pkts decaps: 1434171, #pkts decrypt: 1434171, #pkts verify: 1434171
current_peer 35.179.86.116 port 4500
#pkts encaps: 53602, #pkts encrypt: 53602, #pkts digest: 53602
#pkts decaps: 208986, #pkts decrypt: 208986, #pkts verify: 208986
Facoltativamente, è possibile raccogliere le acquisizioni dei pacchetti su entrambe le interfacce VTI per garantire il bilanciamento del traffico tra le VTI. Per configurare Embedded Packet Capture sui dispositivi Cisco IOS XE, consultare la guida alla configurazione e acquisizione del pacchetto incorporato sul software. Nell'esempio, l'host dietro il router Cisco IOS XE con indirizzo IP di origine: 192.168.150.1 stava inviando richieste ICMP a più IP dalla subnet 192.168.200.0/24. Come si può vedere, le richieste ICMP hanno lo stesso bilanciamento del carico tra i tunnel.
wbrzyszc-cat8k#show monitor capture Tunnel1 buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 114 0.000000 192.168.150.1 -> 192.168.200.2 0 BE ICMP
1 114 0.000000 192.168.150.1 -> 192.168.200.2 0 BE ICMP
10 114 26.564033 192.168.150.1 -> 192.168.200.5 0 BE ICMP
11 114 26.564033 192.168.150.1 -> 192.168.200.5 0 BE ICMP
wbrzyszc-cat8k#show monitor capture Tunnel2 buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 114 0.000000 192.168.150.1 -> 192.168.200.1 0 BE ICMP
1 114 2.000000 192.168.150.1 -> 192.168.200.1 0 BE ICMP
10 114 38.191000 192.168.150.1 -> 192.168.200.3 0 BE ICMP
11 114 38.191000 192.168.150.1 -> 192.168.200.3 0 BE ICMP
Nota: Sui router Cisco IOS XE sono disponibili più meccanismi di bilanciamento del carico ECMP. Per impostazione predefinita, il bilanciamento del carico per destinazione è abilitato, in modo da garantire che il traffico verso la stessa destinazione IP prenda sempre lo stesso percorso. È possibile configurare il bilanciamento del carico per pacchetto, che bilancia il traffico in modo casuale anche per lo stesso IP di destinazione.
Informazioni correlate
- Guida per l'utente di Secure Access
- Come raccogliere l'acquisizione dei pacchetti incorporata
- Documentazione e supporto tecnico – Cisco Systems
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
3.0 |
10-Jul-2026
|
Titolo, introduzione, ortografia, grammatica, struttura della frase, spaziatura, testo alternativo e avvisi CCW aggiornati. |
1.0 |
21-Oct-2024
|
Versione iniziale |
Feedback