Un lien opérateur à 200Mbps fourni sur une interface GE? La solution est connue depuis la nuit des temps: on shape à 200Mbps sur l’interface puis on effectue notre queuing/scheduling ensuite. En l’absence de shaper l’interface n’est jamais vue comme congestionnée et donc aucun mécanisme de QoS ne rentre en jeu. On utilise donc une QoS hiérarchique (HQoS) : on fait notre stratégie de queuing à l’intérieur d’un shaping. Si on effectue ces fonctions généralement sur les routeurs avec des options sophistiquées et une grande scalabilité, on a également une HQoS de base sur les commutateurs catalyst qui pourra peut-être vous dépanner un jour…
Les catalyst 3650, 3850 et 6500/6800 (carte 6904 uniquement avec sup2T) permettent de faire un port-shaper puis d’appeler une policy-map fille qui attribuera la priorité ad-hoc à chaque fille. Le passage en QoS MQC simplifie grandement la configuration. Un exemple sur mon 3850 (release 3.6E ici – je vous épargne les class-maps).
policy-map QUEUING class REALTIME priority level 1 percent 10 class CONTROL bandwidth remaining percent 10 class TRANSACTIONAL-DATA bandwidth remaining percent 50 class BEST-EFFORT bandwidth remaining percent 40 ! policy-map RESEAUXBLOG class class-default shape average 200000000 service-policy QUEUING ! interface GigabitEthernet1/0/17 service-policy output RESEAUXBLOG
Sur le cat6k, la fonction nécessitait auparavant une carte WAN (SIP400/SIP600/ES). Avec la sup2T ces cartes ne sont plus supportées et l’on se focalise sur le coeur du réseau d’entreprise (et non le WAN). Mais une HQoS de base étant toujours bienvenue on a ajouté cette fonctionnalité sur la carte 6904 (4 ports 40GE convertibles en 16 ports GE/10GE). Même type de configuration que ci-dessus (merci la MQC!). Vous trouverez également des détails dans les références.
Petit conseil avant de terminer, pensez bien à vérifier que l’application des policy-map (via la commande service-policy) est fonctionnelle. On est en MQC mais le hardware des commutateurs est moins flexible que celui des routeurs (par exemple avec 8 files d’attente supportées sur le switch ne vous amusez pas à assigner un bandwidth sur 9 classes d’une même policy-map…)
Références
Guide de configuration de la QoS sur catalyst 3850 (et 3650)
Whitepaper sup2T (Regarder le chapitre 16 pour la HQoS sur la carte 6904)
@JeromeDurand
2 commentaires
Bonjour,
merci beaucoup pour cet article très utile.
Je m’aperçois que vous affichez la ‘policy-map’ pour faire le queing mais pas la ‘class-map’ qui permet de matcher les flux à classifier.
Sur de l’IP cela ne me pose pas plus de soucis que ça (‘match ip precedence’), mais une question s’impose :
Comment classifier en ‘out’ sur des flux MPLS ?
Sur le 3650/3850 pas de difficulté car pas de MPLS 🙂
La méthode classique consiste à mapper les champs DSCP IP dans des champs EXP MPLS puis de matcher sur le champ EXP au niveau de la class-map.
Le config guide suivant devrait donner pas mal d’infos sur le sujet: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup2T/15_1_sy_swcg_2T/mplsqos.html