Questa sezione illustra i passaggi di verifica dell'installazione e successivi all'installazione.
Se tutto funziona come previsto nell'installazione, è ora possibile accedere alla macchina virtuale.
- Se tutto funziona come previsto, viene visualizzato il prompt di accesso nella console. Il nome del prompt dovrebbe essere quello specificato in cloud-init.
- È inoltre possibile fare riferimento a /run/cloud-init/result.json. Se viene visualizzato il messaggio seguente, è probabile che cloud-init venga eseguito correttamente.
- Verificare che il gateway sia registrato in SD-WAN Orchestrator.
- Verificare la connettività esterna.
- Verificare che MGMT VRF risponda alle istanze di ARP.
- Facoltativo: disattivare cloud-init in modo che non venga eseguito a ogni avvio.
Nota: Se si distribuisce OVA in VMware vSphere con proprietà vAPP, è necessario disattivare cloud-init prima di eseguire l'aggiornamento alla versione 4.0.1 o 4.1.0 per fare in modo che le impostazioni di personalizzazione come la configurazione di rete o la password non vengano perse durante l'aggiornamento.
touch /etc/cloud/cloud-init.disabled
- Associare il nuovo pool di gateway al cliente.
- Associare il gateway a un Edge.
- Verificare che l'Edge sia in grado di stabilire un tunnel con il gateway sul lato Internet. Da VMware SD-WAN Orchestrator, passare a .
Da VMware SD-WAN Orchestrator, passare a e fare clic su Esegui (Run) per visualizzare l'elenco dei percorsi attivi.
- Configurare l'interfaccia di handoff.
- Verificare che la sessione BGP sia attiva.
- Modificare la configurazione di rete.
I file di configurazione di rete si trovano in /etc/netplan.
Configurazione di rete di esempio (lo spazio vuoto è importante) - /etc/netplan/50-cloud-init.yaml:network: version: 2 ethernets: eth0: addresses: - 192.168.151.253/24 gateway4: 192.168.151.1 nameservers: addresses: - 8.8.8.8 - 8.8.4.4 search: [] routes: - to: 192.168.0.0/16 via: 192.168.151.254 metric: 100 eth1: addresses: - 192.168.152.251/24 gateway4: 192.168.152.1 nameservers: addresses: - 8.8.8.8 search: []
echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
Configurazione dell'interfaccia di handoff nel piano dati
Configurazione della rete di VMware SD-WAN Gateway
Nella seguente figura di esempio (handoff VRF/VLAN su PE), si suppone che eth0 sia l'interfaccia di fronte alla rete pubblica (Internet) e che eth1 sia l'interfaccia di fronte alla rete interna (VRF cliente tramite PE). La configurazione del peering BGP viene gestita nel VCO per ciascuna base cliente/VRF in "Configura (Configure) > Cliente (Customer)". Si noti che l'indirizzo IP di ogni VRF è configurabile per ogni cliente. L'indirizzo IP del VRF di gestione eredita l'indirizzo IP configurato nell'interfaccia del SD-WAN Gateway in Linux.
Un VRF di gestione viene creato in SD-WAN Gateway e viene utilizzato per inviare l'aggiornamento ARP periodico all'IP del gateway predefinito per determinare il MAC dell'hop successivo. Per questo scopo, è consigliabile configurare un VRF dedicato nel router PE. Lo stesso VRF di gestione può essere utilizzato anche dal router PE per inviare un probe SLA IP a SD-WAN Gateway per verificare lo stato di SD-WAN Gateway (SD-WAN Gateway ha un risponditore ICMP stateful che risponde al ping solo quando il suo servizio è attivo). Il peering BGP non è obbligatorio nel VRF di gestione. Se non è impostato un VRF di gestione, è possibile utilizzare uno dei VRF del cliente come VRF di gestione, anche se non è consigliato.
"vcmp.interfaces":[
"eth0"
],
(..snip..)
"wan": [
"eth1"
],
Passaggio 2: configurare il VRF di gestione. Questo VRF viene utilizzato da SD-WAN Gateway su ARP per il MAC dell'hop successivo (router PE). Lo stesso MAC dell'hop successivo verrà utilizzato da tutti i VRF creati da SD-WAN Gateway. È necessario configurare il parametro del VRF di gestione in /etc/config/gatewayd.
Il VRF di gestione è lo stesso VRF utilizzato dal router PE per inviare il probe SLA IP. SD-WAN Gateway risponde al probe ICMP solo se il servizio è attivo e se sono presenti Edge connessi. Nella tabella seguente viene spiegato ogni parametro che deve essere definito. In questo esempio è presente il VRF di gestione nell'ID VLAN 802.1q pari a 1000.
| modalità (mode) | QinQ (0x8100), QinQ (0x9100), nessuna, 802.1Q, 802.1ad |
| c_tag (Tag C) | Valore Tag C per l'incapsulamento QinQ o l'ID VLAN 802.1Q per l'incapsulamento di 802.1Q |
| s_tag (Tag S) | Valore Tag S per l'incapsulamento QinQ |
| interface (interfaccia) | Interfaccia di handoff, in genere eth1 |
"vrf_vlan": {
"tag_info": [
{
"resp_mode": 0,
"proxy_arp": 0,
"c_tag": 1000,
"mode": "802.1Q",
"interface": "eth1",
"s_tag": 0
}
]
},
Passaggio 3: modificare il file /etc/config/gatewayd-tunnel per includere entrambe le interfacce nel parametro WAN. Salvare le modifiche.
wan="eth0 eth1"
Rimozione delle subnet bloccate
Per impostazione predefinita, SD-WAN Gateway blocca il traffico verso 10.0.0.0/8 e 172.16.0.0/14. Prima di utilizzare questo SD-WAN Gateway sarà necessario rimuoverle perché si prevede che SD-WAN Gateway invii il traffico anche alle subnet private. Se non si modifica questo file, quando si tenta di inviare il traffico a subnet bloccate, in /var/log/gwd.log verranno visualizzati i seguenti messaggi
2015-12-18T12:49:55.639 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.254, which is a blocked subnet. 2015-12-18T12:52:27.764 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.254, which is a blocked subnet. [message repeated 48 times] 2015-12-18T12:52:27.764 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.10, which is a blocked subnet.
[
{
"network_addr": "10.0.0.0",
"subnet_mask": "255.0.0.0"
},
{
"network_addr": "172.16.0.0",
"subnet_mask": "255.255.0.0"
}
]
[ ]
Passaggio 3: riavviare il processo di SD-WAN Gateway tramite il riavvio di sudo /opt/vc/bin/vc_procmon.
