Je n'ai pas la même hypothèse pour expliquer que les règles bridge filter en RoS 7.1 fonctionnent sur le CRS312 et pas sur le CCR, autre que l'archi du CPU. P'tet ben que si ça marche sur le CRS, c'est parceque c'est le 98DX8212 qui prend la règle en hardware (et que le support via le CPU reste buggué) ?

Ça ne te limite pas en débit de faire le filtrage pour la CoS avec un CPU anémique ? 
 

Ça ne te limite pas en débit de faire le filtrage pour la CoS avec un CPU anémique ? 

Je t'ai dit que j'ai ressorti un autre switch plus puissant pour ;-)
(En fait c'est un routeur, mais avec un CPU potable, qui arrive à faire du switching @ 1gbps , oui)

Ça ne te limite pas en débit de faire le filtrage pour la CoS avec un CPU anémique ? 

@Mackila

Pour avoir fait des tests sur pleins de Mikrotik et des Ubiquiti, quand on fait la CoS au travers d'un changement de CoS dans le VLAN (VLAN Priority) et que pour les paquets DHCP cela revient (je pense) à inspecter et traiter tout le trafic :
- si cela est fait avec une Switch Rule comme sur un Mikrotik c'est l'Asic du Chip Switch qui est devant le CPU qui fait cela de manière native en hardware sans solliciter le CPU et comme on-dit "Line Rate" (une telle assistance hardware produit le même résultat que l'on est 1Kbps, 1Mbps ou 1Gbps de trafic)
- si cela est fait avec un bridge filter c'est le CPU qui doit vérifier chaque paquet et le traiter d'ou l'effondrement des performances en général quelque soit le CPU sauf monstreux multi-core CPU

Pour avoir fait des tests sur pleins de Mikrotik et des Ubiquiti, quand on fait la CoS au travers d'un changement de CoS dans le VLAN (VLAN Priority) et que pour les paquets DHCP cela revient (je pense) à inspecter et traiter tout le trafic :
- si cela est fait avec une Switch Rule comme sur un Mikrotik c'est l'Asic du Chip Switch qui est devant le CPU qui fait cela de manière native en hardware sans solliciter le CPU et comme on-dit "Line Rate" (une telle assistance hardware produit le même résultat que l'on est 1Kbps, 1Mbps ou 1Gbps de trafic)
- si cela est fait avec un bridge filter c'est le CPU qui doit vérifier chaque paquet et le traiter d'ou l'effondrement des performances en général quelque soit le CPU sauf monstreux multi-core CPU

L'implémentation est assez différente,

- Sur les ubiquiti edgerouters, il y a un vrai offload matériel par des hooks/APIs du SDK (Cavium). Les paquets offloadés ne sont même pas "vus" par le kernel.
La complexité d'une telle implémentation est probablement en rapport avec le gain obtenu.

- Chez Mikrotik, sur les modèles ARM récents tout du moins, c'est beaucoup moins central.

Les CPU utilisés (ARM Alpina ou Marvell) ne disposent d'aucun ASIC, et le "fast-track" n'est qu'un bypass sofware des règles netfilter pour toute connexion taggée comme telle.
La différence n'est pas comparable à l'ERL par exemple "avec ou sans".

Ce fast-track n'existe d'ailleurs pas en IPv6, et ca ne semble pas une priorité vu le faible gain pour les modèles actuels (RB4011 / 5009 / CCR-2xxx) et on peut imaginer que les modèles plus anciens (sous MIPS, tels que hEX, RB2011) ne sont plus leur première préoccupation, même si le gain serait là intéressant sous réserve d'ASICs disponibles sur ces CPUs.

En revanche le fast path sur des interfaces de type bridge reste l'exception réellement matérielle, c'est le switch-chip qui fait la commutation sans remonter au CPU.

https://mikrotik.com/product/crs305_1g_4s_in#fndtn-testresults

C'est un switch.
Et donc ?