Cette aventure fait partie de la première étape du plan de montée en débit de mon réseau domestique. Elle consiste à remplacer le vénérable commutateur qui est derrière ma TV par un modèle disposant de ports gigabits et 10 gigabits. C’est aussi l’occasion de procéder à la découverte de routerOS avec le switch Mikrotik CRS326-24G-2S+RM que j’ai choisi pour remplacer mon cisco catalyst 2950.
J’avais déjà lu pas mal d’excellentes réactions sur ce fameux routerOS, et c’est une des raisons pour lesquelles j’ai choisi de partir sur ce modèle de commutateur.
Mais le mieux pour se faire un avis est quand même de tâter la bête soit-même.
Avant d’acheter ce switch, j’avais un peu étudié la question, en particulier sur les fonctionnalités proposées par le switch. Outre le prix, qui m’a fait m’intéresser à Mikrotik, c’est les fonctions offertes par routerOS qui m’ont convaincu de choisir un modèle tournant sur ce système, plutôt que swOS qui est un autre système Mikrotik, plus simple car totalement orienté commutation.
Je suis totalement novice en la matière, et ce qui va suivre est issu de mes manipulations de débutant pour configurer le commutateur comme j’en ai besoin pour l’intégrer dans mon environnement particulier.
Ce qu’il faut noter également, c’est que je ne vais utiliser qu’une toute petite partie des fonctionnalités de routerOS, qui comme son nom l’indique sait faire entre multiples autres choses, du routage. Ici, je vais me concentrer à 100% sur la commutation, car c’est le rôle que je vais donner à ce…commutateur.
Connexion console
Il y a plusieurs façons d’administrer le commutateur, dont un client graphique qui s’appelle WinBox. Mais bon, on n’est pas non plus chez les Tuche, et on va utiliser un vrai outil d’administrateur pour découvrir et configurer le bouzin : les lignes de commande.
Je plaisante bien sûr (pour les Tuche que j’aime beaucoup). Mais c’est quand même l’occasion de mieux cerner le fonctionnement du système, et en plus la documentation est vraiment abondante sur internet, ça serait dommage de passer à côté de tout ça. Et en plus, ça passe mieux que des copies écran dans un article de blog 🙂
Pour commencer avec ce commutateur qui sort du carton, il y a deux solutions : soit on trouve l’adresse IP par défaut du machin, on se met dans le même réseau, et banzaï avec ssh; soit on a sous la main un câble console qui va bien et on se branche sur le port adéquat. Ce qui est mon cas. Donc go, dans un shell sur mon poste de travail :
minicom -b 115200 -D /dev/ttyUSB0
J’utilise l’émulateur de terminal minicom, mais on aurait pu utiliser putty par exemple. Le port est réglé en usine à 115200 bits/sec et mon câble console est identifié sous le périphérique /dev/ttyUSB0.
Le compte utilisateur est admin, et il n’y a pas de mot de passe définit en usine.
Définir un mot de passe admin
Le premier réflexe, faut pas déconner.
[admin@mikrotik] > /password old-password: new-password: ************** confirm-new-password: **************
Définir le nom d’hôte
Comme c’est mon commutateur qui accueille les deux boîtiers freebox, je lui donne un nom genre « opérateur ».
/system identity set name sw-operateur
Régler l’heure
C’est mieux d’avoir un truc à l’heure, plutôt qu’il se croit en 1970. Je vais donc le brancher à mon serveur NTP interne:
/system ntp client set primary-ntp W.X.Y.Z /system ntp client set enabled=yes /system clock set time-zone-name=Europe/Paris
Où W.X.Y.Z est l’adresse IP de mon serveur NTP. J’aurais pu configurer avec le nom DNS du serveur NTP, si j’avais configuré le client DNS avant.
Configurer le client DNS
Pour que le commutateur puisse résoudre les noms, je vais le brancher à mon serveur DNS interne:
/ip dns set servers=W.X.Y.Z
Où W.X.Y.Z est l’adresse IP dans mon serveur DNS. C’est la même machine qui fait serveur NTP et serveur DNS dans mon infra.
Le vif du sujet: configuration de la commutation
Les switchs de la gamme CRS3xx (je n’ai pas regardé pour les autres) sont équipés d’un processeur entièrement dédié à la commutation, en plus de la CPU centrale qui elle, se charge du reste. Ce processeur dédié à la commutation est relié aux interfaces ethernet du commutateur par des liens dimensionnés pour assumer la bande passante nominale de toutes les interfaces en même temps.
Tout ceci implique que toutes les opérations de niveau 2 seront traitées matériellement, garantissant les performances permises par les interfaces. Si on configure tout correctement bien entendu.
Création du bridge
Le bridge est l’entité logique qui regroupe les interfaces ethernet du commutateur dans un seul domaine de niveau 2 (ou plusieurs, si on fait des vlans). Le commutateur peut gérer plusieurs bridges (et ainsi plusieurs groupes de ports indépendants les uns des autres) mais un seul peut être pris en charge matériellement comme évoqué précédemment. La commutation de tous les autres bridges sera assurée par la CPU centrale, de manière logicielle ce qui fera inmanquablement chuter les performances.
Aussi, l’intérêt de configurer plus d’un bridge semble limité, et dans mon cas, carrément inutile et contre productif. On va donc créer l’unique bridge, ou bien vérifier qu’il n’en existe pas déjà un par défaut et le cas échéant éviter d’en ajouter un deuxième.
[admin@sw-operateur] > /interface bridge add name=bridge failure: already have interface with such name
Arf il dit qu’il en existe déjà un avec le nom « bridge ». Coup de bol que je n’ai pas été inspiré pour le nom du bridge et que j’ai mis le même nom que dans l’exemple de la documentation, sinon je créais un deuxième bridge sans le savoir. Enfin j’aurais sans doute fini par le voir.
On va donc utiliser ce bridge pré-configuré pour la suite, et pour commencer on va lui coller un petit commentaire pour bien le reconnaître.
/interface bridge set 0 comment="bridge sw operateur"
Où « 0 » est l’index du bridge dans le retour de la commande suivante:
/interface bridge print
Ensuite il convient d’enrôler toutes les interfaces ethernet du switch dans le bridge. Comme il existait déjà un bridge par défaut, je me suis dit que certainement tous les ports seraient enrôlés dedans par défaut; vérifions :
[admin@sw-operateur] > /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON 0 H ;;; defconf ether1 bridge yes 10 0x80 10 10 none 1 I H ;;; defconf ether2 bridge yes 1 0x80 10 10 none 2 I H ;;; defconf ether3 bridge yes 1 0x80 10 10 none 3 I H ;;; defconf ether4 bridge yes 1 0x80 10 10 none 4 I H ;;; defconf ether5 bridge yes 1 0x80 10 10 none 5 I H ;;; defconf ether6 bridge yes 1 0x80 10 10 none 6 I H ;;; defconf ether7 bridge yes 1 0x80 10 10 none 7 H ;;; defconf ether8 bridge yes 1 0x80 10 10 none 8 I H ;;; defconf ether9 bridge yes 1 0x80 10 10 none 9 I H ;;; defconf ether10 bridge yes 1 0x80 10 10 none 10 I H ;;; defconf ether11 bridge yes 1 0x80 10 10 none 11 I H ;;; defconf ether12 bridge yes 1 0x80 10 10 none 12 I H ;;; defconf ether13 bridge yes 1 0x80 10 10 none 13 I H ;;; defconf ether14 bridge yes 1 0x80 10 10 none [...]
Effectivement, par défaut, tout le monde est dedans. En un sens ça a du sens, car je pense que l’idée est de fournir un commutateur opérationnel dès la sortie du carton pour les clients qui n’auraient pas envie de s’intéresser à la configuration.
Préparation de l’interface « uplink » avec mon cœur de réseau
J’ai une habitude de vieux gars, et à mon âge il est trop tard pour en changer, c’est que j’aime bien configurer un agrégat 802.3ad pour les interfaces d’interconnexion entre mes switchs. Et ce, même si l’interconnexion ne met en jeu qu’une seule interface ethernet.
De toute façon je n’ai pas le choix, mon switch de cœur de réseau s’attend à discuter avec une interface agrégée LACP.
Je vais donc créer une interface 802.3ad de ce pas, juste après avoir retiré du bridge l’interface qui sera esclave de cet agrégat (car c’est l’agrégat lui-même qui sera intégré au bridge):
/interface bridge port remove 25
Où 25 est l’index de l’interface que je veux intégrer à mon agrégat. En fait c’est le deuxième port SFP+, dans lequel j’ai inséré un module SFP+/RJ45 à 10 gbps. L’idée, c’est que quand j’aurais également mis à jour mon cœur de réseau, ce lien d’agrégat aura une bande passante de 10 gbps. Pour l’instant elle sera négociée à 1 gbps, ce qui représente quand même 10 fois mieux qu’avec mon vieux cisco catalyst 2950 ^^.
Ensuite, je procède à la création à proprement parler de l’agrégat LACP:
/interface bonding add comment="uplink sw-coeur" mode=802.3ad slaves=sfp-sfpplus2 name=uplink-coeur
Et enfin, j’enrôle cette nouvelle interface dans le bridge:
/interface bridge port add bridge=bridge interface=uplink-coeur
Pour finir, je lui mets un petit commentaire pour bien la reconnaître:
/interface bridge port set 25 comment="uplink coeur de reseau"
Où « 25 » est le numéro d’index de l’agrégat dans la sortie de la commande suivante:
/interface bridge port print
Configuration de mes vlans
Il n’y en a pas cinquante(huit), mais il y en a quelques uns quand même. Ils devront bien entendu être transportés depuis mon cœur de réseau jusqu’à mon commutateur opérateur par le lien d’uplink.
Mais avant toute autre chose, on va commencer par configurer le vlan de management du switch; comme ça on va pouvoir ranger le câble console et attaquer la suite de la configuration en utilisant ssh.
Tout d’abord, on active la fonction qui rend le bridge attentif aux vlans car si on ne le fait pas, il ignorera les trames avec une en-tête 802.1q.
/interface bridge set 0 vlan-filtering=yes
Où « 0 » est l’index de notre bridge dans la sortie de la commande suivante:
/interface bridge print
Ensuite on créé l’interface vlan dont on a besoin :
/interface vlan add interface=bridge name=admin vlan-id=XX
Où XX est le numéro de mon vlan d’admin.
Puis on configure ce vlan dans notre bridge:
/interface bridge vlan add bridge=bridge tagged=bridge,uplink-coeur vlan-ids=XX
Notez qu’on demande au bridge de taguer ce vlan sur l’interface d’uplink, ça c’est classique; mais on lui demande aussi de taguer ce vlan pour l’interface bridge. C’est ce qui est indiqué dans la documentation comme configuration à faire pour le vlan de management.
Enfin, on configure une adresse IP pour cette interface vlan:
/ip address add address=xxx.xxxx.xxx.xxx/24 interface=admin
Et tant qu’on y est, on configure la passerelle par défaut du commutateur (je vais en avoir besoin, car mon PC n’est pas dans le même réseau IP que le switch):
/ip route add dst-address=0.0.0.0/0 gateway=xxx.xxx.xxx.1
A partir de là, je peux me connecter en ssh au commutateur, parce que le serveur ssh semble pré-configuré en usine. Je range donc mon câble console dans son tiroir.
A présent, je vais créer toutes les autres interfaces vlan, et taguer tout ça dans mon lien d’uplink :
/interface vlan add interface=bridge name=client vlan-id=AA /interface vlan add interface=bridge name=peripherique vlan-id=BB /interface vlan add interface=bridge name=lab vlan-id=CC /interface vlan add interface=bridge name=fbx-server-player vlan-id=100 /interface vlan add interface=bridge name=fbx-server-wan vlan-id=DD /interface bridge vlan add bridge=bridge tagged=uplink-coeur vlan-ids=AA,BB,CC,DD
Où AA, BB, CC, DD sont les numéros de mes différents vlans. Le vlan 100 est le vlan sur lequel free fait communiquer les deux boitiers freebox. J’en ai besoin aussi, mais je n’ai pas besoin de le remonter jusqu’à mon cœur de réseau, aussi je ne le tague pas sur le lien d’uplink.
La dernière interface vlan qu’il me reste à créer est mon vlan « poubelle » : c’est celui dans lequel je place toutes les trames non taguées:
/interface vlan add interface=bridge name=trash vlan-id=ZZ
Ça sera donc ce à ce vlan ZZ qu’appartiendront toutes les trames non taguées sur le lien d’uplink:
/interface bridge vlan add bridge=bridge untagged=uplink-coeur vlan-ids=ZZ
Enfin, il faut positionner le PVID de l’agrégat aussi à ZZ pour traiter dans le vlan ZZ les trames entrantes non taguées:
/interface bridge port set 25 pvid=ZZ
A partir de là, l’ensemble de mes vlans sont transportés du cœur de réseau vers le commutateur opérateur. Il ne me reste plus qu’à configurer les ports trunk pour les deux boitiers freebox et la borne wifi:
/interface bridge vlan set [ find vlan-ids=XX ] bridge=bridge tagged=bridge,uplink-coeur,ether19 untagged=ether1 vlan-ids=XX /interface bridge vlan add bridge=bridge tagged=uplink-coeur,ether19 untagged=ether1 vlan-ids=AA /interface bridge vlan add bridge=bridge tagged=uplink-coeur untagged=ether17 vlan-ids=BB /interface bridge vlan add bridge=bridge tagged=uplink-coeur vlan-ids=CC /interface bridge vlan add bridge=bridge tagged=ether17,ether18 vlan-ids=100 /interface bridge vlan add bridge=bridge tagged=uplink-coeur untagged=ether18 vlan-ids=DD /interface bridge vlan add bridge=bridge untagged=uplink-coeur,ether19 vlan-ids=ZZ /interface bridge port set 16 pvid=BB /interface bridge port set 17 pvid=CC /interface bridge port set 18 pvid=ZZ
J’ai vu dans des exemples dans la documentation, qu’on peut de manière très pratique remplacer l’index de l’objet qu’on veut éditer (exemple set 0, où 0 est l’index de l’objet tel qu’il apparaît avec la directive print) par une macro dont le résultat fait correspondre un attribut de l’objet qu’on veut éditer. Par exemple, ci-dessus, on a édité les propriétés du vlan XX du bridge en le désignant par la macro [ find vlan-ids=XX ].
Enfin, il faudrait configurer des ports d’accès pour les périphériques tels que la TV, mais on va en reparler juste après.
Affectation dynamique de vlan
Oui, car j’aime bien affecter dynamiquement les vlans de mes ports d’accès. Pas besoin de configurer les ports à chaque fois qu’un bidule change de place dans la maison; ok, je reconnais que c’est rare, et que de toute façon il faut bien qu’à chaque fois que j’ai un nouveau machin, le déclarer dans ma base de mac-address. Et puis il y a le wifi :s
Mais bon, pour le jeu, c’est sympa. Et routerOS sait le faire, donc go.
Un exemple avec les ports 2 à 8 configurés pour le vlan dynamique :
/radius add address=ip.du.serveur.radius service=dot1x secret=secret-partagé-hyper-confidentiel timeout=3s comment="mon serveur radius"
La raison du timeout positionné à 3 secondes est très bien expliquée sur cette page du forum mikrotik, je n’arrivais pas à bien faire fonctionner le vlan de repli (mon vlan poubelle) quand le périphérique était inconnu.
Puis on configure les ports :
/interface dot1x server add interface=ether2 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether3 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether4 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether5 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether6 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether7 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ /interface dot1x server add interface=ether8 auth-types=mac-auth mac-auth-mode=mac-as-username-and-password radius-mac-format=xxxxxxxxxxxx reject-vlan-id=ZZ
Où ZZ est le numéro de mon vlan « voie de garage ». Les paramètres mac-auth-mode et radius-mac-format sont ajustés pour aller avec la configuration de mon serveur radius (qui est adaptée pour fonctionner aussi avec mon commutateur de coeur de réseau).
Vérification du spanning-tree
Il est activé par défaut sur ce commutateur (RTSP). Comme il est également activé sur mon switch de cœur de réseau et que sa priorité de bridge est à 16384, je vais juste m’assurer que le cœur de réseau est bien le root bridge.
/interface bridge monitor bridge ;;; bridge sw operateur state: enabled current-mac-address: AA:BB:CC:DD:EE:FF root-bridge: no root-bridge-id: 0x4000.AB:CD:EF:FE:DC:BA root-path-cost: 10 root-port: uplink-coeur port-count: 26 designated-port-count: 4 fast-forward: no multicast-router: no igmp-querier: uplink-coeur xxx.xxx.xxx.xxx
On voit que le commutateur CRS326 n’est pas le root-bridge, et qu’il est connecté au root-bridge (qui est mon switch de cœur de réseau) par l’interface uplink-coeur.
Import de ma clé publique SSH pour une authentification sans mot de passe
On procède comme avec n’importe quel hôte SSH; copie de la clé publique de mon utilisateur sur le commutateur. Dans un shell sur mon poste de travail:
scp .ssh/id_rsa.pub admin@ip.du.commu.tateur:
Puis import de la clé, depuis un shell sur le switch:
user ssh-keys import id_rsa.pub
Plus besoin de mot de passe pour me connecter au switch en SSH depuis mon PC.
Activer le DHCP snooping
Mon serveur DHCP est une machine virtuelle qui tourne dans mon hyperviseur qui est connecté à mon commutateur de cœur de réseau. Les réponses aux requêtes DHCP faites par les clients branchés à mon commutateur opérateur redescendrons donc par le lien d’uplink: celui-ci doit donc être trusted.
/interface bridge port set [ find interface=uplink-coeur ] trusted=yes
Ensuite il reste à activer le DHCP snooping sur le bridge:
/interface bridge set 0 dhcp-snooping=yes
Où « 0 » est le bridge.
Activer l’IGMP snooping
Juste pour limiter le flood de flux mutlicast sur toutes les interfaces du switch. Il y a un peu de flux multicast dans mon réseau, pour l’accès des clients à mon serveur DLNA (autant dire que c’est critique !).
/interface bridge set 0 igmp-snooping=yes
Où « 0 » est le bridge.
Supervision avec SNMP
Pour que mon serveur zabbix puisse tracer des jolis graphiques de trafic réseau.
/snmp set contact="julien" /snmp set location="derriere la tele" /snmp set engine-id=AABBCCDDEEFF # mac address du bridge /snmp set trap-community=utilisateur-zabbix /snmp set trap-version=3 /snmp community set 0 name=utilisateur-zabbix authentication-protocol=SHA1 authentication-password=mot-de-passe-auth encryption-protocol=AES encryption-password=mot-de-passe-chiffrement /snmp set enabled=yes
Il ne reste alors qu’à brancher le zabbix là-dessus, mais c’est hors cadre de ce billet.
Sauvegarde de la configuration
On peut exporter un fichier de script qui déroule toute la configuration du commutateur:
/export file 2021-12-13_backup_sw-operateur
Ce fichier est ensuite récupérable de diverses manières. Ici je vais utiliser scp pour aller le chercher, depuis un shell sur mon poste de travail:
scp admin@sw-operateur:/2021-12-13_backup_sw-operateur .
On peut éventuellement ensuite supprimer le fichier du switch, depuis un shell sur le switch:
/file remove 1
Où « 1 » est l’index du fichier dans la sortie de la commande
/file print
Mise à jour de routerOS
Au moment où je tape ces lignes, la version 6.49.2 de routerOS est disponible pour mon switch, qui est arrivé sorti du carton en version 6.47.9
/system package print Flags: X - disabled # NAME VERSION SCHEDULED 0 routeros-arm 6.47.9 1 system 6.47.9 2 X ipv6 6.47.9 3 wireless 6.47.9 4 hotspot 6.47.9 5 mpls 6.47.9 6 routing 6.47.9 7 ppp 6.47.9 8 dhcp 6.47.9 9 security 6.47.9 10 advanced-tools 6.47.9
A noter que la toute première version stable de routerOS 7 vient également de sortir (la 7.1), mais je suis trop nouveau dans le domaine Mikrotik pour bien réaliser l’évènement 🙂
Quoi qu’il en soit, je vais déjà monter en 6.49.2, pour le reste, on verra plus tard.
Le système est capable d’aller chercher comme un grand ses mises à jour, mais je n’aime pas trop le concept d’avoir un commutateur qui a accès à internet. On va donc le faire à la main. C’est quand même assez facile, car la mise à jour ne consiste qu’à télécharger le package de mise à jour, le déposer dans le stockage interne du commutateur, et le redémarrer. Il s’occupe du reste.
Depuis mon poste de travail:
scp routeros-arm-6.49.2.npk admin@sw-operateur:/
Puis dans le shell SSH du switch:
/system reboot
Après le redémarrage on peut constater que le commutateur s’est bien mis à jour:
/system resource print uptime: 0d0h2m38s version: 6.49.2 (stable) build-time: Dec/03/2021 14:53:53 factory-software: 6.44.6 free-memory: 483.6MiB total-memory: 512.0MiB cpu: ARMv7 cpu-count: 1 cpu-frequency: 800MHz cpu-load: 0% free-hdd-space: 2184.0KiB total-hdd-space: 16.0MiB write-sect-since-reboot: 20035 write-sect-total: 34533 bad-blocks: 0% architecture-name: arm board-name: CRS326-24G-2S+ platform: MikroTik
Ou en passant par la liste des packages:
/system package print Flags: X - disabled # NAME VERSION SCHEDULED 0 routeros-arm 6.49.2 1 system 6.49.2 2 X ipv6 6.49.2 3 wireless 6.49.2 4 hotspot 6.49.2 5 mpls 6.49.2 6 routing 6.49.2 7 ppp 6.49.2 8 dhcp 6.49.2 9 security 6.49.2 10 advanced-tools 6.49.2
Mes premières impressions
Je dois avouer que ces quelques premières heures en compagnie de routerOS m’ont été agréables. Le système est bluffant en nombre de fonctionnalités, même si je n’en utilise pas en dehors du domaine de la commutation. Dans ce domaine, où je viens de faire mes premières armes, après un petit moment de déstabilisation dû à mes habitudes sur des systèmes IOS-like, j’ai rapidement trouvé mes marques et l’outil de configuration est à mon sens logique et très efficace. On tape la commande qui va bien, et ça marche. Par ailleurs, l’avantage par rapport à un système hyper-propriétaire, est ici que la documentation est abondante sur internet.
Quant au switch lui-même, on verra à la longue si il dure bien dans le temps; en attendant, le bond de performance théorique déjà effectué sur la bande passante de mon backbone (passage de 100 mbps à 1 gbps) est en pratique bien là selon mes tests, et se ressent de manière évidente à l’usage.
o/