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.

  1. 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.

  2. 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.

  3. Vérifiez que le composant SD-WAN Gateway est enregistré dans SD-WAN Orchestrator.

    vcg-is-registered-with-vco

  4. Vérifiez la connectivité externe.

    vcg-code-verify-outside-connectivity

  5. Vérifiez que la technologie VRF de gestion répond au ARP.

    vcg-code-verify-mgmt-vrf

  6. 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
  7. Associez le nouveau pool de passerelles au client.

  8. Associez la passerelle à un dispositif Edge.

    vcg-associate-gateway-with-edge

  9. Vérifiez que le dispositif Edge peut établir un tunnel avec la passerelle côté Internet. Dans VMware SD-WAN Orchestrator, accédez à Surveiller (Monitor) > Dispositifs Edge (Edges) > Présentation (Overview).

    Dans VMware SD-WAN Orchestrator, accédez à Tester et dépanner (Test & Troubleshoot) > Diagnostics à distance (Remote Diagnostics) > [Edge] > Chemins de liste (List Paths), puis cliquez sur Exécuter (Run) pour afficher la liste des chemins actifs.

  10. Configurez l'interface de transfert.

    vcg-configure-handoff-interface

  11. Vérifiez que la session BGP est en cours d'exécution.

    vcg-verify-bgp-session-is-up

  12. 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: []
Important : lorsque cloud-init est activé, la configuration réseau est régénérée à chaque démarrage. Afin d'apporter des modifications à la configuration de l'emplacement, désactivez cloud-init ou le composant de configuration réseau cloud-init :
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é.

Étape 1 : Modifier /etc/config/gatewayd et spécifier l'interface VCMP et WAN appropriée. L'interface VCMP est l'interface publique qui met fin aux tunnels d'overlay. L'interface WAN dans ce contexte est l'interface de transfert.
      "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 (Management VRF) 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.
Étape 1 : Modifier /opt/vc/etc/vc_blocked_subnets.jsonfile sur SD-WAN Gateway. Vous constatez que ce fichier contient d'abord les éléments suivants.
[
            {
                        "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 2 : Supprimer les deux réseaux. Le fichier doit ressembler à ce qui suit après la modification. Enregistrez la modification.
[
]

Étape 3 : Redémarrer le processus SD-WAN Gateway par sudo /opt/vc/bin/vc_procmon restart.