Configuration du transfert coS
Vous pouvez appliquer le transfert coS (CBF) uniquement à un ensemble défini de routes. Par conséquent, vous devez configurer une déclaration de stratégie comme dans l’exemple suivant :
[edit policy-options]
policy-statement my-cos-forwarding {
from {
route-filter destination-prefix match-type;
}
then {
cos-next-hop-map map-name;
}
}
Cette configuration spécifie que les routes correspondant au filtre de routage sont soumises au mappage du saut suivant CoS spécifié par map-name. Pour plus d’informations sur la configuration des déclarations de stratégie, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et du contrôle du trafic.
Sur les routeurs M Series (à l’exception des routeurs M120 et M320), la correspondance basée sur les classes de transfert et le CBF ne fonctionnent pas comme prévu si la classe de transfert a été définie avec un filtre multi-champs sur une interface d’entrée.
À partir de la version 17.2 de Junos OS, les routeurs MX avec MPC ou MS-DPC, VMX, PTX3000 et PTX5000 prennent en charge la configuration du transfert basé sur coS (CBF) pour un maximum de 16 classes de transfert. Toutes les autres plates-formes prennent en charge CBF pour un maximum de 8 classes de transfert. Pour prendre en charge jusqu’à 16 classes de transfert pour les routeurs CBF sur MX, activez l’activation enhanced-ip au niveau hiérarchique [edit chassis network-services] .
Vous pouvez configurer CBF sur un équipement avec le nombre ou moins de classes de transfert pris en charge, plus une classe de transfert par défaut uniquement. Dans cette condition, le mappage de la classe de transfert vers les files d’attente peut être soit un-à-un ou un-à-plusieurs. Toutefois, vous ne pouvez pas configurer CBF lorsque le nombre de classes de transfert configurées dépasse le nombre pris en charge. De même, avec CBF configuré, vous ne pouvez pas configurer plus que le nombre pris en charge de classes de transfert plus une classe de transfert par défaut.
Pour spécifier une carte coS du saut suivant, incluez l’instruction forwarding-policy au niveau de la [edit class-of-service] hiérarchie :
[edit class-of-service] forwarding-policy { next-hop-map map-name { forwarding-class class-name { discard; lsp-next-hop [ lsp-regular-expression ]; next-hop [ next-hop-name ]; non-lsp-next-hop; } forwarding-class-default { discard; lsp-next-hop [ lsp-regular-expression ]; next-hop [next-hop-name]; non-lsp-next-hop; } } }
Lorsque vous configurez CBF avec OSPF comme protocole IGP (Interior Gateway Protocol), vous devez spécifier le saut suivant en tant que nom d’interface ou alias de saut suivant, et non en tant qu’adresse IPv4 ou IPv6. Cela est vrai parce qu’OSPF ajoute des routes avec l’interface comme saut suivant pour les interfaces point à point ; le saut suivant ne contient pas l’adresse IP. Pour obtenir un exemple de configuration, consultez Exemple : configuration du transfert coS.
Pour les VPN de couche 3, lorsque vous utilisez un transfert basé sur des classes pour les routes reçues du routeur de périphérie des fournisseurs lointains (PE) dans une instance VRF, le logiciel peut faire correspondre les routes en fonction des attributs qui viennent avec le routage reçu uniquement. En d’autres termes, la correspondance peut être basée sur le routage dans rib-in. Dans ce cas, l’instruction route-filter que vous incluez au niveau de la [edit policy-options policy-statement my-cos-forwarding from] hiérarchie n’a aucun effet, car la stratégie vérifie la bgp.l3vpn.0 table, et non la vrf.inet.0 table.
Junos OS applique la carte CoS du saut suivant à l’ensemble des sauts suivants précédemment définis ; les sauts suivants peuvent être localisés sur n’importe quelle interface sortante de l’équipement de routage. Par exemple, la configuration suivante associe un ensemble de classes de transfert et des identifiants de saut suivant :
[edit class-of-service forwarding-policy]
next-hop-map map1 {
forwarding-class expedited-forwarding {
next-hop next-hop1;
next-hop next-hop2;
}
forwarding-class best-effort {
next-hop next-hop3;
lsp-next-hop lsp-next-hop4;
}
forwarding-class-default {
lsp-next-hop lsp-next-hop5;
}
}
Dans cet exemple, next-hop N est une adresse IP ou une interface de sortie pour un saut suivant, et lsp-next-hop N est une expression régulière correspondant à n’importe quel saut suivant avec ce label. Q1 à QN sont un ensemble de classes de transfert qui mappent au saut suivant spécifique. Autrement dit, lorsqu’un paquet est commuté avec Q1 à QN, il est transféré vers l’interface associée au saut suivant associé.
Cette configuration a les implications suivantes :
Une seule classe de transfert peut correspondre à plusieurs sauts suivants standard ou sauts suivants LSP. Cela implique que le partage de charge s’effectue entre les sauts suivants standard ou les sauts suivants LSP pour la même valeur de classe. Pour que cela fonctionne correctement, Junos OS crée une liste des sauts suivants à coût égal et transfère les paquets selon des règles de partage de charge standard pour cette classe de transfert.
Si une configuration de classe de transfert comprend des sauts suivants LSP et des sauts suivants standard, les sauts suivants LSP sont préférés aux sauts suivants standard. Dans l’exemple précédent, si les sauts
next-hop3lsp-next-hop4suivants et sont valides pour un routagemap1auquel est appliqué, la table de transfert inclut uniquement l’entréelsp-next-hop4.Si
next-hop-mapelle ne spécifie pas toutes les classes de transfert possibles, la classe de transfert par défaut est sélectionnée comme étant la valeur par défaut. default-forwarding class Elle définit le saut suivant pour le trafic qui ne répond à aucune classe de transfert dans le plan de sauts suivant. Si la classe de transfert par défaut n’est pas spécifiée dans le plan du saut suivant, une valeur par défaut est désignée au hasard. La classe de transfert par défaut est la classe associée à la file d’attente 0.Pour les sauts suivants LSP, Junos OS utilise des expressions régulières de style UNIX
regex(3). Par exemple, si les labels suivants existent :lsp,lsp1,lsp2,lsp3, l’instructionlsp-next-hop lspcorrespondlspà ,lsp1etlsp3lsp2. Si vous ne souhaitez pas ce comportement, vous devez utiliser les caractèreslsp-next-hop " ^lsp$"d’ancre, qui correspondentlspuniquement.Le filtre de routage ne fonctionne pas, car la stratégie vérifie par rapport à la
bgp.l3vpn.0table plutôt qu’à lavrf.inet.0table.
La dernière étape consiste à appliquer le filtre de routage aux routes exportées vers le moteur de transfert. C’est ce que montre l’exemple suivant :
routing-options {
forwarding-table {
export my-cos-forwarding;
}
}
Cette configuration demande au processus de routage d’insérer des routes vers le moteur de transfert correspondant aux my-cos-forwarding règles CBF associées au saut suivant.
L’algorithme suivant est utilisé lorsque vous appliquez une configuration à un routage :
Si l’itinéraire est un itinéraire unique à saut suivant, tout le trafic y est acheminé ; c’est-à-dire qu’aucune CBF ne prend effet.
Pour chaque saut suivant, associez la classe de transfert appropriée. Si un saut suivant apparaît dans la route, mais pas dans la
cos-next-hopcarte, il n’apparaît pas dans l’entrée de la table de transfert.La classe de transfert par défaut est utilisée si toutes les classes de transfert ne sont pas spécifiées dans le plan du saut suivant. Si la valeur par défaut n’est pas spécifiée, la valeur par défaut est attribuée à la classe la plus basse définie dans le plan du saut suivant.