J'ai en ce moment un CRS309 sous la main (qui de base est déjà un excellent switch 8x10G) et il y a en ce moment beaucoup d'avancées chez MTK concernant le L3HW (routage matériel).
Cela méritait bien un essai vs Orange.
La référence technique est ici :
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+OffloadingA bien lire et comprendre, notamment les deux circuits possibles pour l'offload :
- IPV4 / IPV6 : pur HW lorsque les routes sont éligibles, rien ne passe par le CPU/firewall (donc pas de NAT possible)
- IPV4 seulement : CPU first > firewall fast-track (+nat éventuellement) > HW-offload
Ce dernier mode, plus souple, n'existe pas sur tous les CRS (exit CRS305) et impose une limitation en capacité (nb de cnx trackées).
Ci-dessous la config tentée, par étapes.
(via MAC-telnet, par la prise ether1)
Il reste peut-être 1/2 erreurs triviales dans le copier/coller.
Tout d'abord, un unique bridge segmenté par VLANs, qui nous livre deux interfaces. Le tag/detag se fait au niveau du PVID + vlan filtering.
/interface bridge
add admin-mac=XXXXXX auto-mac=no name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus1 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus2 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus3 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus4 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus5 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus6 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus7 pvid=11
add bridge=bridge frame-types=admit-only-vlan-tagged interface=sfp-sfpplus8
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4,sfp-sfpplus5,sfp-sfpplus6,sfp-sfpplus7 vlan-ids=11
add bridge=bridge tagged=bridge,sfp-sfpplus8 vlan-ids=832
/interface vlan
add interface=bridge name=if-lan-11 vlan-id=11
add interface=bridge name=if-orange-832 vlan-id=832
Toujours sur le switch, on définit les bridge-rules pour la CoS=6.
En théorie du moins...
/interface ethernet switch rule
add dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=switch1-cpu protocol=udp src-port=68 switch=switch1 vlan-id=832
add dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=switch1-cpu protocol=udp src-port=546 switch=switch1 vlan-id=832
add mac-protocol=arp new-vlan-priority=6 ports=switch1-cpu switch=switch1 vlan-id=832
add dst-address6=fe00::/7 mac-protocol=ipv6 new-vlan-priority=6 ports=switch1-cpu protocol=icmpv6 switch=switch1 vlan-id=832
Configuration LAN typiquement standard.
/ip pool
add name=dhcp-lan-pool ranges=10.39.11.101-10.39.11.199
/ip dhcp-server
add add-arp=yes address-pool=dhcp-lan-pool interface=if-lan-11 lease-time=1d name=dhcp-lan
/ip address
add address=10.39.11.254/24 interface=if-lan-11 network=10.39.11.0
/ip dhcp-server network
add address=10.39.11.0/24 dns-server=8.8.8.8 gateway=10.39.11.254
Config du client DHCPv6, classique
/ipv6 dhcp-client option
add code=15 name=orange6-userclass value=0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7834
add code=16 name=orange6-class-identifier value=0x0000040e0005736167656d
add code=11 name=orange6-authsend value=XXXXXX
add code=17 name=orange6-vendor value=0x000005580006000e495056365f524551554553544544
add code=6 name=orange6-request value=0x000b0011
/ipv6 address
add address=::1 from-pool=pool_orange6 interface=if-lan-11
/ipv6 dhcp-client
add add-default-route=yes comment=dhcp-orange dhcp-options=orange6-authsend,orange6-userclass,orange6-class-identifier,orange6-request,orange6-vendor interface=if-orange-832 pool-name=pool_orange6 rapid-commit=no request=prefix use-interface-duid=yes use-peer-dns=no
Config du client DHCPv4,
- on refuse la route par défaut, mais par script on l'ajoute après coup avec le flag suppress-hw-offload
- pas de full HW en ipv4 donc
- on prépare en revanche le circuit CPU > Firewall > NAT > HW
/ip dhcp-client option
add code=77 name=orange4-userclass value="'+FSVDSL_livebox.Internet.softathome.Livebox4'"
add code=60 name=orange4-class-identifier value="'sagem'"
add code=90 name=orange4-authsend value=XXXXX
/ip dhcp-client
add add-default-route=no comment=dhcp-orange dhcp-options=orange4-authsend,orange4-userclass,orange4-class-identifier,clientid interface=if-orange-832 script=":local count [/ip route prin\
t count-only where comment=\"dhcp\"]\
\n:if (\$bound=1) do={\
\n\t:if (\$count = 0) do={\
\n\t\t/ip route add gateway=\$\"gateway-address\" comment=\"dhcp\" suppress-hw-offload=yes\
\n\t} else={\
\n\t\t/ip route set [find comment=\"dhcp\"] gateway=\$\"gateway-address\"\
\n\t}\
\n} else={\
\n\t/ip route remove [find comment=\"dhcp\"]\
\n}\
\n"
Ajout des règles firewall/fast-track/nat/hw-offload
dans le firewall V4
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
/ip firewall nat
add action=masquerade chain=srcnat out-interface=if-orange-832
Activation de L3HW
/interface ethernet switch
set 0 l3-hw-offloading=yes
/interface ethernet switch l3hw-settings
set ipv6-hw=yes
Reboot + essai de connexion Orange...Et ca ne fonctionne pas, on se fait refuser pour défaut de CoS=6.
Car en fait les règles switch rules port=switch1-cpu ne fonctionnent pas sur les CRS/CCR.
Le bug est référencé chez MTK, correction prévue, dans 1 semaine ou dans 2 ans.
Pour contourner, on devra donc utiliser un mix de bridge rules et de firewall :
- les bridge rules classiques (type Rb4011/5009) ne sont possibles car le bridge couvre du trafic VLANisé, c'est l'inverse du bridge habituel par dessus des interfaces VLAN
- les matchers ip-protocol src/dst-ports ne sont pas utilisables.
On doit donc trouver plus large mais pas trop.
- IPv4 broadcast(raw sockets) : la règle bridge filter va tagger en CoS=6 tout le trafic broadcast
- IPv4 unicast (renews) : règle firewall mangle
- IPv6 (SARR+renew) : plus simple, règle firewall mangle
/interface bridge filter
add action=set-priority chain=output comment=dhcp-orange dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=vlan new-priority=6 out-bridge=bridge passthrough=yes vlan-encap=ip vlan-id=832
/ip firewall mangle
add action=set-priority chain=output dst-port=67 new-priority=6 protocol=udp src-port=68
/ipv6 firewall mangle
add action=set-priority chain=output dst-port=547 new-priority=6 protocol=udp src-port=546
Nouvel essai de connexion...Les IPs sont obtenues !
Test de performance :
- en IPv6, ~110 Mo/s avec <1% de CPU (whao)
- en IPv4, ~20 Mo/s avec ~75% de CPU
Il se trouve que la règle bridge filter nécessaire à la CoS bloque le fast-track et donc l'offloading en aval.*
On va donc utiliser un "watchdog" script + schedule 5mn pour gérer ça,
- si pas de connectivité, on active la règle et on relance les clients DHCP
- si connectivité OK, on désactive la règle
- pour la suite, les renew passent sans problème
/system script
add name=watchdog-orange source="\
\n:local resetDHCP false ;\
\n\
\n:local ipv6adrIds [/ipv6 address find where global ]\
\n:local ipv6gatewayIds [/ipv6 route find where dst-address=\"::/0\" and routing-table=\"main\" ]\
\n\
\n:if ([:len \$ipv6adrIds] = 0 || [:len \$ipv6gatewayIds] = 0) do={\
\n\t:log warning \"[watchdog] No IPv6 adr or gateway\"\
\n\t:set resetDHCP true\
\n} else={\
\n\t:local ipv6localAdr [/ipv6 address get [:pick \$ipv6adrIds 0] address]\
\n\t:local ipv6gatewayAdr [/ipv6 route get [:pick \$ipv6gatewayIds 0] gateway]\
\n\t:if ([/ping \$ipv6gatewayAdr count=4] = 0) do={\
\n\t\t:log warning \"[watchdog] IPv6 gateway unreachable\"\
\n\t\t:set resetDHCP true\
\n\t}\
\n}\
\n\
\nif ( \$resetDHCP = true ) do={\
\n\t:log warning \"[watchdog] restarting dhcp-client(s)\"\
\n\tif ( [/interface/ethernet/switch/get [find where name=switch1] qos-hw-offloading] = true ) do={\
\n\t\t/interface/ethernet/switch/set [find where name=switch1] qos-hw-offloading=no\
\n\t}\
\n\tif ( [/interface/bridge/filter/get [find where comment=\"dhcp-orange\"] disabled] = true ) do={\
\n\t\t/interface bridge filter set [find where comment=\"dhcp-orange\"] disabled=no\
\n\t}\
\n\t/ip dhcp-client release [find where comment=\"dhcp-orange\"]\
\n\t/ipv6 dhcp-client release [find where comment=\"dhcp-orange\"]\
\n} else={\
\n\tif ( [/interface/bridge/filter/get [find where comment=\"dhcp-orange\"] disabled] = false ) do={\
\n\t\t:log warning \"[watchdog] connection works, disabling bridge rule\"\
\n\t\t/interface/bridge/filter/set [find where comment=\"dhcp-orange\"] disabled=yes\
\n\t}\
\n}\
\n"
/system scheduler
add interval=5m name=watchdog-orange on-event=watchdog-orange start-date=2020-01-01 start-time=11:01:01
Et maintenant, CQFD :
IPv4/IPv6 : ~110 Mo/s pour moins de 1% de CPUQuitte à utiliser le hardware, appliquons également le reset (0x00) du DSCP sortant (car le trafic bride si 0x20 par exemple)
Là on a rien à faire car tous les ports sont "untrusted", tout sera remis à zéro:
/interface ethernet switch
set 0 qos-hw-offloading=yes
Sans appel :
scp -o IPQoS=0x20 /storage/test1G.bin user@hostv4/v6:~
- sans qos-hw : ~ 2 Mo/s
- avec qos-hw : ~ 57 Mo/s
En revanche, qos-hw-offloading fait vriller les règles pour la CoS (initial et renew), il semble que switch1-cpu soit untrusted quoi qu'il arrive et ce n'est pas configurable.
Peut-être lié au bug référencé plus haut ?
En attendant que ce soit solutionné :
- un script schedulé pour forcer un renew sans qos-hw-offloading 2x par jour (ne pas attendre un renew hors contrôle)
/system script
add name=autorenew source="\
\n:local qosRenew false\
\n\
\n:set qosRenew [/interface/ethernet/switch/get [find where name=switch1] qos-hw-offloading]\
\n\
\nif ( \$qosRenew = true ) do={\
\n\t:log warning \"[autorenew] qos-hw-offloading to disable, then renew\"\
\n\t/interface/ethernet/switch/set [find where name=switch1] qos-hw-offloading=no\
\n\t:delay 5\
\n\t/ip dhcp-client renew [find where comment=\"dhcp-orange\"]\
\n\t/ipv6 dhcp-client renew [find where comment=\"dhcp-orange\"]\
\n\t:delay 10\
\n\t/interface/ethernet/switch/set [find where name=switch1] qos-hw-offloading=yes\
\n\t:log warning \"[autorenew] Renew done, re-enable qos-hw-offloading\"\
\n}\
\n"
/system scheduler
add interval=12h name=autorenew on-event=autorenew start-date=2021-01-01 start-time=01:00:00
Fin de la config à ce stade.
En conclusion, on reste dans la preuve de concept, mais c'est prometteur.
Les inconvénients sont évidents :
- pas de firewall LAN-WAN possible, surtout en IPv6 où tous les périphériques restent totalement exposés
- les différentes feintes nécessaires, qui concernent toutes la CoS=6
Mais l'avantage est évident aussi, le futur XXXXGS-PON 10G symétrique pour 0% de CPU, sur un appareil à 200€.
Remplacer la LiveBox par un routeur