Vous avez pas de MTU 1500 sur vos collectes FTTH PPPoE ? C’est quand même vachement plus pratique :-)
Hugues Hugues Voiturier Consultant en architecture réseau AS2027 > On 21 Jun 2024, at 16:57, David Ponzone <david.ponz...@gmail.com> wrote: > > C’est pareil, collecte L2TP, donc MTU 1460 à priori. > À 1492, ça passe avec DF=1 ? > Ca m’étonnerait. > > David > >> Le 21 juin 2024 à 16:55, Olivier Varenne <o.vare...@ipconnect.fr> a écrit : >> >> Pas de xDSL dans notre cas. Fibre FTTH. >> >> >> >> Cordialement, >> >> >> >> Olivier Varenne >> Président, R&D et développement >> T +33 (0)4 27 04 40 00 | ipconnect.fr >> >> Suivez-nous ! >> >> >>> -----Message d'origine----- >>> De : Xavier ROCA <x.r...@sdi.fr> De la part de x.r...@sipleo.com >>> Envoyé : vendredi 21 juin 2024 15:47 >>> À : Olivier Varenne <o.vare...@ipconnect.fr> >>> Cc : frnog-al...@frnog.org; 'David Ponzone' <david.ponz...@gmail.com> >>> Objet : RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink... >>> >>> Pensez au réglage du MSS >>> Pour un MTU de 1500, MSS à 1460 >>> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne >>> modifier pas automatiquement le MSS >>> >>> -----Message d'origine----- >>> De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de >>> David Ponzone Envoyé : vendredi 21 juin 2024 15:05 À : Olivier >>> Varenne <o.vare...@ipconnect.fr> Cc : ALEGRI Rémy >>> <cont...@uptel.tel>; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] >>> La gestion du MAN chez Alphalink... >>> >>> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait >>> plutôt être 1460. >>> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS >>> SFR foutaient la merde dans la négo du MTU. >>> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le >>> problème. >>> >>> Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492 >>> et DF=1 ? >>> >>> David >>> >>>> Le 21 juin 2024 à 14:56, Olivier Varenne <o.vare...@ipconnect.fr> >>> a écrit : >>>> >>>> 1480 en ppp sur mikrotik oui. >>>> Et oui, nos soucis sont sur SFR... >>>> >>>> >>>> >>>> Cordialement, >>>> >>>> >>>> >>>> Olivier Varenne >>>> Président, R&D et développement >>>> T +33 (0)4 27 04 40 00 | ipconnect.fr >>>> >>>> Suivez-nous ! >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : David Ponzone <david.ponz...@gmail.com> Envoyé : vendredi >>> 21 >>>>> juin 2024 14:47 À : Olivier Varenne <o.vare...@ipconnect.fr> Cc : >>>>> ALEGRI Rémy <cont...@uptel.tel>; frnog-al...@frnog.org Objet : Re: >>>>> [FRnOG] [ALERT] La gestion du MAN chez Alphalink... >>>>> >>>>> 1480 par défaut sur un Mikrotik ? >>>>> Sur une interface PPP alors. >>>>> >>>>> Et ça serait pas SFR le lien ? >>>>> Parce que négo foireuse de MTU automatique, ça sent bon SFR en >>> DSL. >>>>> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la >>>>> main dessus non ?). >>>>> >>>>> David >>>>> >>>>>> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog >>> <frnog@frnog.org> >>>>> a écrit : >>>>>> >>>>>> Salut remy >>>>>> Tu vas bien ? >>>>>> >>>>>> On a des soucis vraiment etranges. >>>>>> En effet certaines fois le MTU est en cause. Alphalink se retranche >>>>>> sur le fait que les STAS indiquent un MTU à 1492. Mais certains >>>>> équipements clients ont parfois des MTU inférieures (1480 souvent, >>> ce >>>>> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive >>>>> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas >>> non. >>>>>> >>>>>> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC >>> indique >>>>> qu’il est vraiment conseillé de passer en TCP en cas de >>>>> fragmentation, mais alphalink refuse catégoriquement l’emploi de >>> TCP. >>>>>> >>>>>> >>>>>> >>>>>> Cordialement, >>>>>> >>>>>> >>>>>> [cid:image001.png@01DAC3E8.8234D360] >>>>>> Olivier Varenne >>>>>> Président, R&D et développement >>>>>> T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/> >>>>>> >>>>>> Suivez-nous ! >>>>>> [picto-twitter]<https://twitter.com/ip_connectweets>[picto- >>>>> youtube]<ht >>>>>> >>>>> >>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto- >>>>> linkedin >>>>>> ]<https://www.linkedin.com/company/20541473/admin/> >>>>>> >>>>>> De : ALEGRI Rémy <cont...@uptel.tel> Envoyé : vendredi 21 juin >>> 2024 >>>>>> 14:22 À : Olivier Varenne <o.vare...@ipconnect.fr> Cc : >>>>>> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du >>> MAN >>>>>> chez Alphalink... >>>>>> >>>>>> >>>>>> Bonjour, >>>>>> >>>>>> D'après mon expertise, certains IPBX, comme des Alcatel, ne >>>>> supportent pas le Header Identity. Cependant, il est plus probable >>>>> que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les >>>>> INVITE d'arriver correctement en UDP. >>>>>> >>>>>> Olivier, je te recommande de tester la MTU du lien sous Linux avec >>>>>> la commande suivante pour une MTU de 1500 >>>>>> >>>>>> ping -M do -s 1472 1.1.1.1 >>>>>> >>>>>> >>>>>> >>>>>> Je confirme qu'Alphalink transmet les INVITE avec le Header >>> Identity : >>>>>> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060 >>> INVITE >>>>>> sip:0xxxxxxxxx@ipbx:5060 SIP/2.0 >>>>>> Via: SIP/2.0/UDP >>> alphalink:5060;branch=z9hG4bKfb2c.e3208024.0 >>>>>> Max-Forwards: 69 >>>>>> From: >>> <sip:0600000000@alphalink2;user=phone>;tag=as4e911d28 >>>>>> To: <sip:0xxxxxxxxx@alphalink;user=phone> >>>>>> Contact: <sip:0600000000@alphalink;did=ee3.876b50f6> >>>>>> Call-ID: 16xxxxxxxxxxxxxxxxxx5643c450f8@alphalink2:5060 >>>>>> CSeq: 102 INVITE >>>>>> P-Early-Media: supported >>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE >>>>>> Supported: timer >>>>>> Identity: >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> xx >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> xx >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> xx >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> xx >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> xx >>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> -g >>>>>> ;info=<https://api.xxxxxxxx.fr/certs/xxxx00/xxxxxxxxxxxxxxxx.cer>;al >>>>>> g= >>>>>> ES256;ppt=shaken >>>>>> Content-Type: application/sdp >>>>>> Content-Length: 403 >>>>>> >>>>>> Par contre, il n'y a pas la classification de l'appel. >>>>>> >>>>>> Bien cordialement, >>>>>> ALEGRI Rémy >>>>>> >>>>>> >>>>>> >>>>>> Le 2024-06-21 13:52, Alain Bieuzent a écrit : >>>>>> Ce voudrais donc dire qu'Alphalink envoit les header Identity aux >>>>>> ipbx >>>>> des clients, ce qui est interdit... >>>>>> >>>>>> Le 21/06/2024 12:45, « Benoît Gigarel » >>>>> <bgiga...@izarralde.com<mailto:bgiga...@izarralde.com> >>>>> <mailto:bgiga...@izarralde.com<mailto:bgiga...@izarralde.com>>> a >>>>> écrit : >>>>>> >>>>>> >>>>>> Bonjour à tous, >>>>>> >>>>>> >>>>>> Çà y est, on y est aussi... Nos clients connectés chez Alphalink >>>>>> nous appellent pour des problèmes d'appels depuis ce matin. >>>>>> >>>>>> >>>>>> Voici la dernière communication de Alphalink à 11h56. >>>>>> >>>>>> >>>>>> Statut de l'incident : >>>>>> Nous avons répertoriés des équipements comportant des >>> anomalies : >>>>>> 1-Les IPBX wazo semblent ne pas gérer correctement les Invites >>>>> fragmentés. >>>>>> 2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les >>>>>> Identity Header de plus de 500 caractères (Développement en >>> cours >>>>> de >>>>>> Mitel pour augmenter cette valeur) 3-PABX PANASONIC NS700 >>>>> Versions >>>>>> impactées : >>>>>> Panasonic-MPR16-V006.01089/VSIPGW-V3.0000 >>>>>> Panasonic-MPR16-V008.00055/VSIPGW-V3.0000 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Cordialement, >>>>>> Benoît >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> >>>>>> <mailto:frnog-requ...@frnog.org<mailto:frnog- >>> requ...@frnog.org>> >>>>>> <frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> >>>>>> <mailto:frnog-requ...@frnog.org<mailto:frnog- >>> requ...@frnog.org>>> >>>>> De >>>>>> la part de Jérôme RICHARD Envoyé : vendredi 21 juin 2024 12:37 >>> À : >>>>>> Alain Bieuzent >>>>>> <alain.bieuz...@free.fr<mailto:alain.bieuz...@free.fr> >>>>>> <mailto:alain.bieuz...@free..fr>> Cc : Olivier Varenne >>>>>> <o.vare...@ipconnect.fr<mailto:o.vare...@ipconnect.fr> >>>>>> >>> <mailto:o.vare...@ipconnect.fr<mailto:o.vare...@ipconnect.fr>>>; >>>>>> frnog-al...@frnog.org<mailto:frnog-al...@frnog.org> >>>>>> <mailto:frnog-al...@frnog.org<mailto:frnog-al...@frnog.org>> >>>>>> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink... >>>>>> >>>>>> >>>>>> Pour l'identity je suis Ok. >>>>>> >>>>>> >>>>>> Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de >>>>>> ne pas le transmettre je trouve. >>>>>> >>>>>> >>>>>> Cordialement, >>>>>> Jérôme RICHARD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Le ven. 21 juin 2024 à 12:03, Alain Bieuzent >>>>>> <alain.bieuz...@free.fr<mailto:alain.bieuz...@free.fr> >>>>> <mailto:alain.bieuz...@free.fr<mailto:alain.bieuz...@free.fr>>> a >>>>> écrit >>>>> : >>>>>> >>>>>> >>>>>> >>>>>> Bonjour Jérôme, >>>>>> >>>>>> L'APNF a clairement précisé qu'il était interdit de transmettre >>>>>> l'entête Identity aux client finaux (cela reste de l'info >>>>>> inter-opérateur) et qu'il était aussi interdit de transmettre le >>>>>> niveau d'attestation (quel que soit la manière utilisée). >>>>>> >>>>>> Alain >>>>>> >>>>>> Le 21/06/2024 11:53, « Jérôme RICHARD » <frnog- >>>>> requ...@frnog.org<mailto:frnog-requ...@frnog.org> <mailto:frnog- >>>>> requ...@frnog.org<mailto:frnog-requ...@frnog.org>> <mailto: >>>>>> frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> >>>>> <mailto:frnog-requ...@frnog.org<mailto:frnog- >>> requ...@frnog.org>>> au >>>>> nom de jerome.rich...@va-telecom.fr<mailto:jerome.richard@va- >>>>> telecom.fr> <mailto:jerome.richard@va- >>>>> telecom.fr<mailto:jerome.rich...@va-telecom.fr>> <mailto: >>>>>> jerome.rich...@va-telecom.fr<mailto:jerome.richard@va- >>> telecom.fr> >>>>> <mailto:jerome.rich...@va-telecom.fr<mailto:jerome.richard@va- >>>>> telecom.fr>>>> a écrit : >>>>>> >>>>>> >>>>>> Bonjour, >>>>>> >>>>>> >>>>>> Le MAN ajoute un entête identity assez conséquent (plus de 500 >>>>> octet) >>>>>> à l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et >>>>>> donc de la fragmentation ce qui n'est pas supporté par tous les >>> IPBX. >>>>>> Le symptôme que j'ai pu constater c'est que l'IPBX destinataire ne >>>>>> répond pas aux INVITE avec entête identity. >>>>>> >>>>>> >>>>>> Nous avons fait le choix de ne pas le diffuser vers les trunks de >>>>>> nos clients puisque nous réalisons le contrôle en amont et de >>>>>> diffuser uniquement le Attestation-Info (A, B ou C) qui en ressort. >>>>>> >>>>>> >>>>>> Donc a voir si les appels qui posent problème ont l'entête identity >>>>>> dans l'INVITE. >>>>>> >>>>>> >>>>>> Cordialement, >>>>>> Jérôme RICHARD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog >>>>>> <frnog@frnog.org<mailto:frnog@frnog.org> >>>>> <mailto:frnog@frnog.org<mailto:frnog@frnog.org>> >>>>> <mailto:frnog@frnog.org<mailto:frnog@frnog.org> >>>>> <mailto:frnog@frnog.org<mailto:frnog@frnog.org>>>> a écrit : >>>>>> >>>>>> >>>>>> >>>>>> On est les seuls à être très, TRES, impacté par la mise en place du >>>>>> man chez alphalink depuis plusieurs jours ? >>>>>> On a du mal à identifier l'origine du problème : dans certains cas >>>>>> cela semble être un problème de MTU et de paquet SIP fragmenté, >>>>>> d'autres cas sont plus obscurs... >>>>>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on >>>>>> est un cas isolé ? >>>>>> Comment souvent : communication proche du 0, au début quand >>> on >>>>> a >>>>>> remonté les soucis on nous a gentiment envoyé balader genre « >>> c'est >>>>>> pas notre probleme », et maintenant ça semble être la panique. >>>>>> >>>>>> >>>>>> >>>>>> Cordialement, >>>>>> >>>>>> >>>>>> >>>>> >>> [cid:image001.png@01DAC3C1.1D673B20<mailto:image001.png@01 >>>>> DAC3C1.1D673 >>>>>> B20>] >>>>>> Olivier Varenne >>>>>> Président, R&D et développement >>>>>> T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/> >>>>>> <http://www.ipconnect.fr/>> < http://www.ipconnect.fr/>> >>>>>> <http://www.ipconnect.fr/&gt;>> >>>>>> >>>>>> Suivez-nous ! >>>>>> [picto-twitter]<https://twitter.com/ip_connectweets> >>>>>> <https://twitter.com/ip_connectweets>> < >>>>>> https://twitter.com/ip_connectweets>> >>>>>> <https://twitter.com/ip_connectweets&gt;>>[picto- >>> youtube]< >>>>>> >>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> >>>>>> >>>>> >>> <https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> >>>>>> < >>>>>> >>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> >>>>>> >>>>> >>> <https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug&a >>>>> mp;gt> >>>>>> ;>[picto-linkedin]< >>>>>> https://www.linkedin.com/company/20541473/admin/> >>>>>> <https://www.linkedin..com/company/20541473/admin/>> < >>>>>> https://www.linkedin.com/company/20541473/admin/>> >>>>>> >>>>> >>> <https://www.linkedin.com/company/20541473/admin/&gt;> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------- >>>>>> Liste de diffusion du FRnOG >>>>>> http://www.frnog.org/ <http://www.frnog.org/> >>>>> <http://www.frnog.org/> >>>>>> <http://www.frnog.org/>> >>>>>> >>>>>> >>>>>> --------------------------- >>>>>> Liste de diffusion du FRnOG >>>>>> http://www.frnog.org/ <http://www.frnog.org/> >>>>> <http://www.frnog.org/> >>>>>> <http://www.frnog.org/>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------- >>>>>> Liste de diffusion du FRnOG >>>>>> http://www.frnog.org/ <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/ >>> >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
