Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
Tu peux reproduire sur un autre Mikrotik/ADSL ou seulement sur celui-là ?
Le modem derrière va bien ? Il a été redémarré ?
Tu ne peux pas faire l’upgrade du Mikrotik ?
Sincèrement, j’ai jamais vu ça et de nos jours, un montant d’ADSL saturé, ça 
arrive très souvent donc le problème serait fréquent.

> Le 17 avr. 2020 à 14:11, Brahim AGALMOUCHE  a 
> écrit :
> 
> Oui je peux saturer l'ADSL mais je perds pas systématiquement la sessions PPP 
> c'est en fait un peu aléatoire, du coup pour supprimer la doute et garantir 
> que les trames qui garantissent le maintient de la session PPP (en 
> l’occurrence l'échange PPP echo request/reply entre le CPE et le 
> concentrateur d'accès) 
> 
> Ainsi on les PPP echo requests qui rentrent dans le mikro, et puis les PPP 
> echo replies qui sortent vers l'AC.
> 
> Mon objectif du coup c'est de prioriser via un mécanisme de QoS ses deux 
> types de trames.
> 
> Je ne sais pas si déja mon raisonnement tient ou peut être j'ai loupé quelque 
> chose ?
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  17/04/20 à 13:52:19  
> 
> Le ven. 17 avr. 2020 à 13:32, David Ponzone  > a écrit :
> Je commencerais par un upgrade, sans garantir que ça règle quoi que ce soit, 
> je vois rien à ce sujet dans les RN.
> 
> Tu peux le reproduire en chargeant toi-même l’ADSL ?
> En saturant seulement l’entrant ?
> Seulement le sortant ?
> 
> 
>> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE > > a écrit :
>> 
>> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est 
>> 6.41.3.
>> 
>> 
>> 
>>   
>> 
>>  Sender notified by 
>> Mailtrack 
>> 
>>  17/04/20 à 13:16:22 
>> 
>> Le ven. 17 avr. 2020 à 13:09, David Ponzone > > a écrit :
>> Oui tu as raison, 5.9 minimum pour le 2011.
>> 
>> Donc attendons que Brahim nous confirme la version d’OS (/system resources 
>> print).
>> 
>>> Le 17 avr. 2020 à 13:04, Hugues Voiturier >> > a écrit :
>>> 
>>> Brahim parle peut-être de la version du firmware et non de RouterOS, parce 
>>> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>>> 
>>> Hugues
>>> AS57199 - AS50628
>>> 
 On 17 Apr 2020, at 12:59, David Ponzone >>> > wrote:
 
 Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 
 ans ?
 
> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE  > a écrit :
> 
> 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.
> 
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/ 
>>> 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Brahim AGALMOUCHE 
Oui je peux saturer l'ADSL mais je perds pas systématiquement la sessions
PPP c'est en fait un peu aléatoire, du coup pour supprimer la doute et
garantir que les trames qui garantissent le maintient de la session PPP (en
l’occurrence l'échange PPP echo request/reply entre le CPE et le
concentrateur d'accès)

Ainsi on les PPP echo requests qui rentrent dans le mikro, et puis les PPP
echo replies qui sortent vers l'AC.

Mon objectif du coup c'est de prioriser via un mécanisme de QoS ses deux
types de trames.

Je ne sais pas si déja mon raisonnement tient ou peut être j'ai loupé
quelque chose ?

[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 13:52:19

Le ven. 17 avr. 2020 à 13:32, David Ponzone  a
écrit :

> Je commencerais par un upgrade, sans garantir que ça règle quoi que ce
> soit, je vois rien à ce sujet dans les RN.
>
> Tu peux le reproduire en chargeant toi-même l’ADSL ?
> En saturant seulement l’entrant ?
> Seulement le sortant ?
>
>
> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE 
> a écrit :
>
> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
> 6.41.3.
>
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  17/04/20
> à 13:16:22
>
> Le ven. 17 avr. 2020 à 13:09, David Ponzone  a
> écrit :
>
>> Oui tu as raison, 5.9 minimum pour le 2011.
>>
>> Donc attendons que Brahim nous confirme la version d’OS (/system
>> resources print).
>>
>> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
>> écrit :
>>
>> Brahim parle peut-être de la version du firmware et non de RouterOS,
>> parce que je doute que le rb2011 supporte une aussi vieille version de rOS.
>>
>> Hugues
>> AS57199 - AS50628
>>
>> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>>
>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
>> ans ?
>>
>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
>> a écrit :
>>
>> 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.
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
Je commencerais par un upgrade, sans garantir que ça règle quoi que ce soit, je 
vois rien à ce sujet dans les RN.

Tu peux le reproduire en chargeant toi-même l’ADSL ?
En saturant seulement l’entrant ?
Seulement le sortant ?


> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE  a 
> écrit :
> 
> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est 
> 6.41.3.
> 
> 
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  17/04/20 à 13:16:22  
> 
> Le ven. 17 avr. 2020 à 13:09, David Ponzone  > a écrit :
> Oui tu as raison, 5.9 minimum pour le 2011.
> 
> Donc attendons que Brahim nous confirme la version d’OS (/system resources 
> print).
> 
>> Le 17 avr. 2020 à 13:04, Hugues Voiturier > > a écrit :
>> 
>> Brahim parle peut-être de la version du firmware et non de RouterOS, parce 
>> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>> 
>> Hugues
>> AS57199 - AS50628
>> 
>>> On 17 Apr 2020, at 12:59, David Ponzone >> > wrote:
>>> 
>>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 
>>> ans ?
>>> 
 Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE >>> > a écrit :
 
 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.
 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Brahim AGALMOUCHE 
Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
6.41.3.



[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 13:16:22

Le ven. 17 avr. 2020 à 13:09, David Ponzone  a
écrit :

> Oui tu as raison, 5.9 minimum pour le 2011.
>
> Donc attendons que Brahim nous confirme la version d’OS (/system resources
> print).
>
> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
> écrit :
>
> Brahim parle peut-être de la version du firmware et non de RouterOS, parce
> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>
> Hugues
> AS57199 - AS50628
>
> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>
> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
> ans ?
>
> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
> a écrit :
>
> 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.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
Oui tu as raison, 5.9 minimum pour le 2011.

Donc attendons que Brahim nous confirme la version d’OS (/system resources 
print).

> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a écrit 
> :
> 
> Brahim parle peut-être de la version du firmware et non de RouterOS, parce 
> que je doute que le rb2011 supporte une aussi vieille version de rOS.
> 
> Hugues
> AS57199 - AS50628
> 
>> On 17 Apr 2020, at 12:59, David Ponzone > > wrote:
>> 
>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 
>> ans ?
>> 
>>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE >> > a écrit :
>>> 
>>> 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.
>>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Hugues Voiturier 
Brahim parle peut-être de la version du firmware et non de RouterOS, parce que 
je doute que le rb2011 supporte une aussi vieille version de rOS.

Hugues
AS57199 - AS50628

> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
> 
> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 ans 
> ?
> 
>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE  a 
>> écrit :
>> 
>> 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.
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 ans ?

> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE  a 
> écrit :
> 
> 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.
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Brahim AGALMOUCHE 
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]

Sender
notified by
Mailtrack

17/04/20
à 12:40:36

Le ven. 17 avr. 2020 à 12:35, David Ponzone  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  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  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 
> 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) :
>
> 
> Le type de paquet qu’on souhaite marquer :
>
> 
>
> 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/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
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  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 > > 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 >> > 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) :
>>> 
>>> 
>>> Le type de paquet qu’on souhaite marquer :
>>> 
>>> 
>>> 
>>> 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.
>>> 
>>>  
>>> >>  
>>> >
>>>   Sender notified by 
>>> Mailtrack 
>>> >>  
>>> >
>>>  17/04/20 à 12:14:45 
>>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Hugues Voiturier 
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  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 > > 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) :
>> 
>> 
>> Le type de paquet qu’on souhaite marquer :
>> 
>> 
>> 
>> 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.
>> 
>>  
>> >  
>> >
>>Sender notified by 
>> Mailtrack 
>> >  
>> >
>>  17/04/20 à 12:14:45  
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet David Ponzone 
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  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) :
>  
> 
> Le type de paquet qu’on souhaite marquer :
>  
> 
> 
> 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.
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  17/04/20 à 12:14:45  
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

2020-04-17 Par sujet Brahim AGALMOUCHE 
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: image.png]
Le type de paquet qu’on souhaite marquer :

[image: 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.

[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 12:14:45