Comme toute superposition, VMware impose une capacité supplémentaire sur le trafic qui traverse le réseau. Cette section décrit d'abord la capacité supplémentaire ajoutée dans un réseau IPsec traditionnel et sa comparaison avec VMware, puis une explication de la relation de l'ajout de cette capacité supplémentaire avec les comportements de la MTU et de la fragmentation des paquets dans le réseau.
Capacité supplémentaire du tunnel IPsec
- Remplissage
- AES chiffre les données dans des blocs de 16 octets, appelés taille de « bloc ».
- Si le corps d'un paquet est inférieur ou indivisible par la taille de bloc, il est rempli pour correspondre à la taille de bloc.
- Exemples :
- Un paquet de 1 octet passe à 16 octets avec 15 octets de remplissage.
- Un paquet de 1 400 octets passe à 1 408 octets avec 8 octets de remplissage.
- Un paquet de 64 octets ne nécessite aucun remplissage.
- En-têtes et codes de fin IPsec :
- En-tête UDP pour NAT Traversal (NAT-T).
- En-tête IP pour le mode de tunnel IPsec.
- En-tête et code de fin ESP.
| Élément | Taille en octets |
|---|---|
| En-tête IP | 20 |
| En-tête UDP | 8 |
| Numéro de séquence IPsec | 4 |
| SPI IPsec | 4 |
| Vecteur d'initialisation | 16 |
| Remplissage | 0 – 15 |
| Longueur de remplissage | 1 |
| En-tête suivant | 1 |
| Données d'authentification | 12 |
| Total | 66-81 |
Capacité supplémentaire du tunnel VMware
Pour prendre en charge Dynamic Multipath Optimization™ (DMPO), VMware encapsule les paquets dans un protocole appelé VeloCloud Multipath Protocol (VCMP). VCMP ajoute 31 octets de capacité supplémentaire pour que les paquets d'utilisateur prennent en charge le reséquencement, la correction des erreurs, l'analyse réseau et la segmentation réseau dans un seul tunnel. VCMP fonctionne sur un port enregistré dans IANA d'UDP 2426. Pour garantir un comportement cohérent dans tous les scénarios potentiels (non chiffré, chiffré et derrière une NAT, chiffré, mais pas derrière une NAT), VCMP est chiffré à l'aide d'IPsec en mode de transport et force NAT-T à être conforme à un port NAT-T spécial 2426.
Les paquets envoyés à Internet via SD-WAN Gateway ne sont par défaut pas chiffrés, car ils sont sortants vers le réseau Internet ouvert en quittant la passerelle. Par conséquent, la capacité supplémentaire du trafic à chemins multiples Internet est inférieure au trafic VPN.
Trafic VPN
| Élément | Taille en octets |
|---|---|
| En-tête IP | 20 |
| En-tête UDP | 8 |
| Numéro de séquence IPsec | 4 |
| SPI IPsec | 4 |
| En-tête VCMP | 23 |
| En-tête de données VCMP | 8 |
| Vecteur d'initialisation | 16 |
| Remplissage | 0 – 15 |
| Longueur de remplissage | 1 |
| En-tête suivant | 1 |
| Données d'authentification | 12 |
| Total | 97 – 112 |
Trafic à chemins multiples Internet
| Élément | Taille en octets |
|---|---|
| En-tête IP | 20 |
| En-tête UDP | 8 |
| En-tête VCMP | 23 |
| En-tête de données VCMP | 8 |
| Total | 59 |
Impact du tunnel IPv6 sur la MTU
VMware SD-WAN prend en charge les adresses IPv6 pour configurer les interfaces Edge et les paramètres de superposition WAN Edge.
Le tunnel VCMP peut être configuré dans les environnements suivants : IPv4 uniquement, IPv6 uniquement et double pile. Pour plus d'informations, reportez-vous à la section Paramètres IPv6.
Lorsqu'un site distant dispose d'au moins un tunnel IPv6, DMPO utilise ce dernier de manière transparente avec d'autres tunnels IPv4. Les paquets d'un flux spécifique peuvent prendre n'importe quel tunnel, IPv4 ou IPv6, en fonction de la santé en temps réel du tunnel. Le score de sélection de chemin pour le trafic équilibré en charge constitue un exemple de flux spécifique. Dans de tels cas, l'augmentation de la taille de l'en-tête IPv6 (20 octets supplémentaires) doit être prise en compte. Par conséquent, la MTU de chemin effective est alors inférieure de 20 octets. En outre, cette MTU effective réduite est propagée aux autres sites distants distantes par le biais d'une passerelle afin que les routes entrantes dans cette site distant locale à partir d'autres sites distants distantes reflètent la MTU réduite.
Détection MTU du chemin (Path MTU Discovery)
Après avoir déterminé la capacité supplémentaire appliquée, le dispositif SD-WAN Edge doit détecter la MTU maximale autorisée pour calculer la MTU effective pour les paquets du client. Pour rechercher la MTU maximale autorisée, le dispositif Edge effectue la détection de la MTU du chemin :
- Pour les liaisons WAN Internet publiques :
- La détection de la MTU du chemin est effectuée sur toutes les passerelles.
- La MTU de tous les tunnels est définie sur la MTU minimale détectée.
- Pour les liaisons WAN privées :
- La détection de la MTU du chemin est effectuée sur tous les autres dispositifs Edge du réseau client.
- La MTU de chaque tunnel est définie en fonction des résultats de la détection de la MTU du chemin.
Le dispositif Edge tente d'abord la détection de la MTU du chemin RFC 1191, où un paquet de la MTU de liaison connue actuelle (par défaut : 1 500 octets) est envoyé à l'homologue avec le bit « Don't Fragment » (DF) défini dans l'en-tête IP. Si ce paquet est reçu sur la passerelle ou le dispositif Edge distant, un paquet d'accusé de réception de la même taille est renvoyé au dispositif Edge. Si le paquet ne peut pas accéder à la passerelle ou au dispositif Edge distant en raison de contraintes de la MTU, le périphérique intermédiaire est censé envoyer un message ICMP de destination inaccessible (fragmentation nécessaire). Lorsque le dispositif Edge reçoit le message ICMP de destination inaccessible, il valide ce dernier (pour vérifier que la valeur MTU signalée est Sane) et une fois validée, ajuste la MTU. Le processus se répète ensuite jusqu'à ce que la MTU soit détectée.
Dans certains cas (par exemple, les dongles USB LTE), le périphérique intermédiaire n'envoie aucun message ICMP de destination inaccessible, même si le paquet est trop volumineux. En cas d'échec de RFC 1191 (le dispositif Edge n'a reçu aucun accusé de réception ou la destination ICMP est inaccessible), il revient à la détection de la MTU du chemin de la couche de paquétisation RFC 4821. Le dispositif Edge tente d'effectuer une recherche binaire pour détecter la MTU.
Lorsqu'une MTU est détectée pour un homologue, tous les tunnels vers cet homologue sont définis sur la même MTU. Cela signifie que si un dispositif Edge dispose d'une liaison avec une MTU de 1 400 octets et d'une liaison avec une MTU de 1 500 octets, tous les tunnels disposent d'une MTU de 1 400 octets. Cela garantit l'envoi à tout moment de paquets sur n'importe quel tunnel à l'aide de la même MTU. Nous l'appelons MTU effective de dispositif Edge (Effective Edge MTU). En fonction de la destination (VPN ou Internet à chemins multiples), la capacité supplémentaire décrite ci-dessus est soustraite pour calculer la MTU effective de paquet (Effective Packet MTU). Pour le trafic Internet direct ou autre trafic de sous-couche, la capacité supplémentaire est de 0 octet et, étant donné que le basculement de la liaison n'est pas requis, la MTU effective de paquet est identique à la MTU de liaison WAN détectée.
Trafic VPN et MTU
Maintenant que le dispositif SD-WAN Edge a détecté la MTU et qu'il a calculé les capacités supplémentaires, vous pouvez calculer une MTU effective pour le trafic client. Le dispositif Edge tente d'appliquer cette MTU aussi efficacement que possible pour les différents types potentiels de trafic reçu.
Trafic TCP
Le dispositif Edge effectue automatiquement l'ajustement de la taille maximale de segment (Maximum Segment Size, MSS) pour les paquets TCP reçus. Du fait que les paquets SYN et SYN|ACK traversent le dispositif Edge, la MSS est réécrite en fonction de la MTU effective de paquet.
Trafic non-TCP sans bit DF défini
Si le paquet est supérieur à la MTU effective de paquet, le dispositif Edge effectue automatiquement la fragmentation IP conformément à RFC 791.
Trafic non-TCP avec bit DF défini
Si le paquet est supérieur à la MTU effective de paquet :
- La première fois qu'un paquet est reçu pour ce flux (IP 5-tuple), le dispositif Edge abandonne le paquet et envoie un message ICMP de destination inaccessible (fragmentation nécessaire) conformément à RFC 791.
- Si les paquets suivants, qui sont toujours trop volumineux, sont reçus pour le même flux, ils sont fragmentés en plusieurs paquets VCMP et réassemblés de manière transparente avant le transfert à l'extrémité distante.
