Ce document fournit des instructions sur la mise à niveau de la passerelle partenaire VMware de la version 3.3.2 ou 3.4 vers la version 4.0.
La version 4.0 du dispositif SD-WAN Gateway inclut les modifications suivantes :
- Nouvelle disposition de disque système basée sur LVM pour procurer plus de flexibilité en matière de gestion des volumes
- Nouvelle version du noyau
- Modules de système d'exploitation de base nouveaux et mis à niveau
- Amélioration de la sécurisation renforcée sur la base des évaluations du Center for Internet Security
- ifupdown a été désapprouvé au profit de https://netplan.io/.
- ifup et ifdown ne sont plus disponibles.
- La configuration réseau se trouve désormais dans /etc/netplan et non plus dans /etc/network/.
- etc/network/ifup.d et /etc/network/ifdown.d ne fonctionnent plus. Les emplacements Network-Dispatcher doivent être utilisés : /usr/lib/networkd-dispatcher (dormant.d, no-carrier.d, off.d, routable.d).
- Des modifications importantes ont été apportées à cloud-init. Les scripts de déploiement cloud-init doivent être examinés et testés à des fins de compatibilité.
- Les utilitaires net-tools (ifconfig, Netstats, etc.) sont considérés comme « obsolètes » et peuvent être supprimés des versions ultérieures.
Configuration réseau
ifupdown a été désapprouvé au profit de https://netplan.io/. La configuration réseau a été déplacée de /etc/network vers /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 a été mis à niveau vers la version 20.2. Vous trouverez plus d'informations sur Cloud-init ici : https://cloudinit.readthedocs.io/en/stable/index.html
Exemple 1 : simple
Fichier meta-data :
instance-id: vcg1
local-hostname: vcg1
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
Exemple 2 : configuration réseau selon le nouveau style (fichier 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”'
Exemple 1 de fichier 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
Exemple 2 de fichier network-config :
REMARQUE : si plusieurs interfaces sont présentes sur la passerelle et qu'une interface doit être sélectionnée comme interface préférée pour la passerelle par défaut, la configuration ci-dessous (avec la valeur de mesure) peut être utilisée pour sélectionner l'interface appropriée.
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}
Utilitaires net-tools
Les utilitaires net-tools, tels que ifconfig, netstat, route, etc., sont considérés comme « obsolètes ». Les suggestions de remplacement des utilitaires net-tools sont présentées dans le tableau ci-dessous. Ces commandes affichent uniquement des informations sur l'hôte Linux, pas sur le réseau de superposition SD-WAN. REMARQUE : pour plus d'informations, saisissez : man ip.
| Anciens utilitaires net-tools | Nouveaux utilitaires net-tools correspondants |
|---|---|
| arp | ip n (ip neighbor) |
| ifconfig | ip a (ip addr), ip link, ip -s (ip -stats) |
| nameif | ip link, ifrename |
| netstat | ss, ip route (pour netstat-r), ip -s link (pour netstat -i), ip maddr (pour netstat-g) |
| route | ip r (ip route) |
Exemple de sortie de commande pour les utilitaires net-tools
L'exemple de sortie est la confirmation de la réussite de la commande. Les exemples de sortie de commande pour ip n (ip neighbor), ip a (ipaddr) et ip link sont affichés ci-dessous.
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:~#
Considérations relatives à la mise à niveau
En raison de modifications importantes apportées à la disposition de disque et aux fichiers système, il n'est pas possible d'effectuer une mise à niveau sur place entre les versions antérieures et la version 4.0. La migration nécessite le déploiement de nouveaux systèmes SD-WAN Gateway 4.0 et la désaffectation de systèmes exécutant un code plus ancien.
Pour les Passerelles SD-WAN Gateway VPN ou les Passerelles SD-WAN Gateway NAT avec des adresses IP publiques connues, respectez la procédure suivante si l'adresse IP publique du système SD-WAN Gateway doit être conservée.
- Lancez le nouveau système SD-WAN Gateway en fonction de l'image de la version 4.0. Pour plus d'informations, reportez-vous au guide de déploiement de votre plate-forme (procédures d'installation de la passerelle).
- Arrêtez l'ancien système SD-WAN Gateway. (Arrêtez l'ancienne VM SD-WAN Gateway (en exécutant la commande
“sudo poweroff”sur la console d'interface de ligne de commande (CLI), ou en désactivant les options disponibles de l'hyperviseur). - Migrez l'adresse IP publique vers le nouveau système : mettez à jour l'enregistrement NAT de sorte qu'il pointe vers le nouveau système SD-WAN Gateway ou configurez l'adresse IP publique sur la nouvelle interface réseau SD-WAN Gateway. Déployez la nouvelle passerelle avec les exemples cloud-init fournis ci-dessus, en utilisant la même adresse IP que le système SD-WAN Gateway précédent.
- Obtenez la clé d'activation à partir de l'enregistrement SD-WAN Gateway existant de SD-WAN Orchestrator (comme décrit dans les étapes ci-dessous).
- Dans le panneau de navigation de gauche de SD-WAN Orchestrator, sélectionnez Passerelles (Gateways).
- Dans l'écran Passerelles (Gateways), cliquez sur un système SD-WAN Gateway pour le sélectionner.
- Dans l'écran du système SD-WAN Gateway sélectionné, cliquez sur la flèche vers le bas en regard du nom de SD-WAN Gateway pour ouvrir la zone d'informations.
- La clé d'activation se trouve en bas de la zone d'informations, comme illustré sur l'image ci-dessous.
- Définissez la propriété système « gateway.activation.validate.deviceId » sur Faux (False), comme illustré sur l'image ci-dessous. Pour plus d'informations, reportez-vous à la section Propriétés système du Guide de l'opérateur de VMware SD-WAN si nécessaire.
- Réactivez le nouveau système SD-WAN Gateway : depuis la console d'interface de ligne de commande, exécutez :
“sudo /opt/vc/bin/activate.py -s <vco_address> <activation_code>” - Restaurez la propriété système « gateway.activation.validate.deviceId » sur la valeur d'origine (si nécessaire).
Le système SD-WAN Gateway est désormais enregistré et prêt à recevoir une connexion depuis les dispositifs Edge.
Exemple de sortie d'activation
root@gateway/opt/vc# /opt/vc/bin/activate.py FLM6-CSV6-REJS-XFR5 -i -s 169.254.8.2
Activation réussie, vCO remplacé par 169.254.8.2 root@SS1-gateway-2:/opt/vc# (Activation successful, VCO overridden back to 169.254.8.2 root@SS1-gateway-2:/opt/vc#)
Passerelles SD-WAN Gateway sans adresses IP publiques connues
Cette section porte uniquement sur les Passerelles SD-WAN Gateway sans adresses IP publiques connues, comme les Passerelles SD-WAN Gateway VPN. Si ce scénario s'applique, suivez la procédure ci-dessous.
- Lancez un nouveau système SD-WAN Gateway. Si nécessaire, reportez-vous au guide de déploiement de votre plate-forme (procédures d'installation de la passerelle).
- Activez un nouveau système SD-WAN Gateway.
- Ajoutez un nouveau système SD-WAN Gateway au pool SD-WAN Gateway de SD-WAN Orchestrator. Pour plus d'informations, reportez-vous à la section « Gestion des passerelles » du Guide de l'opérateur de VMware SD-WAN.
- Le système SD-WAN Gateway est désormais enregistré et prêt à recevoir une connexion depuis les dispositifs Edge.
- Supprimez l'ancien système SD-WAN Gateway du pool SD-WAN Gateway de SD-WAN Orchestrator. Pour plus d'informations, reportez-vous à la section « Gestion des passerelles » du Guide de l'opérateur de VMware SD-WAN.
- Désaffectez l'ancienne machine virtuelle SD-WAN Gateway. (Supprimez l'enregistrement SD-WAN Gateway de SD-WAN Orchestrator et désaffectez l'instance de machine virtuelle).
Obtention de la clé d'activation de la passerelle via l'API
Pour effectuer un déploiement selon la méthode API, utilisez l'instruction suivante : « network/getNetworkGateways »
Exemple de réponse :
{"jsonrpc":"2.0","result":[{"id":1, "activationKey":"69PX-YHY2-N5PZ-G3UW … Configurer l'interface de transfert dans le plan de données
Configuration du réseau VMware SD-WAN Gateway
Dans l'exemple présentant la figure ci-dessous (Transfert VRF/VLAN vers le PE), nous supposons que eth0 est l'interface faisant face au réseau public (Internet) et eth1 est l'interface faisant face au réseau interne (VRF client via le PE). La configuration du peering BGP est gérée sur le VCO par client/VRF sous Configurer (Configure) > Client (Customer). Notez que l'adresse IP de chaque VRF est configurable par client. L'adresse IP du VRF de gestion hérite de l'adresse IP configurée sur l'interface de SD-WAN Gateway dans Linux.
Un VRF de gestion est créé sur SD-WAN Gateway et est utilisé pour envoyer une actualisation ARP périodique à l'adresse IP de la passerelle par défaut pour déterminer l'adresse MAC next-hop. Il est recommandé de configurer un VRF dédié sur le routeur PE à cette fin. Le même VRF de gestion peut également être utilisé par le routeur PE pour envoyer la sonde SLA IP à SD-WAN Gateway afin de vérifier l'état de SD-WAN Gateway (celui-ci dispose d'un répondeur ICMP avec état qui répond au ping uniquement lorsque son service est actif). Le peering BGP n'est pas requis sur le VRF de gestion. Si un VRF de gestion n'est pas configuré, vous pouvez utiliser l'un des VRF du client comme VRF de gestion, bien que cela ne soit pas recommandé.
"vcmp.interfaces":[
"eth0"
],
(..snip..)
"wan": [
"eth1"
],
Étape 2 : configurer le VRF de gestion. Ce VRF est utilisé par SD-WAN Gateway vers ARP pour l'adresse MAC next-hop (routeur PE). La même adresse MAC next-hop sera utilisée par tous les VRF créés par SD-WAN Gateway. Vous devez configurer le paramètre VRF de gestion dans /etc/config/gatewayd.
Le VRF de gestion est le même que celui utilisé par le routeur PE pour envoyer la sonde SLA IP. SD-WAN Gateway répond uniquement à la sonde ICMP si le service est actif et si des dispositifs Edge y sont connectés. Le tableau ci-dessous décrit chaque paramètre à définir. Cet exemple comporte le VRF de gestion sur l'ID du VLAN 802.1q de 1000.
| mode | QinQ (0x8100), QinQ (0x9100), aucun, 802.1Q, 802.1ad |
| c_tag | Valeur de balise C pour l'encapsulation QinQ ou ID du VLAN 802.1Q pour l'encapsulation 802.1Q |
| s_tag | Valeur de balise S pour l'encapsulation QinQ |
| interface | Interface de transfert, généralement eth1 |
"vrf_vlan": {
"tag_info": [
{
"resp_mode": 0,
"proxy_arp": 0,
"c_tag": 1000,
"mode": "802.1Q",
"interface": "eth1",
"s_tag": 0
}
]
},
Étape 3 : Modifier /etc/config/gatewayd-tunnel afin d'inclure les deux interfaces dans le paramètre WAN. Enregistrez la modification.
wan="eth0 eth1"
Supprimer les sous-réseaux bloqués
Par défaut, SD-WAN Gateway bloque le trafic vers 10.0.0.0/8 et 172.16.0.0/14. Nous devons les supprimer avant d'utiliser cette instance de SD-WAN Gateway, car nous nous attendons à ce que SD-WAN Gateway envoie également le trafic à des sous-réseaux privés. Si vous ne modifiez pas ce fichier, lorsque vous tentez d'envoyer le trafic à des sous-réseaux bloqués, vous trouverez les messages suivants dans /var/log/gwd.log
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"
}
]
[ ]
Étape 3 : Redémarrer le processus SD-WAN Gateway par sudo /opt/vc/bin/vc_procmon restart.
