Traditionnellement, la QoS était gérée soit globalement sur une interface, soit par sous-interface, soit par service-instance. La politique était donc valide soit pour toute l’interface, soit pour une partie bien précise. Seulement parfois on va vouloir créer des règles partagées entre plusieurs sous-interfaces ou service-instances. Le plus simple est de prendre l’exemple du réseau suivant, interconnectant un site principal avec 2 sites distants via un réseau managé de niveau 2. L’entreprise va pouvoir définir des VLANs point-à-point au-dessus de l’infrastructure de niveau 2. Tous ces VLANs vont arriver sur la même interface physique au niveau du site principal.
Ici 2 VLANs ont été créés entre le site principal et le site 2. Comment traiter la QoS de manière globale entre ces 2 VLANs? Par exemple comment shaper la somme du trafic des 2 VLANs JAUNE et BLEU à 20Mbps afin d’être conforme au débit souscrit sur le site distant? C’est justement le rôle des service-groups.
Les service-groups sont une des nouvelles fonctionnalités sorties sur IOS-XE 3.15S. Supportée sur ASR1000, ISR4000 et CSR1000v, cette fonctionnalité permet de partager une règle de QoS entre plusieurs sous-interfaces ou service-instances.
La première étape consiste à créer les groupes en question, et d’y appliquer les configurations de QoS souhaitées.
service-group 1 description VLANs vers SITE-1 service-policy output SITE-10Mbps service-group 2 description VLANs vers SITE-2 service-policy output SITE-20Mbps
Je vous épargne ici la définition des policy-maps et des class-maps, pas grand intérêt. Notez juste qu’il est possible dans la policy-map appliquée à un group de faire référence à un VLAN dans une class-map et ainsi de pouvoir appliquer des spécificités à un VLAN dédié. La hiérarchie à 3 niveaux de la QoS sur les plateformes concernées permet cela.
Après on peut placer les service instances dans des groupes (pour une configuration flexible avec des services switchés et d’autres routés avec utilisation de BDI). Pour ceux qui ont besoin d’un rappel sur les service instances et plus globalement les EVC, vous pouvez relire cet article que j’avais publié en 2012.
interface GigabitEthernet0/0/0 no ip address negotiation auto service instance 101 ethernet description ROUGE encapsulation dot1q 101 group 1 bridge-domain 101 ! service instance 106 ethernet description BLEU encapsulation dot1q 106 group 2 bridge-domain 106 ! service instance 107 ethernet description JAUNE encapsulation dot1q 107 group 2 bridge-domain 107
Autre option on peut tout gérer au niveau des sous-interfaces quand on n’a pas besoin de service instances (pas de switching par exemple)
interface GigabitEthernet0/0/0 no ip address negotiation auto ! interface GigabitEthernet0/0/0.101 description ROUGE encapsulation dot1Q 101 ip address 192.168.101.1 255.255.255.0 group 1 ! interface GigabitEthernet0/0/0.106 description BLEU encapsulation dot1Q 106 ip address 192.168.106.1 255.255.255.0 group 2 ! interface GigabitEthernet0/0/0.107 description JAUNE encapsulation dot1Q 107 ip address 192.168.107.1 255.255.255.0 group 2
Dans ces 2 exemples de configuration, je vais partager la règle de QoS “SITE-20Mbps” entre les 2 VLANs JAUNE et BLEU. Cela me permet bien d’arriver au comportement désiré qui est par exemple d’avoir un shaper global à 20Mbps pour tout le trafic en direction du site distant, quelque soit le VLAN.
On va retrouver également ces service-groups sur des plateformes métro (ASR920 / ASR 900). Sur IOS-XR on peut utiliser les Shared Policy Instances pour arriver au même résultat.
@JeromeDurand
Authors
