Bonjour à tous,
Tout d’abord merci pour vos retours positifs, ça fait toujours plaisir à lire
Slothy ta remarque ça m’a donné l’occasion de creuser un peu plus en détail cette histoire de CoS et j’ai une bonne nouvelle
pour les processeurs d’un Mikrotik / RouterOS, pas besoin de bidouiller des binaires ou d’installer un switch en amont, vous pouvez bien changer la CoS de vos requêtes DHCP directement depuis RouterOS.
Comme à mon habitude, explication
Protocole de testTu indiques la manière de marquer les requêtes en CoS 6 via une règle Mangle, mais il me semble que cela a été testé et ne fonctionne pas car il faut que le paquet soit marqué avant qu'il arrive au routeur. Vu que tu es dans une zone qui n'a pas besoin de la CoS, tu ne peux pas tester, c'est dommage
En effet de chez moi, pas besoin de définir une CoS spécifique sur les requêtes DHCP pour obtenir une IP. Je ne peux donc « tester » directement.
La « CoS » pour « Class of service » va définir la priorité d’une trame Ethernet (couche 2). Cette notion a été introduite par ce que l’on appelle le « 802.1p » bien que ce ne soit pas un standard à part entière, cette notion est incorporée dans le standard 802.1D. L’idée du « 802.1p » étant d’implèmenter un mécanisme de « QoS » au niveau de la couche 2 (MAC).
Cependant la « CoS » bien que définie par le « 802.D » ne peut pas fonctionner sans les « VLAN » définis eux par un autre standard, le « 802.1Q », car cette information est stockée dans un champ nommé « PCP » (Priority code point) contenu dans l’entête d’une trame Ethernet au format 802.1Q au côté du « VID » (Vlan identifier).
En effet, une trame « taguée » (802.1Q) contient un surplus de 32 bits dans l’entête de la trame Ethernet pour contenir entre autre le numéro du VLAN (VID) mais aussi la priorité de la trame (PCP).
C’est donc seulement les trames Ethernet 802.1Q « taguées » qui peuvent contenir cette information, une trame Ethernet classique (802.3) ne peut pas contenir d’information quant à la priorité (on utilisera alors le ToS/DSCP au niveau 3, pour ajouter l’indice de priorité dans l’entête d’un paquet IP).
Le champ PCP occupe 3 bits (soit 8 valeurs possibles) ce qui permet de définir la priorité de la trame avec une valeur comprise entre 0 (priorité minimale) et 7 (priorité maximale).
Dans notre cas, les requêtes DHCP envoyées à Orange sont contenues dans des trames 802.1Q étant donné que l’on discute avec Orange en utilisant différents VLANs, celui qui nous intéresse ici étant le VLAN 832 pour Internet et doivent être marquées avec un CoS à « 6 » (classe
Internetwork Control) soit une priorité très haute.
De ce fait même si je ne peux pas réellement tester le fonctionnement, on peut vérifier en analysant le trafic entre le routeur et Orange au moyen d’un « sniffer réseau » que les requêtes DHCP sont envoyées avec la bonne priorité.
Le but du jeu étant de voir partir nos requêtes DHCP avec le champ « PCP » (CoS) à 6.
Aussi pour votre information, j’ai réalisé toutes mes tests (et les captures d’écran ci-dessous) sur le VLAN 838 (celui de la VoD) dans lequel on s’identifie également en DHCP car je ne pouvais pas tester directement sur 832 afin d’éviter la pagaille sur mon réseau (pas mal de connexions actives vers Internet, je ne voulais pas tout chambouler lors de mes tests alors que des coupures du réseau VOD ne dérangera personne
).
Quoi qu’il en soit, le principe est le même, que l’on soit sur le VLAN 832 ou 838, l’idée étant de rajouter la CoS dans la trame Ethernet pour les requêtes DHCP.
Ne soyez donc pas surpris de voir le VLAN 838 dans les captures. Et aussi pour éviter la confusion, ce VLAN n’a absolument pas besoin d’une « CoS » particulière, je l’ai utilisé à des fins de test uniquement.
Sniffer le trafic réseauBeaucoup d’entre vous ont l’habitude de ces opérations mais pour mettre tout le monde d’accord, notamment sur les possibilités propres à Mikrotik/RouterOS, voici quelques mots à ce sujet ….
Sniffer et streamer le trafic réseau depuis RouterOSDans mon post sur la partie TV, je vous parlais de « Torch » un outil intégré à RouterOS ultra-light permettant d’afficher le trafic réseau de façon macro (adresses dst/src, port, protocole, n° du vlan, …) avec la possibilité de mettre quelques filtres.
Pratique mais assez limité car on n’a pas possible d’analyser le contenu des paquets !
Un autre outil intégré à RouterOS que j’aime beaucoup est « Packet Sniffer. Il est plus complet avec la possibilité de visualiser les hosts, les connections, les paquets, etc... Mais ce qui est génial c’est le « Streaming » TZSP (TaZmen Sniffer Protocol).
En clair, le trafic capturé sur RouterOS peut être « streamé » sur une machine de votre choix :
/tool sniffer set streaming-enabled=yes streaming-server=<mon_ip>
/tool sniffer startSur votre machine, vous démarrez une capture Wireshark en filtrant tout ce qui arrive sur le port UDP 37008.
Vous obtiendrez alors les trames Ethernet du routeur à votre machine of course, et dans les paquets IP vous trouverez des enveloppes TZSP qui elles, contiennent le trafic de couche 2 capturé par le routeur (trames Ethernet, paquets IP, etc..).
Bon attention, dans les lignes ci-dessus il n’y a aucun filtre, donc vous allez capturer et streamer sur votre machine tout le trafic de votre routeur ! Il sera préférable de mettre en place des filtres pour le capturer et donc streamer que les trames qui vous intéresse (déjà définir la ou les interfaces à capturées, le protocole, port(s), etc…).
Par exemple ici on capture le trafic du VLAN838 attaché à l’ONT (vlan838-vod) pour les paquets UDP sur les ports 67 et 68 (DHCP) et on stream ce trafic vers « 10.2.4.114 » (mon IP) :
Sur mon PC j’ai lancé la capture Wireshark sur le port UDP 37008 et je vois bien apparaitre les requêtes DHCP sur le VLAN 838 de mon routeur (en rose, la trame Ethernet entre mon routeur et ma machine contenant l’enveloppe TZSP qui renferme la trame Ethernet de la requête DHCP capturée sur le VLAN 838 du routeur).
La trame ci-dessus est reçue quand je sniffe l’interface du VLAN directement or ce qui nous intéresse c’est de contrôler la « CoS » c’est-à-dire la priorité de la trame, information contenue dans les headers VLAN 802.1Q.
Autrement dit pour analyser l’entête 802.1Q liée au VLAN pour pouvoir connaitre la priorité associée et donc la CoS, il faut sniffer le trafic au niveau de l’interface Ethernet (« ether2-WAN » dans mon cas).
Seulement si je change les filtres sur « Packet Sniffer » en prenant tout le trafic sur « ether2 » (comme on le voit dans la capture ci-dessus), impossible de lire correctement les entêtes des trames Ethernet dans Wireshark :
De ce fait, impossible de lire l’entête 802.1Q et donc de connaitre la priorité (CoS) de la trame.
Je n’ai pas plus creusé que cela ! En résumé on arrive bien à récupérer via streaming TZSP les trames Ethernet classique (803.2) mais jamais celle au format VLAN (802.1Q).
Ainsi cette feature est parfaite pour une analyse rapide sans avoir besoin de se brancher en filaire (pratique sur un laptop en Wifi), mais sera réservée sur de petit volume de trafic car le streaming crée des pertes et de la latence, et pour des analyses au-dessus de la couche 2 (couche IP ou protocoles TCP/UDP). Autrement j’utilise le bon vieux « port mirroring » !
Sniffer le trafic réseau depuis un switch avec le « port mirroring »En principe tous les switches manageable proposent cette fonctionnalité même sur l’entrée de gamme comme par exemple sur mon petit switch du salon, un SG108E (Easy Smart) de chez TP-Link (environ 30 euros).
Le principe est simple on indique au switch quels sont les ports pour lesquels on souhaite dupliquer le trafic reçu et/ou émis et quel est le port du switch sur lequel on va envoyer cette copie de trafic.
Dans mon cas, j’ai connecté mon laptop au réseau filaire avec une carte réseau USB, (Realtek USB Giga ethernet) et j’active le mirroring du trafic entrant et sortant du port « g1 » (celui où est connecté l’ONT Orange) sur le port où j’ai connecté mon laptop (ici en « g13 »).
Encore une fois nous ce que l’on veut, ce sont les informations propres aux VLANs ce qui est pas toujours possible en fonction de la carte réseau utilisée. Par chance, pas de soucis avec les Realteks d’après différentes sources d’information.
Il faudra cependant « Désactiver » la propriété « Propriété & VLAN dans les options avancées de la carte réseau USB (car le driver Windows supprime les entête 802.1Q).
Maintenant nous pouvons lancer une capture avec Wireshark sur la carte réseau USB branchée sur le switch en « g13 » sur lequel nous avons une copie du trafic vers/de l’ONT Orange branché en « g1 ».
Vu mais pas pris : les règles « Mangle » sur le client DHCPQuand j’ai écrit mon post où j’indiquais la règle Mangle pour marquer la CoS des requêtes DHCP, je n’ai pu réellement la valider car je n’ai pas besoin de cela pour avoir une réponse d’Orange.
Ceci dit pour moi elle marchait car le compteur de la règle s’incrèmentait bien !
Je fus donc étonné de lire la remarque de Slothy et surtout la réponse kgersen :
oui l'info sur la QoS avec une règle n'est pas bonne et peut induire en erreur quelqu'un qui voudrait répliquer ta config sans trop s'y connaitre et aurait la malchance d’être dans une zone ou la QoS 6 est nécessaire: il risque d'investir et se retrouver bloquer...
Sous Linux (et donc RouterOS) , DHCP en IPv4 utilise des 'raw sockets' qui sortent directement du routeur sans passer par iptables et donc sans passer par la règle indiquée.
C'est ce qui m’a donné envie de pousser l’analyser pour réellement comprendre car même si il est vrai que RouterOS est basé sur le noyau Linux, on n’a pas vraiment d’information sur ce qui a était réutilisé, réécrit ou modifié par Mikrotik. On ne sait pas vraiment si le code du client dhcp se base sur celui de linux ou même si le firewall se base sur iptable. On sait juste que ça tourne sur une base Linux après pour le reste, pas d’idée et ça ne m’étonnerai pas qu’ils aient réécrit tout à un tas de chose à leur sauce. Bon je sais que certain, pour ces raisons, prôneront l’open-source, mais là n’est pas le débat
Pour en revenir aux faits, si on utilise cette fameuse règle comme indiqué dans mon post :
add action=set-priority chain=output comment="CoS 6 for DHCP packets" \
dst-port=67 src-port=68 new-priority=6 out-interface=vlan832-internet \
passthrough=no protocol=udp On peut constater qu'elle est bien exécutée sur chaque requête DHCP. J’ai ajouté l’option « Log » à cette règle et comme le montre la capture ci-dessous, on voit bien le compteur de la règle s’incrèmenter à chaque requête DHCP accompagné de logs :
Donc contrairement à l’explication généralement admise que l’on retrouve sur les forums et autres sites consistant à dire que n’ayant pas d’IP, le client DHCP ne peut invoquer la stack réseau du kernel, l’obligeant à ré-implèmenter le protocole UDP pour èmettre des requêtes DHCP avec utilisant ce que l’on appelle des « raw sockets » qui bypass complétement le firewall et autre règle mangle, n’est pas tout à fait vrai dans le cas du Mikrotik car force de constater que les règles sont bien invoquées.
Ceci dit dans l’analyseur réseau :
Cette règle est sensée changer la CoS (set-priority) de la trame or le champ reste à « 0 ». Elle n’a pas l’air de fonctionner bien qu’elle soit correctement exécutée à en croire le compteur et les logs produits.
J’ai fait plusieurs tests, c’est assez étrange mais en résumé tout ce qui ne modifie pas le paquet marche parfaitement, le compteur s’incrèmente, on peut loger, on peut « jumper » vers d’autres règles qui elles même s’incrèmentent, etc…
On peut même créer un règle « firewall » (et non Mangle) pour « dropper » le paquet par exemple. Le firewall fonctionne également très bien sur les paquets émis par le client DHCP. Dans ce cas aucune trace sur l’analyseur réseau et bien évidement pas de réponse d’Orange, le client DHCP restant en « Searching … » car notre firewall aura bloqué la trame en question.
Par contre, si je teste des actions qui modifient la requête, tel le « set priority », le « change TTL » ou encore le « Change DSCP » rien à faire, la trame reste tel qu’elle bien que le compteur s’incrèmente.
Donc en résumé les règles firewall/mangle fonctionnent bien même pour les requêtes DHCP produit par le client DHCP du routeur mais impossible de modifier les trames (priorité, DSCP ou TTL). En gros, ça marche en « read only » seulement : « Vu mais pas pris »
Modifier les trames avec un bridgeCeci dit il y a une deuxième technique, qui elle fonctionne : utiliser un bridge !
Pour cela commencez par créer un bridge qu’on peut par exemple nommer « br-wan » :
/interface bridge
add name=br-wanDans ce bridge ajoutons l’interface du VLAN 832 sur lequel nous voulons modifier la CoS des trames DHCP :
/interface bridge port
add bridge=br-wan interface=vlan832-internetVous allez ensuite modifier votre client DHCP pour ne plus être directement lié à l’interface du VLAN832 mais au bridge qui lui-même est connecté sur ce VLAN :
/ip dhcp-client
add dhcp-options=authsend,clientid,hostname,userclass \
disabled=no interface=br-wanEnfin, le plus important, ajouter une règle de filtrage du bridge pour changer la priorité à « 6 » sur ce qui sort sur le VLAN832 à destination du port UDP 67 (requêtes DHCP) en ajoutant du log :
/interface bridge filter
add action=set-priority chain=output dst-port=67 ip-protocol=udp log=yes \
log-prefix="Set CoS6 on DHCP request" mac-protocol=ip new-priority=6 \
out-interface=vlan838-vod passthrough=yes
Comme pour la règle « Mangle », ce filtre est bien exécuté à chaque requête DHCP émise par le client DHCP du Mikrotik : le compteur s’incrèmente et des logs sont produits !
Sur l’analyse du trafic vers l’ONT on peut cette fois-ci constater que la priorité de nos trames est modifiée :
J’ai fait quelques tests en testant différentes priorités, chaque requête DHCP que l’on èmet part bien avec la priorité que vous lui aurez spécifiée dans votre filtre.
Ainsi vous pourrez bien utiliser votre Mikrotik/RouterOS sans bidouille ni switch supplèmentaire pour modifier la CoS de votre requête DHCP si cela est nécessaire. Du moins c’est ce que prouve l’expérience ci-dessus, à voir avec ceux qui sont dans une zone où ce marquage CoS est obligatoire pour valider cette procédure.
Ps : tests réalisés sous RouterOS 6.38, la dernière version « stable » à ce jour
Remplacer la LiveBox par un routeur