La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: pinomat le 26 septembre 2024 à 09:13:06
-
Bonjour,
Pour information, Mikrotik, depuis la version RouterOS 7.16, a changé la manière de traiter dont les priorités pcp/dscp. Lorsque les paquets arrivent sur une interface d'un switch/router (avec chip switch), les priorités sont réinitialisées. Il faut donc modifier le paramètre Trust L2 et Trust L3 (Ignore à Keep) afin que les paquets marqués avec un pcp/dscp <> 0 ne soient réinitialisées (pcp = 0 + dscp =0) [/b][/color]
/interface/ethernet/switch/qos/port/set trust-l2=keep trust-l3=keep INTERFACENAME
Donc si vous avez un switch Mikrotik devant votre routeur, que votre routeur altère en amont du switch la priorité pcp et/ou dscp de certains paquets (par ex. IGMP/ARP/IPv6), ils seront tous réinitialisés à 0 tant que vous ne modifiés pas le trust du port dans la configuration du switch Mikrotik.
PS : j'ai perdu ma connexion IPv4 et IPv6 hier car ma configuration IPv4/IPv6 n'était plus cohérente. Après analyse, il s'avère que mes paquets DHCP IPv6 n'étaient pas envoyés avec un pcp 6 alors que le routeur les marquaient correctement (en sortie du routeur OK, en sortie du switch NOK).
-
Merci pour l'info, même si je ne suis pas impacté puisque je fais tout le marquage de CoS sur un switch CRS305 dédié connecté à l'ONT (ainsi que le marquage DSCP, possible depuis RouterOS 7.15 dans les switch rules).
Concernant la 7.16, j'étais plus inquiet des changements de la gestion des temps de renouvellement des baux IPv6 de leur client DHCP6-PD (Le changelog n'est pas très clair sur ce sujet).
-
Merci pour la confirmation, j'ai fait une conf ici pour ceux qui seraient intéressés : https://lafibre.info/remplacer-livebox/tuto-switch-mikrotik-crs-305-pour-hgsmii-2-5gbps-et-la-cos-6/msg1076556/#msg1076556 (https://lafibre.info/remplacer-livebox/tuto-switch-mikrotik-crs-305-pour-hgsmii-2-5gbps-et-la-cos-6/msg1076556/#msg1076556)
-
Conf qui fonctionne parfaitement chez moi depuis 1 mois, merci fftmeh !
-
Salut à tous,
Est-ce que ce nouveau pré-requis à un impact si on change la prio sur le switch / routeur lui-même ? Y a-t-il un effet pervers à l'appliquer en permanence, y compris si la prio est modifiée en local ?
Je m'explique, mon ONT est dans un CRS310 en front de mon router. Je change la prio sur ce CRS310. Puis-je activer ce paramètre tout de même ? Et est-ce que le CRS310 continuera à changer la prio ?
Des fois que j'ai l'idée de changer mon installation et de changer la prio sur le router après le CRS310...
Merci.
-
Est-ce que ce nouveau pré-requis à un impact si on change la prio sur le switch / routeur lui-même ? Y a-t-il un effet pervers à l'appliquer en permanence, y compris si la prio est modifiée en local ?
Y a-t-il un effet pervers à l'appliquer en permanence, y compris si la prio est modifiée en local ? Pas vraiment, tout dépend de ce que tu fais en terme de QoS.
Est-ce que ce nouveau pré-requis à un impact si on change la prio sur le switch / routeur lui-même ? Si ton switch gère toutes les priorités (dhcp IPv4 et IPv6 par ex) et que ton GPON est directement connecté à ce switch.), il n'y a aucun problème.
Pour essayer de schématiser très rapidement (voir PJ) :
Avec Trust L2+L3 Ignore sur CRS310 : Quand les paquets arrivent sur une interface du switch les pcp (L2) et le dscp (L3) sont réinitialisés à 0.
Avec Trust L2+L3 Keep sur CRS310 : Quand les paquets arrivent sur une interface du switch les pcp (L2) et le dscp (L3) ne sont pas altérés.
-
Merci pour l'info, même si je ne suis pas impacté puisque je fais tout le marquage de CoS sur un switch CRS305 dédié connecté à l'ONT (ainsi que le marquage DSCP, possible depuis RouterOS 7.15 dans les switch rules).
J'ai mis une grosse partie dans les firewall du CCR, j'ai l'espoir, qu'un jour, Mikrotik permettra de marquer des paquets DHCPv4 d'une manière ou d'une autre... J'ai des règles pour les dscp puis une règle globale pour modifier le pcp sur base des dscp (from dscp high 3 bits).
Concernant la 7.16, j'étais plus inquiet des changements de la gestion des temps de renouvellement des baux IPv6 de leur client DHCP6-PD (Le changelog n'est pas très clair sur ce sujet).
Je vais surveiller si j'ai des problèmes. Tu crains quelque chose en particulier, tu veux que je monitore les renouvellements ?
-
Y a-t-il un effet pervers à l'appliquer en permanence, y compris si la prio est modifiée en local ? Pas vraiment, tout dépend de ce que tu fais en terme de QoS.
Est-ce que ce nouveau pré-requis à un impact si on change la prio sur le switch / routeur lui-même ? Si ton switch gère toutes les priorités (dhcp IPv4 et IPv6 par ex) et que ton GPON est directement connecté à ce switch.), il n'y a aucun problème.
Pour essayer de schématiser très rapidement (voir PJ) :
Avec Trust L2+L3 Ignore sur CRS310 : Quand les paquets arrivent sur une interface du switch les pcp (L2) et le dscp (L3) sont réinitialisés à 0.
Avec Trust L2+L3 Keep sur CRS310 : Quand les paquets arrivent sur une interface du switch les pcp (L2) et le dscp (L3) ne sont pas altérés.
merci.
Donc je peux trust L2+L3 Keep sur le CRS310 dans tous les cas.
- Si la QOS est déjà gérée avant par le firewall (par exemple), le CRS310 conservera cette QOS puis l'écrasera par ces propres paramêtres (s'ils sont définis).
- Si les packets arrivent sans QOS, le CRS310 appliquera ces propres paramêtres.
C'est bien cela ?
-
Donc je peux trust L2+L3 Keep sur le CRS310 dans tous les cas.
- Si la QOS est déjà gérée avant par le firewall (par exemple), le CRS310 conservera cette QOS puis l'écrasera par ces propres paramêtres (s'ils sont définis).
- Si les packets arrivent sans QOS, le CRS310 appliquera ces propres paramêtres.
C'est bien cela ?
C'est exact (sous condition que les règles du CRS310 ne filtrent pas les paquets sur base du DSCP et/ou PCP).
-
C'est exact (sous condition que les règles du CRS310 ne filtrent pas les paquets sur base du DSCP et/ou PCP).
merci !
-
Je vais surveiller si j'ai des problèmes. Tu crains quelque chose en particulier, tu veux que je monitore les renouvellements ?
Le client DHCP ne respecte pas vraiment les durée de renouvellement retournées par le serveur d’Orange (sans que ça ne pose de problème en pratique), alors que c’est le cas pour DHCP6 au moins jusqu’à la version 7.15.x.
Je me demandais juste si ils n’avaient pas fait la même chose dans RouterOS 7.16 pour DHCP6 vu la ligne dans le changelog à propos du T0 et T1…
-
Je me demandais juste si ils n’avaient pas fait la même chose dans RouterOS 7.16 pour DHCP6 vu la ligne dans le changelog à propos du T0 et T1…
Je n’ai pas l’impression que le comportement du client DHCPv6 ait changé, je vois un RENEW toutes les 23.5 heures avec cette nouvelle version.
-
Je me demandais juste si ils n’avaient pas fait la même chose dans RouterOS 7.16 pour DHCP6 vu la ligne dans le changelog à propos du T0 et T1…
Depuis l'activation du debug dhcp (Sep/27/2024 14h00), j'ai eu 3 renew DHCPv6, 1 renew DHCPv4 :
Sep/28/2024 01:44:44 dhcp,debug,packet send OrangeNet -> ff02::1:2%25
Sep/29/2024 01:15:56 dhcp,debug,packet send OrangeNet -> ff02::1:2%25
Sep/29/2024 11:42:51 dhcp,debug,state dhcp-client on OrangeNet entering <renewing...> state
Sep/30/2024 00:47:09 dhcp,debug,packet send OrangeNet -> ff02::1:2%25
Si je comprends bien, il y a au moins un problème avec le bail DHCPv6 qui est de 604800s, impossible qu'il fasse 1 renew par jour... Pour le bail DHCPv4, il faut attendre qq jours.
-
Le comportement est tout à fait normal.
Bien que le bail DHCP Orange soit de 604800s (7 jours), le "dhcp-renewal-time" présent est de 84672s (soit un tout petit peu moins de 24h).
Que ce soit en IPv4 ou IPv6.
-
Ok, comportement toujours normal donc, au contraire du DHCP4 ou le dhcp-renewal-time est ignoré et le bail renouvelé à priori à mi bail (je n'ai pas vérifié moi même mais il y a plusieurs témoignages sur ce sujet dans le forum).
Ceci dit, vu le bug du /resolve je vais attendre la 7.16.1 ;)
-
C'est donc un bug Mikrotik (sur routeur linux, j'ai bien le renouvellement peu avant 24h en IPv4/IPv6).
-
Le comportement est tout à fait normal.
Bien que le bail DHCP Orange soit de 604800s (7 jours), le "dhcp-renewal-time" présent est de 84672s (soit un tout petit peu moins de 24h).
Que ce soit en IPv4 ou IPv6.
Top, merci pour l'info.
Ok, comportement toujours normal donc, au contraire du DHCP4 ou le dhcp-renewal-time est ignoré et le bail renouvelé à priori à mi bail (je n'ai pas vérifié moi même mais il y a plusieurs témoignages sur ce sujet dans le forum).
Ceci dit, vu le bug du /resolve je vais attendre la 7.16.1 ;)
Ca me dit quelque chose cette histoire de renew à la mi-bail, mais je ne sais plus où j'avais vu ça :/ Je vais ouvrir un ticket chez Mikoritk pour DHCP4 alors avec toutes les infos pour être sûr qu'il ne l'oublie pas.
-
Bonjour,
Pour le problème dhcp-client v4, ça va venir :
What's new in 7.17beta2 (2024-Sep-27 10:07):
!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
!) webfig - redesigned HTML, styling and functionality;
*) 6to4 - fixed issue ............
.........
*) dhcpv4-client - respect Renewal-Time (58) and Rebinding-Time (59) options;
...................
...................
*) dhcpv6-client/server - added support for DHCPv6 reconfigure messages;
*) dhcpv6-server - include all existing prefixes (with lifetime 0) in renew reply and new prefix if RADIUS returns different prefix;..................
-
Bonjour,
Chez ROS, le dhcp-script est bien appelé à chaque RENEW pour IPv6, mais ce ne pas le cas pour IPv4.
En attendant un fix et seulement pour la forme (car la connexion fonctionne très bien sans), j'ai fait un script pour renouveller le string d'authentification DHCPv4 après chaque RENEW.
:local iface "vlan832-wan"
:global vlan832dhcpv4exp
:local vlan832dhcpv4expnow
:if ([:len $vlan832dhcpv4exp] = 0) do={
:set $vlan832dhcpv4exp [:tonum [/ip/dhcp-client/get $iface value-name=expires-after ]]
}
:set $vlan832dhcpv4expnow [:tonum [/ip/dhcp-client/get $iface value-name=expires-after ]]
if ($vlan832dhcpv4exp < $vlan832dhcpv4expnow) do={ /system/script/run generateOrangeAuthV4 }
:set vlan832dhcpv4exp $vlan832dhcpv4expnow