Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.
Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL) qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du fastpath/track, je crois que ca va pas changer grand chose vu que les perfs du CPU ne sont pas impactés, et que ca reste uniquement un souci de priorisation des trames sortantes. [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;> 17/04/20 à 12:40:36 Le ven. 17 avr. 2020 à 12:35, David Ponzone <david.ponz...@gmail.com> a écrit : > C’est pas faux, et bon débarras le LCD du 3011 qui a jamais servi à rien, > et merci pour le chassis métal qui fait quand même plus sérieux. > > Par contre, ça peut être un peu overkill pour un petit client, mais si le > budget le permet…. > > Le 17 avr. 2020 à 12:33, Hugues Voiturier <hugues-lis...@milkywan.fr> a > écrit : > > Bonne règle qui peut être simplifiée par : > - Prends un RB4011, en plus d’avoir de la patate, ça fait joli chez le > client. > Plus sérieusement, l’avantage avec le RB4011, c’est que si même avec lui > ça merde, c’est que le souci est ailleurs :) > > Hugues > AS57199 - AS50628 > > On 17 Apr 2020, at 12:30, David Ponzone <david.ponz...@gmail.com> wrote: > > Très surprenant, j’ai jamais vu ça. > > Quelle version de RouterOS ? > T’as contrôlé le CPU quand ta liaison surcharge ? > Il est assez fréquent de voir des CPE Mikrotik un peu sous-dimensionné, > parce qu’on se fie un peu trop aux specs. > Si tu désactives le fastpath par exemple, parce qu’il te gêne (et il gêne > plein de trucs), ou si t’as oublié de l’activer, ça peut faire une grosse > différence. > Chez Mikrotik, je crois que la bonne règle quand on est pas sûr de soi > c’est: > -cherche le modèle qui supporte ton traffic avec des paquets de 512 octets > et 25 filtres > -prends le modèle au-dessus > > Le 17 avr. 2020 à 12:15, Brahim AGALMOUCHE <brahim.agalmou...@gmail.com> > a écrit : > > Bonjour, > > Je sollicite votre aide concernant une problématique de maintien des > sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients. > > En effet en constate que suite à une surcharge/congestion sur le lien WAN > sur le CPE Mikrotik, on perd la session PPPoE. > > Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP > echo reply, pour le faire on doit marquer ces trames pour les affecter à > une Queue et leur réserver de la bande passante. > > Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers > le modem ADSL) on a comme condition dans les matchers que le champ Type > dans le header des trames Ethernet, ce qui fait qu’on arrive pas à matcher > uniquement les trames LCP echo reply. > > La condition dans le matcher du filtre bridge (pour marquage des paquets) : > > <image.png> > Le type de paquet qu’on souhaite marquer : > > <image.png> > > Est-ce qu’on a un moyen pour affiner les conditions sur matching des > frames sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre > cette problématique de maintien des sessions lors de la congestion WAN > autrement ? > > D’avance merci pour vos retours. > Cordialement. > > < > https://mailtrack.io/?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&; > > Sender notified by > Mailtrack < > https://mailtrack.io/?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;> > 17/04/20 à 12:14:45 > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
