Traduction de paquets et tunnelisation GRE

Avantages de la traduction de paquets et du tunneling GRE par les routeurs de périphérie d’entreprise

• Contourner les passerelles de datacenter
• Tunnelisation asymétrique en ce qui concerne l’encapsulation et la désencapsulation
• La traduction découplée et l’encapsulation en tunnel permettent au client de choisir une encapsulation différente à l’avenir avec un minimum de modifications logicielles, et également de sonder le chemin de transfert séparément

Comprendre les profils et découpler les profils

Le routeur de périphérie traduit les paquets en fonction des paramètres définis dans le profil de traduction. Les paramètres incluent le type de traduction (IPv4 vers IPv6 ou IPv6 vers IPv4), le type d’algorithme, les préfixes et d’autres informations connexes.

Les paquets sont encapsulés en fonction des paramètres définis dans le profil d’encapsulation du tunnel.

Afin de mettre en œuvre le découplage des profils, deux routes distinctes sont ajoutées par le responsable du traitement pour la traduction et l’encapsulation du tunnel :

• IPv4 RouteAdd() ou RouteUpdate() programme la route de destination dans la table d’inet VRF avec l’action comme translate.
• IPv6 RouteAdd() ou RouteUpdate() programme la route IPv6 traduite dans la table VRF inet6 avec l’action comme encapsulation GRE (en-tête de tunnel IPv4 externe et en-tête GRE)

Comprendre le chemin de transfert

Le routeur de périphérie effectue trois recherches de route par paquet IPv4.

• Recherche de route dans la table d’inet VRF : l’en-tête IPv4 est traduit en en-tête IPv6. Le contrôleur ajoute la route IPv4.

• Recherche de route dans la table VRF inet6 : l’adresse de destination IPv6 traduite est recherchée pour obtenir le profil d’encapsulation du tunnel, qui ajoute l’en-tête IPv4 GRE et le tunnel au-dessus de l’en-tête IPv6 interne. Le contrôleur ajoute la route IPv6.

• Recherche de route dans l’instance principale : la table d’inet de l’instance principale est recherchée pour acheminer les paquets du tunnel vers la destination du tunnel. IGP ajoute la route.

Traduction IPv4-IPv6

Les détails de la traduction sont les suivants :

• Si IPv4 est fragmenté ou comporte des options IP, il est ignoré.

• Le type de paquet passe de IPv4 à IPv6.

• Les champs ToS / DSCP sont copiés.

• La limite de sauts IPv6 est définie sur IPv4 TTL.

• Le protocole de charge utile est copié (sans vérification des erreurs/incohérences).

• L’adresse de destination du paquet IPv6 est définie sur TranslationDestinationIPv6.

• 96 bits les plus significatifs de l’adresse source du paquet IPv6 sont définis sur TranslationSourceIPv6Prefix.

• Les 32 bits les moins significatifs de l’adresse source du paquet IPv6 sont définis sur l’adresse IPv4 du paquet d’origine

Le paquet IPv6 traduit est illustré comme illustré à la Figure 2

Figure 2 : Format d’adresse source IPv6 traduit

GRE Encapsulation

Le contrôleur définit le profil d’encapsulation de tunnel GRE pour la destination IPv6 traduite via l’API PRPD. Le routeur de périphérie recherche la destination IPv6 traduite dans la table VRF inet6 du client pour l’encapsulation du tunnel. Les détails sont les suivants :

• Ajout d’un en-tête de tunnel IPv4 GRE externe

• La clé GRE est définie sur GREKey, qui est configurable par l’utilisateur

• La destination IPv4 est définie sur TunnelDestinationIPv4

• La source IPv4 est définie sur TunnelSourceIPv4

• Remarque :

  Le nombre de profils d’encapsulation de tunnel peut être inférieur ou égal au nombre de règles de conversion. Par défaut, un seul tunnel GRE peut être partagé entre plusieurs VRF de clients finaux. Dans PFE, il peut y avoir de nombreuses routes d’encapsulation GRE qui utilisent les mêmes paramètres de profil et donc le même tunnel prochain saut. Cependant, de nombreuses routes de traduction peuvent ne pas utiliser la même route GRE.

Après encapsulation, le format des paquets sur le routeur de périphérie est celui illustré à la Figure 3

Figure 3 : Formats de paquets après encapsulation

Comprendre les profils et découpler les profils

Le découplage des profils de déencapsulation et de traduction inverse est essentiel. Le contrôleur ajoute deux routes distinctes pour la traduction inverse et la désencapsulation du tunnel via des appels GRPC distincts.

• FlexibleTunnelAdd() programme la terminaison du tunnel pour qu’elle pointe vers le VRF de traduction global.

• IPv6 RouteAdd() ou RouteUpdate() programme la route IPv6 de destination interne dans la table VRF inet6 dans le VRF de traduction globale avec l’action comme traduction inverse et cible le VRF comme VRF du client final.

• La route VRF inet du client final pour l’adresse IPv4 traduite est programmée par le protocole BGP.

Comprendre le chemin de transfert

Le paquet IPv6 encapsulé GRE reçu du serveur PaaS fait l’objet d’une recherche de terminaison de tunnel, qui désencapsule l’en-tête GRE ou IPv4 et pointe vers le VRF où la recherche suivante pour la traduction inverse a lieu.

• Recherche de terminaison de tunnel GRE et déencapsulation de tunnel

  • Les attributs de déencapsulation forment une clé de recherche , une clé GRE, une adresse IPv4 de destination du tunnel, une source de tunnelpréfixe IPv4.

  • La recherche de terminaison de tunnel identifie l’instance VPN du client et supprime l’en-tête du tunnel (en-tête IPv4 externe et en-tête GRE).

  • L’en-tête GRE reçu du serveur PaaS aurait le bit de clé défini et une valeur de clé GRE de 32 bits. La recherche de transfert inclut la clé GRE avec les autres clés de recherche.

  • Les paquets sont dirigés vers le VRF cible, qui est le VRF de traduction globale.

• Traduction inverse et identification VRF du client final

  • Après la déencapsulation du tunnel, le trafic doit être acheminé vers le VRF du client final. Ce routage est effectué à l’aide de la recherche de route de traduction sur l’adresse InnerDestinationIPv6 dans un VRF de traduction globale, une instance de routage que le client crée pour contenir les routes de traduction IPv6.

    Vous pouvez utiliser l’adresse InnerDestinationIPv6 comme facteur de différenciation pour identifier le VRF du client final.

  • Dans la recherche de route de traduction (InnerDestinationIPv6), le profil de traduction inverse transforme l’en-tête IPv6 en en-tête IPv4 et pointe vers le VRF du client final. Les 32 bits inférieurs de l’adresse IPv6 forment l’adresse IPv4 traduite.

• Recherche de route dans la table d’inet VRF du client final

  • L’adresse IPv4 traduite est recherchée dans la table d’inet VRF pour acheminer le paquet vers le réseau client.

Figure 5 : Format de destination InnerIPv6

Comprendre l’adresse IPv6Src interne

L’API FlexibleTunnelAdd prend également en charge un paramètre facultatif, le champ InnerSourceIPv6. Vous pouvez utiliser ce paramètre facultatif pour inclure l’adresse IPv6 InnerSource, servant à terminer le tunnel GRE et à identifier le VRF client.

Lorsque l’adresse InnerSourceIPv6 est utilisée comme facteur de différenciation, vous pouvez configurer la recherche de terminaison de tunnel pour qu’elle pointe vers le VRF du client final en transmettant le VRF du client final comme VRF cible dans l’API FlexibleTunnelAdd. Dans ce cas, les routes de traduction (InnerDestinationIPv6) peuvent être programmées dans la table VRF respective du client final. Toutefois, l’activation de l’IPv6 InnerSourceIPv6 facultatif n’empêche pas l’utilisation du flux de déencapsulation avec VRF de traduction globale.

Figure 6 : Déencapsulation avec InnerIPv6Src

Désencapsulation GRE

Le processus de déencapsulation GRE comprend les étapes suivantes :

• La recherche de tunnel et l’instance TargetVRF sont déterminées à l’aide des clés de recherche définies précédemment.

• L’en-tête GRE externe est ignoré.

Traduction d’IPv6 en IPv4

Les détails de la traduction sont expliqués comme suit :

• Le type de paquet interne passe d’IPv6 à IPv4. Si le type de paquet interne n’est pas IPv6, le paquet est abandonné et le compteur d’erreurs est incrémenté.

• Le champ de protocole de la charge utile est copié sans vérification d’erreur ou d’incohérence.

• Le champ TC est copié dans le champ DSCP

• La durée de vie IPv4 est définie sur la limite de sauts IPv6 interne

• L’adresse de destination IPv4 du paquet est dérivée des 32 bits les moins significatifs de l’adresse de destination IPv6 interne

• L’adresse source IPv4 du paquet est dérivée des 32 bits les moins significatifs de l’adresse source IPv6 interne

La structure des paquets reçus au niveau du routeur de périphérie est illustrée à la figure 7.

Figure 7 : Formats de paquets (flux de déencapsulation)