Questo documento fornisce istruzioni su come aggiornare il gateway partner di VMware dalla versione 3.3.2 o 3.4 alla versione 4.0.
L'appliance di SD-WAN Gateway include le seguenti modifiche nella versione 4.0:
- Un nuovo layout del disco di sistema basato su LVM per consentire una maggiore flessibilità nella gestione dei volumi
- Una nuova versione del kernel
- Pacchetti di sistemi operativi di base nuovi e aggiornati
- Miglioramento della sicurezza in base ai benchmark di Center for Internet Security
- ifupdown è stato sostituito da https://netplan.io/
- ifup e ifdown non sono più disponibili
- La configurazione della rete è ora in /etc/netplan vs /etc/network/
- etc/network/ifup.d ed /etc/network/ifdown.d non funzionano più. È necessario utilizzare le posizioni di network-dispatcher /usr/lib/networkd-dispatcher (dormant.d, no-carrier.d, off.d, routable.d)
- Modifiche sostanziali di cloud-init. Gli script di distribuzione di cloud-init devono essere esaminati e testati per verificarne la compatibilità
- Le utilità net-tools (ifconfig, netstat e così via) sono considerate "obsolete" e potranno essere rimosse nelle versioni future
Configurazione della rete
ifupdown è stato sostituito da https://netplan.io/. La configurazione della rete è stata spostata da /etc/network a /etc/netplan.
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
Cloud-init
Cloud-init è stato aggiornato alla versione 20.2. Ulteriori informazioni su cloud-init sono disponibili qui: https://cloudinit.readthedocs.io/en/stable/index.html
Esempio 1: semplice
meta-data:
instance-id: vcg1
local-hostname: vcg1
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
Esempio 2: nuovo stile della configurazione di rete (file network-config)
instance-id: vcg1 local-hostname: vcg1
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa … rsa-key
velocloud:
vcg:
vco: demo.velocloud.net
activation_code: F54F-GG4S-XGFI
vco_ignore_cert_errors: false
runcmd:
- 'echo “Welcome to VeloCloud”'
Esempio 1 network-config:
version: 2
ethernets:
eth0:
addresses:
- 192.168.152.55/24
gateway4: 192.168.152.1
nameservers:
addresses:
- 192.168.152.1
eth1:
addresses:
- 192.168.151.55/24
gateway4: 192.168.151.1
nameservers:
addresses:
- 192.168.151.1
Esempio 2 network-config:
Nota: se nel gateway sono presenti più interfacce ed è necessario selezionare un'interfaccia come interfaccia preferita per il gateway predefinito, è possibile utilizzare la configurazione seguente (con il valore della metrica) per selezionare l'interfaccia corretta.
version: 2
ethernets:
eth0:
addresses: [192.168.82.1/24]
eth1:
addresses: [70.150.1.1/24]
routes:
- {metric: 1, to: 0.0.0.0/0, via: 70.150.1.254}
eth2:
addresses: [70.155.1.1/24]
routes:
- {metric: 2, to: 0.0.0.0/0, via: 70.155.1.254}
Net-tools
Le utilità net-tools come ifconfig, netstat, route e così via sono considerate "obsolete". Le sostituzioni suggerite per net-tools sono indicate nella tabella seguente. Questi comandi consentono di visualizzare solo le informazioni per l'host Linux e non per la rete overlay SD-WAN. NOTA: per ulteriori informazioni, digitare: man ip.
| Utilità net-tools obsolete | Nuove utilità net-tools corrispondenti |
|---|---|
| arp | ip n (ip neighbor) |
| ifconfig | ip a (ip addr), ip link, ip -s (ip -stats) |
| nameif | ip link, ifrename |
| netstat | ss, ip route (per netstat-r), ip -s link (per netstat -i), ip maddr (per netstat-g) |
| route | ip r (ip route) |
Esempio di output del comando per le utilità net-tools
L'output di esempio conferma che il comando è stato eseguito correttamente. Di seguito sono disponibili gli output dei comandi di esempio per ip n (ip neighbor), ip a (ipaddr) e ip link.
root@SS-gateway-1:~# ip n 192.168.0.100 dev eth2 lladdr 00:50:56:84:85:d4 REACHABLE 192.168.0.250 dev eth2 lladdr 00:50:56:84:97:66 REACHABLE 13.1.1.2 dev eth0 lladdr 00:50:56:84:e7:fa REACHABLE root@SS-gateway-1:~#
root@SS-gateway-1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 4096
link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff
inet 13.1.1.1/24 brd 13.1.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:a009/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff
inet 101.101.101.1/24 brd 101.101.101.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:a6ab/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.201/24 brd 192.168.0.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:bc75/64 scope link
valid_lft forever preferred_lft forever
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 4096
link/none
inet 169.254.129.1/32 scope global gwd1
valid_lft forever preferred_lft forever
inet6 fe80::27d5:9e46:e7f7:7198/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@SS-gateway-1:~#
root@SS-gateway-1:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 4096
link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 4096
link/none
root@SS-gateway-1:~#
Considerazioni sull'aggiornamento
A causa delle modifiche sostanziali apportate al layout del disco e ai file di sistema, non è possibile eseguire un aggiornamento sul posto dalle versioni precedenti alla 4.0. La migrazione richiederà la distribuzione di nuovi sistemi di SD-WAN Gateway 4.0 e la disattivazione dei sistemi che eseguono il vecchio codice.
Per i SD-WAN Gateway VPN o i SD-WAN Gateway NAT con indirizzi IP pubblici noti, eseguire la procedura seguente se l'IP pubblico del SD-WAN Gateway deve essere conservato.
- Avviare il nuovo sistema SD-WAN Gateway in base all'immagine della versione 4.0. Per ulteriori informazioni, fare riferimento alla guida alla distribuzione per la piattaforma in uso (procedure di installazione del gateway).
- Arrestare il sistema del SD-WAN Gateway precedente. Spegnere la macchina virtuale precedente di SD-WAN Gateway (eseguendo il comando
“sudo poweroff”nella console CLI o disattivandola dalle opzioni dell'hypervisor disponibili). - Eseguire la migrazione dell'IP pubblico nel nuovo sistema: aggiornare il record NAT in modo che punti al nuovo sistema del SD-WAN Gateway o configurare l'IP pubblico nella nuova interfaccia di rete di SD-WAN Gateway. Distribuire il nuovo gateway con gli esempi di cloud-init indicati sopra utilizzando lo stesso indirizzo IP del SD-WAN Gateway precedente.
- Ottenere la chiave di attivazione dal record del SD-WAN Gateway esistente in SD-WAN Orchestrator (come descritto nei passaggi seguenti).
- In SD-WAN Orchestrator, selezionare Gateway (Gateways) nel riquadro di spostamento a sinistra.
- Nella schermata Gateway (Gateways), fare clic su un SD-WAN Gateway per selezionarlo.
- Nella schermata del SD-WAN Gateway scelto, fare clic sulla freccia in giù accanto al nome del SD-WAN Gateway per aprire la casella delle informazioni.
- La chiave di attivazione si trova nella parte inferiore della casella delle informazioni, come illustrato nell'immagine seguente.
- Impostare la proprietà di sistema "gateway.activation.validate.deviceId" su False, come illustrato nell'immagine seguente. Per ulteriori informazioni, fare riferimento alla sezione Proprietà di sistema nella guida dell'operatore di VMware SD-WAN, se necessario.
- Riattivare il nuovo sistema SD-WAN Gateway: dalla console di CLI eseguire:
“sudo /opt/vc/bin/activate.py -s <vco_address> <activation_code>” - Ripristinare il valore originale della proprietà di sistema "gateway.activation.validate.deviceId" (se necessario).
Il SD-WAN Gateway è ora registrato e pronto per ricevere una connessione dagli Edge.
Output di un'attivazione di esempio
root@gateway/opt/vc# /opt/vc/bin/activate.py FLM6-CSV6-REJS-XFR5 -i -s 169.254.8.2
Activation successful, VCO overridden back to 169.254.8.2 root@SS1-gateway-2:/opt/vc#
SD-WAN Gateway senza IP pubblici noti
Questa sezione è dedicata solo ai SD-WAN Gateway che non dispongono di un indirizzo IP pubblico noto, ad esempio i SD-WAN Gateway VPN. Se questo scenario è applicabile, eseguire la procedura seguente.
- Avviare un nuovo sistema SD-WAN Gateway. Se necessario, fare riferimento alla guida alla distribuzione per la piattaforma in uso (procedure di installazione del gateway).
- Attivare un nuovo sistema del SD-WAN Gateway.
- Aggiungere il nuovo SD-WAN Gateway al pool di SD-WAN Gateway di SD-WAN Orchestrator. Per ulteriori dettagli, fare riferimento alla sezione "Gestione del gateway" nella guida dell'operatore di VMware SD-WAN.
- Il SD-WAN Gateway è ora registrato e pronto per ricevere una connessione dagli Edge.
- Rimuovere il SD-WAN Gateway precedente dal pool di SD-WAN Gateway di SD-WAN Orchestrator. Per ulteriori informazioni, fare riferimento alla sezione "Gestione del gateway" nella guida dell'operatore di VMware SD-WAN.
- Disattivare la macchina virtuale del SD-WAN Gateway precedente. (Rimuovere il record del SD-WAN Gateway da SD-WAN Orchestrator e disattivare l'istanza della macchina virtuale).
Recupero della chiave di attivazione del gateway tramite API
Per eseguire la distribuzione mediante il metodo API, utilizzare "network/getNetworkGateways"
Risposta di esempio:
{"jsonrpc":"2.0","result":[{"id":1, "activationKey":"69PX-YHY2-N5PZ-G3UW … 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.
