Cette section décrit les étapes de post-installation et de vérification de l'installation.
Si tout fonctionne comme prévu dans l'installation, vous pouvez maintenant vous connecter à la machine virtuelle.
- Si tout fonctionne comme prévu, l'invite de connexion s'affiche sur la console. Vous devez voir le nom de l'invite tel que spécifié dans cloud-init.
- Vous pouvez également vous reporter à /run/cloud-init/result.json. Si vous voyez le message ci-dessous, il est probable que cloud-init s'exécute correctement.
- Vérifiez que la passerelle est enregistrée dans SASE Orchestrator.
- Vérifiez la connectivité externe.
- Vérifiez que la technologie VRF de gestion répond au ARP.
- Facultatif : désactivez cloud-init afin qu'il ne s'exécute pas à chaque démarrage.
Note : Si vous avez déployé OVA sur VMware vSphere avec des propriétés vAPP, vous devez désactiver cloud-init avant la mise à niveau vers la version 4.0.1 ou 4.1.0. Cela évite de perdre les paramètres de personnalisation, tels que la configuration réseau ou le mot de passe pendant la mise à niveau.
touch /etc/cloud/cloud-init.disabled
- Associez le nouveau pool de passerelles au client.
- Associez la passerelle à un dispositif Edge. Pour plus d'informations, reportez-vous à la section « Attribuer un transfert de passerelles de partenaires » du Guide d'administration de VMware SD-WAN.
- Vérifiez que le dispositif Edge peut établir un tunnel avec la passerelle côté Internet. Dans SASE Orchestrator, accédez à .
Dans SASE Orchestrator, accédez à , puis cliquez sur Exécuter (Run) pour afficher la liste des chemins actifs.
- Configurez l'interface de transfert. Reportez-vous à la section Configurer le transfert aux partenaires.
- Vérifiez que la session BGP est en cours d'exécution.
- Modifiez la configuration réseau.
Les fichiers de configuration réseau se trouvent sous /etc/netplan.
Exemple de configuration réseau (l'espace a son importance !) - /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
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 de 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.
