Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Configurazione

Esempio di rete

Transport Network

Sovrapponi rete

Configurazioni spoke

Configurazione interfaccia tunnel spoke

Configurazione Spoke Border Gateway Protocol (BGP)

Configurazioni hub

Pool locali

Configurazione BGP hub

Verifica

Risoluzione dei problemi

Introduzione

Questo documento descrive come configurare un spoke in una rete FlexVPN con l'uso del blocco di configurazione client FlexVPN in uno scenario in cui sono disponibili più hub.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- FlexVPN

- Protocolli di routing Cisco

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

- Cisco serie G2 Integrated Service Router (ISR)

- Cisco IOS® versione 15.2M

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.

Configurazione

Per motivi di ridondanza, un spoke potrebbe dover connettersi a più hub. La ridondanza sul lato spoke consente il funzionamento continuo senza un singolo punto di errore sul lato hub.

I due progetti di hub ridondanti FlexVPN più comuni che utilizzano la configurazione spoke sono:

- Approccio basato su cloud doppio, in cui un spoke dispone di due tunnel separati attivi a entrambi gli hub in qualsiasi momento.

- Approccio di failover, in cui un spoke ha un tunnel attivo con un hub in un determinato point in time.

Entrambi gli approcci hanno un insieme unico di pro e contro.

Approccio

Pro

Svantaggi

Cloud doppio

- Ripristino più rapido in caso di guasto, in base ai timer del protocollo di routing

- Più possibilità di distribuire il traffico tra gli hub, poiché la connessione a entrambi gli hub è attiva

- Spoke mantiene la sessione su entrambi gli hub contemporaneamente, consumando le risorse su entrambi gli hub

Failover

- Configurazione semplice - integrata in FlexVPN

- Non si basa sul protocollo di routing in caso di errore

- Tempi di ripristino più lenti, basati su Dead Peer Detection (DPD) o (facoltativamente) Object Tracking

- Tutto il traffico è costretto a viaggiare su un hub alla volta.

Questo documento descrive il primo approccio. L'approccio a questa configurazione è simile a quello della configurazione DMVPN (Dynamic Multipoint VPN) con doppio cloud. La configurazione di base di Hub and Spoke si basa sui documenti di migrazione da DMVPN a FlexVPN. Fare riferimento alla migrazione di FlexVPN: Articolo Hard Move from DMVPN to FlexVPN on Same Devices (Spostamento rapido da DMVPN a FlexVPN sugli stessi dispositivi) per una descrizione di questa configurazione.

Esempio di rete

Transport Network

Il diagramma mostra la rete di trasporto di base generalmente utilizzata nelle reti FlexVPN.

Sovrapponi rete

Nel diagramma viene illustrata la rete sovrapposta con connettività logica che illustra il funzionamento del failover. Durante il normale funzionamento, il raggio 1 e il raggio 2 mantengono una relazione con entrambi gli hub. In caso di errore, il protocollo di routing passa da un hub all'altro.

Nota: Nel diagramma, le linee verdi indicano la connessione e la direzione delle sessioni di Internet Key Exchange versione 2 (IKEv2)/Flex all'hub 1, mentre le linee blu indicano la connessione all'hub 2.

Entrambi gli hub mantengono indirizzi IP separati in cloud sovrapposti. L'indirizzamento /24 rappresenta il pool di indirizzi allocati per questo cloud, non l'indirizzamento effettivo dell'interfaccia. Infatti, in genere, l'hub FlexVPN alloca un indirizzo IP dinamico per l'interfaccia spoke e si basa sulle route inserite in modo dinamico tramite i comandi route nel blocco di autorizzazione FlexVPN.

Configurazioni spoke

Configurazione interfaccia tunnel spoke

La configurazione tipica utilizzata in questo esempio è semplicemente due interfacce tunnel con due indirizzi di destinazione separati.

interface Tunnel1

ip address negotiated

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel source Ethernet0/0

tunnel destination 172.25.1.1

tunnel path-mtu-discovery

tunnel protection ipsec profile default

interface Tunnel2

ip address negotiated

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel source Ethernet0/0

tunnel destination 172.25.2.1

tunnel path-mtu-discovery

tunnel protection ipsec profile default

Per consentire la corretta formazione dei tunnel spoke, è necessario un modello virtuale (VT, Virtual Template).

interface Virtual-Template1 type tunnel

ip unnumbered ethernet1/0

ip mtu 1400

ip nhrp network-id 2

ip nhrp shortcut virtual-template 1

ip nhrp redirect

ip tcp adjust-mss 1360

tunnel path-mtu-discovery

tunnel protection ipsec profile default

Lo spoke utilizza un'interfaccia senza numero che indica l'interfaccia LAN nel VRF (Virtual Routing and Forwarding), che in questo caso è globale. Tuttavia, potrebbe essere preferibile fare riferimento a un'interfaccia di loopback. Questo perché le interfacce di loopback rimangono online in quasi tutte le condizioni.

Configurazione Spoke Border Gateway Protocol (BGP)

Poiché Cisco consiglia iBGP come protocollo di routing da utilizzare nella rete di overlay, questo documento menziona solo questa configurazione.

Nota: Gli spoke devono mantenere la raggiungibilità BGP a entrambi gli hub.

router bgp 65001

bgp log-neighbor-changes

network 192.168.101.0

neighbor 10.1.1.1 remote-as 65001

neighbor 10.1.1.1 fall-over

neighbor 10.2.2.1 remote-as 65001

neighbor 10.2.2.1 fall-over

FlexVPN in questa configurazione non dispone di un concetto di hub primario o secondario. L'amministratore decide se il protocollo di routing preferisce un hub a un altro oppure, in alcuni scenari, esegue il bilanciamento del carico.

Considerazioni su failover e convergenza spoke

Per ridurre al minimo il tempo necessario affinché un spoke rilevi il guasto, utilizzate questi due metodi tipici.

- Abbreviare i timer BGP. Il tempo di attesa predefinito causa il failover.

- Configurare il failover BGP, descritto in questo articolo, Supporto BGP per la disattivazione rapida della sessione di peering.

- Non utilizzare il rilevamento inoltro bidirezionale (BFD), poiché non è consigliato nella maggior parte delle distribuzioni FlexVPN.

Tunnel e failover spoke-to-spoke

I tunnel spoke utilizzano la commutazione rapida NHRP (Next Hop Resolution Protocol). Cisco IOS indica che tali collegamenti sono route NHRP, ad esempio:

Spoke1#show ip route nhrp

(...)

192.168.102.0/24 is variably subnetted, 2 subnets, 2 masks

H 192.168.102.0/24 [250/1] via 10.2.2.105, 00:00:21, Virtual-Access1

Queste route non scadono quando scade la connessione BGP; al contrario, vengono trattenute per un periodo di sospensione NHRP, che per impostazione predefinita è di due ore. Ciò significa che i tunnel spoke attivi rimangono in funzione anche in caso di guasto.

Configurazioni hub

Pool locali

Come indicato nella sezione Diagramma reticolare, entrambi gli hub mantengono indirizzi IP separati.

Hub1

ip local pool FlexSpokes 10.1.1.100 10.1.1.254

Hub2

ip local pool FlexSpokes 10.2.2.100 10.2.2.254

Configurazione BGP hub

La configurazione BGP dell'hub rimane simile agli esempi precedenti.

Questo output viene generato dall'hub 1 con indirizzo IP LAN 192.168.0.1.

router bgp 65001

bgp log-neighbor-changes

bgp listen range 10.1.1.0/24 peer-group Spokes

network 192.168.0.0

aggregate-address 192.168.0.0 255.255.0.0 summary-only

neighbor Spokes peer-group

neighbor Spokes remote-as 65001

neighbor Spokes fall-over

neighbor 192.168.0.2 remote-as 65001

neighbor 192.168.0.2 route-reflector-client

neighbor 192.168.0.2 next-hop-self all

neighbor 192.168.0.2 unsuppress-map ALL

route-map ALL permit 10

match ip address 1

ip access-list standard 1

permit any

In sostanza, questo è ciò che viene fatto:

- Il pool di indirizzi FlexVPN locale è incluso nell'intervallo di ascolto BGP.

- La rete locale è 192.168.0.0/24.

- Un riepilogo viene pubblicizzato solo per i raggi. La configurazione dell'indirizzo di aggregazione crea una route statica per il prefisso tramite l'interfaccia null0, ovvero una route da ignorare utilizzata per impedire i loop di routing.

- Tutti i prefissi specifici vengono annunciati all'altro hub. Poiché è anche una connessione iBGP, richiede una configurazione del router-reflector.

Questo diagramma rappresenta lo scambio di prefissi BGP tra spoke e hub in un cloud FlexVPN.

Nota: Nel diagramma, la linea verde rappresenta le informazioni fornite dagli spoke all'hub, la linea rossa rappresenta le informazioni fornite da ciascun hub agli spoke (solo un riepilogo) e la linea blu rappresenta i prefissi scambiati tra gli hub.

Verifica

Poiché ogni spoke mantiene l'associazione con entrambi gli hub, con il comando show crypto ikev2 sa vengono visualizzate due sessioni IKEv2.

IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status

3 172.16.1.2/500 172.16.2.2/500 none/none READY

Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/3147 sec

Tunnel-id Local Remote fvrf/ivrf Status

1 172.16.1.2/500 172.25.2.1/500 none/none READY

Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/3256 sec

Per visualizzare le informazioni sul protocollo di routing, immettere questi comandi:

show bgp ipv4 unicast

show bgp summary

Sugli spoke, il prefisso di riepilogo viene ricevuto dagli hub e le connessioni a entrambi gli hub sono attive.

Spoke1#show bgp ipv4 unicast

BGP table version is 4, local router ID is 192.168.101.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*>i 192.168.0.0/16 10.1.1.1 0 100 0 i

* i         10.2.2.1 0 100 0 i

*> 192.168.101.0 0.0.0.0 0 32768 i

Spoke1#show bgp summa

Spoke1#show bgp summary

BGP router identifier 192.168.101.1, local AS number 65001

BGP table version is 4, main routing table version 4

2 network entries using 296 bytes of memory

3 path entries using 192 bytes of memory

3/2 BGP path/bestpath attribute entries using 408 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 896 total bytes of memory

BGP activity 2/0 prefixes, 3/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.1 4 65001 7 7 4 0 0 00:00:17 1

10.2.2.1 4 65001 75 72 4 0 0 01:02:24 1

Risoluzione dei problemi

I principali blocchi da risolvere sono due:

- IKE (Internet Key Exchange)

- IPsec (Internet Protocol Security)

Di seguito sono riportati i comandi show rilevanti:

show crypto ipsec sa

show crypto ikev2 sa

Di seguito sono riportati i comandi di debug pertinenti:

debug crypto ikev2 [internal|packet]

debug crypto ipsec

debug vtemplate event

Di seguito è riportato il protocollo di routing desiderato:

show bgp ipv4 unicast (or show ip bgp)

show bgp summary