Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-03-06 Par sujet Jérôme Marteaux

Le 06/03/2023 à 19:04, Toussaint OTTAVI a écrit :


Le 06/03/2023 à 18:03, Sébastien 65 a écrit :

Maintenant je monte bien à 1492 sur le CPE client 


Cool ! Comme quoi, un gros opérateur peut se tromper et c'est normal de 
remonter le problème pour qu'il corrige, j'espère que ça servira d'exemple.




En pratique, 1492 au lieu de 1462, çà a un réel impact sur les perfs / 
la stabilité ? Vu que, de toute façon, les deux sont inférieurs à 1500 ?


En tant que client, j'ai des cas où le lien est à 1462, et çà ne m'a 
jamais vraiment gêné...




Si la MTU est correcte sur le PE et le CPE (qu'il n'y ai pas de problème 
de connectivité):

- sur TCP il n'y a pas d'impact car le PE/CPE vont fragmenter;
- sur UDP ça peut poser problème. Certaines piles n'implémentent pas la 
fragmentation, la pile SIP d'Asterisk par exemple. Mais c'est quand même 
rare d'avoir des paquets SIP obèse. Mais en gros ça peut poser problème 
sur DNS, SIP (SIP chiffré) et surtout avec une MTU plus faible.


Mais si on est à 1492 ou moins l'impact est négligeable.


Pour être complet il y a une petite perte de bande passante. Mettons que 
tu télécharge un gros fichier, avec une MTU inférieure à 1500 le lien 
sera moins efficace car tu vas avoir besoin d'un nombre supérieur de 
paquet et ainsi plus d'header IPv4, header udp/tcp/gre/ipsec/whatever 
qui ne transportent pas de données, donc plus la MTU est élevée plus le 
rapport volume total des paquets (header + payload) sur la bande 
passante sera élevé et plus le lien sera efficient.


Si on pousse encore plus loin, moins il y a de paquet (et donc de 
header) moins ton CPU va passer du temps dans la pile L2, IP pour 
traiter ces paquets (sur les nœuds finaux et les nœuds intermédiaire). 
D'où l'intérêt des jumbo frame dans les réseaux SAN/NAS.


Mais ça serait encore plus drôle si on considérait que ton CPE est 
derrière une ADSL qui tourne en ATM entre le modem et le DLSAM avec des 
cellules de 53 octets, on pourrait éviter de choisir une MTU qui 
amènerait à la génération de cellule de 53 octets où il n'y aurait que 1 
octet utile, là il y aurait une sacré perte d'efficacité de la bande 
passante brute ADSL.


Ca me rappelle les opérateurs qui livraient du SIP sur un lien SDH: 
c'était diablement inefficace, une bande passante SDH de 1 Mbps ne 
permettait pas de faire passer 1 Mbps de RTP mais beaucoup moins !

Au prix du Mbps sur la SDH ça faisait réfléchir.

Avec la généralisation d'ethernet dans les réseaux d'accès et les 
backbone longue distance il n'y a plus trop ces problèmes de dégradation 
de performance dû à la MTU.


Jérôme

--
Jérôme Marteaux


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-03-06 Par sujet Toussaint OTTAVI



Le 06/03/2023 à 18:03, Sébastien 65 a écrit :

Maintenant je monte bien à 1492 sur le CPE client 


En pratique, 1492 au lieu de 1462, çà a un réel impact sur les perfs / 
la stabilité ? Vu que, de toute façon, les deux sont inférieurs à 1500 ?


En tant que client, j'ai des cas où le lien est à 1462, et çà ne m'a 
jamais vraiment gêné...



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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-03-06 Par sujet Sébastien 65
Bonsoir,

Nous avons enfin réussi à faire fonctionner le MTU  SFR a réalisé quelques 
updates de conf et PE durant ces derniers jours/semaines sur la DSP.

Maintenant je monte bien à 1492 sur le CPE client 

ping 1.1.1.1 size 1492 df-bit fonctionne ENFIN (contre 1462 avant) ! Ou autre 
chose bien entendu...

Il faut bien utiliser un MTU de 2000 sur l'interface de collecte et sur les 2 
VLANs de livraison 1998 et 1999. En gros les STAS de SFR génériques sont 
correctes pour les DSP.

Merci à tous ceux qui ont participé au débug.

@+




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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-18 Par sujet Jérôme Marteaux

Le 17/02/2023 à 13:50, Sébastien 65 a écrit :

Salut Christophe,

Non, problème toujours présent ! En cours d'analyse côté SFR...

De mon côté je suis avec un MTU 9000 de bout en bout, pour faire simple conf de dernière 
"chance"...


Ca ne fonctionnera pas. Si jamais ton LNS reçoit l'ICMP depuis SFR, il 
va envoyer l'echo-reply dans un paquet trop gros pour SFR. Le routeur de 
SFR va dropper ton paquet et incrémenter son compteur giants.


Jérôme

--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-17 Par sujet Sébastien 65
Merci David pour l'info ! Je vais essayer aussi pour voir.

Je ne connais pas cette commande je vais me rencarder sur la doc CISCO.

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-17 Par sujet David Ponzone
Comme j’ai aussi des symptômes bizarres, j’ai pris un peu de temps et j’ai 
trouvé un paramètre magique dans le VT qui arrange bien des choses.
Maintenant les MTU de chaque côté sont alignés, mes ping DF passent jusqu’à la 
valeur du MTU, et plus au-dessus:

int virtual-templateX
 ppp mru match


> Le 17 févr. 2023 à 13:50, Sébastien 65  a écrit :
> 
> Salut Christophe,
> 
> Non, problème toujours présent ! En cours d'analyse côté SFR...
> 
> De mon côté je suis avec un MTU 9000 de bout en bout, pour faire simple conf 
> de dernière "chance"...
> 
> Sébastien
> 
> De : Christophe LUCAS 
> Envoyé : vendredi 17 février 2023 12:19
> À : Sébastien 65 
> Cc : Jérôme Marteaux ; frnog 
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
> 
> Salut,
> 
> Est-ce que ton problème s'est réglé ?
> 
> Pour obtenir 1500 côté usager :
> - RFC2516 + RFC4638 (PPPoE Max-Payload) avec 8 octects de plus sur ta wan 
> physique pour PPP + PPPoE (6+2) ;
> - Avoir une MTU alignée avec SFR entre ton PE qui fait du BGP avec SFR > 1548 
> ;
> - Avoir ta MTU > 1548 sur ton propre réseau pour transporter l'overhead du 
> tunnel L2TP (40 octets) jusqu'à ton LNS ;
> 
> Bonne journée,
> Christophe
> 
> 
> - Mail original -----
> De: "Sébastien 65" 
> À: "Jérôme Marteaux" , "frnog" 
> Envoyé: Mercredi 15 Février 2023 11:46:52
> Objet: RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
> 
>> As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant ton 
>> ping ICMP ?
> Rapidement mais rien qui me choque... Que je ping depuis le CPE vers la 
> Loopback du LNS ou inversement j'ai un mtu = 0 en debug icmp...
> 
> Si je ping le CPE depuis le LNS en indiquant le size 1460 j'ai bien le len à 
> 1460 sur le debug ICMP du CPE.
> 
> *Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
> sending
> *Feb 15 10:34:36.926: ICMP type=0, code=0
> *Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
> output feature
> *Feb 15 10:34:36.926: ICMP type=0, code=0, Post-routing NAT Outside(26), 
> rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
> 
>> Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce cas tu 
>> ne devrais pas être le seul impacté. 1 seul lien impacté ?
> C'est notre première liaison de livrée localement sur cette porte...
> 
> Je viens enfin d'avoir le support, le sujet est en cours de traitement.
> En plus du problème MTU j'avais indiqué un gros problème de latence qui vient 
> de m'être confirmé par le support SFR ! On va avancer...
> Etant a première vue l'un des premiers opérateurs locaux à avoir activé la 
> porte j'ai l'impression qu'un de mes confrères rencontre +/- les mêmes 
> soucis... Donc ça va avancer plus rapidement car je ne suis plus le seul !
> 
> Sébastien
> 
> De : frnog-requ...@frnog.org  de la part de Jérôme 
> Marteaux 
> Envoyé : mercredi 15 février 2023 10:57
> À : frnog@frnog.org 
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
> 
> Le 15/02/2023 à 10:47, Sébastien 65 a écrit :
>>> Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>>> 1460 tu as un problème de fragmentation quelque part.
>>> 1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
>> Entièrement d'accord ! Mais qui est le coupable 
>> 
>>> Donc soit chez SFR soit chez toi.
>>> Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il 
>>> des "giants" dans show interface xxx ?
>> Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
>> directement à l'équipement de collecte SFR et sur l'équipement qui est 
>> connecté au LNS !
>> J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.
> 
> As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant
> ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp
> packet)
> 
>> 
>> C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
>> bouffe la MTU !
>> 
> 
> Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus
> haute) tu devrais recevoir les paquets.
> Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce
> cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?
> 
> 
> --
> Jérôme Marteaux
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-17 Par sujet Sébastien 65
Salut Christophe,

Non, problème toujours présent ! En cours d'analyse côté SFR...

De mon côté je suis avec un MTU 9000 de bout en bout, pour faire simple conf de 
dernière "chance"...

Sébastien

De : Christophe LUCAS 
Envoyé : vendredi 17 février 2023 12:19
À : Sébastien 65 
Cc : Jérôme Marteaux ; frnog 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Salut,

Est-ce que ton problème s'est réglé ?

Pour obtenir 1500 côté usager :
 - RFC2516 + RFC4638 (PPPoE Max-Payload) avec 8 octects de plus sur ta wan 
physique pour PPP + PPPoE (6+2) ;
 - Avoir une MTU alignée avec SFR entre ton PE qui fait du BGP avec SFR > 1548 ;
 - Avoir ta MTU > 1548 sur ton propre réseau pour transporter l'overhead du 
tunnel L2TP (40 octets) jusqu'à ton LNS ;

Bonne journée,
Christophe


- Mail original -
De: "Sébastien 65" 
À: "Jérôme Marteaux" , "frnog" 
Envoyé: Mercredi 15 Février 2023 11:46:52
Objet: RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

>As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant ton 
>ping ICMP ?
Rapidement mais rien qui me choque... Que je ping depuis le CPE vers la 
Loopback du LNS ou inversement j'ai un mtu = 0 en debug icmp...

Si je ping le CPE depuis le LNS en indiquant le size 1460 j'ai bien le len à 
1460 sur le debug ICMP du CPE.

*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
sending
*Feb 15 10:34:36.926: ICMP type=0, code=0
*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
output feature
*Feb 15 10:34:36.926: ICMP type=0, code=0, Post-routing NAT Outside(26), 
rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

>Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce cas tu 
>ne devrais pas être le seul impacté. 1 seul lien impacté ?
C'est notre première liaison de livrée localement sur cette porte...

Je viens enfin d'avoir le support, le sujet est en cours de traitement.
En plus du problème MTU j'avais indiqué un gros problème de latence qui vient 
de m'être confirmé par le support SFR ! On va avancer...
Etant a première vue l'un des premiers opérateurs locaux à avoir activé la 
porte j'ai l'impression qu'un de mes confrères rencontre +/- les mêmes 
soucis... Donc ça va avancer plus rapidement car je ne suis plus le seul !

Sébastien

De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : mercredi 15 février 2023 10:57
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 15/02/2023 à 10:47, Sébastien 65 a écrit :
>> Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>> 1460 tu as un problème de fragmentation quelque part.
>> 1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
> Entièrement d'accord ! Mais qui est le coupable 
>
>> Donc soit chez SFR soit chez toi.
>> Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>> "giants" dans show interface xxx ?
> Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
> directement à l'équipement de collecte SFR et sur l'équipement qui est 
> connecté au LNS !
> J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant
ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp
packet)

>
> C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
> bouffe la MTU !
>

Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus
haute) tu devrais recevoir les paquets.
Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce
cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?


--
Jérôme Marteaux


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

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

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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Sébastien 65
>As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant ton 
>ping ICMP ?
Rapidement mais rien qui me choque... Que je ping depuis le CPE vers la 
Loopback du LNS ou inversement j'ai un mtu = 0 en debug icmp...

Si je ping le CPE depuis le LNS en indiquant le size 1460 j'ai bien le len à 
1460 sur le debug ICMP du CPE.

*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
sending
*Feb 15 10:34:36.926: ICMP type=0, code=0
*Feb 15 10:34:36.926: IP: s=IP-CPE (local), d=IP-LNS (Dialer0), len 1460, 
output feature
*Feb 15 10:34:36.926: ICMP type=0, code=0, Post-routing NAT Outside(26), 
rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

>Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce cas tu 
>ne devrais pas être le seul impacté. 1 seul lien impacté ?
C'est notre première liaison de livrée localement sur cette porte...

Je viens enfin d'avoir le support, le sujet est en cours de traitement.
En plus du problème MTU j'avais indiqué un gros problème de latence qui vient 
de m'être confirmé par le support SFR ! On va avancer...
Etant a première vue l'un des premiers opérateurs locaux à avoir activé la 
porte j'ai l'impression qu'un de mes confrères rencontre +/- les mêmes 
soucis... Donc ça va avancer plus rapidement car je ne suis plus le seul !

Sébastien

De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : mercredi 15 février 2023 10:57
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 15/02/2023 à 10:47, Sébastien 65 a écrit :
>> Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>> 1460 tu as un problème de fragmentation quelque part.
>> 1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
> Entièrement d'accord ! Mais qui est le coupable 
>
>> Donc soit chez SFR soit chez toi.
>> Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>> "giants" dans show interface xxx ?
> Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
> directement à l'équipement de collecte SFR et sur l'équipement qui est 
> connecté au LNS !
> J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant
ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp
packet)

>
> C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
> bouffe la MTU !
>

Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus
haute) tu devrais recevoir les paquets.
Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce
cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?


--
Jérôme Marteaux


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

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Jérôme Marteaux

Le 15/02/2023 à 10:47, Sébastien 65 a écrit :

Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
1460 tu as un problème de fragmentation quelque part.
1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.

Entièrement d'accord ! Mais qui est le coupable 


Donc soit chez SFR soit chez toi.
Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
"giants" dans show interface xxx ?

Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
directement à l'équipement de collecte SFR et sur l'équipement qui est connecté 
au LNS !
J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.


As-tu regardé si tu recevais bien le(s) paquet(s) L2TP de SFR contenant 
ton ping ICMP ? (debug ip icmp, monitor capture, sh ip traf, debug l2tp 
packet)




C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
bouffe la MTU !



Ca me semblerait étonnant, car dans les 2 cas (MTU à 1500 et MTU plus 
haute) tu devrais recevoir les paquets.
Peut-être que l'OLT ou le réseau de collecte a un problème et dans ce 
cas tu ne devrais pas être le seul impacté. 1 seul lien impacté ?



--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Sébastien 65
>Si tu as toujours des problèmes pour faire passer des paquets plus gros que 
>1460 tu as un problème de fragmentation quelque part.
>1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.
Entièrement d'accord ! Mais qui est le coupable 

>Donc soit chez SFR soit chez toi.
>Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il des 
>"giants" dans show interface xxx ?
Je viens de re-regarder, je n'ai pas de giants sur l'interface connectée 
directement à l'équipement de collecte SFR et sur l'équipement qui est connecté 
au LNS !
J'avais check cela quand j'avais passé tout le monde à MTU 9000 pour voir.

C'est pour cela que je pense vraiment que c'est un équipement de SFR qui me 
bouffe la MTU !

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Jérôme Marteaux

Le 15/02/2023 à 09:53, Sébastien 65 a écrit :

Le MTU sur l'interface vi2 est de 1492 comme pour le Dialer0.

CPE#sh interface vi2
Virtual-Access2 is up, line protocol is up
   Hardware is Virtual Access interface
   Description: *** PPPoE lns_FTTH SFR ***
   MTU 1492 bytes, BW 56 Kbit/sec, DLY 2 usec,
  reliability 255/255, txload 18/255, rxload 18/255
   Encapsulation PPP, LCP Open


As-tu bien toute la négo ppp dans ton debug ?

Oui j'ai collé toute la nego PPP qui trace MTU/MRU sur le CPE.



Donc maintenant tu as 1492 des 2 côtés, mieux que les 1464 du début.

Cette valeur correspond à ce qu'un CPE peut faire de mieux avec une 
interface physique WAN à 1500 de MTU.


Si tu as toujours des problèmes pour faire passer des paquets plus gros 
que 1460 tu as un problème de fragmentation quelque part.

1460 + 20 octets IP + 8 octets UDP + 12 octets L2TP = 1500.

Donc soit chez SFR soit chez toi.
Tu peux déjà regarder l'interface qui fait face à la porte SFR, y-a-t'il 
des "giants" dans show interface xxx ?


--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Sébastien 65
Le MTU sur l'interface vi2 est de 1492 comme pour le Dialer0.

CPE#sh interface vi2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Description: *** PPPoE lns_FTTH SFR ***
  MTU 1492 bytes, BW 56 Kbit/sec, DLY 2 usec,
 reliability 255/255, txload 18/255, rxload 18/255
  Encapsulation PPP, LCP Open

>As-tu bien toute la négo ppp dans ton debug ?
Oui j'ai collé toute la nego PPP qui trace MTU/MRU sur le CPE.

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-15 Par sujet Jérôme Marteaux

Le 15/02/2023 à 08:52, Sébastien 65 a écrit :

@Jérôme Marteaux

Donc là ça s'accorde sur 1514 en MTU. Et en vrai tu as combien ?

Le CPE ne peut jamais dépasser 1460 avec un ping size (même en pinguant l'IP de 
la Loopback LNS).


"sh ip int vi2" quelle est la MTU affichée ?
As-tu bien toute la négo ppp dans ton debug ? Car il doit y avoir 
plusieurs négo: entre ton CPE et l'OLT SFR, puis entre ton CPE et ton 
LNS car tu as lcp renegotiation always.
Car il y a quand même une grosse différence entre les 1514 négocié en 
ppp et ce que tu arrive à sortir en ICMP.



--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-14 Par sujet Sébastien 65
@Jérôme Marteaux
>Donc là ça s'accorde sur 1514 en MTU. Et en vrai tu as combien ?
Le CPE ne peut jamais dépasser 1460 avec un ping size (même en pinguant l'IP de 
la Loopback LNS).
Comme indiqué dans un précédent message sur la nego PPP du LNS il indique à 
chaque fois "PPP: Reducing MTU to peer's MRU" mais rien côté CPE...

@Steeve BEAUVAIS
>Pour moi c'est normal que cela ne fonctionne pas à 1492 à cause du L2TP de 
>l'OI.
En fait j'ai envie de dire que cela n'est pas normal que je ne dépasse pas les 
1460... Je peux me tromper !

Je n'ai toujours pas le retour de SFR sur le sujet au bout de 15J c'est 
fabuleux !!
Par contre quand je consulte les STAS IP Access SFR - en me disant que cela 
sera simmilaire sur leur DSP (?) je vois :

*sur accès FTTH
On utilise PPPoE et par défaut la MTU est 1492.
Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le CPE 
d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500. 
L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 octets. 
La LNS doit être configurée correctement (négociation MRU).

J'ai eu quelques retours en OFF m'indiquant que pour eux il est possible 
d'aller bien au dela de 1460...

Je vais aller chercher dans mes cartons poussiéreux un bon C7301 et faire le 
test à la place de l'ASR-1001, sérieux :p
D'ailleurs si quelqu'un a dans ces archives c7301-boot-mz.152-4.M11.bin et 
C7301_RMFUR.srec.123-4r.T4 je suis prenneur ;)

Sébastien



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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-14 Par sujet Steeve BEAUVAIS - Société Serinya Telecom
Si justement si tu met ton WAN à 1508 tu pourras passer ton dialer à 1500.

Comme je disais de mon côté les FTTH collectés en L2TP je mets le dialer à
1460 pour gérer l'encapsulation L2TP.

Pour moi c'est normal que cela ne fonctionne pas à 1492 à cause du L2TP de
l'OI.

Cordialement,

Steeve Beauvais
Directeur Architecture & Solutions
Serinya Telecom

Ce message a été envoyé depuis un appareil mobile.

Le mar. 14 févr. 2023, 18:22, Jérôme Marteaux  a écrit :

> Le 14/02/2023 à 17:14, Sébastien 65 a écrit :
> > Bonjour à tous,
> >
> > OK Steeve je suis d'accord il n'est pas possible de modifier le MTU sur
> le Dialer. Je l'avais indiqué dans une réponse précédente c'est pour cela
> que j'étais plutôt sur la Loopback/Vi-Template du LNS...
> >
> > @Jérôme Marteaux Voici le ppp nego sur le
> CPE :
> >
> > *Feb 14 15:59:17.435: Vi2 PPP: Using dialer call direction
> > *Feb 14 15:59:17.435: Vi2 PPP: Treating connection as a callout
> > *Feb 14 15:59:17.435: Vi2 PPP: Session handle[7719] Session id[14]
> > *Feb 14 15:59:17.435: Vi2 LCP: Event[OPEN] State[Initial to Starting]
> > *Feb 14 15:59:17.435: Vi2 PPP: No remote authentication for call-out
> > *Feb 14 15:59:17.435: Vi2 LCP: O CONFREQ [Starting] id 1 len 14
> > *Feb 14 15:59:17.435: Vi2 LCP:MRU 1492 (0x010405D4)
> > *Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
> > *Feb 14 15:59:17.435: Vi2 LCP: Event[UP] State[Starting to REQsent]
> > *Feb 14 15:59:17.435: Vi2 LCP: I CONFREQ [REQsent] id 1 len 38
> > *Feb 14 15:59:17.435: Vi2 LCP:MRU 1514 (0x010405EA)
> > *Feb 14 15:59:17.435: Vi2 LCP:AuthProto CHAP (0x0305C22305)
> > *Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
> > *Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
> > *Feb 14 15:59:17.435: Vi2 LCP:EndpointDisc 1 lns-FTTH
> (0x130F016c6e732d46545448)
> > *Feb 14 15:59:17.435: Vi2 LCP: O CONFREJ [REQsent] id 1 len 8
> > *Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
> > *Feb 14 15:59:17.435: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to
> REQsent]
> > *Feb 14 15:59:17.455: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
> > *Feb 14 15:59:17.455: Vi2 LCP:MRU 1492 (0x010405D4)
> > *Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
> > *Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfAck] State[REQsent to
> ACKrcvd]
> > *Feb 14 15:59:17.455: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 34
> > *Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
> > *Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
> > *Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
> > *Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH
> (0x130F016c6e732d46545448)
> > *Feb 14 15:59:17.455: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 34
> > *Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
> > *Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
> > *Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
> > *Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH
> (0x130F016c6e732d46545448)
> > *Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to
> Open]
> > *Feb 14 15:59:17.487: Vi2 PPP: Phase is AUTHENTICATING, by the peer
> > *Feb 14 15:59:17.487: Vi2 LCP: State is Open
> >
>
> Donc là ça s'accorde sur 1514 en MTU. Et en vrai tu as combien ?
>
> --
> Jérôme Marteaux
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

-- 


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-14 Par sujet Jérôme Marteaux

Le 14/02/2023 à 17:14, Sébastien 65 a écrit :

Bonjour à tous,

OK Steeve je suis d'accord il n'est pas possible de modifier le MTU sur le 
Dialer. Je l'avais indiqué dans une réponse précédente c'est pour cela que 
j'étais plutôt sur la Loopback/Vi-Template du LNS...

@Jérôme Marteaux Voici le ppp nego sur le CPE :

*Feb 14 15:59:17.435: Vi2 PPP: Using dialer call direction
*Feb 14 15:59:17.435: Vi2 PPP: Treating connection as a callout
*Feb 14 15:59:17.435: Vi2 PPP: Session handle[7719] Session id[14]
*Feb 14 15:59:17.435: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Feb 14 15:59:17.435: Vi2 PPP: No remote authentication for call-out
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREQ [Starting] id 1 len 14
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.435: Vi2 LCP: Event[UP] State[Starting to REQsent]
*Feb 14 15:59:17.435: Vi2 LCP: I CONFREQ [REQsent] id 1 len 38
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.435: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREJ [REQsent] id 1 len 8
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
*Feb 14 15:59:17.487: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Feb 14 15:59:17.487: Vi2 LCP: State is Open



Donc là ça s'accorde sur 1514 en MTU. Et en vrai tu as combien ?

--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-14 Par sujet Sébastien 65
Bonjour à tous,

OK Steeve je suis d'accord il n'est pas possible de modifier le MTU sur le 
Dialer. Je l'avais indiqué dans une réponse précédente c'est pour cela que 
j'étais plutôt sur la Loopback/Vi-Template du LNS...

@Jérôme Marteaux<mailto:jer...@dedwen.info> Voici le ppp nego sur le CPE :

*Feb 14 15:59:17.435: Vi2 PPP: Using dialer call direction
*Feb 14 15:59:17.435: Vi2 PPP: Treating connection as a callout
*Feb 14 15:59:17.435: Vi2 PPP: Session handle[7719] Session id[14]
*Feb 14 15:59:17.435: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Feb 14 15:59:17.435: Vi2 PPP: No remote authentication for call-out
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREQ [Starting] id 1 len 14
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.435: Vi2 LCP: Event[UP] State[Starting to REQsent]
*Feb 14 15:59:17.435: Vi2 LCP: I CONFREQ [REQsent] id 1 len 38
*Feb 14 15:59:17.435: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.435: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.435: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.435: Vi2 LCP: O CONFREJ [REQsent] id 1 len 8
*Feb 14 15:59:17.435: Vi2 LCP:MRRU 1524 (0x110405F4)
*Feb 14 15:59:17.435: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1492 (0x010405D4)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x7D1CD9B7 (0x05067D1CD9B7)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
*Feb 14 15:59:17.455: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 34
*Feb 14 15:59:17.455: Vi2 LCP:MRU 1514 (0x010405EA)
*Feb 14 15:59:17.455: Vi2 LCP:AuthProto CHAP (0x0305C22305)
*Feb 14 15:59:17.455: Vi2 LCP:MagicNumber 0x3401577D (0x05063401577D)
*Feb 14 15:59:17.455: Vi2 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
*Feb 14 15:59:17.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
*Feb 14 15:59:17.487: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Feb 14 15:59:17.487: Vi2 LCP: State is Open


De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : lundi 13 février 2023 21:23
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 10/02/2023 à 13:24, Sébastien 65 a écrit :
> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je 
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait 
> n'importe quoi et me bouffe mon MTU !
>

Et que dit un debug ppp nego sur le CPE ?

--
Jérôme Marteaux


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

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-13 Par sujet Jérôme Marteaux

Le 10/02/2023 à 13:24, Sébastien 65 a écrit :

Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je n'ai 
aucune indication de type Reducing MTU sur le CPE.

J'ai l'impression que sur la chaine SFR il y a un équipement qui fait n'importe 
quoi et me bouffe mon MTU !



Et que dit un debug ppp nego sur le CPE ?

--
Jérôme Marteaux


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-13 Par sujet Steeve BEAUVAIS - Société Serinya Telecom
Je confirme que je parlais du cas du CPE où on crée une interface dialer,
pour répondre à ce problème là :

CPE(config)#int dialer 0
CPE(config-if)#mtu 1500
 MAX allowed PPPOE MTU[1492] is set as MTU
CPE(config-if)#no mtu 1492
 MAX allowed PPPOE MTU[1492] is set as MTU

D'ailleurs je me suis aperçu que j'ai omis le point principal dans ma
première phrase :
"Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au MTU
de l'interface physique *-8 octets* ou logique associé."

Cordialement,


*Quelle que soit l'heure à laquelle vous parvient ce message, vous n'êtes
pas tenu d'y répondre en dehors de vos heures habituelles de travail.*


Le dim. 12 févr. 2023 à 15:10, David Ponzone  a
écrit :

> Il parlait du dialer donc du CPE je pense, et dans ce cas le dialer est
> bien associé à une interface physique.
>
> Pour ma part concernant ton souci, je suis à peu près certain que certains
> réseaux ont des équipements qui viennent altérer la négociation MTU (pour
> une bonne ou mauvaise raison, cela reste à déterminer).
> Je manque de temps pour faire les mêmes tests que toi sur différents
> réseaux, mais je vais essayer de mettre ça plus en haut de la pile.
>
> > Le 12 févr. 2023 à 14:56, Sébastien 65  a écrit :
> >
> > Salut Steeve,
> >
> >> Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au
> MTU de l'interface physique ou logique associé.
> > L'interface logique associée dans la virtual-template est une loopback,
> donc le MTU est de 1514.
> >
> > Le MTU du Dialer devrait être bien supérieure à 1452, ce qui n'est pas
> le cas...
> >
> > Sébastien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

-- 


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-12 Par sujet David Ponzone
Il parlait du dialer donc du CPE je pense, et dans ce cas le dialer est bien 
associé à une interface physique.

Pour ma part concernant ton souci, je suis à peu près certain que certains 
réseaux ont des équipements qui viennent altérer la négociation MTU (pour une 
bonne ou mauvaise raison, cela reste à déterminer).
Je manque de temps pour faire les mêmes tests que toi sur différents réseaux, 
mais je vais essayer de mettre ça plus en haut de la pile.

> Le 12 févr. 2023 à 14:56, Sébastien 65  a écrit :
> 
> Salut Steeve,
> 
>> Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au MTU de 
>> l'interface physique ou logique associé.
> L'interface logique associée dans la virtual-template est une loopback, donc 
> le MTU est de 1514.
> 
> Le MTU du Dialer devrait être bien supérieure à 1452, ce qui n'est pas le 
> cas...
> 
> Sébastien
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-12 Par sujet Sébastien 65
Salut Steeve,

>Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au MTU de 
>l'interface physique ou logique associé.
L'interface logique associée dans la virtual-template est une loopback, donc le 
MTU est de 1514.

Le MTU du Dialer devrait être bien supérieure à 1452, ce qui n'est pas le cas...

Sébastien

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-11 Par sujet Steeve BEAUVAIS - Société Serinya Telecom
Salut,

Sur un cisco le MTU max que tu peux mettre sur un dialer est égale au MTU
de l'interface physique ou logique associé.

Donc si ton interface WAN est à 1500 tu ne pourras pas mettre plus de 1492
sur ton dialer.
Si tu veux mettre 1500 que ton dialer ton interface WAN doit au moins être
à 1508 octets en MTU.

Pour le reste si SFR fait de de la collecte PPPoE à travers L2TP il faut
prendre en compte les 40 octets de l'entête L2TP.
Donc ton WAN passe à 1460 et ton dialer à 1452 en en MTU. Sans oublié le
MSS à 1412.

Cordialement,

Steeve Beauvais

Le sam. 11 févr. 2023, 14:20, Sébastien 65  a écrit :

> Fabien,
>
> J'avais même essayé avec MTU 9000 sur le LNS et même chose sur
> l'équipement de collecte qui récupère l'infra FTTH SFR afin d'être sur que
> la réduction MTU ne soit pas faite par un de mes équipements !
>
> Cela ne change strictement rien côté CPE... Le debug sur le LNS indique
> toujours  PPP: Reducing MTU to peer's MRU
>
> Sébastien
> 
> De : frnog-requ...@frnog.org  de la part de
> Fabien H 
> Envoyé : vendredi 10 février 2023 18:37
> À : Liste FRnoG 
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>
> Peut-être vérifier sur ton LNS que ton interface de Collecte opérateur ait
> bien un MTU à minimum 2000 ?
>
> Le ven. 10 févr. 2023 à 13:25, Sébastien 65  a
> écrit :
>
> > Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que
> je
> > n'ai aucune indication de type Reducing MTU sur le CPE.
> >
> > J'ai l'impression que sur la chaine SFR il y a un équipement qui fait
> > n'importe quoi et me bouffe mon MTU !
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-11 Par sujet Sébastien 65
Fabien,

J'avais même essayé avec MTU 9000 sur le LNS et même chose sur l'équipement de 
collecte qui récupère l'infra FTTH SFR afin d'être sur que la réduction MTU ne 
soit pas faite par un de mes équipements !

Cela ne change strictement rien côté CPE... Le debug sur le LNS indique 
toujours  PPP: Reducing MTU to peer's MRU

Sébastien

De : frnog-requ...@frnog.org  de la part de Fabien H 

Envoyé : vendredi 10 février 2023 18:37
À : Liste FRnoG 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Peut-être vérifier sur ton LNS que ton interface de Collecte opérateur ait
bien un MTU à minimum 2000 ?

Le ven. 10 févr. 2023 à 13:25, Sébastien 65  a écrit :

> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait
> n'importe quoi et me bouffe mon MTU !
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Fabien H
Peut-être vérifier sur ton LNS que ton interface de Collecte opérateur ait
bien un MTU à minimum 2000 ?

Le ven. 10 févr. 2023 à 13:25, Sébastien 65  a écrit :

> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait
> n'importe quoi et me bouffe mon MTU !
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Sébastien 65
Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je n'ai 
aucune indication de type Reducing MTU sur le CPE.

J'ai l'impression que sur la chaine SFR il y a un équipement qui fait n'importe 
quoi et me bouffe mon MTU !

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Jérôme Marteaux

Le 10/02/2023 à 12:54, Sébastien 65 a écrit :

Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.

En modifiant le vpdn/virtual-template j'ai bien la MRU qui passe de 1464 à 1524 
avec un message de reducing MTU que je n'avais pas avant sur le LNS :

Feb 10 12:35:44.717: Vi2.1 CHAP: O SUCCESS id 2 len 4
Feb 10 12:35:44.717: Vi2.1 PPP: Reducing MTU to peer's MRU
Feb 10 12:35:44.717: Vi2.1 PPP: Phase is UP


Par contre sur le CPE je ne peux toujours pas aller au-delà de 1460.


Il faut que tu fasse debug ppp nego aussi sur le CPE pour analyser ce 
qu'il se passe et en trouver l'origine.



C'est à cause de ip mtu adjust dans ton vpdn sans ip mtu dans la
virtual-template:

Automatically Adjusting the IP MTU
You can also enable automatic adjustment of the IP MTU. This feature
allows the router to automatically adjust the IP MTU on the
virtual-access interface to compensate for the size of the L2TP header
and the MTU of the egress interface.

Note: The IP MTU is only adjusted automatically if there is no IP MTU
manually configured on the virtual-template interface (using the option
in the previous section).

https://www.cisco.com/c/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/24320-l2tp-mtu-tuning.html

Supprime tout ce qui est relatif à la mtu dans le vpdn et met ppp mtu
adaptive dans la virtual-template.


--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Sébastien 65
>Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.
En modifiant le vpdn/virtual-template j'ai bien la MRU qui passe de 1464 à 1524 
avec un message de reducing MTU que je n'avais pas avant sur le LNS :

Feb 10 12:35:44.717: Vi2.1 CHAP: O SUCCESS id 2 len 4
Feb 10 12:35:44.717: Vi2.1 PPP: Reducing MTU to peer's MRU
Feb 10 12:35:44.717: Vi2.1 PPP: Phase is UP


Par contre sur le CPE je ne peux toujours pas aller au-delà de 1460.



De : frnog-requ...@frnog.org  de la part de Jérôme 
Marteaux 
Envoyé : vendredi 10 février 2023 11:22
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Le 10/02/2023 à 11:08, Sébastien 65 a écrit :
>> C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il fait 
>> au mieux 1464.
> Le debug indiqué est bien sur notre LNS. Je ne comprends pas justement 
> pourquoi il MTU à 1464 ?!
>

C'est à cause de ip mtu adjust dans ton vpdn sans ip mtu dans la
virtual-template:

Automatically Adjusting the IP MTU
You can also enable automatic adjustment of the IP MTU. This feature
allows the router to automatically adjust the IP MTU on the
virtual-access interface to compensate for the size of the L2TP header
and the MTU of the egress interface.

Note: The IP MTU is only adjusted automatically if there is no IP MTU
manually configured on the virtual-template interface (using the option
in the previous section).

https://www.cisco.com/c/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/24320-l2tp-mtu-tuning.html

Supprime tout ce qui est relatif à la mtu dans le vpdn et met ppp mtu
adaptive dans la virtual-template.

>> Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500
> Mon interco est bien à 1500 ! Côté SFR j'attends d'avoir un retour j'ai 
> ouvert un ticket sans réponse depuis 1 semaine sur le sujet...
>
> Etant sur une nouvelle DSP il n'y a pas de STAS pour le moment, donc 
> clairement tu pars à l'aveugle...
>
> J'ai regardé les STAS de SFR FTTH ils indiquent que :
>
> # Entre le CPE sur le site du client final et le LNS du client Opérateur
> - On utilise PPPoE et par défaut la MTU est 1492.
> -Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le 
> CPE d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500.
> -L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 
> octets. La LNS doit être configurée correctement (négociation MRU).
>
> # Sur les Portes de Livraison
> -La MTU entre les équipements Opérateur et le NTU de SFR devra être de 2000 
> octets en émission et en réception,

Si SFR respecte ^^ alors la MTU de la porte de collecte est à 2000.

> -Les équipements Opérateur ne devront pas envoyer des paquets L2TP fragmentés 
> vers SFR.
>
> J'aimerais que le support de la DSP me confirme cela...
>
>> Ré-essaye 1501 sans df pour voir si ça fragmente bien.
> Oui ça fragmente bien, par ex un ping de 1600 sans df passera !

Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.

--
Jérôme Marteaux



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

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Jérôme Marteaux

Le 10/02/2023 à 11:08, Sébastien 65 a écrit :

C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il fait au 
mieux 1464.

Le debug indiqué est bien sur notre LNS. Je ne comprends pas justement pourquoi 
il MTU à 1464 ?!



C'est à cause de ip mtu adjust dans ton vpdn sans ip mtu dans la 
virtual-template:


Automatically Adjusting the IP MTU
You can also enable automatic adjustment of the IP MTU. This feature 
allows the router to automatically adjust the IP MTU on the 
virtual-access interface to compensate for the size of the L2TP header 
and the MTU of the egress interface.


Note: The IP MTU is only adjusted automatically if there is no IP MTU 
manually configured on the virtual-template interface (using the option 
in the previous section).


https://www.cisco.com/c/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/24320-l2tp-mtu-tuning.html

Supprime tout ce qui est relatif à la mtu dans le vpdn et met ppp mtu 
adaptive dans la virtual-template.



Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500

Mon interco est bien à 1500 ! Côté SFR j'attends d'avoir un retour j'ai ouvert 
un ticket sans réponse depuis 1 semaine sur le sujet...

Etant sur une nouvelle DSP il n'y a pas de STAS pour le moment, donc clairement 
tu pars à l'aveugle...

J'ai regardé les STAS de SFR FTTH ils indiquent que :

# Entre le CPE sur le site du client final et le LNS du client Opérateur
- On utilise PPPoE et par défaut la MTU est 1492.
-Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le CPE 
d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500.
-L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 octets. 
La LNS doit être configurée correctement (négociation MRU).

# Sur les Portes de Livraison
-La MTU entre les équipements Opérateur et le NTU de SFR devra être de 2000 
octets en émission et en réception,


Si SFR respecte ^^ alors la MTU de la porte de collecte est à 2000.


-Les équipements Opérateur ne devront pas envoyer des paquets L2TP fragmentés 
vers SFR.

J'aimerais que le support de la DSP me confirme cela...


Ré-essaye 1501 sans df pour voir si ça fragmente bien.

Oui ça fragmente bien, par ex un ping de 1600 sans df passera !


Déjà un bon point ! Mais dans l'autre sens (SFR->toi) c'est pas garanti.

--
Jérôme Marteaux



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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Sébastien 65
>C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il fait 
>au mieux 1464.
Le debug indiqué est bien sur notre LNS. Je ne comprends pas justement pourquoi 
il MTU à 1464 ?!

>Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500
Mon interco est bien à 1500 ! Côté SFR j'attends d'avoir un retour j'ai ouvert 
un ticket sans réponse depuis 1 semaine sur le sujet...

Etant sur une nouvelle DSP il n'y a pas de STAS pour le moment, donc clairement 
tu pars à l'aveugle...

J'ai regardé les STAS de SFR FTTH ils indiquent que :

# Entre le CPE sur le site du client final et le LNS du client Opérateur
- On utilise PPPoE et par défaut la MTU est 1492.
-Si on veut une taille du paquet IP de 1500 octets, il faut utiliser sur le CPE 
d’extrémité le tag PPPoE max-payload en le mettant à la valeur 1500.
-L'interface Ethernet WAN du CPE doit avoir une MTU d'au moins de 1512 octets. 
La LNS doit être configurée correctement (négociation MRU).

# Sur les Portes de Livraison
-La MTU entre les équipements Opérateur et le NTU de SFR devra être de 2000 
octets en émission et en réception,
-Les équipements Opérateur ne devront pas envoyer des paquets L2TP fragmentés 
vers SFR.

J'aimerais que le support de la DSP me confirme cela...

>Ré-essaye 1501 sans df pour voir si ça fragmente bien.
Oui ça fragmente bien, par ex un ping de 1600 sans df passera !

Sébastien

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-10 Par sujet Jérôme Marteaux

Le 10/02/2023 à 08:42, Sébastien 65 a écrit :

Bonjour Jérôme,


Pour moi mtu et ip mtu veulent dire la même chose sur un dialer (mtu ne devrait 
pas exister car dialer n'est pas une interface physique).

mtu 1492 est automatique, je ne le configure pas moi-même c'est le routeur qui 
se rajoute cette commande.
D'ailleurs, il n'est jamais possible de supprimer ou d'augmenter la mtu d'un 
dialer ppp :

CPE(config)#int dialer 0
CPE(config-if)#mtu 1500
  MAX allowed PPPOE MTU[1492] is set as MTU
CPE(config-if)#no mtu 1492
  MAX allowed PPPOE MTU[1492] is set as MTU



étrange.


Pour voir ce que chacun dit tu peux faire un debug ppp nego pour savoir qui 
annonce quoi en MRU (entre ton CPE, l'OLT/BNG SFR et ton LNS)

Justement c'est ici que je ne comprends pas pourquoi la MRU ne dépasse jamais 
1492 // 1464, un output :

Feb 08 07:03:16.714: PPP: Alloc Context [9713814]
Feb 08 07:03:16.714: ppp31 PPP: Phase is ESTABLISHING
Feb 08 07:03:16.714: ppp31 LCP: Event[OPEN] State[Initial to Starting]
Feb 08 07:03:16.714: ppp31 LCP: O CONFREQ [Starting] id 1 len 38
Feb 08 07:03:16.714: ppp31 LCP:MRU 1464 (0x010405B8)


C'est bien sur cet équipement (LNS ?) que ça coince, celui-ci dit qu'il 
fait au mieux 1464.



Feb 08 07:03:16.714: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.714: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.714: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.714: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.714: ppp31 LCP: Event[UP] State[Starting to REQsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREQ [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: O CONFACK [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfReq+] State[REQsent to 
ACKsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREJ [ACKsent] id 1 len 8
Feb 08 07:03:16.998: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.998: ppp31 LCP: O CONFREQ [ACKsent] id 2 len 34
Feb 08 07:03:16.998: ppp31 LCP:MRU 1464 (0x010405B8)
Feb 08 07:03:16.998: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.998: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.306: ppp31 LCP: I CONFNAK [ACKsent] id 2 len 8
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP: O CONFREQ [ACKsent] id 3 len 34
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.306: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.306: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.306: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.618: ppp31 LCP: I CONFACK [ACKsent] id 3 len 34
Feb 08 07:03:17.618: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.618: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.618: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.618: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.618: ppp31 LCP: Event[Receive ConfAck] State[ACKsent to Open]
Feb 08 07:03:17.646: ppp31 PPP: Phase is AUTHENTICATING, by this end
Feb 08 07:03:17.646: ppp31 CHAP: O CHALLENGE id 2 len 33 from "lns-FTTH"
Feb 08 07:03:17.646: ppp31 LCP: State is Open


Regarde show l2tp tunnel, prend l'IP d'un OLT/BNG SFR au hasard et essaye de le 
pinger en df pour voir si déjà tu as bien 1500 octets,

Je peux pinger une IP du BNG SFR depuis le LNS avec 1500 mais pas en 1501 (size 
150x df-bit)


Donc ton interco avec SFR est à 1500. Côté SFR est-ce bien aussi à 1500 
? Ré-essaye 1501 sans df pour voir si ça fragmente bien.


Il faut que tu valide 2 choses:
 - l'interco avec SFR est-elle bien fonctionnelle ? Quand le 
LNS/OLT/BNG va envoyer un paquet plus gros que la MTU est-ce qu'ils vont 
bien fragmenter ? => Est-ce que tes interco entre ton LNS, backbone et 
SFR sont bien alignées ?


 - PPP/L2TP: alignement des MTU.


Jérôme

--
Jérôme Marteaux


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-09 Par sujet Sébastien 65
Bonjour Jérôme,

>Pour moi mtu et ip mtu veulent dire la même chose sur un dialer (mtu ne 
>devrait pas exister car dialer n'est pas une interface physique).
mtu 1492 est automatique, je ne le configure pas moi-même c'est le routeur qui 
se rajoute cette commande.
D'ailleurs, il n'est jamais possible de supprimer ou d'augmenter la mtu d'un 
dialer ppp :

CPE(config)#int dialer 0
CPE(config-if)#mtu 1500
 MAX allowed PPPOE MTU[1492] is set as MTU
CPE(config-if)#no mtu 1492
 MAX allowed PPPOE MTU[1492] is set as MTU

>Pour voir ce que chacun dit tu peux faire un debug ppp nego pour savoir qui 
>annonce quoi en MRU (entre ton CPE, l'OLT/BNG SFR et ton LNS)
Justement c'est ici que je ne comprends pas pourquoi la MRU ne dépasse jamais 
1492 // 1464, un output :

Feb 08 07:03:16.714: PPP: Alloc Context [9713814]
Feb 08 07:03:16.714: ppp31 PPP: Phase is ESTABLISHING
Feb 08 07:03:16.714: ppp31 LCP: Event[OPEN] State[Initial to Starting]
Feb 08 07:03:16.714: ppp31 LCP: O CONFREQ [Starting] id 1 len 38
Feb 08 07:03:16.714: ppp31 LCP:MRU 1464 (0x010405B8)
Feb 08 07:03:16.714: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.714: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.714: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.714: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.714: ppp31 LCP: Event[UP] State[Starting to REQsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREQ [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: O CONFACK [REQsent] id 1 len 14
Feb 08 07:03:16.998: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x67B01CAC (0x050667B01CAC)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfReq+] State[REQsent to 
ACKsent]
Feb 08 07:03:16.998: ppp31 LCP: I CONFREJ [ACKsent] id 1 len 8
Feb 08 07:03:16.998: ppp31 LCP:MRRU 1524 (0x110405F4)
Feb 08 07:03:16.998: ppp31 LCP: O CONFREQ [ACKsent] id 2 len 34
Feb 08 07:03:16.998: ppp31 LCP:MRU 1464 (0x010405B8)
Feb 08 07:03:16.998: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:16.998: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:16.998: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:16.998: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.306: ppp31 LCP: I CONFNAK [ACKsent] id 2 len 8
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP: O CONFREQ [ACKsent] id 3 len 34
Feb 08 07:03:17.306: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.306: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.306: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.306: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.306: ppp31 LCP: Event[Receive ConfNak/Rej] State[ACKsent to 
ACKsent]
Feb 08 07:03:17.618: ppp31 LCP: I CONFACK [ACKsent] id 3 len 34
Feb 08 07:03:17.618: ppp31 LCP:MRU 1492 (0x010405D4)
Feb 08 07:03:17.618: ppp31 LCP:AuthProto CHAP (0x0305C22305)
Feb 08 07:03:17.618: ppp31 LCP:MagicNumber 0x1D788BA5 (0x05061D788BA5)
Feb 08 07:03:17.618: ppp31 LCP:EndpointDisc 1 lns-FTTH 
(0x130F016c6e732d46545448)
Feb 08 07:03:17.618: ppp31 LCP: Event[Receive ConfAck] State[ACKsent to Open]
Feb 08 07:03:17.646: ppp31 PPP: Phase is AUTHENTICATING, by this end
Feb 08 07:03:17.646: ppp31 CHAP: O CHALLENGE id 2 len 33 from "lns-FTTH"
Feb 08 07:03:17.646: ppp31 LCP: State is Open

>Regarde show l2tp tunnel, prend l'IP d'un OLT/BNG SFR au hasard et essaye de 
>le pinger en df pour voir si déjà tu as bien 1500 octets,
Je peux pinger une IP du BNG SFR depuis le LNS avec 1500 mais pas en 1501 (size 
150x df-bit)

Sébastien

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-09 Par sujet Jérôme Marteaux

Le 08/02/2023 à 09:50, Sébastien 65 a écrit :

Bonjour,


Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
L2TP/PPPoE...


Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer le 
Dialer du routeur client comme ceci :


interface Dialer0

  encapsulation ppp

  mtu 1492

  ip mtu 1460

  ip tcp adjust-mss 1420



Pour moi mtu et ip mtu veulent dire la même chose sur un dialer (mtu ne 
devrait pas exister car dialer n'est pas une interface physique). Si tu 
enlève mtu et ip mtu le dialer devrait hériter de la MTU - 8 de 
l'interface physique / du vlan et donc être la MTU maximale possible.

Je ne pense pas qu'il y ai un intérêt à la spécifier dans ton cas.



Le Dialer0 est rattaché sur le VLAN d'accès 2900.


Et cette interface a quelle MTU ? Tu peux aussi augmenter la MTU de 
l'interface physique, SFR doit supporter 1508 pour avoir 1500 sur la 
virtual-access.


Pour voir ce que chacun dit tu peux faire un debug ppp nego pour savoir 
qui annonce quoi en MRU (entre ton CPE, l'OLT/BNG SFR et ton LNS) et au 
final qui est le moins disant et surlequel toute la chaîne va se caler.


Ce qu'il faut vérifier (en L2 et L3):
 - la MTU de l'interface de ton LNS qui fait face à ton backbone et 
l'équipement en face doit être identique;
 - l'interface qui fait face à SFR doit avoir la bonne MTU négociée 
avec SFR (pour fragmenter si nécessaire);


Il est rare que la négo MTU du L2TP pose problème depuis le temps que 
les piles L2TP sont correctes (perso je n'ai jamais eu de problème).


Regarde show l2tp tunnel, prend l'IP d'un OLT/BNG SFR au hasard et 
essaye de le pinger en df pour voir si déjà tu as bien 1500 octets, 
ensuite essaye 1501 sans df pour voir si ça fragmente bien côté L2TP.



Jérôme

--
Jérôme Marteaux


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-09 Par sujet Dominique Rousseau
Le Wed, Feb 08, 2023 at 03:59:01PM +, Sébastien 65 [sebastien...@live.fr] a 
écrit:
> Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
> 1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.
> 
> Je ne peux pas dire encore l'impact car il s'agit du premier lien
> livré localement sur cette DSP !
> Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par
> défaut en PPPoE d'où mon interrogation 

De toute facon, 1492 ou 1462 ( ou autre ), si c'est pas 1500, faut
tricher avec la MSS pour TCP et prier pour le reste.
( car tu n'auras pas la possibilité de configurer les interfaces des
clients pour leur mettre une mtu spécifique )


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
>Tu veux dire que le paquet de 1462 passe puis ensuite ne passe plus ?
C'est bien ça !

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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet David Ponzone
Tu veux dire que le paquet de 1462 passe puis ensuite ne passe plus ?
Je pense que c’est l'équipement Edgecast qui doit être en cause.

Moi je fais tout mes tests avec l’IP de mes LNS, sinon ça devient inextricable.

> Le 8 févr. 2023 à 17:15, Sébastien 65  a écrit :
> 
> Nop pas du tout David ! C'est un réflexe le 8.8.8.8
> 
> Tu me crois ou pas (délirant) :
> 
> CPE#ping 152.199.23.71 size 1462 df-bit source dial0
> Type escape sequence to abort.
> Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
> Packet sent with a source address of 
> Packet sent with the DF bit set
> !
> Success rate is 100 percent (5/5), round-trip min/avg/max = 40/47/64 ms
> CPE#ping 152.199.23.71 size 1463 df-bit source dial0
> Type escape sequence to abort.
> Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
> Packet sent with a source address of 
> Packet sent with the DF bit set
> .
> Success rate is 0 percent (0/5)
> CPE#ping 152.199.23.71 size 1463 df-bit source dial0
> Type escape sequence to abort.
> Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
> Packet sent with a source address of 
> Packet sent with the DF bit set
> .
> Success rate is 0 percent (0/5)
> CPE#ping 152.199.23.71 size 1462 df-bit source dial0
> Type escape sequence to abort.
> Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
> Packet sent with a source address of 
> Packet sent with the DF bit set
> .
> Success rate is 0 percent (0/5)
> 
> 
> 
> De : David Ponzone mailto:david.ponz...@gmail.com>>
> Envoyé : mercredi 8 février 2023 17:08
> À : Sébastien 65 mailto:sebastien...@live.fr>>
> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>  <mailto:frnog-t...@frnog.org>>
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>  
> Et oui, je t’ai prévenu et tu m’as pris à la légère :)
> 
> Quand tu fais un ping 1462 vers 8.8.8.8, tu envoies ça dans le payload:
> 
> Data (1462 bytes)
> 
> Et tu reçois ça en réponse:
> 
> Data (68 bytes)
> 
> Donc l’ICMP REPLY était bien plus petit que ta limite de MTU LNS->CPE.
> 
> Ceci dit, tu sembles avoir un MTU asymétrique et ça mérite de s’y pencher, 
> mais bon avec SFR, tu auras difficilement quelqu’un qui tient la route en 
> face pour discuter de ça.
> 
> Pour 152.199.23.71, tu es sûr de ton coup ?
> Je ne vois pas la même asymétrie de l’ICMP REPLY.
> 
>> Le 8 févr. 2023 à 16:59, Sébastien 65 > <mailto:sebastien...@live.fr>> a écrit :
>> 
>> Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
>> 1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.
>> 
>> Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
>> localement sur cette DSP ! 
>> Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par 
>> défaut en PPPoE d'où mon interrogation 
>> 
>> De : David Ponzone mailto:david.ponz...@gmail.com>>
>> Envoyé : mercredi 8 février 2023 16:18
>> À : Sébastien 65 mailto:sebastien...@live.fr>>
>> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org> 
>> mailto:frnog-t...@frnog.org>>
>> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>>  
>> Et ça passe à 1462 et pas plus ?
>> C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier 
>> (1995) qu’on se prend la tête avec le MTU et les trucs bizarres.
>> Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
>> Virtual-Template et dans ton CPE.
>> 
>> Tu as un impact client ou c’était par curiosité ?
>> Généralement, si les MTU de tes interfaces autorisent des paquets d’une 
>> taille qui sera droppée par le réseau, tu as/auras un impact client 
>> immédiat, puisque la fragmentation va faire des paquets trop gros.
>> D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le 
>> problème pour ICMP et UDP).
>> 
>>> Le 8 févr. 2023 à 11:32, Sébastien 65 >> <mailto:sebastien...@live.fr>> a écrit :
>>> 
>>> L'interface Virtual-Access2.X a un MTU de 1464 !
>>> 
>>> Je suis en directe sur une collecte FTTH SFR Pro (DSP).
>>> De : David Ponzone >> <mailto:david.ponz...@gmail.com>>
>>> Envoyé : mercredi 8 février 2023 11:24
>>> À : Sébastien 65 mailto:sebastien...@live.fr>>
>>> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org> 
>>> mailto:frnog-t...@frnog.org>>
>>> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>>>  
>>> Cherche la Vi de ton lien (sh users | inc ), e

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
Nop pas du tout David ! C'est un réflexe le 8.8.8.8

Tu me crois ou pas (délirant) :

CPE#ping 152.199.23.71 size 1462 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/47/64 ms
CPE#ping 152.199.23.71 size 1463 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)
CPE#ping 152.199.23.71 size 1463 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1463-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)
CPE#ping 152.199.23.71 size 1462 df-bit source dial0
Type escape sequence to abort.
Sending 5, 1462-byte ICMP Echos to 152.199.23.71, timeout is 2 seconds:
Packet sent with a source address of
Packet sent with the DF bit set
.
Success rate is 0 percent (0/5)




De : David Ponzone 
Envoyé : mercredi 8 février 2023 17:08
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et oui, je t’ai prévenu et tu m’as pris à la légère :)

Quand tu fais un ping 1462 vers 8.8.8.8, tu envoies ça dans le payload:

Data (1462 bytes)

Et tu reçois ça en réponse:

Data (68 bytes)

Donc l’ICMP REPLY était bien plus petit que ta limite de MTU LNS->CPE.

Ceci dit, tu sembles avoir un MTU asymétrique et ça mérite de s’y pencher, mais 
bon avec SFR, tu auras difficilement quelqu’un qui tient la route en face pour 
discuter de ça.

Pour 152.199.23.71, tu es sûr de ton coup ?
Je ne vois pas la même asymétrie de l’ICMP REPLY.

Le 8 févr. 2023 à 16:59, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.

Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
localement sur cette DSP !
Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par défaut 
en PPPoE d'où mon interrogation 


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 16:18
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et ça passe à 1462 et pas plus ?
C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier (1995) 
qu’on se prend la tête avec le MTU et les trucs bizarres.
Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
Virtual-Template et dans ton CPE.

Tu as un impact client ou c’était par curiosité ?
Généralement, si les MTU de tes interfaces autorisent des paquets d’une taille 
qui sera droppée par le réseau, tu as/auras un impact client immédiat, puisque 
la fragmentation va faire des paquets trop gros.
D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le problème 
pour ICMP et UDP).

Le 8 févr. 2023 à 11:32, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’es

Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet David Ponzone
Et oui, je t’ai prévenu et tu m’as pris à la légère :)

Quand tu fais un ping 1462 vers 8.8.8.8, tu envoies ça dans le payload:

Data (1462 bytes)

Et tu reçois ça en réponse:

Data (68 bytes)

Donc l’ICMP REPLY était bien plus petit que ta limite de MTU LNS->CPE.

Ceci dit, tu sembles avoir un MTU asymétrique et ça mérite de s’y pencher, mais 
bon avec SFR, tu auras difficilement quelqu’un qui tient la route en face pour 
discuter de ça.

Pour 152.199.23.71, tu es sûr de ton coup ?
Je ne vois pas la même asymétrie de l’ICMP REPLY.

> Le 8 févr. 2023 à 16:59, Sébastien 65  a écrit :
> 
> Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
> 1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.
> 
> Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
> localement sur cette DSP ! 
> Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par défaut 
> en PPPoE d'où mon interrogation 
> 
> De : David Ponzone 
> Envoyé : mercredi 8 février 2023 16:18
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>  
> Et ça passe à 1462 et pas plus ?
> C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier 
> (1995) qu’on se prend la tête avec le MTU et les trucs bizarres.
> Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
> Virtual-Template et dans ton CPE.
> 
> Tu as un impact client ou c’était par curiosité ?
> Généralement, si les MTU de tes interfaces autorisent des paquets d’une 
> taille qui sera droppée par le réseau, tu as/auras un impact client immédiat, 
> puisque la fragmentation va faire des paquets trop gros.
> D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le 
> problème pour ICMP et UDP).
> 
>> Le 8 févr. 2023 à 11:32, Sébastien 65 > <mailto:sebastien...@live.fr>> a écrit :
>> 
>> L'interface Virtual-Access2.X a un MTU de 1464 !
>> 
>> Je suis en directe sur une collecte FTTH SFR Pro (DSP).
>> De : David Ponzone mailto:david.ponz...@gmail.com>>
>> Envoyé : mercredi 8 février 2023 11:24
>> À : Sébastien 65 mailto:sebastien...@live.fr>>
>> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org> 
>> mailto:frnog-t...@frnog.org>>
>> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>>  
>> Cherche la Vi de ton lien (sh users | inc ), et fais un:
>> sh int ViX.Y
>> 
>> Tu vas avoir le MTU de la Vi.
>> 
>> Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es 
>> pas en direct avec SFR.
>> 
>>> Le 8 févr. 2023 à 11:17, Sébastien 65 >> <mailto:sebastien...@live.fr>> a écrit :
>>> 
>>> David,
>>> 
>>> Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 
>>> 
>>> interface Virtual-Template1
>>>  description SFR FTTH
>>>  ip unnumbered Loopback10
>>>  no ip redirects
>>>  no ip proxy-arp
>>>  ip verify unicast source reachable-via rx
>>>  ppp ..
>>> !
>>> 
>>> J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis 
>>> le routeur CPE.
>>> 
>>> Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers 
>>> d'autres destinations.
>>> 
>>> De : David Ponzone >> <mailto:david.ponz...@gmail.com>>
>>> Envoyé : mercredi 8 février 2023 10:26
>>> À : Sébastien 65 mailto:sebastien...@live.fr>>
>>> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org> 
>>> mailto:frnog-t...@frnog.org>>
>>> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>>>  
>>> Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si 
>>> dedans tu as:
>>> mtu 1462
>>> alors c’est normal (c’est le retour qui bloque à 1462).
>>> 
>>> Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
>>> bizarres sur ICMP…
>>> Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu 
>>> as mises dans le Virtual-Template1
>>> 
>>> David
>>> 
>>> > Le 8 févr. 2023 à 09:50, Sébastien 65 >> > <mailto:sebastien...@live.fr>> a écrit :
>>> > 
>>> > Bonjour,
>>> > 
>>> > 
>>> > Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
>>> > L2TP/PPPoE...
>>> > 
>>> > 
>>> > Pour pouvoir surfer "correctement" sur internet je suis obligé de 
>>> > configurer le Dialer du routeur

RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
Le ping size 1462 passe vers 8.8.8.8/152.199.23.71 mais pas vers 
1.1.1.1/208.67.222.222/212.82.100.150, pour eux il faut un size à 1460.

Je ne peux pas dire encore l'impact car il s'agit du premier lien livré 
localement sur cette DSP !
Mais quand je regarde les STAS de SFR il est bien indiqué MTU 1492 par défaut 
en PPPoE d'où mon interrogation 


De : David Ponzone 
Envoyé : mercredi 8 février 2023 16:18
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Et ça passe à 1462 et pas plus ?
C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier (1995) 
qu’on se prend la tête avec le MTU et les trucs bizarres.
Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
Virtual-Template et dans ton CPE.

Tu as un impact client ou c’était par curiosité ?
Généralement, si les MTU de tes interfaces autorisent des paquets d’une taille 
qui sera droppée par le réseau, tu as/auras un impact client immédiat, puisque 
la fragmentation va faire des paquets trop gros.
D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le problème 
pour ICMP et UDP).

Le 8 févr. 2023 à 11:32, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet David Ponzone
Et ça passe à 1462 et pas plus ?
C’est bizarre, mais bon, ça fait depuis que j’ai commencé dans ce métier (1995) 
qu’on se prend la tête avec le MTU et les trucs bizarres.
Déjà si ça coupe à 1462, tu devrais mettre ça comme valeur dans ton 
Virtual-Template et dans ton CPE.

Tu as un impact client ou c’était par curiosité ?
Généralement, si les MTU de tes interfaces autorisent des paquets d’une taille 
qui sera droppée par le réseau, tu as/auras un impact client immédiat, puisque 
la fragmentation va faire des paquets trop gros.
D’où la réduction du MTU, ou l’utilisation du MSS (qui ne règle pas le problème 
pour ICMP et UDP).

> Le 8 févr. 2023 à 11:32, Sébastien 65  a écrit :
> 
> L'interface Virtual-Access2.X a un MTU de 1464 !
> 
> Je suis en directe sur une collecte FTTH SFR Pro (DSP).
> De : David Ponzone mailto:david.ponz...@gmail.com>>
> Envoyé : mercredi 8 février 2023 11:24
> À : Sébastien 65 mailto:sebastien...@live.fr>>
> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>  <mailto:frnog-t...@frnog.org>>
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>  
> Cherche la Vi de ton lien (sh users | inc ), et fais un:
> sh int ViX.Y
> 
> Tu vas avoir le MTU de la Vi.
> 
> Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es 
> pas en direct avec SFR.
> 
>> Le 8 févr. 2023 à 11:17, Sébastien 65 > <mailto:sebastien...@live.fr>> a écrit :
>> 
>> David,
>> 
>> Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 
>> 
>> interface Virtual-Template1
>>  description SFR FTTH
>>  ip unnumbered Loopback10
>>  no ip redirects
>>  no ip proxy-arp
>>  ip verify unicast source reachable-via rx
>>  ppp ..
>> !
>> 
>> J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis 
>> le routeur CPE.
>> 
>> Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers 
>> d'autres destinations.
>> 
>> De : David Ponzone mailto:david.ponz...@gmail.com>>
>> Envoyé : mercredi 8 février 2023 10:26
>> À : Sébastien 65 mailto:sebastien...@live.fr>>
>> Cc : frnog-t...@frnog.org <mailto:frnog-t...@frnog.org> 
>> mailto:frnog-t...@frnog.org>>
>> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>>  
>> Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans 
>> tu as:
>> mtu 1462
>> alors c’est normal (c’est le retour qui bloque à 1462).
>> 
>> Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
>> bizarres sur ICMP…
>> Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
>> mises dans le Virtual-Template1
>> 
>> David
>> 
>> > Le 8 févr. 2023 à 09:50, Sébastien 65 > > <mailto:sebastien...@live.fr>> a écrit :
>> > 
>> > Bonjour,
>> > 
>> > 
>> > Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
>> > L2TP/PPPoE...
>> > 
>> > 
>> > Pour pouvoir surfer "correctement" sur internet je suis obligé de 
>> > configurer le Dialer du routeur client comme ceci :
>> > 
>> > 
>> > interface Dialer0
>> > 
>> > encapsulation ppp
>> > 
>> > mtu 1492
>> > 
>> > ip mtu 1460
>> > 
>> > ip tcp adjust-mss 1420
>> > 
>> > 
>> > Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>> > 
>> > 
>> > Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>> > 
>> > 
>> > ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe 
>> > depuis le routeur.
>> > 
>> > 
>> > Côté LNS j’ai la configuration suivante :
>> > 
>> > 
>> > vpdn-group FTTH-SFR
>> > 
>> > accept-dialin
>> > 
>> >  protocol l2tp
>> > 
>> >  virtual-template 1
>> > 
>> > source-ip X.X.X.X
>> > 
>> > local name LNS-FTTH
>> > 
>> > lcp renegotiation always
>> > 
>> > no l2tp tunnel authentication
>> > 
>> > ip pmtu
>> > 
>> > ip mtu adjust
>> > 
>> > !
>> > 
>> > 
>> > Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>> > 
>> > 
>> > Merci !
>> > 
>> > 
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/ <http://www.frnog.org/>

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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
L'interface Virtual-Access2.X a un MTU de 1464 !

Je suis en directe sur une collecte FTTH SFR Pro (DSP).

De : David Ponzone 
Envoyé : mercredi 8 février 2023 11:24
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

Le 8 févr. 2023 à 11:17, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet David Ponzone
Cherche la Vi de ton lien (sh users | inc ), et fais un:
sh int ViX.Y

Tu vas avoir le MTU de la Vi.

Ca peut aussi venir de SFR ou de ton collecteur puisque je suppos que tu es pas 
en direct avec SFR.

> Le 8 févr. 2023 à 11:17, Sébastien 65  a écrit :
> 
> David,
> 
> Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 
> 
> interface Virtual-Template1
>  description SFR FTTH
>  ip unnumbered Loopback10
>  no ip redirects
>  no ip proxy-arp
>  ip verify unicast source reachable-via rx
>  ppp ..
> !
> 
> J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
> routeur CPE.
> 
> Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
> destinations.
> 
> De : David Ponzone 
> Envoyé : mercredi 8 février 2023 10:26
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH
>  
> Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans 
> tu as:
> mtu 1462
> alors c’est normal (c’est le retour qui bloque à 1462).
> 
> Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
> bizarres sur ICMP…
> Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
> mises dans le Virtual-Template1
> 
> David
> 
> > Le 8 févr. 2023 à 09:50, Sébastien 65  a écrit :
> > 
> > Bonjour,
> > 
> > 
> > Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> > L2TP/PPPoE...
> > 
> > 
> > Pour pouvoir surfer "correctement" sur internet je suis obligé de 
> > configurer le Dialer du routeur client comme ceci :
> > 
> > 
> > interface Dialer0
> > 
> > encapsulation ppp
> > 
> > mtu 1492
> > 
> > ip mtu 1460
> > 
> > ip tcp adjust-mss 1420
> > 
> > 
> > Le Dialer0 est rattaché sur le VLAN d'accès 2900.
> > 
> > 
> > Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
> > 
> > 
> > ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe 
> > depuis le routeur.
> > 
> > 
> > Côté LNS j’ai la configuration suivante :
> > 
> > 
> > vpdn-group FTTH-SFR
> > 
> > accept-dialin
> > 
> >  protocol l2tp
> > 
> >  virtual-template 1
> > 
> > source-ip X.X.X.X
> > 
> > local name LNS-FTTH
> > 
> > lcp renegotiation always
> > 
> > no l2tp tunnel authentication
> > 
> > ip pmtu
> > 
> > ip mtu adjust
> > 
> > !
> > 
> > 
> > Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
> > 
> > 
> > Merci !
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ <http://www.frnog.org/>

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


RE: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
David,

Le Virtual-Template1 ne comporte pas de ip mtu ou adjust-mss 

interface Virtual-Template1
 description SFR FTTH
 ip unnumbered Loopback10
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx
 ppp ..
!

J'ai la même valeur MTU en faisant un ping de l'IP de la Loopback10 depuis le 
routeur CPE.

Je prends note du PING 8.8.8.8. Mais cela me fait la même chose vers d'autres 
destinations.


De : David Ponzone 
Envoyé : mercredi 8 février 2023 10:26
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65  a écrit :
>
> Bonjour,
>
>
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
>
>
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
>
>
> interface Dialer0
>
> encapsulation ppp
>
> mtu 1492
>
> ip mtu 1460
>
> ip tcp adjust-mss 1420
>
>
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
>
>
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
>
>
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
>
>
> Côté LNS j’ai la configuration suivante :
>
>
> vpdn-group FTTH-SFR
>
> accept-dialin
>
>  protocol l2tp
>
>  virtual-template 1
>
> source-ip X.X.X.X
>
> local name LNS-FTTH
>
> lcp renegotiation always
>
> no l2tp tunnel authentication
>
> ip pmtu
>
> ip mtu adjust
>
> !
>
>
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
>
>
> Merci !
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet David Ponzone
Faudrait peut-être montrer ton Virtual-Template 1 aussi, parce que si dedans tu 
as:
mtu 1462
alors c’est normal (c’est le retour qui bloque à 1462).

Conseil: évite de faire tes tests de ping avec 8.8.8.8, ils font des trucs 
bizarres sur ICMP…
Le mieux c’est de pinger l’autre endpoint donc l’IP de l’interface que tu as 
mises dans le Virtual-Template1

David

> Le 8 févr. 2023 à 09:50, Sébastien 65  a écrit :
> 
> Bonjour,
> 
> 
> Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
> L2TP/PPPoE...
> 
> 
> Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer 
> le Dialer du routeur client comme ceci :
> 
> 
> interface Dialer0
> 
> encapsulation ppp
> 
> mtu 1492
> 
> ip mtu 1460
> 
> ip tcp adjust-mss 1420
> 
> 
> Le Dialer0 est rattaché sur le VLAN d'accès 2900.
> 
> 
> Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…
> 
> 
> ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
> le routeur.
> 
> 
> Côté LNS j’ai la configuration suivante :
> 
> 
> vpdn-group FTTH-SFR
> 
> accept-dialin
> 
>  protocol l2tp
> 
>  virtual-template 1
> 
> source-ip X.X.X.X
> 
> local name LNS-FTTH
> 
> lcp renegotiation always
> 
> no l2tp tunnel authentication
> 
> ip pmtu
> 
> ip mtu adjust
> 
> !
> 
> 
> Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?
> 
> 
> Merci !
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


[FRnOG] [TECH] Valeur MTU PPPOE FTTH

2023-02-08 Par sujet Sébastien 65
Bonjour,


Je suis confronté à un problème de MTU sur des FTTH SFR en livraison 
L2TP/PPPoE...


Pour pouvoir surfer "correctement" sur internet je suis obligé de configurer le 
Dialer du routeur client comme ceci :


interface Dialer0

 encapsulation ppp

 mtu 1492

 ip mtu 1460

 ip tcp adjust-mss 1420


Le Dialer0 est rattaché sur le VLAN d'accès 2900.


Je ne comprends pas pourquoi une MTU de 1492 ne passe pas…


ping 8.8.8.8 size 1462 df-bit source Dialer0 => Ping maximum qui passe depuis 
le routeur.


Côté LNS j’ai la configuration suivante :


vpdn-group FTTH-SFR

accept-dialin

  protocol l2tp

  virtual-template 1

 source-ip X.X.X.X

 local name LNS-FTTH

 lcp renegotiation always

 no l2tp tunnel authentication

 ip pmtu

 ip mtu adjust

!


Etes vous dans la même situation que moi ou bien ai-je râté quelque chose ?


Merci !


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