Comprendre l’algorithme utilisé pour équilibrer la charge du trafic sur les routeurs MX Series

Lorsqu’un paquet est reçu sur l’interface entrante d’un équipement, le moteur de transfert de paquets (PFE) effectue une recherche vers le haut pour identifier le prochain saut de transfert. S’il existe plusieurs chemins à coût égal (ECMP) vers la même destination de saut suivant, le PFE d’entrée peut être configuré pour distribuer le flux entre les sauts suivants. De même, une répartition du trafic peut être nécessaire entre les liens membres d’une interface agrégée telle qu’Ethernet agrégé. La sélection du prochain saut de transfert réel est basée sur le résultat du calcul de hachage sur certains champs d’en-tête de paquet et plusieurs champs internes tels que l’index d’interface. Vous pouvez configurer certains des champs utilisés par l’algorithme de hachage.

Pour les routeurs MX Series avec des concentrateurs de ports modulaires (MPC) et des FPC de type 5, configurez le hachage pour les types de trafic pris en charge au niveau de la forwarding-options enhanced-hash-key hiérarchie. Vous trouverez ci-dessous des détails sur les champs inclus par défaut pour quelle famille de trafic.

Dans Junos OS version 18.3R1, la méthode par défaut de calcul du hachage amélioré a été modifiée afin d’améliorer l’entropie des tunnels IP, des flux IPv6 et des charges utiles PPPoE transmises en multiservice familial. Ces valeurs par défaut peuvent être désactivées en définissant leurs commandes no- respectives.
Pour les routeurs MX Series avec DPC, configurez le hachage pour les types de trafic pris en charge au niveau de la forwarding-options hash-key hiérarchie.

Junos prend en charge différents types d’équilibrage de charge.

équilibrage de charge par préfixe : chaque préfixe est mappé à un seul saut suivant de transfert.
équilibrage de charge par paquet : toutes les adresses de saut suivant pour une destination dans la route active sont installées dans la table de transfert (le terme équilibrage de charge par paquet dans Junos équivaut à ce que d’autres fournisseurs peuvent appeler un équilibrage de charge par flux ). Pour plus d’informations , reportez-vous à la section Configuration de l’équilibrage de charge par paquet .
équilibrage de charge aléatoire des paquets : les sauts suivants sont choisis de manière aléatoire pour chaque paquet. Cette méthode est disponible sur les routeurs MX avec des cartes de ligne MPC pour les interfaces Ethernet agrégées et les chemins ECMP. Pour configurer l’équilibrage de charge par pulvérisation aléatoire par paquet, incluez l’instruction per-packet au niveau de la [edit interfaces aex aggregated-ether-options load-balance] hiérarchie. Pour plus d’informations, reportez-vous à la section Exemple : configuration de l’équilibrage de charge Ethernet agrégé.
Équilibrage de charge de pulvérisation aléatoire par paquet – Lorsque l’option d’équilibrage de charge adaptatif échoue, l’équilibrage de charge de pulvérisation aléatoire par paquet ne sert qu’en dernier recours. Il garantit que les membres de l’ECMP sont chargés de manière égale sans tenir compte de la bande passante. L’option Par paquet entraîne une réorganisation des paquets et n’est donc recommandée que si les applications absorbent la réorganisation. La pulvérisation aléatoire par paquet élimine le déséquilibre du trafic qui se produit à la suite d’erreurs logicielles, à l’exception du hachage des paquets.

À partir de Junos OS version 20.2R1, vous pouvez configurer l’équilibrage de charge aléatoire par paquet sur les routeurs MX240, MX480 et MX960 avec carte de ligne MPC10E (MPC10E-15C-MRATE et MPC10E-10C-MRATE) et les routeurs MX2010 et MX2020 avec carte de ligne MX2K-MPC11E.
Équilibrage de charge adaptatif : l’équilibrage de charge adaptatif (ALB) est une méthode qui corrige un véritable déséquilibre de trafic en utilisant un mécanisme de rétroaction pour distribuer le trafic sur les liaisons d’un bundle Ethernet agrégé et sur les sauts suivants ECMP (Equal-cost Multipath). ALB optimise la distribution du trafic lorsque les flux de paquets ont des débits très variables. ALB utilise un mécanisme de rétroaction pour corriger le déséquilibre de charge du trafic en ajustant la bande passante et les flux de paquets sur les liaisons au sein d’un faisceau AE.
- ALB sur plusieurs moteurs de transfert de paquets pour les bundles Ethernet agrégés
  
  À partir de Junos OS version 20.1R1, sur les MPC MX Series, sur les bundles Ethernet agrégés, ALB redistribue le trafic de manière uniforme sur plusieurs moteurs de transfert de paquets (PFE) entrants sur la même carte de ligne. Dans les versions précédentes, ALB était limité à un seul PFE lors de la redistribution du trafic dans un bundle AE. Cela a eu un impact sur la flexibilité et la redondance. ALB est désactivé par défaut.
  
  Vous pouvez configurer ALB en définissant l’instruction adaptive au niveau de la [edit interfaces ae-interface aggregated-ether-options load-balance] hiérarchie.
  
  Pour plus d’informations, reportez-vous à la section Configuration de l’équilibrage de charge adaptatif .
- ALB sur plusieurs PFE pour les sauts suivants ECMP
  
  À partir de Junos OS version 20.1R1, vous pouvez configurer ALB pour les sauts ECMP suivants sur plusieurs PFE entrants sur la même carte de ligne afin d’assurer une répartition uniforme du trafic et la redondance. Dans les versions précédentes, l’ALB pour les sauts ECMP next était limité à un seul PFE. Cette limitation a eu un impact sur la flexibilité et la redondance. ALB surveille dynamiquement la charge de trafic apportée par chaque flux par rapport aux niveaux de charge globaux de la liaison ECMP, puis prend des mesures correctives lorsque le seuil est atteint.
  
  Vous pouvez configurer ALB pour les sauts suivants ECMP en configurant la ecmp-alb commande sous le niveau hiérarchique [edit chassis] .
  
  Voir ecmp-alb pour plus d’informations.
Note:
ALB fonctionne pour plusieurs PFE résidant sur la même carte de ligne. Cette fonctionnalité ne sera pas prise en charge pour les PFE résidant sur des cartes de ligne différentes.

Pour les PFE résidant sur des cartes de ligne différentes, le trafic entrant peut entraîner une charge inégale sur les ports de sortie, même si l’ALB est activé.

Plusieurs options de configuration supplémentaires sont également disponibles :

Configuration de la fonction de hachage par emplacement –Cette méthode est basée sur une valeur de hachage unique d’équilibrage de charge pour chaque emplacement PIC et n’est valable que pour les routeurs M120, M320 et MX Series équipés de cartes de ligne DPCE et MS-DPC.
équilibrage de charge symétrique : cette méthode fournit une équilibrage de charge symétrique sur un LAG 802.3ad. Le hachage utilisé pour l’équilibrage de charge symétrique est défini au niveau de la interface hiérarchie. Il garantit qu’un flux donné de trafic duplex traverse les mêmes périphériques dans les deux sens, et est disponible sur les routeurs MX Series.

Spécificités du MX MPC et du FPC de type 5 de la série T

L’algorithme de calcul de hachage sur les FPC MX MPC et T Series Type 5 produit des résultats identiques pour les paquets avec des adresses de couche 3 ou des ports de transport de couche 4 échangés. Par exemple, le résultat du calcul de hachage pour un paquet dont l’adresse source est 192.0.2.1 et l’adresse de destination 203.0.113.1 est identique au résultat du calcul de hachage pour un paquet dont l’adresse source est 203.0.113.1 et l’adresse de destination 192.0.2.1.

Pour éviter une éventuelle réorganisation des paquets, les ports du protocole de transport de couche 4 ne sont jamais utilisés dans le calcul de hachage des paquets IPv4 fragmentés. Cela est vrai pour le premier fragment du flux, identifié par le bit dans un en-tête, et tous les fragments suivants, identifiés par un more fragment décalage de fragment non nul. Le premier fragment et les fragments suivants sont toujours transférés via le même saut suivant.

Algorithme de hachage utilisé dans Junos 18.3R1 et versions ultérieures

Dans la plupart des cas, l’inclusion d’informations de champ de couche 3 et de couche 4 dans le calcul de hachage produit des résultats suffisamment bons pour une distribution équitable du trafic. Toutefois, dans des cas tels que les tunnels IP dans IP ou GRE, les informations de champ des couches 3 et 4 peuvent ne pas suffire à elles seules à produire un hachage avec une entropie suffisante pour l’équilibrage de charge. Par exemple, dans un déploiement où des routeurs MX Series transitent des flux GRE, les tunnels d’encapsulation GRE se présentent généralement sous la forme d’un flux unique avec la même source et la même destination, ainsi que la même clé GRE. Les flux gras peuvent également accentuer sensiblement le déséquilibre dans l’utilisation des liaisons, à mesure que le volume de trafic sur les tunnels augmente. Un autre exemple est lorsque les routeurs MX PE sont utilisés comme périphériques VPLS PE dans un déploiement de périphérie d’abonné où les routeurs acheminent le trafic d’abonnés haut débit des périphériques d’accès vers une passerelle réseau haut débit (BNG) centrale. Dans ce cas, seules les adresses MAC de l’abonné et les adresses MAC du routeur BNG sont disponibles pour le hachage. Mais avec peu d’adresses MAC BNG et relativement peu d’adresses MAC d’abonné, les champs typiques des couches 3 et 4 ne suffisent pas à créer un hachage pour un équilibrage de charge optimal.

Par conséquent, pour les routeurs MX Series avec MPC Trio et exécutant Junos OS version 18.3R1 ou ultérieure, le calcul par défaut enhanced-hash-key a changé. Vous trouverez ci-dessous un résumé des modifications :

Pour les paquets GRE, si le paquet IP externe n’est pas un paquet fragmenté (premier fragment ou tout fragment suivant) et que le paquet interne est IPv4 ou IPv6, alors les adresses source et de destination du paquet interne sont utilisées dans le calcul de hachage en plus des adresses source et de destination externes. Les ports de couche 4 du paquet interne sont également inclus si le protocole du paquet IP interne est TCP ou UDP et que le paquet IP interne n’est pas un fragment (premier fragment ou tout fragment suivant). De même, si le paquet IP externe n’est pas un paquet de fragments et que le paquet interne est MPLS, l’étiquette interne supérieure est incluse dans le calcul de hachage.
Pour les paquets PPPoE, si le paquet interne est IPv4 ou IPv6, les adresses source et de destination du paquet interne sont incluses. Les ports de couche 4 sont inclus si le protocole du paquet IP interne est TCP ou UDP et que le paquet IP interne n’est pas un fragment. L’inclusion des champs de paquets internes PPPoE peut être désactivée en configurant l’option no-payload au niveau de la forwarding-options enhanced-hash-key family multiservice hiérarchie.
Pour IPv6, le champ d’étiquette de flux d’en-tête IPv6 est inclus dans le calcul de hachage. La RFC 6437 décrit le champ d’étiquette de flux 20 bits dans l’en-tête IPv6. Définissez l’option no-flow-label au niveau de la forwarding-options enhanced-hash-key family inet6 hiérarchie pour désactiver la nouvelle valeur par défaut.

Champs de hachage utilisés pour le trafic GRE envoyé via IPv4

Les listes indiquent les champs utilisés dans le calcul de hachage, pour les paquets non fragmentés, dans Junos 18.3R1 et versions ultérieures. Par défaut, le champ est utilisé dans le calcul du hachage, sauf indication contraire. De plus, lorsque cela est indiqué, les champs IP et port utilisés dans le hachage sont symétriques, c’est-à-dire que l’échange des champs ne modifie pas le résultat du hachage.

IPv4, GRE
- Clé GRE
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

IPv4 dans IPv4, GRE
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
- Clé GRE
  
  Protocole GRE = IPv4
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

IPv6 dans IPv4, GRE
- Charge utile (IPv6 interne : ports source et de destination, adresses IP) ; Symétrique
- Clé GRE
  
  Protocole GRE = IPv6
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

MPLS dans IPv4, GRE
- Charge utile (MPLS interne : étiquette supérieure)
- Clé GRE
  
  Protocole GRE = MPLS
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

IPv4, L2TPv2 utilisés dans Junos 17.2 et versions ultérieures

L’inclusion de l’ID de tunnel L2TPv2 et de l’ID de session peut être activée en configurant l’option forwarding-options enhanced-hash-key family inet l2tp-tunnel-session-identifier . Notez que Juniper ne recommande pas d’activer cette option par défaut. En effet, l’identification de session L2TP est basée sur la correspondance du port UDP de destination (1701) et ce port peut ne pas être exclusivement utilisé pour le transport L2TP, de sorte que l’extraction des champs d’ID de tunnel et de session du paquet n’est pas toujours exacte.
- Session ID
- Tunnel ID
- Port source et port de destination
- Adresse source et adresse de destination ; Symétrique
- Protocole (UDP)
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour le trafic GRE envoyé via IPv6

La liste affiche les champs utilisés dans le calcul de hachage pour les paquets non fragmentés. Par défaut, le champ est utilisé dans le calcul du hachage, sauf indication contraire. De plus, lorsque cela est indiqué, les champs IP et port utilisés dans le hachage sont symétriques, c’est-à-dire que l’échange des champs ne modifie pas le résultat du hachage.

IPv6, GRE
- Clé GRE
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

IPv4 dans IPv6, GRE (Junos 18.3 et versions ultérieures)
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
- Clé GRE
  
  Protocole GRE = IPv4
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

IPv6 dans IPv6, GRE (Junos 18.3 et versions ultérieures)
- Charge utile (IPv6 interne : ports source et de destination, adresses IP) ; Symétrique
- Clé GRE
  
  Protocole GRE = IPv6
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

MPLS en IPv6, GRE (Junos 18.3 et versions ultérieures)
- Charge utile (MPLS interne : étiquettes supérieures) ; Symétrique
- Clé GRE
  
  Protocole GRE = MPLS
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour IPv4

La liste affiche les champs utilisés dans le calcul de hachage pour les paquets non fragmentés, sauf indication contraire. Par défaut, le champ est utilisé dans le calcul du hachage, sauf indication contraire. De plus, le hachage des champs IP et port est symétrique, c’est-à-dire que l’échange des champs ne modifie pas le résultat du hachage.

IPv4, pas TCP ou UDP, ou paquets fragmentés
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

IPv4, TCP et UDP, paquets non fragmentés
- Port source et port de destination ; Symétrique
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

IPv4, PPTP
- 16 bits les moins significatifs de la clé GRE
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)
Trafic IPv4, GTP, UDP vers le port de destination 2152

L’inclusion de l’identifiant de point de terminaison de tunnel (TEID) du protocole de tunnelisation GPRS (GTP) peut être activée à l’aide de cette forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier option. Notez que Juniper ne recommande pas d’activer cette option par défaut. En effet, l’identification de session GTP est basée sur la correspondance du port UDP de destination (2152) et ce port peut ne pas être exclusivement utilisé pour le transport GTP, de sorte que l’extraction du champ TEID du paquet peut ne pas toujours être précise.
- GTP TEID (désactivé)
- Port source et port de destination
- Adresse source et adresse de destination ; Symétrique
- Protocole
- DSCP (désactivé)
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour IPv6

IPv6, paquet non TCP et UDP, ou paquet TCP et UDP fragmenté par l’expéditeur
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

IPv6, paquets TCP et UDP non fragmentés
- Port source et port de destination ; Symétrique
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

IPv6, PPTP
- 16 bits les moins significatifs de la clé GRE
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)
IPv6, GTP

L’inclusion de l’identifiant de point de terminaison de tunnel (TEID) du protocole de tunnelisation GPRS (GTP) peut être activée au niveau de la forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier hiérarchie. Notez que Juniper ne recommande pas d’activer cette option par défaut. En effet, l’identification de session GTP est basée sur la correspondance du port UDP de destination (2152) et ce port peut ne pas être exclusivement utilisé pour le transport GTP, de sorte que l’extraction du champ TEID du paquet peut ne pas toujours être précise.
- GTP TEID (désactivé par défaut ; activé au niveau de la forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier hiérarchie.
- Port source et port de destination
- Adresse source et adresse de destination ; Symétrique
- En-tête suivant
- Étiquette de flux (Junos 18.3 et versions ultérieures)
- Classe de trafic (désactivée)
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour le multiservice

La configuration de hachage multiservice familiale s’applique aux paquets entrant dans le routeur sous la forme family ccc, vpls, ou bridge. La liste affiche les champs utilisés dans le calcul de hachage pour les paquets non fragmentés. Par défaut, le champ est utilisé dans le calcul du hachage, sauf indication contraire. De plus, lorsque cela est indiqué, les champs IP et port utilisés dans le hachage sont symétriques, c’est-à-dire que l’échange des champs ne modifie pas le résultat du hachage.

Ethernet, non-IP ou non-MPLS

Si cette configuration est configurée, les informations relatives à la charge utile sont extraites des paquets non étiquetés ou des paquets comportant jusqu’à deux balises VLAN.
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

Ethernet, IPv4
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

Ethernet, IPv6
- Charge utile (IPv6 interne : ports source et de destination, adresses IP) ; Symétrique
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

Ethernet, MPLS
- Charge utile (MPLS interne : étiquettes supérieures plus champs IPv4 et IPv6 internes) ; Symétrique. Pour plus d’informations, reportez-vous à la section Champs de hachage utilisés pour MPLS, Junos 18.3 et versions ultérieures ci-dessous.
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

IPv4 dans PPPoE (paquet de données)
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
- Protocole PPP IPv4 version 0x1, type 0x1
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

IPv6 dans PPPoE (paquet de données)
- Charge utile (IPv6 interne : ports source et de destination, adresses IP) ; Symétrique
- Protocole PPP IPv6 version 0x1, type 0x1
- Externe 802.1p (désactivé)
- MAC source et de destination ; Symétrique
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour MPLS, Junos 18.3 et versions ultérieures

MPLS, IPv4 ou IPv6 encapsulé
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
- Charge utile (IPv6 interne : ports source et de destination, adresses IP, en-tête suivant) ; Symétrique
- Label 1..16 (20 bits)
- EXP de l’étiquette extérieure (désactivée)
- Index de l’interface entrante (désactivé)

MPLS, IPv4 ou IPv6 dans Ethernet pseudo-wire
- Charge utile (IPv4/IPv6 dans Ethernet pseudo-wire)
- Label 2..16 (20 bits)
- EXP de l’étiquette extérieure (désactivée)
- Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

MPLS, MPLS dans Ethernet pseudo-wire
- Charge utile (deux étiquettes supérieures de l’entrée de la pile d’étiquettes MPLS dans le pseudo-fil Ethernet)
- Label 2..16 (20 bits)
- EXP de l’étiquette extérieure (désactivée)
- Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

MPLS, étiquette d’entropie

Lorsqu’une étiquette d’entropie est détectée, le champ de charge utile n’est pas traité et l’indicateur n’est pas inclus dans le calcul du hachage
- Label 1..16 (20 bits)
- EXP de l’étiquette extérieure (désactivée)
- Index de l’interface entrante (désactivé)

Champs de hachage utilisés pour MPLS de Junos 14.1 à Junos 18.3

MPLS, IPv4 ou IPv6 encapsulé
- Charge utile (IPv4 interne : ports source et de destination, adresses IP) ; Symétrique
  
  Charge utile (IPv6 interne : ports source et de destination, adresses IP, en-tête suivant) ; Symétrique
- Label 2.8 (20 bits)
  
  EXP de l’étiquette extérieure (désactivée)
  
  Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

MPLS, IPv4 ou IPv6 dans Ethernet pseudo-wire
- Charge utile (IPv4/IPv6 dans Ethernet pseudo-wire)
- Label 2.8 (20 bits)
  
  EXP de l’étiquette extérieure (désactivée)
  
  Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

MPLS, MPLS dans Ethernet pseudo-wire
- Charge utile (deux étiquettes supérieures de l’entrée de la pile d’étiquettes MPLS dans le pseudo-fil Ethernet)
- Label 2..16 (20 bits)
- EXP de l’étiquette extérieure (désactivée)
- Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

MPLS, étiquette d’entropie

Lorsqu’une étiquette d’entropie est détectée, le champ de charge utile n’est pas traité et l’indicateur n’est pas inclus dans le calcul du hachage
- Label 2.8 (20 bits)
  
  EXP de l’étiquette extérieure (désactivée)
  
  Étiquette 1 (20 bits)
- Index de l’interface entrante (désactivé)

Liste des mises à jour de Junos pour le calcul du hachage et l’équilibrage de charge pour les routeurs MX Series avec MPC

Tableau 1 : Liste des mises à jour pour les routeurs MX Series
`Junos Release`	`Change`
18.3R1	Inclut l’étiquette de flux IPv6, l’en-tête GRE interne et le PPPoE interne dans le calcul de hachage par défaut. Augmente la profondeur de la pile d’étiquettes MPLS à 16 étiquettes.
17.2R1	Équilibrage de charge pour les paquets IPv4 et IPv6 encapsulés en L2TP.
16.1R1	Inclut le hachage de la charge utile EoMPLS avec le mot de contrôle. Introduit le hachage basé sur la source uniquement et la destination uniquement.
15.1R1	Fournit une distribution ciblée des interfaces statiques sur les liaisons membres AE. Inclut la source, la destination et l’adresse MAC de la charge utile PPPoE encapsulée MPLS dans le calcul de hachage par défaut.
14.2R3	Augmente la mise à l’échelle du LAG et du MC-LAG.
14.2R2	Fournit un ensemble Ethernet agrégé avec des liaisons 10G, 40G et 100G.
14.1R1	Découple la création de l’interface aeX à partir de `ch agg eth dev`. Augmente l’espace de noms d’interface Ethernet agrégé. Fournit un équilibrage de charge adaptatif pour les sauts suivants ECMP.
13.3R1	Inclut des améliorations pour l’équilibrage de charge adaptatif, aléatoire par paquet et à rééquilibrage périodique.
11.4R1	permet de partager la charge entre les sauts suivants ECMP.