Re: [FRnOG] [ALERT] Attention a vos Krotiks :)

2021-09-09 Par sujet Kevin Thiou
Au delta près des problèmes d'espace disque ...

Le jeu. 9 sept. 2021 à 17:12, David Ponzone  a
écrit :

> Ca a été corrigé en 6.38, un truc comme ça non ?
> Heureusement qu’upgrader un MK, c’est scriptable rapide, et quasiment
> infaillible!
>
> > Le 9 sept. 2021 à 17:07, Hugues Voiturier  a
> écrit :
> >
> > La faille en question date de 2018, un de mes anciens jobs s’est fait
> trouer une partie du parc comme ça, si vous avez MAJ vos routeurs après
> 2018, ça devrait aller :)
> >
> > Hugues Voiturier
> > Consultant en architecture réseau
> > AS57199
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [ALERT] Lambda sipartech down

2021-08-31 Par sujet Kevin Thiou
De mon point de vue, c'est un reboot de netcenter

Le mar. 31 août 2021 à 10:13, Clément Guivy  a
écrit :

> Bonjour, j'ai également des liens de plusieurs opérateurs en région
> parisienne (qui louent probablement des fibres à quelqu'un d'autre) qui
> sont tombés à 9h48.
>
> Le 2021-08-31 10:09, GUILLOT Florent a écrit :
> > Bonjour,
> > Alphalink semble pas en forme depuis environ exactement la même
> > heure...
> >
> > Cdlt
> > Florent
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org  De la part de
> > Kevin Thiou
> > Envoyé : mardi 31 août 2021 10:04
> > À : frnog-alert 
> > Objet : [FRnOG] [ALERT] Lambda sipartech down
> >
> > Bonjour,
> >
> > j'ai un lambda down depuis 9h48 et quand j'appelle le 0800 695 695
> > toutes les lignes sont occupées.
> >
> > Un gros problème chez eux ?
> >
> > ---
> > Liste de diffusion du FRnOG
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7Cfguillot%40fltechno.scc.com%7Cb90113d64d594e96732908d96c55f26a%7Cc69c7e2fa16841088187675b5c936b5a%7C0%7C0%7C637659938658845721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BAmlDKhiCYDyupvTi78kQzGPcktkRLSF%2F%2BI1Y2u4Gws%3Dreserved=0
> > __
> > Ce message contient des informations dont le contenu est susceptible
> > d' etre confidentiel. Il est destine au(x) destinataire(s) indique(s)
> > exclusivement.
> > A moins que vous ne fassiez partie de la liste des destinataires, ou
> > que vous soyez habilite a recevoir le mail a leur place, il vous est
> > interdit de le copier, de l'utiliser ou de devoiler son contenu a un
> > tiers.
> > Si vous avez recu cet email par erreur, merci de prendre contact avec
> > l'emetteur.
> > Les opinions exprimees dans cet e-mail sont celles de l'emetteur et ne
> > refletent pas necessairement celles de l'entreprise.
> > Ce e-mail peut contenir des pieces jointes dont certaines pourraient
> > contenir des virus qui pourraient endommager votre systeme
> > informatique.
> > La compagnie a pris toutes dispositions afin de minimiser ce risque et
> > decline toute responsabilite pour toute perte ou dommage resultant
> > directement ou indirectement de l'utilisation de cet email ou de son
> > contenu.
> > Il vous appartient d'effectuer vos propres controles anti-virus avant
> > d'ouvrir la ou les pieces jointes.
> > __
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

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


[FRnOG] [ALERT] Lambda sipartech down

2021-08-31 Par sujet Kevin Thiou
Bonjour,

j'ai un lambda down depuis 9h48 et quand j'appelle le 0800 695 695 toutes
les lignes sont occupées.

Un gros problème chez eux ?

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


[FRnOG] [TECH] [CISCO] [ASR] et les messages d'erreur incompréhensible

2021-07-13 Par sujet Kevin Thiou
Bonjour,

j'ai un message d'erreur qui apparait sur un de mes routeurs et j'ai du mal
à savoir d'où ça sort :

*SGPM-3-POLICY_RULE_SERVICE_CONFIG_ERROR* Service () is configured
incorrectly, service_failed event will be thrown

Un service ne fonctionne pas correctement à cause d'une configuration
incorrecte.
Comment en savoir plus ? Certains d'entre vous ont-ils déjà vu ce message ?


Merci

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


Re: [FRnOG] [TECH] Re: VRF-Lite process OSPF

2021-07-02 Par sujet Kevin Thiou
Je ne l'ai pas maquetté et je n'ai pas de quoi le maquetter rapidement.
C'est pour cela que j'ai posé la question car j'imaginais que quelqu'un
aurait déjà tenté l'expérience.

Je me suis effectivement dit qu'avec un seul process OSPF il y aurait des
problèmes de route dupliqué avec moulte vrf-lit accrochées.

Merci pour les retours, merci Fabien pour toutes ces bonnes raisons de ne
pas (pouvoir) le faire.

Le ven. 2 juil. 2021 à 00:15, Fabien VINCENT FrNOG via frnog <
frnog@frnog.org> a écrit :

> Ma compréhension de ta question est un peu difficile sans
> contexte/archi. Mais il peut y avoir des réponses simples et ta question
> m'a intrigué (#LaPassion)
>
> Un ID de process OSPF n'a d'existence que local (i.e. tu peux avoir 12 à
> un endroit et 15 à un endroit, ça empêchera pas une adjacence, dans la
> plupart des cas). Tout comme les VRF-LITE d'ailleurs qui ne nécessitent
> pas d'identifiant unique (coucou RD auto/default).
>
> Maintenant si je devais le faire, je séparerai pour respecter le
> raisonnement suivant :
> - Séparation logique "humaine" plus claire, ça évite les erreurs bêtes
> et le "fat-finger".
> - Séparation "logicielle". Si tu dois clear ton process OSPF, tu cleares
> pas toutes tes VRFs, mais un process qui tourne dans une VRF.
> - Séparation OSPF plus explicite. Dans le cas du numéro, ça déclare un
> process logiciel distinct (peut être que c'est virtuel, mais ca se
> constate, cf le "sh proc cpu" ci dessous). Si il y a en qui crashe, tout
> le monde n'est pas embarqué.
>
> R3#sh proc cpu | i OSPF
>   386  10 606 16  0.00%  0.00%  0.00%   0 OSPF-1
> Router
>   513   8 350 22  0.07%  0.00%  0.00%   0 OSPF-1
> Hello
>   544   6 540 11  0.00%  0.00%  0.00%   0 OSPF-2
> Router
>   582   0   1  0  0.00%  0.00%  0.00%   0 OSPF-2
> Hello
>
> Ensuite si on passe à est ce que c'est possible, j'ai été curieux et
> j'ai testé sur IOS-XE 16.12.02 et ça ne semble pas possible de le faire
> de toute façon :
>
> R3(config)# vrf definition vrf1
> R3(config-vrf)# address-family ipv4 unicast
>
> R3(config-vrf-af)#vrf definition vrf2
> R3(config-vrf)#address-family ipv4 unicast
>
> R3(config-vrf-af)#router ospf 1
> R3(config-router)#router-id 1.1.1.1
>
> R3(config)#router ospf 1 vrf vrf1
> %VRF specified does not match existing router
>
> Même si tu essaies de créer une VRF sur le même process sans la VRF par
> défaut:
>
> R3(config-router)#no router ospf 1
>
> R3(config)#router ospf 1 vrf vrf1
> R3(config-router)#router-id 1.1.1.1
> R3(config-router)#exit
>
> R3(config)#router ospf 1 vrf vrf2
> %VRF specified does not match existing router
> R3(config)#
>
> Le process est bien créé sur la vrf vrf1 cependant:
> R3#sh ip ospf  | i ID|VRF
>   Routing Process "ospf 1" with ID 1.1.1.1
> Domain ID type 0x0005, value 0.0.0.1
>   Connected to MPLS VPN Superbackbone, VRF vrf1
>
> Mais il semble qu'il y ait une limitation qui semble liée aux VRF avec
> l'usage de MPLS (cf le domain ID ? encore une découverte grâce à ta
> question ! Je ne m'étais jamais demandé quel était l'usage de ce domain
> ID, donc merci !)
>
> Bref, moi je le ferai pas pour le raisonnement du début, et qui plus est
> cela ne semble pas possible au moins sur un IOS-XE "récent".
>
> Curieux de savoir sur quoi ça fonctionne si tu l'as maquetté et ce qui
> t’amènerai à choisir cette solution.
>
> @+
>
> Le 01-07-2021 12:00, Kevin Thiou a écrit :
> > Pour clarifier,
> >
> > quel avantage y a t il a créé un process ospf indépendant :
> > *router ospf 1*
> > *router ospf 2 vrf xyz*
> >
> > plutôt que juste une instance ospf rattachée à la vrf mais dans le même
> > process :
> > *router ospf 1*
> > *router ospf 1 vrf xyz*
> >
> > Le jeu. 1 juil. 2021 à 11:54, Kevin Thiou  a
> > écrit :
> >
> >> Bonjour,
> >>
> >> Est-il nécessaire dans un environnement multi-VRF-Lite (pas de couche
> >> MPLS) de dissocier les process OSPF pour chaque VRF sur les PE ?
> >>
> >> Si oui pour quelle raison ?
> >>
> >> Merci
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> --
> Fabien VINCENT
> _@beufanet_
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [TECH] Re: VRF-Lite process OSPF

2021-07-01 Par sujet Kevin Thiou
Pour clarifier,

quel avantage y a t il a créé un process ospf indépendant :
*router ospf 1*
*router ospf 2 vrf xyz*

plutôt que juste une instance ospf rattachée à la vrf mais dans le même
process :
*router ospf 1*
*router ospf 1 vrf xyz*

Le jeu. 1 juil. 2021 à 11:54, Kevin Thiou  a écrit :

> Bonjour,
>
> Est-il nécessaire dans un environnement multi-VRF-Lite (pas de couche
> MPLS) de dissocier les process OSPF pour chaque VRF sur les PE ?
>
> Si oui pour quelle raison ?
>
> Merci
>

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


[FRnOG] [TECH] VRF-Lite process OSPF

2021-07-01 Par sujet Kevin Thiou
Bonjour,

Est-il nécessaire dans un environnement multi-VRF-Lite (pas de couche MPLS)
de dissocier les process OSPF pour chaque VRF sur les PE ?

Si oui pour quelle raison ?

Merci

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


Re: [FRnOG] [ALERT] Incident Collecte Kosc FTTH

2021-05-27 Par sujet Kevin Thiou
C'est pas revenu à 16h00 ...

Corrage Kosc !

Le jeu. 27 mai 2021 à 17:15, Kamel Moudachirou  a
écrit :

> Services : XDSL
> Type : Interruption de service
> Description : L'incident est localisé sur les équipements de notre
> opérateur de collecte et entraîne une perte de synchronisation . Les
> équipes sont actuellement mobilisées afin de rétablir les services dans les
> meilleurs délais. Une date de rétablissement est estimée au 27/05/2021 à
> 16h00.
>
> Message OVH
>
> 
> De : frnog-requ...@frnog.org  de la part de
> Romain 
> Envoyé : jeudi 27 mai 2021 16:17:54
> À : David Ponzone
> Cc : frnog-alert
> Objet : Re: [FRnOG] [ALERT] Incident Collecte Kosc FTTH
>
> En tout cas ça discute sur la ML adsl d'OVH.
>
> Le jeu. 27 mai 2021 à 16:12, David Ponzone  a
> écrit :
>
> > Un gros incident depuis 16h01 à priori sur la collecte FTTH Kosc.
> >
> > Qqun confirme ?
> >
> >
> > ---
> > 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] Broadband Access Aggregation and DSL Configuration

2021-05-11 Par sujet Kevin Thiou
Merci

Le mar. 11 mai 2021 à 10:31, Fabien H  a écrit :

> Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant.
> C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
> selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de
> fragmentation.
>
> Sachant que la plupart du temps c'est le trafic descendant qui a le débit
> le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le
> sens descendant (le LNS oui mais il est surement dimensionné)
>
>
>
> Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a écrit :
>
> > Pour changer toujours dans le dépatouillage :)
> >
> > J'ai des comportements étranges.
> >
> > Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
> > semblent fonctionner.
> >
> > Pour certains j'ai des problèmes de débit.
> >
> > Je me pose la question de la puissance du CPE, car dans beaucoup de cas
> il
> > y a un RB2011.
> > Je ne demande pas une solution mais juste une validation de ma réflexion.
> >
> > La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
> > client sur le CPE a une MTU de 1500.
> > La session pppoe se retrouve avec une MTU à 1460. L'interface de
> > terminaison sur le cisco est aussi à 1460.
> >
> > Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
> > sur le CPE ?
> > Et par conséquent si le CPE est un peu juste niveau CPU le débit
> s'écroule.
> >
> > Merci de vos lumières
> >
> >
> > Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :
> >
> >> Je me posais justement la question des calculs théoriques.
> >>
> >> j'ai trouvé ca comme article :
> >>
> >>
> >>
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
> >>
> >>
> >> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
> >> écrit :
> >>
> >>> J’ai pas osé te le suggérer :)
> >>> Le 2011, il commence à dater.
> >>> CHR dans une VM c’est pas mal pour les tests de BW.
> >>>
> >>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> >>> significative de bande passante (pas 70% en tout cas).
> >>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
> >>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as
> juste à
> >>> attendre.
> >>>
> >>>
> >>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
> >>>
> >>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
> >>> galère à envoyer plus ...
> >>>
> >>> Donc avec un serveur de test public mikrotik on atteint des valeurs
> bien
> >>> meilleurs.
> >>>
> >>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a
> écrit :
> >>>
> >>>> j'ai le même modèle.
> >>>>
> >>>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE
> et
> >>>> faire des tests croisés.
> >>>>
> >>>> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
> >>>> écrit :
> >>>>
> >>>>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> >>>>> PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> >>>>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
> >>>>>
> >>>>> Donc je pense que ton problème est ailleurs.
> >>>>> Ou alors tu te méfies pas assez du CPU de ton MK.
> >>>>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> >>>>> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP
> (en tout
> >>>>> cas, qui limite le bandwidth-test).
> >>>>>
> >>>>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit
> :
> >>>>> >
> >>>>> > Je ne vais pas rentrer dans le c'est la faute à truc.
> >>>>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> >>>>> >
> >>>>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> >>>>> perte de débit en tcp par rapport à l'udp par exemple.
> >>>>> >
> >>>>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> >>>>> trouve acceptable.
> >>>>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> >>>>> >
> >>>>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> >>>>> annoncée.
> >>>>> >
> >>>>>
> >>>>>
> >>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-05-11 Par sujet Kevin Thiou
Pour changer toujours dans le dépatouillage :)

J'ai des comportements étranges.

Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
semblent fonctionner.

Pour certains j'ai des problèmes de débit.

Je me pose la question de la puissance du CPE, car dans beaucoup de cas il
y a un RB2011.
Je ne demande pas une solution mais juste une validation de ma réflexion.

La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
client sur le CPE a une MTU de 1500.
La session pppoe se retrouve avec une MTU à 1460. L'interface de
terminaison sur le cisco est aussi à 1460.

Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
sur le CPE ?
Et par conséquent si le CPE est un peu juste niveau CPU le débit s'écroule.

Merci de vos lumières


Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :

> Je me posais justement la question des calculs théoriques.
>
> j'ai trouvé ca comme article :
>
>
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
>
>
> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
> écrit :
>
>> J’ai pas osé te le suggérer :)
>> Le 2011, il commence à dater.
>> CHR dans une VM c’est pas mal pour les tests de BW.
>>
>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
>> significative de bande passante (pas 70% en tout cas).
>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
>> attendre.
>>
>>
>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>>
>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
>> galère à envoyer plus ...
>>
>> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
>> meilleurs.
>>
>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>>
>>> j'ai le même modèle.
>>>
>>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
>>> faire des tests croisés.
>>>
>>> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
>>> écrit :
>>>
>>>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
>>>> PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
>>>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>>>>
>>>> Donc je pense que ton problème est ailleurs.
>>>> Ou alors tu te méfies pas assez du CPU de ton MK.
>>>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
>>>> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
>>>> cas, qui limite le bandwidth-test).
>>>>
>>>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>>>> >
>>>> > Je ne vais pas rentrer dans le c'est la faute à truc.
>>>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
>>>> >
>>>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
>>>> perte de débit en tcp par rapport à l'udp par exemple.
>>>> >
>>>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
>>>> trouve acceptable.
>>>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>>> >
>>>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>>>> annoncée.
>>>> >
>>>>
>>>>
>>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
Je me posais justement la question des calculs théoriques.

j'ai trouvé ca comme article :

https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/


Le mar. 4 mai 2021 à 23:10, David Ponzone  a
écrit :

> J’ai pas osé te le suggérer :)
> Le 2011, il commence à dater.
> CHR dans une VM c’est pas mal pour les tests de BW.
>
> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> significative de bande passante (pas 70% en tout cas).
> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
> attendre.
>
>
> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>
> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
> galère à envoyer plus ...
>
> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
> meilleurs.
>
> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>
>> j'ai le même modèle.
>>
>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
>> faire des tests croisés.
>>
>> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
>> écrit :
>>
>>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
>>> (c’est le CPU du MK qui limite à 470 à priori).
>>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>>>
>>> Donc je pense que ton problème est ailleurs.
>>> Ou alors tu te méfies pas assez du CPU de ton MK.
>>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
>>> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
>>> cas, qui limite le bandwidth-test).
>>>
>>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>>> >
>>> > Je ne vais pas rentrer dans le c'est la faute à truc.
>>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
>>> >
>>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
>>> perte de débit en tcp par rapport à l'udp par exemple.
>>> >
>>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
>>> trouve acceptable.
>>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>> >
>>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>>> annoncée.
>>> >
>>>
>>>
>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
galère à envoyer plus ...

Donc avec un serveur de test public mikrotik on atteint des valeurs bien
meilleurs.

Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :

> j'ai le même modèle.
>
> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
> faire des tests croisés.
>
> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
> écrit :
>
>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
>> (c’est le CPU du MK qui limite à 470 à priori).
>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>>
>> Donc je pense que ton problème est ailleurs.
>> Ou alors tu te méfies pas assez du CPU de ton MK.
>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant
>> que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui
>> limite le bandwidth-test).
>>
>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>> >
>> > Je ne vais pas rentrer dans le c'est la faute à truc.
>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
>> >
>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
>> perte de débit en tcp par rapport à l'udp par exemple.
>> >
>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>> >
>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>> >
>>
>>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
j'ai le même modèle.

Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
faire des tests croisés.

Le mar. 4 mai 2021 à 22:53, David Ponzone  a
écrit :

> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
> (c’est le CPU du MK qui limite à 470 à priori).
> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>
> Donc je pense que ton problème est ailleurs.
> Ou alors tu te méfies pas assez du CPU de ton MK.
> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant
> que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui
> limite le bandwidth-test).
>
> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
> >
> > Je ne vais pas rentrer dans le c'est la faute à truc.
> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> >
> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> perte de débit en tcp par rapport à l'udp par exemple.
> >
> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> trouve acceptable.
> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> >
> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
> >
>
>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
J'ai une VT par porte de collecte, ce qui me permet d'être très granulaire
dans les configurations.

Le mar. 4 mai 2021 à 22:49, Fabien H  a écrit :

> Sinon utilise des VT différents avec des MTU différents selon les
> interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?
>
> Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>
>> Je ne vais pas rentrer dans le c'est la faute à truc.
>> Pour le moment, celui qui m'occupe ne commence pas par un S.
>>
>> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
>> de débit en tcp par rapport à l'udp par exemple.
>>
>> J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>
>> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>>
>> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
>> écrit :
>>
>>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>>> un ping clean à 2000 ?
>>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence
>>> par S et finit par R ?
>>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>>> nom…)
>>>
>>> Tu as donc un Arista entre le Cisco et SFR ?
>>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>>> Cisco, le ping est ok à 2000 ?
>>> Je vois que ça comme manière de procéder.
>>>
>>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>>> SFR aient fait de la merde de leur côté.
>>>
>>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>>> >
>>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>>> collectes.
>>> >
>>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000
>>> df-bit et
>>> > que cela fonctionne.
>>> >
>>> > C'est d'ailleurs écrit dans leur STAS.
>>> >
>>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit
>>> :
>>> >
>>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>>> >> bien mis :
>>> >>
>>> >> mtu 1460
>>> >> ip tcp adjust-mss 1420
>>> >>
>>> >> ?
>>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>>> >>
>>> >>
>>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>>> écrit :
>>> >>
>>> >>> Je relance le sujet.
>>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>>> tu en
>>> >>> voilà.
>>> >>>
>>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>>> LAC
>>> >>> du
>>> >>> provider et mon LNS soit a 2000 minimum.
>>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>>> termine
>>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>>> >>> Le ping  df-bit size 2000 ne passe pas.
>>> >>>
>>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>>> preneur.
>>> >>>
>>> >>> Merci
>>> >>>
>>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>>> >>>
>>> >>>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>>> >>>>> L2 et L3 sur le même port.
>>> >>>>>
>>> >>>>> Le paquet qui passe c'est 1460.
>>> >>>>
>>> >>>> ip tcp adjust-mss 1420 ?
>>> >>>>
>>> >>>> 1420 = 1460 - 40 (IP + TCP headers)
>>> >>>>
>>> >>>>
>>> >>>> ---
>>> >>>> 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] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
Je ne vais pas rentrer dans le c'est la faute à truc.
Pour le moment, celui qui m'occupe ne commence pas par un S.

Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
de débit en tcp par rapport à l'udp par exemple.

J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve
acceptable.
En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.

Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
annoncée.

Le mar. 4 mai 2021 à 22:33, David Ponzone  a
écrit :

> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
> un ping clean à 2000 ?
> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence par
> S et finit par R ?
> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme nom…)
>
> Tu as donc un Arista entre le Cisco et SFR ?
> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
> Cisco, le ping est ok à 2000 ?
> Je vois que ça comme manière de procéder.
>
> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que SFR
> aient fait de la merde de leur côté.
>
> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
> >
> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
> collectes.
> >
> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit
> et
> > que cela fonctionne.
> >
> > C'est d'ailleurs écrit dans leur STAS.
> >
> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :
> >
> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
> >> bien mis :
> >>
> >> mtu 1460
> >> ip tcp adjust-mss 1420
> >>
> >> ?
> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
> >>
> >>
> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit
> :
> >>
> >>> Je relance le sujet.
> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
> tu en
> >>> voilà.
> >>>
> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
> LAC
> >>> du
> >>> provider et mon LNS soit a 2000 minimum.
> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
> termine
> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> >>> Le ping  df-bit size 2000 ne passe pas.
> >>>
> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
> preneur.
> >>>
> >>> Merci
> >>>
> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> >>> fr...@radu-adrian.feurdean.net> a écrit :
> >>>
> >>>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> >>>>> L2 et L3 sur le même port.
> >>>>>
> >>>>> Le paquet qui passe c'est 1460.
> >>>>
> >>>> ip tcp adjust-mss 1420 ?
> >>>>
> >>>> 1420 = 1460 - 40 (IP + TCP headers)
> >>>>
> >>>>
> >>>> ---
> >>>> 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] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
Je suis d'accord que la mtu sur la loopback est inutile.
Sur les interface 10G j'ai 9214 en MTU donc je suis large.
Sur l'interface de collecte qui est en 1G j'ai aussi 9214

Ethernet5 is up, line protocol is up (connected)
 Hardware is Ethernet, address is 444c.a830.ba00 (bia 444c.a830.ba00)
 Ethernet MTU 9214 bytes , BW 100 kbit
 Full-duplex, 1Gb/s, auto negotiation: on, uni-link: disabled

Mais lorsque je fais des tests de ping, je m'arrête à 1500.
Donc je suppose que les STAS ne sont pas forcément respectées chez eux ce
qui est un peu pénible.

Le mar. 4 mai 2021 à 22:22, David Ponzone  a
écrit :

> Je doute que le MTU de la Loopback serve à qqchose.
>
> Et le MTU sur le port TenG, il est bien à 2000 ?
> Si tu as une IP directement en face (parce que tu as peut-être pas
> vraiment 2000 de MTU jusqu’au LAC), tu devrais pouvoir la pinger avec 2000
> et DF.
> Sinon, réduis la taille pour trouver à combien ça bloque (déjà, est-ce que
> tu dépasses 1500 ?).
>
> > Le 4 mai 2021 à 22:11, Kevin Thiou  a écrit :
> >
> > Je relance le sujet.
> > Toujours en galère avec certains accès, des problèmes de MTU en veux tu
> en
> > voilà.
> >
> > Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC
> du
> > provider et mon LNS soit a 2000 minimum.
> > J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> > les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> > Le ping  df-bit size 2000 ne passe pas.
> >
> > Si quelqu'un a fait marcher une conf similaire sur un asr je suis
> preneur.
> >
> > Merci
> >
> > Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> > fr...@radu-adrian.feurdean.net> a écrit :
> >
> >> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> >>> L2 et L3 sur le même port.
> >>>
> >>> Le paquet qui passe c'est 1460.
> >>
> >> ip tcp adjust-mss 1420 ?
> >>
> >> 1420 = 1460 - 40 (IP + TCP headers)
> >>
> >>
> >> ---
> >> 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] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
je l'ai fait sur certains accès.Et ça fonctionne pour certaines collectes.

Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit et
que cela fonctionne.

C'est d'ailleurs écrit dans leur STAS.

Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :

> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
> bien mis :
>
>  mtu 1460
>  ip tcp adjust-mss 1420
>
> ?
> A priori c'est le seul endroit où il faut jouer sur le MTU.
>
>
> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :
>
>> Je relance le sujet.
>> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
>> voilà.
>>
>> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC
>> du
>> provider et mon LNS soit a 2000 minimum.
>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>> Le ping  df-bit size 2000 ne passe pas.
>>
>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>>
>> Merci
>>
>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>> fr...@radu-adrian.feurdean.net> a écrit :
>>
>> > On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>> > > L2 et L3 sur le même port.
>> > >
>> > > Le paquet qui passe c'est 1460.
>> >
>> > ip tcp adjust-mss 1420 ?
>> >
>> > 1420 = 1460 - 40 (IP + TCP headers)
>> >
>> >
>> > ---
>> > 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] Broadband Access Aggregation and DSL Configuration

2021-05-04 Par sujet Kevin Thiou
Je relance le sujet.
Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
voilà.

Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
provider et mon LNS soit a 2000 minimum.
J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
les tunnels L2TP mais ça n'a pas l'air de fonctionner.
Le ping  df-bit size 2000 ne passe pas.

Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.

Merci

Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> > L2 et L3 sur le même port.
> >
> > Le paquet qui passe c'est 1460.
>
> ip tcp adjust-mss 1420 ?
>
> 1420 = 1460 - 40 (IP + TCP headers)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
Je ne crie pas victoire mais c'est mieux.

Les ping de toutes tailles passent, la session ssh sur le cpe de test monte
alors qu'elle ne fonctionnait pas avant.

Pour aider les prochains voila des commande de debug utiles :
L2TP:
 L2TP packet errors debugging is on
 L2TP errors debugging is on
 L2TP events debugging is on
PPP:
 PPP authentication debugging is on
 PPP protocol negotiation debugging is on
VPN:
 VPDN events debugging is on
 VPDN errors debugging is on
 VPDN packet debugging is on

J'ai ajouté à la conf du vpdn :
lcp renegotiation on-mismatch

Et précisé la mtu sur l'interface virtual-template :
interface Virtual-Template5
mtu 1460
ip unnumbered Loopback5
no peer default ip address
ppp mtu adaptive
ppp authentication pap chap

Ressource intéressante qui m'a bien aidé :
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/vpdn/configuration/xe-3s/vpd-xe-3s-book/vpd-cfg-additional-feat.html#GUID-CD96BA0D-BC86-4FD7-B89C-602CFA4272B9

Je vous dirais si ça règle mon problème avec tous les types de collecte et
tous les cpe.


Le mer. 24 mars 2021 à 17:02, Kevin Thiou  a écrit :

> Actuellement, j'ai une dizaine de portes certaines en 10G d'autres en 1G.
> Tout ce petit monde arrive sur un Arista.
> Toutes mes sessions connectées sur le un Redback.
>
> J'essaie de changer ce redback par l'ASR.
> Première différence entre Redback et ASR, la connexion physique.
> Le Redback est connecté avec des lag de port 1G
> Le Cisco est connecté avec des ports 10G.
>
> J'ai précisé la MTU à 9214 sur les ports du cisco, de base elle est à 9214
> sur les arista.
> Un "ping ip 172.16.70.76 size 9214 df-bit" entre les ip sur le arista et
> sur le cisco fonctionne jusqu'à 9214 comme attendu.
>
> Je pars donc du principe que la connexion entre arista et cisco supporte
> des paquets de 9214.
>
> J'ai regardé la différence entre ppp mtu adaptative et sans.
>
> Sans mtu adaptative
> Mar 24 14:29:43.432 CET: PPP: Alloc Context [7F252B08EB48]
> Mar 24 14:29:43.432 CET: ppp2358 PPP: Phase is ESTABLISHING
> Mar 24 14:29:43.432 CET: ppp2358 LCP: Event[Jam Start] State[Initial to
> Closed]
> Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED rcvd CONFACK len 19
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1492 (0x010405D4)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:AuthProto CHAP (0x0305C22305)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x2FDDBE11
> (0x05062FDDBE11)
> Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED sent CONFACK len 14
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1480 (0x010405C8)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x042877CC
> (0x0506042877CC)
> *Mar 24 14:29:43.433 CET: ppp2358 PPP: LCP not accepting sent CONFACK*
> Mar 24 14:29:43.433 CET: ppp2358 LCP: O TERMREQ [Closed] id 1 len 4
> Mar 24 14:29:43.433 CET: ppp2358 PPP DISC: LCP Jam options rejected
> Mar 24 14:29:43.433 CET: ppp2358 PPP: Sending Acct Event[Down] id[2F127]
> Mar 24 14:29:43.433 CET: PPP: NET STOP send to AAA.
> Mar 24 14:29:43.433 CET: ppp2358 LCP: Event[DOWN] State[Closed to Initial]
> Mar 24 14:29:43.433 CET: ppp2358 PPP: Phase is DOWN
>
> avec ppp mtu adaptative
> Mar 24 16:04:55.231 CET: ppp3423 PPP: Phase is ESTABLISHING
> Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam Start] State[Initial to
> Closed]
> Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED rcvd CONFACK len 19
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1492 (0x010405D4)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:AuthProto CHAP (0x0305C22305)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x2FDF19D5
> (0x05062FDF19D5)
> Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED sent CONFACK len 14
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1480 (0x010405C8)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x496149B5
> (0x0506496149B5)
> Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam UP] State[Closed to Open]
> Mar 24 16:04:55.252 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
> Forward
> Mar 24 16:04:55.252 CET: ppp3423 LCP: State is Open
> Mar 24 16:04:55.253 CET: ppp3423 PPP: Phase is AUTHENTICATING,
> Unauthenticated User
> Mar 24 16:04:55.253 CET: ppp3423 PPP: Sent CHAP LOGIN Request
> Mar 24 16:04:55.292 CET: ppp3423 PPP: Received LOGIN Response PASS
> Mar 24 16:04:55.292 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
> Forward
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   App type set to VPDN
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default
> tx disabled
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default
> rx disabled
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Framing set to sync
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Bearer set to none
> Mar 24 16:04:55.298 CET: VPDN Received L2TUN socket message Data UP
> Mar 2

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
Actuellement, j'ai une dizaine de portes certaines en 10G d'autres en 1G.
Tout ce petit monde arrive sur un Arista.
Toutes mes sessions connectées sur le un Redback.

J'essaie de changer ce redback par l'ASR.
Première différence entre Redback et ASR, la connexion physique.
Le Redback est connecté avec des lag de port 1G
Le Cisco est connecté avec des ports 10G.

J'ai précisé la MTU à 9214 sur les ports du cisco, de base elle est à 9214
sur les arista.
Un "ping ip 172.16.70.76 size 9214 df-bit" entre les ip sur le arista et
sur le cisco fonctionne jusqu'à 9214 comme attendu.

Je pars donc du principe que la connexion entre arista et cisco supporte
des paquets de 9214.

J'ai regardé la différence entre ppp mtu adaptative et sans.

Sans mtu adaptative
Mar 24 14:29:43.432 CET: PPP: Alloc Context [7F252B08EB48]
Mar 24 14:29:43.432 CET: ppp2358 PPP: Phase is ESTABLISHING
Mar 24 14:29:43.432 CET: ppp2358 LCP: Event[Jam Start] State[Initial to
Closed]
Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED rcvd CONFACK len 19
Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1492 (0x010405D4)
Mar 24 14:29:43.432 CET: ppp2358 LCP:AuthProto CHAP (0x0305C22305)
Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x2FDDBE11
(0x05062FDDBE11)
Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED sent CONFACK len 14
Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1480 (0x010405C8)
Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x042877CC
(0x0506042877CC)
*Mar 24 14:29:43.433 CET: ppp2358 PPP: LCP not accepting sent CONFACK*
Mar 24 14:29:43.433 CET: ppp2358 LCP: O TERMREQ [Closed] id 1 len 4
Mar 24 14:29:43.433 CET: ppp2358 PPP DISC: LCP Jam options rejected
Mar 24 14:29:43.433 CET: ppp2358 PPP: Sending Acct Event[Down] id[2F127]
Mar 24 14:29:43.433 CET: PPP: NET STOP send to AAA.
Mar 24 14:29:43.433 CET: ppp2358 LCP: Event[DOWN] State[Closed to Initial]
Mar 24 14:29:43.433 CET: ppp2358 PPP: Phase is DOWN

avec ppp mtu adaptative
Mar 24 16:04:55.231 CET: ppp3423 PPP: Phase is ESTABLISHING
Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam Start] State[Initial to
Closed]
Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED rcvd CONFACK len 19
Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1492 (0x010405D4)
Mar 24 16:04:55.231 CET: ppp3423 LCP:AuthProto CHAP (0x0305C22305)
Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x2FDF19D5
(0x05062FDF19D5)
Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED sent CONFACK len 14
Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1480 (0x010405C8)
Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x496149B5
(0x0506496149B5)
Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam UP] State[Closed to Open]
Mar 24 16:04:55.252 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
Forward
Mar 24 16:04:55.252 CET: ppp3423 LCP: State is Open
Mar 24 16:04:55.253 CET: ppp3423 PPP: Phase is AUTHENTICATING,
Unauthenticated User
Mar 24 16:04:55.253 CET: ppp3423 PPP: Sent CHAP LOGIN Request
Mar 24 16:04:55.292 CET: ppp3423 PPP: Received LOGIN Response PASS
Mar 24 16:04:55.292 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
Forward
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   App type set to VPDN
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default tx
disabled
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default rx
disabled
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Framing set to sync
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Bearer set to none
Mar 24 16:04:55.298 CET: VPDN Received L2TUN socket message Data UP
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn ev DP-Up
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Snin established
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn do Ignore-DP-UP
Mar 24 16:04:55.299 CET: Vi3.22 PPP: Phase is AUTHENTICATING, Authenticated
User
Mar 24 16:04:55.299 CET: Vi3.22 CHAP: O SUCCESS id 1 len 4
Mar 24 16:04:55.299 CET: L2TP:Vi3.22 FS Network to tunnel: Punted 44 byte
pak to l2x process queue
*Mar 24 16:04:55.299 CET: Vi3.22 PPP: Reducing MTU to peer's MRU*
Mar 24 16:04:55.299 CET: Vi3.22 PPP: Phase is UP

On voit la différence de traitement. mais ça ne m'explique pas pourquoi le
trafic "normal" ne fonctionne pas.
J'ai l'impression qu'un "do-not-fragment" apparaît avec ou sans ppp mtu
adaptative. Car seuls les paquets non fragmentés passent.

Le mer. 24 mars 2021 à 16:00, David Ponzone  a
écrit :

> Hmm t’as pas compris ma question je crois :)
> Ca devrait être 1500 sur une interface 10G.
> Je te parle vraiment du port 10G.
> Quand tu montes une collecte, tu commences généralement par vérifier que
> le MTU est ok.
> Bon en général, tu le fais pas, parce qu’entre professionnels, ça se passe
> plutôt bien.
> Eventuellement tu le fais si tu veux monter à plus de 1500 en accord avec
> l’autre côté.
> Mais là tu as un comportement anormal qui pourrait s’expliquer par un mtu
> foireux sur le port 10G.
>
> Le 24 mars 2021 

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
L2 et L3 sur le même port.

Le paquet qui passe c'est 1460.

Le mer. 24 mars 2021 à 15:53, David Ponzone  a
écrit :

> On parle de collecte L2 et L3 qui arrivent sur des ports différents ou
> toutes sur le même ?
>
> Si ports différents -> je comprends pas
> Si même port -> tu as vérifié le MTU du port lui-même (vérifier, c’est
> chercher le plus paquet qui passe à coup de ping, pas faire confiance à ce
> que te dit le mec en face….) ?
>
> > Le 24 mars 2021 à 15:47, Kevin Thiou  a écrit :
> >
> > Autre précision, mon parc est constitué de mirkrotik et de modem type
> > technicolor.
> > Je ne pourrais pas changer la configuration du parc, il est trop grand.
> > Donc je suis cantonné à trouver une solution sur l'ASR.
>
>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
Autre précision, mon parc est constitué de mirkrotik et de modem type
technicolor.
Je ne pourrais pas changer la configuration du parc, il est trop grand.
Donc je suis cantonné à trouver une solution sur l'ASR.

Le mer. 24 mars 2021 à 15:38, Kevin Thiou  a écrit :

> Merci pour les réponses.
>
> Précision, j'ai de tout, adsl, sdsl, ftth.
> J'ai eu le problème sur toutes les collectes, ethernet ou ip
>
> Par contre je fais tourner des sessions L2tp qui passe par de la 4G sans
> problème depuis quelques semaines.
>
> Le mer. 24 mars 2021 à 15:25, David Ponzone  a
> écrit :
>
>> C’est de l’ADSL ?
>> T’as essayé en virant le mtu adaptative (j’ai jamais eu trop de réussite
>> avec ce truc) et en forçant un MTU 1460 partout ?
>> Parce que sur de l’ADSL en livraison L2TP, c’est plutôt 1460 le max.
>>
>> > Le 24 mars 2021 à 14:59, Kevin Thiou  a écrit :
>> >
>> > Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
>> > max-mru:auto
>> > une fois la session montée tout ce petit monde est d'accord sur 1480
>> octets.
>> >
>> > Toutes les idées de debug ou de configuration sont les bien venues.
>> >
>>
>>

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


Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
Merci pour les réponses.

Précision, j'ai de tout, adsl, sdsl, ftth.
J'ai eu le problème sur toutes les collectes, ethernet ou ip

Par contre je fais tourner des sessions L2tp qui passe par de la 4G sans
problème depuis quelques semaines.

Le mer. 24 mars 2021 à 15:25, David Ponzone  a
écrit :

> C’est de l’ADSL ?
> T’as essayé en virant le mtu adaptative (j’ai jamais eu trop de réussite
> avec ce truc) et en forçant un MTU 1460 partout ?
> Parce que sur de l’ADSL en livraison L2TP, c’est plutôt 1460 le max.
>
> > Le 24 mars 2021 à 14:59, Kevin Thiou  a écrit :
> >
> > Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
> > max-mru:auto
> > une fois la session montée tout ce petit monde est d'accord sur 1480
> octets.
> >
> > Toutes les idées de debug ou de configuration sont les bien venues.
> >
>
>

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


[FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

2021-03-24 Par sujet Kevin Thiou
Bonjour,

je pensais être arrivé au bout de ma migration Redback > ASR, mais non.

Toutes les sessions clientes étaient remontées. Tout avait l'air au top.
Ça pingait dans tous les sens, même dans les VRF.


Mais il n'en était rien. 7h appel téléphonique :
X : "je crois qu'on a un problème, y a plus le net là"
Moi : "mais si toutes les sessions sont montées"
X : "Non, bon j'arrive à prendre la main sur un pc derrière le CPE avec
RDP, mais sur ce pc y a pas le net"
Moi : "si tu fais du RDP c'et qu'il y a le net"
X : "J'aurais dis pareil mais la pluspart des sites ne marchent pas"
Moi : "Je prends juste 30 minutes pour essayer de comprendre, si ca marche
pas, je rollback"

Un rollback plus tard ...

Quelqu'un aurait il une idée de pourquoi les paquets de plus de 1433 octets
ne passent pas.

Coté ASR :
conf
interface Virtual-Template5
ip unnumbered Loopback5
no peer default ip address
ppp mtu adaptive
ppp authentication pap chap

Interface :
Virtual-Access3.78 is up, line protocol is up
 Hardware is Virtual Access interface
 Interface is unnumbered. Using address of Loopback5 (46.21.128.24)
 MTU 1480 bytes, BW 4294967 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, LCP Open
 Open: IPCP
 PPPoVPDN vaccess, cloned from Virtual-Template5
 Vaccess status 0x0
 Protocol l2tp, tunnel id 41161, session id 44608
 Keepalive set (10 sec)
28 packets input, 1311 bytes
34 packets output, 1432 bytes
 Last clearing of "show interface" counters never

Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
max-mru:auto
une fois la session montée tout ce petit monde est d'accord sur 1480 octets.

Toutes les idées de debug ou de configuration sont les bien venues.

Merci

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


Re: [FRnOG] [TECH] BGP internal routes et external routes

2021-03-01 Par sujet Kevin Thiou
La conf en face c'est Est / Ouest.
Le pkoi ? volonté du peer d'équilibrer la charge.
Mais je ne peux pas le faire avec les routeurs actuels se sera donc
actif/secours.

Le lun. 1 mars 2021 à 11:53, David Ponzone  a
écrit :

> Mais pourquoi tu veux mixer les 2 ?
> Dans ce cas, autant pratiquer la patate chaude: le routeur qui reçoit un
> paquet du LAN l’envoie directement à ton peer, sans passer par l’autre.
> De toute façon, chez ton peer, tu es soit sur le même routeur pour les 2
> ports, soit un port sur leur « Ouest »  et un sur leur « Est » .
>
> > Le 1 mars 2021 à 11:35, Kevin Thiou  a écrit :
> >
> > Merci de t'être penché sur le sujet.
> >
> > Sûrement ai je mal exprimé mon besoin.
> >
> > Je suis connecté au même peer privé sur les deux routeurs.
> >
> > Du coup je reçois strictement la même route sur mon routeur A et mon
> > routeur B, mais l'un et l'autre l'apprennent avec une route eBGP et une
> > route iBGP.
> >
> > Il faut donc pouvoir mixer les deux. La commande donnée pour cisco est la
> > bonne mais les ASR sont encore en phase d'intégration.
> >
> > Ca attendra donc leur mise en production.
> >
>
>

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


Re: [FRnOG] [TECH] BGP internal routes et external routes

2021-03-01 Par sujet Kevin Thiou
Merci de t'être penché sur le sujet.

Sûrement ai je mal exprimé mon besoin.

Je suis connecté au même peer privé sur les deux routeurs.

Du coup je reçois strictement la même route sur mon routeur A et mon
routeur B, mais l'un et l'autre l'apprennent avec une route eBGP et une
route iBGP.

Il faut donc pouvoir mixer les deux. La commande donnée pour cisco est la
bonne mais les ASR sont encore en phase d'intégration.

Ca attendra donc leur mise en production.

Le mer. 24 févr. 2021 à 18:51, Michel Py 
a écrit :

> > Kevin Thiou a écrit :
> > Mais si tu veux faire un "load-blancing" et que tes deux routes sont
> apprises en eBGP sur
> > 2 routeurs différents, il faut que tu puisses comparer une route eBGP et
> une route iBGP.
>
> Ah ce que tu veux faire c'est "Traffic Engineering", vaste sujet.
> Tu envoies le trafic à Router A, qui a tendance à préférer envoyer le
> trafic vers le transit auquel il est connecté, et tu voudrais qu'il envoie
> une partie du trafic à router B, qui a un autre transit (si je comprends
> bien) ?
>
> Situation typique quand les 2 transits ne sont pas du même tiers, par
> exemple un tier-1 et un tier-2, la route annoncée par le tier-1 que tu
> reçois sur Routeur A va souvent avoir un AS-PATH plus court que celle
> annoncée par le tier-2 que tu reçois sur Routeur B, donc le trafic aura
> tendance à préférer le "gros" transit et tu as un déséquilibre.
>
> Qu'est-ce que tu peux faire ? Premièrement, c'est d'envoyer ton trafic à
> router B au lieu de routeur A (encore mieux, que du côté interne ils soient
> une paire VRRP, et que tu configures B à être le Master). Ca ne vas pas
> forcément inverser la situation, en particulier si le transit connecté à B
> est plus "petit" que celui connecté à A, ça pourrait même équilibrer la
> situation. C'est un peu brutal, mais ça vaut le coup d'essayer.
>
> Deuxièmement, sur le routeur auquel tu veux donner plus d'importance (B
> dans ce cas), il faut favoriser une partie des routes que tu reçois en
> changeant quelque chose qui est au-dessus de AS-PATH dans le processus de
> décision, typiquement LOCAL_PREF avec une valeur élevée. En termes Cisco,
> tu mettrais set local-preference $valeur_élevée dans une route-map qui
> matche une partie des routes. Quand Routeur A reçoit la route iBGP en
> provenance de Router B, il va la préférer à la route eBGP qu'il reçoit de
> l'autre transit, parce que LOCAL_PREF est plus élevée.
>
> En jouant sur la sélection des routes auxquelles tu appliques la
> LOCAL_PREF plus élevée, tu influences la balance de ton trafic sortant.
>
> Pour influencer la balance du trafic entrant, c'est moins controlable, il
> faut faire un prepend de ton propre AS sur tes préfixes quand tu les
> annonces au transit que tu veux défavoriser en entrée.
>
> Michel.
>
>
>

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


Re: [FRnOG] [TECH] BGP internal routes et external routes

2021-02-24 Par sujet Kevin Thiou
Oui.

Mais si tu veux faire un "load-blancing" et que tes deux routes sont
apprises en eBGP sur 2 routeurs différents, il faut que tu puisses comparer
une route eBGP et une route iBGP.

C'est effectivement à ça que sert la commande d'après la doc cisco.

Sur mon arista 7150S ça n'existe pas. Problème réglé pour le moment.

Le mar. 23 févr. 2021 à 22:54, Michel Py 
a écrit :

> > Vincent Bernat a écrit :
> > Cisco ne compare pas les distances administratives entre iBGP et eBGP
> car ce critère est inclus dans la
> > sélection du meilleur chemin BGP. La distance ne sert que pour comparer
> BGP avec un autre protocole.
>
> C'est tout à fait correct, pourquoi donc est-ce que j'ai cette notion de
> distance administrative en tête ?
>
> Quelque part la distance administrative iBGP de 200 va faire que les
> routes OSPF vont être préférées, mais c'est irrelevant avec seulement BGP.
>
> Pourtant quelque part dans mon subconscient il y a une route interne qui
> vient prendre la priorité sur une route eBGP.
> Ah oui, 3. Prefer the path that was locally originated via a network or
> aggregate BGP subcommand or through redistribution from an IGP.
>
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
>
> En effet, ça n'a rien à voir avec la distance administrative mais avec le
> fait que la route redistribuée de l'IGP a priorité dans la sélection du
> meilleur chemin.
> Merci pour la correction, j'avais pas bien lu la question.
>
> Pour en revenir au problème d'origine :
>
> > Kevin Thiou a écrit :
> > j'ai deux routeurs connectés en iBGP, chacun connectés à un peer eBGP.
> Une route externe apprise
> > sur un routeur est annoncée sur l'autre routeur en iBGP. Chaque routeur
> prend la route eBGP locale
> > car  celle-ci prévaut par rapport à la route iBGP. J'ai un arista et un
> brocade :)
>
> Pourquoi est-ce que c'est un problème ? Distance administrative ou pas,
> c'est souvent la route eBGP qui a priorité sur la route iBGP, ce qui a du
> sens : le reste des critères étant les mêmes, on veut que le trafic aille
> vers le chemin qui a l'AS-PATH le plus court, la méthode éternelle de la
> patate chaude : se débarrasser du paquet le plus tot possible : le donner
> au pair ou au transit au lieu de le transporter en interne.
>
> Michel.
>
>

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


Re: [FRnOG] [TECH] BGP internal routes et external routes

2021-02-23 Par sujet Kevin Thiou
J'ai un arista et un brocade :)

je vais regarder pour avoir les commandes équivalentes.



Le mar. 23 févr. 2021 à 16:09, Said Ahmed Sambe  a
écrit :

> Sur routeur CISCO
>
> Maximum-path eibgp 2
>
> Cdlt
>
> Envoyé de mon iPhone
>
> > Le 23 févr. 2021 à 15:56, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > voilà le topo :
> >
> > j'ai deux routeurs connectés en iBGP, chacun connectés à un peer eBGP.
> >
> > Une route externe apprise sur un routeur est annoncée sur l'autre routeur
> > en iBGP.
> >
> > Chaque routeur prend la route eBGP locale car celle-ci prévaut par
> rapport
> > à la route iBGP.
> >
> > Quel moyen y existe-t-il pour que chaque routeur accepte les deux routes
> > dans sa table de routage ?
> >
> > Merci
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

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


[FRnOG] [TECH] BGP internal routes et external routes

2021-02-23 Par sujet Kevin Thiou
Bonjour,

voilà le topo :

j'ai deux routeurs connectés en iBGP, chacun connectés à un peer eBGP.

Une route externe apprise sur un routeur est annoncée sur l'autre routeur
en iBGP.

Chaque routeur prend la route eBGP locale car celle-ci prévaut par rapport
à la route iBGP.

Quel moyen y existe-t-il pour que chaque routeur accepte les deux routes
dans sa table de routage ?

Merci

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


Re: [FRnOG] [TECH] CIsco ASR dissociation peer L2TP

2021-02-11 Par sujet Kevin Thiou
Merci, je vais testé du coup.

C'est carrément pas clair dans les docs...

Le jeu. 11 févr. 2021 à 09:16, David Ponzone  a
écrit :

> A préciser sur quelle IP le vdpn-group « écoute ».
> Si tu le mets pas, il prendra tout.
> Donc dans ton cas, PEER1 est en premier et va donc tout récupérer.
> Tu dois donc avoir 2 Loopback, une pour chaque vpdn-group.
> Généralement, tu annonces ces 2 IPs au LAC en BGP.
> Et le LAC t’envoie les L2TP vers la bonne IP en fonction du realm (soit
> parce que c’est en dur chez eux, soit parce que leur proxy-radius demande à
> ton radius l’IP de ton LNS).
>
>
> Le 11 févr. 2021 à 08:59, Kevin Thiou  a écrit :
>
> Possible j'ai pas bien compris a quoi sert l'option.
>
> Je vais potasser la doc en parallèle.
>
> Le jeu. 11 févr. 2021 à 08:59, David Ponzone  a
> écrit :
>
>> Il te manque pas un source-ip dans chaque vpdn-group ?
>>
>>
>> > Le 11 févr. 2021 à 08:53, Kevin Thiou  a écrit :
>> >
>> > Bonjour,
>> >
>> > j'ai un problème de configuration sur des Cisco ASR.
>> >
>> > Voici la partie de la configuration qui me pose problème.
>> >
>> > vpdn-group PEER1
>> > accept-dialin
>> >  protocol l2tp
>> >  virtual-template 7
>> > local name LNS1
>> > no l2tp tunnel authentication
>> > !
>> > vpdn-group PEER2
>> > accept-dialin
>> >  protocol l2tp
>> >  virtual-template 11
>> > local name router1
>> > no l2tp tunnel authentication
>> >
>> > Lorsque les sessions L2TP montent pour le PEER2, elles utilisent les
>> > paramètres du vpdn-group PEER1. Le virtual-template et l'interface
>> attachée
>> > à celui-ci n'étant pas bon, le tunnel reste dans un  état ou les
>> sessions
>> > clientes ne montent pas.
>>
>>
>

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


Re: [FRnOG] [TECH] CIsco ASR dissociation peer L2TP

2021-02-11 Par sujet Kevin Thiou
Possible j'ai pas bien compris a quoi sert l'option.

Je vais potasser la doc en parallèle.

Le jeu. 11 févr. 2021 à 08:59, David Ponzone  a
écrit :

> Il te manque pas un source-ip dans chaque vpdn-group ?
>
>
> > Le 11 févr. 2021 à 08:53, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > j'ai un problème de configuration sur des Cisco ASR.
> >
> > Voici la partie de la configuration qui me pose problème.
> >
> > vpdn-group PEER1
> > accept-dialin
> >  protocol l2tp
> >  virtual-template 7
> > local name LNS1
> > no l2tp tunnel authentication
> > !
> > vpdn-group PEER2
> > accept-dialin
> >  protocol l2tp
> >  virtual-template 11
> > local name router1
> > no l2tp tunnel authentication
> >
> > Lorsque les sessions L2TP montent pour le PEER2, elles utilisent les
> > paramètres du vpdn-group PEER1. Le virtual-template et l'interface
> attachée
> > à celui-ci n'étant pas bon, le tunnel reste dans un  état ou les sessions
> > clientes ne montent pas.
>
>

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


[FRnOG] [TECH] CIsco ASR dissociation peer L2TP

2021-02-10 Par sujet Kevin Thiou
Bonjour,

j'ai un problème de configuration sur des Cisco ASR.

Voici la partie de la configuration qui me pose problème.

vpdn-group PEER1
 accept-dialin
  protocol l2tp
  virtual-template 7
 local name LNS1
 no l2tp tunnel authentication
!
vpdn-group PEER2
 accept-dialin
  protocol l2tp
  virtual-template 11
 local name router1
 no l2tp tunnel authentication

Lorsque les sessions L2TP montent pour le PEER2, elles utilisent les
paramètres du vpdn-group PEER1. Le virtual-template et l'interface attachée
à celui-ci n'étant pas bon, le tunnel reste dans un  état ou les sessions
clientes ne montent pas.

De plus le routeur me le dit :

*% Warning, the vpdn groups PEER2 and PEER1 have the same accept-dial
configuration*

Je cherche un moyen de dissocier les PEER. Pour d'autre configuration
j'utilise l'attribut *terminate-from hostname *ou *l2tp tunnel password*.
Ces deux attributs nécessitent une configuration des deux côtés (Moi et le
peer en face).

J'ai pensé mettre des ACL sur l'interface de terminaison du tunnel L2TP, je
n'ai pas encore testé.

Y a t-il une solution pour dissocier les peer en local et faire en sorte
que cela fonctionne ?

Merci

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


Re: [FRnOG] [BIZ] Revendeur ARISTA et Juniper

2021-02-03 Par sujet Kevin Thiou
Merci pour vos réponses.

Le mer. 3 févr. 2021 à 15:32, sofiane JALID  a
écrit :

> Bonjour
> Dans les 3 ISP dans lequel j’ai pu bosser, passent par techdata je ne
> pourrais en revanche pas te dire le billet d’entré car je cela n’est pas ma
> partie mais je crois bien qu’ils sont très compétitif encore plus vrai pour
> le catalogue Juniper.
>
>
> Le mer. 3 févr. 2021 à 14:36, sofiane JALID  a
> écrit :
>
>> Go techdata
>>
>>
>> Le mer. 3 févr. 2021 à 14:35, Kevin Thiou  a
>> écrit :
>>
>>> Si il y a un revendeur arista et juniper dans la place,
>>> j'ai des besoins de modules d'alimentation et de ventilation.
>>>
>>> Merci de me contacter.
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>

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


[FRnOG] [BIZ] Revendeur ARISTA et Juniper

2021-02-03 Par sujet Kevin Thiou
Si il y a un revendeur arista et juniper dans la place,
j'ai des besoins de modules d'alimentation et de ventilation.

Merci de me contacter.

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


Re: [FRnOG] [TECH] Cisco ASR, Arista 7150, OSPF et MTU

2021-01-06 Par sujet Kevin Thiou
Une fois les oublis de configuration sur l'interface vlan réglés, on peut
bien sûr retirer le ignore-mtu.

Pour info "ping df-bit size " m'a bien aidé pour savoir où était le
problème.

la conf finale sur l'interface vlan du arista :

interface Vlan86
   mtu 9214
   ip address 172.16.70.77/31
   ip ospf network point-to-point

Le mar. 5 janv. 2021 à 21:17, Fabien VINCENT FrNOG via frnog <
frnog@frnog.org> a écrit :

>
>
> Le 05-01-2021 13:57, Kevin Thiou a écrit :
> > Bonjour,
> >
> > toujours dans mes problèmes de collecte sur cisco ASR.
>
> Quel ASR ? Si c'est du IOS-XE ca devrait être la même MTU (mais je vois
> qu'apparement la MTU était manquante sur ton Arista).
>
> Sur du IOS-XR, c'est parfois un peu plus tricky
>
> https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
>
> >
> > J'essaie de faire en sorte de respecter les stas par exemple pour SFR
> > REFLEX il me faut une MTU à 2000 sur toute la chaîne.
> >
> > Je collecte sur un Arista 7150, sur lequel la MTU est à 9124.
> > Le trafic est envoyé vers mes Cisco ASR (interco 10G entre Arista et
> > CIsco)
> >
> > J'ai essayé de passer la MTU entre le cisco et le arista à 9124.
> >
> > Mais OSPF n'est pas content :
> >
> > *DD MTU is too large*
> >
> > La solution c'est de faire un *ip ospf ignore mtu*.
> > !! Si quelqu'un a une autre solution je suis preneur !!
> >
> > et là j'ai un autre message d'erreur que je ne comprends pas trop :
> >
> > adjacency dropped: nbr did not list our router ID, state was: EXCH
> > START
> >
> >
> > Conf Cisco :
> > interface TenGigabitEthernet0/2/0
> >  mtu 9214
> >  no ip address
> > interface TenGigabitEthernet0/2/0.86
> >  encapsulation dot1Q 86
> >  ip address 172.16.70.76 255.255.255.254
> >  ip ospf network point-to-point
> >  no lldp transmit
> >  no lldp receive
> > !
> > router ospf 1
> >  router-id 2.2.2.2
> >  auto-cost reference-bandwidth 1000
> >  passive-interface default
> >  no passive-interface TenGigabitEthernet0/2/0.86
> >  network 172.16.70.76 0.0.0.1 area 0
> >
> > Conf arista:
> > interface Vlan86
> >ip address 172.16.70.77/31
> >ip ospf network point-to-point
> > !
> > router ospf 1
> >router-id 1.1.1.1
> >auto-cost reference-bandwidth 1000
> >passive-interface default
> >no passive-interface Vlan86
> >network 172.16.70.76/31 area 0.0.0.0
> >max-lsa 12000
> >graceful-restart
> > interface Ethernet39
> >switchport trunk allowed vlan 14,86,88,216,221-222
> >switchport mode trunk
> >ip ospf mtu-ignore
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> --
> Fabien VINCENT
> _@beufanet_
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [TECH] Re: Cisco ASR, Arista 7150, OSPF et MTU

2021-01-05 Par sujet Kevin Thiou
Pour info, après de l'aide en privé, il manquait la mtu sur l'interface
vlan des arista.

avec ca :

interface Vlan86
   mtu 9214
   ip address 172.16.70.77/31
   ip ospf network point-to-point
   ip ospf mtu-ignore

c'est bon.

Le mar. 5 janv. 2021 à 13:57, Kevin Thiou  a écrit :

> Bonjour,
>
> toujours dans mes problèmes de collecte sur cisco ASR.
>
> J'essaie de faire en sorte de respecter les stas par exemple pour SFR
> REFLEX il me faut une MTU à 2000 sur toute la chaîne.
>
> Je collecte sur un Arista 7150, sur lequel la MTU est à 9124.
> Le trafic est envoyé vers mes Cisco ASR (interco 10G entre Arista et CIsco)
>
> J'ai essayé de passer la MTU entre le cisco et le arista à 9124.
>
> Mais OSPF n'est pas content :
>
> *DD MTU is too large*
>
> La solution c'est de faire un *ip ospf ignore mtu*.
> !! Si quelqu'un a une autre solution je suis preneur !!
>
> et là j'ai un autre message d'erreur que je ne comprends pas trop :
>
> adjacency dropped: nbr did not list our router ID, state was: EXCH START
>
>
> Conf Cisco :
> interface TenGigabitEthernet0/2/0
>  mtu 9214
>  no ip address
> interface TenGigabitEthernet0/2/0.86
>  encapsulation dot1Q 86
>  ip address 172.16.70.76 255.255.255.254
>  ip ospf network point-to-point
>  no lldp transmit
>  no lldp receive
> !
> router ospf 1
>  router-id 2.2.2.2
>  auto-cost reference-bandwidth 1000
>  passive-interface default
>  no passive-interface TenGigabitEthernet0/2/0.86
>  network 172.16.70.76 0.0.0.1 area 0
>
> Conf arista:
> interface Vlan86
>ip address 172.16.70.77/31
>ip ospf network point-to-point
> !
> router ospf 1
>router-id 1.1.1.1
>auto-cost reference-bandwidth 1000
>passive-interface default
>no passive-interface Vlan86
>network 172.16.70.76/31 area 0.0.0.0
>max-lsa 12000
>graceful-restart
> interface Ethernet39
>switchport trunk allowed vlan 14,86,88,216,221-222
>switchport mode trunk
>ip ospf mtu-ignore
>

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


[FRnOG] [TECH] Cisco ASR, Arista 7150, OSPF et MTU

2021-01-05 Par sujet Kevin Thiou
Bonjour,

toujours dans mes problèmes de collecte sur cisco ASR.

J'essaie de faire en sorte de respecter les stas par exemple pour SFR
REFLEX il me faut une MTU à 2000 sur toute la chaîne.

Je collecte sur un Arista 7150, sur lequel la MTU est à 9124.
Le trafic est envoyé vers mes Cisco ASR (interco 10G entre Arista et CIsco)

J'ai essayé de passer la MTU entre le cisco et le arista à 9124.

Mais OSPF n'est pas content :

*DD MTU is too large*

La solution c'est de faire un *ip ospf ignore mtu*.
!! Si quelqu'un a une autre solution je suis preneur !!

et là j'ai un autre message d'erreur que je ne comprends pas trop :

adjacency dropped: nbr did not list our router ID, state was: EXCH START


Conf Cisco :
interface TenGigabitEthernet0/2/0
 mtu 9214
 no ip address
interface TenGigabitEthernet0/2/0.86
 encapsulation dot1Q 86
 ip address 172.16.70.76 255.255.255.254
 ip ospf network point-to-point
 no lldp transmit
 no lldp receive
!
router ospf 1
 router-id 2.2.2.2
 auto-cost reference-bandwidth 1000
 passive-interface default
 no passive-interface TenGigabitEthernet0/2/0.86
 network 172.16.70.76 0.0.0.1 area 0

Conf arista:
interface Vlan86
   ip address 172.16.70.77/31
   ip ospf network point-to-point
!
router ospf 1
   router-id 1.1.1.1
   auto-cost reference-bandwidth 1000
   passive-interface default
   no passive-interface Vlan86
   network 172.16.70.76/31 area 0.0.0.0
   max-lsa 12000
   graceful-restart
interface Ethernet39
   switchport trunk allowed vlan 14,86,88,216,221-222
   switchport mode trunk
   ip ospf mtu-ignore

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


Re: [FRnOG] [TECH] Mikrotik et le roaming

2020-12-10 Par sujet Kevin Thiou
Je n'ai pas poussé jusqu'au PCAP, mais j'ai découvert certains problèmes.

Quand c'est long voir très long c'est le TC56 qui n'arrive pas à se décider.

11:10:22 caps,info 94:FB:29:8D:D6:7F@2G_FR_16 connected, signal strength
-53
11:10:22 caps,info 94:FB:29:8D:D6:7F@2G_FR_6 disconnected, registered to
other interface
11:10:37 caps,info 94:FB:29:8D:D6:7F@2G_FR_12 connected, signal strength
-43
11:10:37 caps,info 94:FB:29:8D:D6:7F@2G_FR_16 disconnected, registered to
other interface
11:11:30 caps,info 94:FB:29:8D:D6:7F@2G_FR_16 connected, signal strength
-59
11:11:31 caps,info 94:FB:29:8D:D6:7F@2G_FR_12 disconnected, registered to
other interface
11:11:44 caps,info 94:FB:29:8D:D6:7F@2G_FR_12 connected, signal strength
-37
11:11:44 caps,info 94:FB:29:8D:D6:7F@2G_FR_16 disconnected, registered to
other interface

Et effectivement il faudrait une capture pour voir qui cause et de quoi.

Ensuite le 802.11r j'y ai bien pensé mais les Cap AC de mikrotik ne le
supportent pas.

Après d'autres retours, je pense partir sur une solution Ubiquiti avec le
802.11r et voir ce que ça donne.

Je vous remonterai l'info si c'est mieux.

Le jeu. 10 déc. 2020 à 15:52, Jerome Lien  a écrit :

> Parfois le roaming prend 5 à 10 secondes, je me dis que c'est des valeurs
> acceptables même si ça peut être pénible.
> >>> c'est énorme !!  Ici,  on m'aurait déjà tué ^^
>
> as tu déjà tenté de faire des pcap sur les bornes au niveau des radios,
> pour comprendre se qui prends du temps pour le roaming ?, dhcp ?
> authentification ?
> parfois un bête probléme de relay dhcp peut mettre un joyeux bordel.
>
> J'ai deja testé des Zebra TC56, il possède du 802.11r, soit du fast roaming
> donc. On arrive dans notre environnement au pire à perdre 1 paquet. soit
> moins 1s de roaming.
>
> Notre installation est sous aerohive, mais on avait monté un lab mikrotik
> et on avait eu des résultat pas mauvais, 2s max à cause de fréquence
> identique sur deux antennes.
>
>
> Le jeu. 10 déc. 2020 à 09:23, Kevin Thiou  a écrit :
>
> > Saut,
> >
> > C'est sympa, mais tu me parles de connexion LTE.
> >
> > C'est le wifi qui me pose problème. Je ne peux pas dire au client qu'il
> > sera mieux en LTE.
> >
> > Le mer. 9 déc. 2020 à 20:36, Jérôme Nicolle  a écrit :
> >
> > > Kevin,
> > >
> > > Le 09/12/2020 à 20:24, Jérôme Nicolle a écrit :
> > > > Bizarre, le SoC Qualcom utilisé devrait supporter des bandes TDD mais
> > la
> > > > datasheet ne mentionne que des bandes FDD.
> > >
> > > À priori au temps pour moi, ce ne serait que sur le TC57 qu'ils le
> > > supportent officiellement.
> > >
> > > Si ton client envisage d'upgrader, j'ai les small-cells B39 et bientôt
> > > B38 qu'il te faut sous la main ;-)
> > >
> > > @+
> > >
> > > --
> > > Jérôme Nicolle
> > > +33 6 19 31 27 14
> > >
> > >
> > > ---
> > > 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] Mikrotik et le roaming

2020-12-10 Par sujet Kevin Thiou
Saut,

C'est sympa, mais tu me parles de connexion LTE.

C'est le wifi qui me pose problème. Je ne peux pas dire au client qu'il
sera mieux en LTE.

Le mer. 9 déc. 2020 à 20:36, Jérôme Nicolle  a écrit :

> Kevin,
>
> Le 09/12/2020 à 20:24, Jérôme Nicolle a écrit :
> > Bizarre, le SoC Qualcom utilisé devrait supporter des bandes TDD mais la
> > datasheet ne mentionne que des bandes FDD.
>
> À priori au temps pour moi, ce ne serait que sur le TC57 qu'ils le
> supportent officiellement.
>
> Si ton client envisage d'upgrader, j'ai les small-cells B39 et bientôt
> B38 qu'il te faut sous la main ;-)
>
> @+
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] Mikrotik et le roaming

2020-12-09 Par sujet Kevin Thiou
wpa-psk et wpa2 psk
encryption aes ccm.

Le mer. 9 déc. 2020 à 15:45, Ludovic Scotti  a écrit :

> Quelle type d'authentification tu utilises sur ton SSID ?
>
> Le mer. 9 déc. 2020 à 15:10, Olivier Lange  a écrit :
>
>> Mikrotik fait de très bons produits... Mais le wifi n'est pas leurs points
>> fort pour moi... Surtout en roaming...
>>
>> Le mer. 9 déc. 2020 08 h 56, Kevin Thiou  a écrit :
>>
>> > Salut la liste,
>> >
>> > Petit sujet du moment Mikrotik Caps vs Zebra TC56 :)
>> > J'ai un client qui utilise des terminaux Zebra TC56, il se plaint de
>> > déconnexion du réseau wifi qui empêche les petits robots humains de
>> > travailler.
>> >
>> > J'ai passé du temps à chercher des solutions, mais rien n'y fait.
>> >
>> > Le setup c'est un entrepôt couvert par 11 bornes RBcAPGi-5acD2nD. Pour
>> ce
>> > qui est de la couverture on doit être bon, les tech de terrain se sont
>> > baladés dans l'entrepôt sans zone blanche.
>> >
>> > Parfois le roaming prend 5 à 10 secondes, je me dis que c'est des
>> valeurs
>> > acceptables même si ça peut être pénible.
>> >
>> > Mais parfois je ne vois pas le terminal pendant 1 minute.
>> > Je le vois dans les logs du Capsman qu'il essaie de se connecter à une
>> > borne et à une autre et revenir sur la première et repartir sur une
>> autre
>> > encore.
>> >
>> > Du coup je me demande s' il y a une solution pour améliorer la
>> situation.
>> >
>> > J'ai ajouté des acl pour virer les terminaux qui ont un signal trop
>> faible,
>> > mais ça joue à la marge.
>> >
>> > Les terminaux supporte le 802.11r mais pas mes mikrotik. Je me demande
>> si
>> > ça serait magique de toute façon.
>> >
>> > Quelqu'un sait il ce que amazon ou d'autres gros utilisent ? (c'est pour
>> > mon info personnelle, le tarif des équipement ne doit pas être le même
>> que
>> > mikrotik)
>> >
>> > Merci de vos lumières
>> >
>> > ---
>> > 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/


[FRnOG] [TECH] Mikrotik et le roaming

2020-12-09 Par sujet Kevin Thiou
Salut la liste,

Petit sujet du moment Mikrotik Caps vs Zebra TC56 :)
J'ai un client qui utilise des terminaux Zebra TC56, il se plaint de
déconnexion du réseau wifi qui empêche les petits robots humains de
travailler.

J'ai passé du temps à chercher des solutions, mais rien n'y fait.

Le setup c'est un entrepôt couvert par 11 bornes RBcAPGi-5acD2nD. Pour ce
qui est de la couverture on doit être bon, les tech de terrain se sont
baladés dans l'entrepôt sans zone blanche.

Parfois le roaming prend 5 à 10 secondes, je me dis que c'est des valeurs
acceptables même si ça peut être pénible.

Mais parfois je ne vois pas le terminal pendant 1 minute.
Je le vois dans les logs du Capsman qu'il essaie de se connecter à une
borne et à une autre et revenir sur la première et repartir sur une autre
encore.

Du coup je me demande s' il y a une solution pour améliorer la situation.

J'ai ajouté des acl pour virer les terminaux qui ont un signal trop faible,
mais ça joue à la marge.

Les terminaux supporte le 802.11r mais pas mes mikrotik. Je me demande si
ça serait magique de toute façon.

Quelqu'un sait il ce que amazon ou d'autres gros utilisent ? (c'est pour
mon info personnelle, le tarif des équipement ne doit pas être le même que
mikrotik)

Merci de vos lumières

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


Re: [FRnOG] [TECH] Modification de l'adresse mac dans les requêtes PPPOE sur cisco ASR

2020-11-26 Par sujet Kevin Thiou
Bonjour,


Effectivement, l'autre porte que je dois collecter est bien une Optimum
avec tous les vlans associés.

J'ai eu d'autres réponses en privé.

Utilisations de l'interface BDI pour changer la mac-address.
Un Crtl+r dans les doc cisco montre que c'est un des seul endroit où
interagir la dessus.
Par contre les premières lignes parlant des BDI précisent :

"
Restrictions for Bridge Domain Interfaces
• Bridge domain interfaces do not support the following features: ◦PPP over
Ethernet (PPPoE)
"

Du coup je m'étais dit fausse piste. Mais effectivement la commande pppoe
enable existe sur les interfaces BDI.
Je vais même dire que ça doit fonctionner car j'ai réussi à monter les
sessions hier dans la nuit.

Du coup je suis partie sur les interfaces BDI, avec quelques surprises.
Une histoire de Punt discard packet à cause du double tagging que
j'applique et qui si il n'est pas bien géré fait exploser la cpu.

Je continue les tests avec peu de charge et je monterais au fur et à mesure.

Si il y a quelqu'un de cisco qui peut m'expliquer pourquoi il est noté dans
la doc que le pppoe n'est pas supporté, mais dans la réalité la commande
existe et fonctionne.


Le jeu. 26 nov. 2020 à 11:54, Laurent DURU  a
écrit :

> Bonjour Kevin,
>
> Je te confirme qu'il faut la changer sur l'interface physique de l'ASR,
> c'est pour cela qu'en général on dédie une interface à la collecte C2E.
> En cas de livraison sur 2 portes en sécurisation, il faut que ta MAC soit
> différente sur chacune des livraisons.
>
> Petite info complémentaire, les STAS prévoient que la MAC soit unique par
> VLAN de livraison.
> Dans les faits avec un ASR (et d'autres réfs Cisco) cela reviendrait à
> avoir une interface physique par vlan de collecte, un peu fou. La collecte
> fonctionne bien même si tu ne respectes pas la MAC par vlan tant que tu
> l'as bien configurée sur l'interface physique qui porte tous les vlans.
>
> Il y a quelques années j'avais sollicité des contacts Orange et notamment
> Obiane qui intégrait des portes OWS pour leurs clients, comme ils
> utilisaient des ASR ils avaient le même problème que toi et ne respectait
> pas non plus cette subtilité des STAS.
>
> Je profite donc de la liste et de ta question pour requêter un statut
> d'OWS sur ce point et une éventuelle mise à jour des STAS (pour info je
> n'en ai pas parcouru depuis la version 2018), d'autant plus que les STAS de
> la nouvelle offre Optimum Collect ont eu le droit au ctrl+c, ctrl+v sur ce
> chapitre ;)
>
> Bonne journée,
>
> Laurent DURU
>
>
>
>
> Le mer. 25 nov. 2020 à 00:47, Kevin Thiou  a écrit :
>
>> Bonjour,
>>
>> Je teste en ce moment mes nouveaux routeurs cisco ASR et j'ai un problème
>> avec une collecte C2E sur laquelle il est nécessaire de modifier l'adresse
>> mac source.
>>
>> ma conf est la suivante :
>>
>> bba-group pppoe 212
>>  virtual-template 212
>>  mac-address 0637.6000.
>> !
>> interface TenGigabitEthernet0/1/0.212
>>  encapsulation dot1Q 212 second-dot1q 200,600-625
>>  pppoe enable group 212
>>  no lldp transmit
>>  no lldp receive
>> !
>> interface Virtual-Template212
>>  ip unnumbered Loopback0
>>  no peer default ip address
>>  ppp authentication pap chap
>>  service-policy output dscp2
>>
>> Je pensais que la commande mac-address dans le bba-group était là pour ça.
>>
>> Mais quand je fais des tests, il faut que je change la mac directement sur
>> l'interface Te0/1/0 pour que cela fonctionne.
>>
>> Ca n'est pas possible comme configuration, bien trop restrictif. Surtout
>> que j'ai une autre collecte qui ira sur la même interface avec une autre
>> mac à changer.
>>
>> J'ai du mal comprendre quelque chose, quelqu'un a déjà fait ça ?
>>
>> un log de PADO ou on voit bien la mac de l'interface Te0/1/0 et non pas
>> celle du bba-group
>>
>> 00:30:43.374763 *78:ba:f9:eb:d5:10* > 02:22:4b:82:00:45, ethertype 802.1Q
>> (0x8100), length 106: vlan 212, p 0, ethertype 802.1Q, vlan 600, p 0,
>> ethertype PPPoE D, PPPoE PADO [Host-Uniq 0xEB006300] [Service-Name]
>> [Vendor-Specific
>> 0x0DE90100020E30303033303632313831333030328104024082040240]
>> [AC-Name "roc1"] [AC-Cookie 0xA524042AFE1F91C8C99F14ECCB03C581]
>>
>> Merci
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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


[FRnOG] [TECH] Modification de l'adresse mac dans les requêtes PPPOE sur cisco ASR

2020-11-24 Par sujet Kevin Thiou
Bonjour,

Je teste en ce moment mes nouveaux routeurs cisco ASR et j'ai un problème
avec une collecte C2E sur laquelle il est nécessaire de modifier l'adresse
mac source.

ma conf est la suivante :

bba-group pppoe 212
 virtual-template 212
 mac-address 0637.6000.
!
interface TenGigabitEthernet0/1/0.212
 encapsulation dot1Q 212 second-dot1q 200,600-625
 pppoe enable group 212
 no lldp transmit
 no lldp receive
!
interface Virtual-Template212
 ip unnumbered Loopback0
 no peer default ip address
 ppp authentication pap chap
 service-policy output dscp2

Je pensais que la commande mac-address dans le bba-group était là pour ça.

Mais quand je fais des tests, il faut que je change la mac directement sur
l'interface Te0/1/0 pour que cela fonctionne.

Ca n'est pas possible comme configuration, bien trop restrictif. Surtout
que j'ai une autre collecte qui ira sur la même interface avec une autre
mac à changer.

J'ai du mal comprendre quelque chose, quelqu'un a déjà fait ça ?

un log de PADO ou on voit bien la mac de l'interface Te0/1/0 et non pas
celle du bba-group

00:30:43.374763 *78:ba:f9:eb:d5:10* > 02:22:4b:82:00:45, ethertype 802.1Q
(0x8100), length 106: vlan 212, p 0, ethertype 802.1Q, vlan 600, p 0,
ethertype PPPoE D, PPPoE PADO [Host-Uniq 0xEB006300] [Service-Name]
[Vendor-Specific
0x0DE90100020E30303033303632313831333030328104024082040240]
[AC-Name "roc1"] [AC-Cookie 0xA524042AFE1F91C8C99F14ECCB03C581]

Merci

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


Re: [FRnOG] [MISC] Franglais

2020-09-08 Par sujet Kevin Thiou
Merci

Le mar. 8 sept. 2020 à 11:52, Benjamin Collet  a écrit :

> Salut,
>
> En terminologie MEF, pour du carrier Ethernet, on parle de NNI (ou
> ENNI).
>
> ++
> Benjamin
>
> On Tue, Sep 08, 2020 at 11:32:14AM +0200, Kevin Thiou wrote:
> > Salut,
> >
> > quelqu'un connait il le nom donné par nos amis anglophones aux portes de
> > collecte ?
> >
> > Merci
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> --
> Benjamin Collet
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [MISC] Franglais

2020-09-08 Par sujet Kevin Thiou
Salut,

quelqu'un connait il le nom donné par nos amis anglophones aux portes de
collecte ?

Merci

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


[FRnOG] [TECH] Cisco ASR vs REdback configuration

2020-07-21 Par sujet Kevin Thiou
Bonjour,

je suis en train de tenter la migration Redback vers cisco ASR.

Sur les redback il existe une configuration que je dirais de repli pour le
l2tp.

l2tp-peer unnamed

ce qui permet de gérer les connexion l2tp même avec un Remote-Name que l'on
ne connaîtrait pas ou plusieur remote-name que l'on connaît mais qu'on veut
faire tomber dans une case par défaut.

Y a t'il la même chose sur un ASR ?

Pour le moment ce n'est pas encore très clair qui fait quoi sur l'asr entre
le vpdn group et les interface virtual-template. Si quelqu'un à une page
web ou c'est un peu expliqué je suis preneur.

Merci

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


Re: [FRnOG] [TECH] Wifi sur mikrotik

2020-07-07 Par sujet Kevin Thiou
Merci pour vos réponses,

le problème se précise, les déconnections n'ont lieu que la journée.

Je vais passer les robots sur du 5ghz et les utilisateurs sur le 2.4

Je verrais ce que cela donne.

Le lun. 6 juil. 2020 à 18:19, Jerome Lien  a écrit :

> Pour les interférences bêtes, nous avions trouvé une petite enceinte low
> cost en bluetooth capable de brouiller 3channel complet
>
>
> Pour le Spy low cost, je suis sur un projet de réutiliser du matos
> aerohive. Elle embarque des puces capables d'analyse de bande. Je taff avec
> une ap250. Mais malheureusement j'ai peux de temps à consacrer pour ce
> projet, pourtant fort utile. L'idée est de lui embarquer une interface web
> et de la mettre sur batterie puis ce balader avec.
>
>
>
> Le lun. 6 juil. 2020 à 17:14,  a écrit :
>
> > Bonjour,
> >
> >
> > EKAHAU (le side Kick) marche bien mieux (j'ai également le wi-spy), il
> est
> > également bien plus précis mais ça ne coche certainement pas la case
> > "libre", c'est encore plus cher.
> >
> >
> > @+
> >
> > - Mail original -
> > De: "Michel Py" 
> > À: "Kevin CHAILLY | Service Technique" ,
> > "Jerome Lien" 
> > Cc: "frnog-tech" 
> > Envoyé: Lundi 6 Juillet 2020 16:38:13
> > Objet: RE: [FRnOG] [TECH] Wifi sur mikrotik
> >
> > > Kevin CHAILLY a écrit :
> > > Pour avoir du wifi qui marche en cas d'interférence, j'ai soit la
> poudre
> > verte, soit, le Wi-Spy.
> > > https://www.metageek.com/products/wi-spy/
> >
> > Je plussoie, c'est ce que j'ai.
> >
> > Michel.
> >
> >
> > ---
> > 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/


[FRnOG] [TECH] Wifi sur mikrotik

2020-07-03 Par sujet Kevin Thiou
Bonjour,

J'ai une installation client assez compliqué mais intéressante, du coup
quand il me remonte des problèmes j'y passe un peu de temps.

Malheureusement sur la dernière demande je me retrouve un peu sec.

Le client se plaint d'avoir des temps de réponse pas toujours nickel en
wifi, de ce que je sais il a des robots qui utilisent le wifi et sont assez
sensibles aux changements de latence.

j'ai fait des ping pour voir ce que cela donne et effectivement ca bouge.

[Admin_KE@MikroTik] > /ping 192.168.1.210
  SEQ HOST SIZE TTL TIME  STATUS

0 192.168.1.210  56  64 8ms
1 192.168.1.210  56  64 0ms
2 192.168.1.210  56  64 34ms
3 192.168.1.210  56  64 2ms
4 192.168.1.210  56  64 0ms
5 192.168.1.210  56  64 0ms
6 192.168.1.210  56  64 116ms
7 192.168.1.210  56  64 6ms
8 192.168.1.210  56  64 0ms
9 192.168.1.210  56  64 10ms
   10 192.168.1.210  56  64 1ms
   11 192.168.1.210  56  64 5ms
   12 192.168.1.210  56  64 0ms
   13 192.168.1.210  56  64 0ms
   14 192.168.1.210  56  64 0ms
sent=15 received=15 packet-loss=0% min-rtt=0ms avg-rtt=12ms
max-rtt=116ms

Je me demande comment améliorer la stabilité.

Sachant que les robots marchent en 5Ghz, bon je trouve ca con pour moi le
2.4 est plus résilient mais je n'ai pas le choix.
J'utilise capsman pour configurer les bornes car il y en a une petite
dizaine. j'ai activé le local-forwarding et le client to client forwarding.

Si quelqu'un a une idée, je suis preneur.

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


[FRnOG] [BIZ] contact datacenter Paris

2020-06-09 Par sujet Kevin Thiou
Bonjour,

je cherche des contacts pour les datacenter parisiens et ile-de-france,
nous avons besoin de 4 ou 5 baies.

Cordialement

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


[FRnOG] [TECH] Attributs RADUS

2020-04-17 Par sujet Kevin Thiou
Bonjour,

L'opérateur en face me demande de répondre Tunnel-Password  avec pour
valeur "1:motdepasse"

ma réponse actuelle est : Tunnel-Password = "0:motdepasse"

2 questions :
C'est quoi le 1 ou 0 devant le mot de passe dans la réponse ?
Comment je passe de l'un à l'autre ?

Merci

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


[FRnOG] [BIZ] contact commercial / avant vente

2020-04-10 Par sujet Kevin Thiou
Bonjour,

je cherche des infos pour changer mes LNS.

je cherche des contacts pour du cisco, juniper et nokia.

n'hésitez pas à me contacter.

Merci

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


[FRnOG] [BIZ] Alimentation pour Brocade MLX 4e

2020-03-24 Par sujet Kevin Thiou
Bonjour,
je cherche 1 ou 2 modules d'alimentation pour brocade MLX 4e.

Si quelqu'un a ça faite moi signe.

Merci

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


Re: [FRnOG] [MISC] Fake or note Fake

2020-02-19 Par sujet Kevin Thiou
Merci 

Le mer. 19 févr. 2020 à 12:27, Joris 'Tifox' BOQUET 
a écrit :

> retour de l'anssi
>
> Bonjour,
> >
> > Après vérification, nous vous confirmons que l'adresse 92.154.95.236
> > appartient bien à l'ANSSI.
> >
> > Cordialement,
> >
> > VC
> >
> > --
> > ANSSI/SDO/CERT-FR
> > Agence nationale de la sécurité des systèmes d'information
> > Centre opérationnel de la sécurité des systèmes d'information
> > Centre d'Expertise gouvernemental de Réponse et de Traitement des
> > Attaques informatiques
> > 51, boulevard de La Tour-Maubourg - 75700 PARIS 07 SP
> > Tel : +33 (0)1 71 75 84 68 - Fax : +33 (0)1 71 75 84 70
> > Mel : cert-fr.co...@ssi.gouv.fr - Web : http://www.cert.ssi.gouv.fr
> >
> > pour le reste, effectivement c'est crade., peut être volontaire dans le
> cadre du monitoring d'OIV mais bon au moins on est fixé
>
>
> Le mer. 19 févr. 2020 à 12:22, Vincent  a écrit :
>
> > Le 19/02/2020 à 11:42, Guillaume Tournat via frnog a écrit :
> > >
> > > Le 19/02/2020 à 11:31, Daniel via frnog a écrit :
> > >>
> > >> Le 19/02/2020 à 11:24, Francois Prems a écrit :
> > >>> Mouais, perso je trouve ça bien étrange que l'ANSSI ait une page web
> > >>> non
> > >>> https, c'est un peu la base pour eux non ?
> > >> Je trouve aussi
> > >
> > >
> > > https, avec certificat valide, n'a d'intérêt que si l'on veut garantir
> > > l'intégrité et la confidentialité de l'information.
> > >
> > > là, c'est juste une page statique d'information, aucun intérêt pour la
> > > confidentialité.
> >
> > Ce que l'on chercher, actuellement, c'est bien d'authentifier cette
> > page. Et non la confidentialité ( au contraire ).
> >
> >
> > L'authenticité de l'information est permise par le certificat.
> >
> > Sur une page comme celle-là, le plus important dans le https, c'est le
> > certificat.
> >
> > >
> > >
> > > et pour pouvoir fonctionner en https, il faudrait l'atteindre avec un
> > > FQDN.
> > >
> > > lorsque l'on est scanné par une IP, on a aucune idée du FQDN du site
> > > pour la requêter.
> > >
> > > et ce n'est pas le reverse dns qui va nous aider...
> > >
> > >
> > > ---
> > > 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] [MISC] Fake or note Fake

2020-02-19 Par sujet Kevin Thiou
Justement le whois ne m'a pas donné l'information que je cherchais.

Ex-transpac et ANSSI je vois pas forcement le rapport direct mais merci

Le mer. 19 févr. 2020 à 11:11, Julien Escario  a
écrit :

> Le 19/02/2020 à 11:07, Kevin Thiou a écrit :
> > Bonjour,
> >
> > j'ai une ip qui me scan un peu, pas trop mais passionnément :
> 92.154.95.236
> >
> > je vous laisse aller sur le site http://92.154.95.236
> >
> > Et me dire ce que vous en pensez.
>
> Bah, tu fais un whois sur l'IP, constate que c'est de l'ex-transpac donc
> ça paraît cohérent.
> Un whois propre avec l'identification de l'ANSSI pour le préfixe aurait
> été un plus mais pas obligatoire car ressources 'legacy'.
>
> Et si tu as encore des doutes, tu écris à ab...@orange.fr pour leur
> demander confirmation.
>
> Julien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [MISC] Fake or note Fake

2020-02-19 Par sujet Kevin Thiou
Bonjour,

j'ai une ip qui me scan un peu, pas trop mais passionnément : 92.154.95.236

je vous laisse aller sur le site http://92.154.95.236

Et me dire ce que vous en pensez.

Bonne journée

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


[FRnOG] [TECH] FSOS vs BGP

2020-01-28 Par sujet Kevin Thiou
Bonjour,

j'ai depuis peu un switch/routeur FSOS Software, S5850, Version 7.2.1

J'ai configuré BGP dessus, les sessions EBGP montent parfaitement, je
reçois les routes des peer externes.

J'ai aussi configuré mes peer IBGP, les sessions sont montées et je reçois
bien les routes des différents peer.

NeighborV AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
46.21.128.2 4  35184   1021799655285500 5d22h39m
  8622
46.21.128.3 4  35184   4879499715285500 5d22h39m
  4804
46.21.128.214  35184982799605285500 00:17:26
46
46.21.128.224  35184   1112999705285500 5d22h39m
   300
46.21.128.234  35184   1654699795285500 5d22h39m
  3614
46.21.131.134 206958   17176   200795285400 5d22h35m
16
83.167.60.162   4   8218   18782   202025285500 4d05h08m
 1

Par contre je n'envoie rien vers mes peer IBGP, j'ai retiré toutes les
prefix-list et autre route-map mais rien n'y fait.

Une idée d'un oublie bête avant de rentrer dans le détail de la conf ?

Merci

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


Re: [FRnOG] [TECH] Gestion restauration config Mikrotik

2020-01-09 Par sujet Kevin Thiou
ot;defconf: drop all not coming from
> LAN" \
> in-interface-list=!LAN
> add action=accept chain=forward comment="defconf: accept in ipsec policy" \
> ipsec-policy=in,ipsec
> add action=accept chain=forward comment="defconf: accept out ipsec policy"
> \
> ipsec-policy=out,ipsec
> add action=fasttrack-connection chain=forward comment="defconf: fasttrack"
> \
> connection-state=established,related
> add action=accept chain=forward comment=\
> "defconf: accept established,related, untracked" connection-state=\
> established,related,untracked
> add action=drop chain=forward comment="defconf: drop invalid" \
> connection-state=invalid
> add action=drop chain=forward comment=\
> "defconf:  drop all from WAN not DSTNATed"
> connection-nat-state=!dstnat \
> connection-state=new in-interface-list=WAN
> /ip firewall nat
> add action=masquerade chain=srcnat comment="defconf: masquerade" \
> ipsec-policy=out,none out-interface-list=WAN
> /ip route
> add distance=1 gateway=10.0.1.170
> /ip service
> set telnet disabled=yes
> set ftp disabled=yes
> set www disabled=yes
> set ssh disabled=yes
> set api disabled=yes
> set winbox address=\
> 192.168.88.253/32
> set api-ssl disabled=yes
> /ipv6 address
> add address=A:B:C:D:E:F:G:1/126 advertise=no comment=\
> "IPv6" interface=vlan143
> add address=::f254 comment="Gateway IPv6 LAN" from-pool=pool1 interface=\
> bridge
> /ipv6 firewall filter
> add action=accept chain=input comment="Accept
> established,related,untracked" \
> connection-state=established,related
> add action=accept chain=input comment="Accept ICMP" protocol=icmpv6
> add action=accept chain=input comment="Accept WINBOX" dst-port=8291 \
> in-interface=vlan143 protocol=tcp
> add action=drop chain=input connection-state=invalid
> add action=drop chain=input connection-state=new in-interface=vlan143
> add chain=forward protocol=icmpv6
> add chain=forward connection-state=established,related
> add chain=forward connection-state=new in-interface=!vlan143
> add action=drop chain=forward connection-state=invalid
> add action=drop chain=forward connection-state=new in-interface=vlan143
> /ipv6 nd
> set [ find default=yes ] advertise-dns=yes interface=bridge \
> managed-address-configuration=yes other-configuration=yes
> /ipv6 nd prefix
> add autonomous=no interface=bridge
> /ipv6 route
> add distance=1 gateway=A:B:C:D:E:F:G:2
> /system clock
> set time-zone-name=Europe/Paris
> /system identity
> set name=RB952UI_TEST-143
> /tool bandwidth-server
> set enabled=no
> /tool graphing interface
> add allow-address=192.168.1.254/32 interface=vlan143
> /tool mac-server
> set allowed-interface-list=none
> /tool mac-server mac-winbox
> set allowed-interface-list=none
> /tool mac-server ping
> set enabled=no
> --
> *De :* frnog-requ...@frnog.org  de la part de
> Sébastien 65 
> *Envoyé :* jeudi 9 janvier 2020 11:49
> *À :* Kevin Thiou ; Mathieu 
> *Cc :* frnog-tech 
> *Objet :* RE: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
> J'utilise des Mikrotik https://mikrotik.com/product/RB952Ui-5ac2nD-TC
> [
> https://i.mt.lv/img/mt/v2/logo_fb.jpg]<https://mikrotik.com/product/RB952Ui-5ac2nD-TC
> >
> MikroTik Routers and Wireless - Products: hAP ac lite TC<
> https://mikrotik.com/product/RB952Ui-5ac2nD-TC>
> The hAP ac lite is a Dual-concurrent Access Point, that provides WiFi
> coverage for 2.4GHz and 5GHz frequencies at the same time. Unit is equipped
> with a 650MHz CPU, 64MB RAM, five 10/100Mbps Ethernet ports (PoE output on
> port #5), dual-chain 802.11b/g/n 2.4GHz wireless, single chain 802.11a/n/ac
> 5GHz wireless, USB port for 3G/4G modem and a RouterOS L4 license.
> mikrotik.com
>
> @Mathieu
> > Si tu as un port sd/usb, tu peux peut-être aussi essayer de mettre ton
> fichier là pour voir.
> Je vais essayer avec une clé USB, pas bête !!
>
> @Kevin Thiou<mailto:kevinth...@gmail.com >
> >Les fichiers placés dans /flash restent au reboot, info support mikrotik.
> Pas sur le mien !!!
>
> >As tu pensé au TR069 ? je l'ai mis en place avec genieacs et ca marche
> plutôt bien.
> Non :) Je vais regarder à mes heures perdues mais la je n'ai vraiment pas
> le temps
>
> >Si tu as la moindre erreur de configuration dans ton fichier .rsc il est
> possible qu'il ne puisse l'importer, généralement il importe jusqu'à la
> ligne qui n'est pas bonne.
> Le même fichier de configuration si je le copie/colle dans le terminal ne
> me donne aucune erreur 
> 

Re: [FRnOG] [TECH] Gestion restauration config Mikrotik

2020-01-09 Par sujet Kevin Thiou
J'ai dans mon parc des RBD52G-5HacD2HnD-TC et ca fonctionne.

Quelle version de RouterOS utilises tu ?

Peut être peux tu nous donner un aperçu de ta configuration ?

Le jeu. 9 janv. 2020 à 11:49, Sébastien 65  a écrit :

> J'utilise des Mikrotik https://mikrotik.com/product/RB952Ui-5ac2nD-TC
> <https://mikrotik.com/product/RB952Ui-5ac2nD-TC>
> MikroTik Routers and Wireless - Products: hAP ac lite TC
> <https://mikrotik.com/product/RB952Ui-5ac2nD-TC>
> The hAP ac lite is a Dual-concurrent Access Point, that provides WiFi
> coverage for 2.4GHz and 5GHz frequencies at the same time. Unit is equipped
> with a 650MHz CPU, 64MB RAM, five 10/100Mbps Ethernet ports (PoE output on
> port #5), dual-chain 802.11b/g/n 2.4GHz wireless, single chain 802.11a/n/ac
> 5GHz wireless, USB port for 3G/4G modem and a RouterOS L4 license.
> mikrotik.com
>
> @Mathieu
> > Si tu as un port sd/usb, tu peux peut-être aussi essayer de mettre ton
> fichier là pour voir.
> Je vais essayer avec une clé USB, pas bête !!
>
> @Kevin Thiou 
> >Les fichiers placés dans /flash restent au reboot, info support mikrotik.
> Pas sur le mien !!!
>
> >As tu pensé au TR069 ? je l'ai mis en place avec genieacs et ca marche
> plutôt bien.
> Non :) Je vais regarder à mes heures perdues mais la je n'ai vraiment pas
> le temps
>
> >Si tu as la moindre erreur de configuration dans ton fichier .rsc il est
> possible qu'il ne puisse l'importer, généralement il importe jusqu'à la
> ligne qui n'est pas bonne.
> Le même fichier de configuration si je le copie/colle dans le terminal ne
> me donne aucune erreur 
> --
> *De :* Kevin Thiou 
> *Envoyé :* jeudi 9 janvier 2020 11:23
> *À :* Mathieu 
> *Cc :* Sébastien 65 ; frnog-tech <
> frnog-t...@frnog.org>
> *Objet :* Re: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
> Les fichiers placés dans /flash restent au reboot, info support mikrotik.
>
> As tu pensé au TR069 ? je l'ai mis en place avec genieacs et ca marche
> plutôt bien.
>
> Pour ce qui est de la récupération de conf avec des fchier .rsc je
> l'utilise quotidiennement sur un parc de RB2011 et d'autes modèles sans
> aucun souci.
>
> J'ai mis sur ce modèle un delay de 20 sec.
>
> Si tu as la moindre erreur de configuration dans ton fichier .rsc il est
> possible qu'il ne puisse l'importer, généralement il importe jusqu'à la
> ligne qui n'est pas bonne.
>
>
> Le mer. 8 janv. 2020 à 23:19, Mathieu  a écrit :
>
> > Oui au reboot le fichier backup n'est plus présent.
>
> c'est probablement là le problème. Quand j'avais fait des tests avec un
> routerboard HEX, le fichier de backup était bien resté après le reset. Il
> faudrait regarder dans la doc de ton modèle pour voir ou placer les
> fichiers qui doivent être persistants. Si tu as un port sd/usb, tu peux
> peut-être aussi essayer de mettre ton fichier là pour voir.
>
>
> - Mail original -
> De: "Sébastien 65" 
> À: "Mathieu" 
> Cc: frnog-t...@frnog.org
> Envoyé: Mercredi 8 Janvier 2020 11:46:48
> Objet: RE: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> >tu as mis le "no-defaults=yes" aussi ?
>
> Oui ! Je viens de le faire aussi avec Winbox > system > Reset
> configuration [X] No Default Configuration
>
>
> > dans un de tes messages précédents, tu dis que le fichier est effacé
> lors du reset, ça me parait curieux. Suivant les modèles, il faut mettre
> les fichiers dans / ou dans /flash pour qu'ils restent après un reset.
>
> Oui au reboot le fichier backup n'est plus présent. Dans Winbox je clique
> sur Files et ensuite j'upload mon fichier backup.rsc.
>
>
>
> Il est bien dans dans flash/backup.rsc
>
>
>
> De : Mathieu 
> Envoyé : mercredi 8 janvier 2020 11:36
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> tu as mis le "no-defaults=yes" aussi ?
>
> chez moi, sur un ccr1072, j'ai pu restaurer un fichier de backup avec
> cette commande:
>
> /system reset-configuration no-defaults=yes run-after-reset=backup.rsc
>
>
> après avoir ajouté:
>
> :delay 60s
>
> en haut du fichier de backup
>
>
> dans un de tes messages précédents, tu dis que le fichier est effacé lors
> du reset, ça me parait curieux. Suivant les modèles, il faut mettre les
> fichiers dans / ou dans /flash pour qu'ils restent après un reset.
>
>
>
>
> - Mail original -
> De: "Sébastien 65" 
> À: maaathie...@free.fr
> Cc: frnog-t...@frnog.org
> Envoyé: Mercredi 8 Janvier 2020 11:23:21
> Objet: RE: [FRnOG] [TECH] Gestion restauration config 

Re: [FRnOG] [TECH] Gestion restauration config Mikrotik

2020-01-09 Par sujet Kevin Thiou
Les fichiers placés dans /flash restent au reboot, info support mikrotik.

As tu pensé au TR069 ? je l'ai mis en place avec genieacs et ca marche
plutôt bien.

Pour ce qui est de la récupération de conf avec des fchier .rsc je
l'utilise quotidiennement sur un parc de RB2011 et d'autes modèles sans
aucun souci.

J'ai mis sur ce modèle un delay de 20 sec.

Si tu as la moindre erreur de configuration dans ton fichier .rsc il est
possible qu'il ne puisse l'importer, généralement il importe jusqu'à la
ligne qui n'est pas bonne.


Le mer. 8 janv. 2020 à 23:19, Mathieu  a écrit :

> > Oui au reboot le fichier backup n'est plus présent.
>
> c'est probablement là le problème. Quand j'avais fait des tests avec un
> routerboard HEX, le fichier de backup était bien resté après le reset. Il
> faudrait regarder dans la doc de ton modèle pour voir ou placer les
> fichiers qui doivent être persistants. Si tu as un port sd/usb, tu peux
> peut-être aussi essayer de mettre ton fichier là pour voir.
>
>
> - Mail original -
> De: "Sébastien 65" 
> À: "Mathieu" 
> Cc: frnog-t...@frnog.org
> Envoyé: Mercredi 8 Janvier 2020 11:46:48
> Objet: RE: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> >tu as mis le "no-defaults=yes" aussi ?
>
> Oui ! Je viens de le faire aussi avec Winbox > system > Reset
> configuration [X] No Default Configuration
>
>
> > dans un de tes messages précédents, tu dis que le fichier est effacé
> lors du reset, ça me parait curieux. Suivant les modèles, il faut mettre
> les fichiers dans / ou dans /flash pour qu'ils restent après un reset.
>
> Oui au reboot le fichier backup n'est plus présent. Dans Winbox je clique
> sur Files et ensuite j'upload mon fichier backup.rsc.
>
>
>
> Il est bien dans dans flash/backup.rsc
>
>
>
> De : Mathieu 
> Envoyé : mercredi 8 janvier 2020 11:36
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> tu as mis le "no-defaults=yes" aussi ?
>
> chez moi, sur un ccr1072, j'ai pu restaurer un fichier de backup avec
> cette commande:
>
> /system reset-configuration no-defaults=yes run-after-reset=backup.rsc
>
>
> après avoir ajouté:
>
> :delay 60s
>
> en haut du fichier de backup
>
>
> dans un de tes messages précédents, tu dis que le fichier est effacé lors
> du reset, ça me parait curieux. Suivant les modèles, il faut mettre les
> fichiers dans / ou dans /flash pour qu'ils restent après un reset.
>
>
>
>
> - Mail original -
> De: "Sébastien 65" 
> À: maaathie...@free.fr
> Cc: frnog-t...@frnog.org
> Envoyé: Mercredi 8 Janvier 2020 11:23:21
> Objet: RE: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> @mathieu : Pas mieux, j'avais essayé déjà !
>
>
> @david :
>
> >Ton Mikrotik cible a bien la même version de firmware que celui qui a
> généré la conf ?
> Oui exactement la même version !!!
>
>
>
> >Elle passe bien en copier/coller ?
> Oui c'est comme ça que je fais sauf que Winbox déconnecte 2/3 fois c'est
> pénible de devoir reconnecter est vérifier que le dernier copier/coller à
> bien fonctionné !
>
> C'est un coup à avoir des règles FW en double (je me suis fait avoir sur
> ça)
>
>
>
>
> De : maaathie...@free.fr 
> Envoyé : mercredi 8 janvier 2020 11:06
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
>
> moi j'ai du mettre 60s pour que ça fonctionne chez moi.
>
>
>
>
> - Mail original -
> De: "Sébastien 65" 
> À: "David Ponzone" 
> Cc: frnog-t...@frnog.org
> Envoyé: Mercredi 8 Janvier 2020 10:56:56
> Objet: RE: [FRnOG] [TECH] Gestion restauration config Mikrotik
>
> >Ben pourtant ça devrait régler le problème le delay:
> Nop, même avec 30s ça ne change rien !
>
> >Dernier recours: copier/coller sur le Mikrotik dont tu as effacé la conf
> et sur lequel tu te connectes avec le mac-telnet d’un autre Mikrotik
> Actuellement c'est comme ça que je fais mais c'est trop naze...
>
>
>
> ---
> Liste de diffusion du FRnOG
>
> https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C1e47435d6dfd443fe31708d79426a5f3%7C84df9e7fe9f640afb435%7C1%7C0%7C637140766012869086sdata=Deln9cSwYETsYrQui63QNC1zuLl7adU4mB%2FF%2B2tQbAY%3Dreserved=0
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] port down malgré niveau optique correcte

2020-01-09 Par sujet Kevin Thiou
Oui c'est un problème de négociation, c'est rentré dans l'ordre.

Merci

Le jeu. 9 janv. 2020 à 11:09, Clement Cavadore  a
écrit :

> Hello,
>
> On Thu, 2020-01-09 at 10:19 +0100, Kevin Thiou wrote:
> >   Temp   Voltage   Current   Tx Power  Rx Power
> > Port  (Celsius)  (Volts)   (mA)  (dBm) (dBm) Last Update
> > - -        
> >  ---
> > Et35   20.10  3.36  14.55-6.03 -6.77 0:00:00 ago
>
>
> J'ai déjà eu le cas suivant: Une optique 1G face à une optique 10G.
> Ou sinon, effectivement, autoneg d'un côté, et pas de l'autre (up coté
> autoneg désactivé). Est-ce que tu es sûr de toi ?
>
> --
> Clément Cavadore
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [TECH] port down malgré niveau optique correcte

2020-01-09 Par sujet Kevin Thiou
Bonjour,

je ne m'explique pas cette situation :

sh int e 35 transceiver
If device is externally calibrated, only calibrated values are printed.
N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels (milliwatts).
   Bias  Optical   Optical
  Temp   Voltage   Current   Tx Power  Rx Power
Port  (Celsius)  (Volts)   (mA)  (dBm) (dBm) Last Update
- -        
 ---
Et35   20.10  3.36  14.55-6.03 -6.77 0:00:00 ago

sh int e 35
Ethernet35 is down, line protocol is down (notconnect)
  Hardware is Ethernet, address is 444c.a830.be8c (bia 444c.a830.be8c)
  Ethernet MTU 9214 bytes , BW 100 kbit
  Full-duplex, 1Gb/s, auto negotiation: off, uni-link: disabled
  Down 9 hours, 6 minutes, 44 seconds
  Loopback Mode : None
  11 link status changes since last clear
  Last clearing of "show interface" counters never
  5 minutes input rate 0 bps (0.0% with framing overhead), 0 packets/sec
  5 minutes output rate 0 bps (0.0% with framing overhead), 0 packets/sec
 37272716 packets input, 10241947883 bytes
 Received 42494 broadcasts, 27 multicast
 0 runts, 0 giants
 0 input errors, 0 CRC, 0 alignment, 0 symbol, 0 input discards
 0 PAUSE input
 61085627 packets output, 56045279287 bytes
 Sent 0 broadcasts, 4264681 multicast
 0 output errors, 0 collisions
 0 late collision, 0 deferred, 0 output discards
 0 PAUSE output

Le port en face est up.

Quelque'un peut il m'expliqué ?

Merci

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


[FRnOG] [TECH] Problème sur Redback

2019-12-04 Par sujet Kevin Thiou
Bonjour,

je me retrouve aujourd'hui avec un problème de session L2TP qui n'arrête
pas de tombée.

Sur mon redback j'ai ce message dans les logs

Dec 4 14:23:24: %L2TP-7-TUN: MikroTik/185.194.184.16:20590: Recv'd packet
with wrong remote port: 4258005628 instead of 4258005798
Dec 4 14:23:24: %L2TP-6-TUNNEL: MikroTik/185.194.184.16:20590 receive
packet error: Wrong local address

Je n'ai pas trouvé d'informations concernant ce message dans aucune doc.

Si je le lis bêtement, je comprends bien que les paquets que je recevais
sur une session établie m'arrive maintenant avec un mauvais port.
Il est vachement haut l'id du port donc c'est pas un port tcp/udp mais
quelque chose dans la session L2TP géré par le redback et surement échangé
avec le cpe(mikrotik).

Quelqu'un aurait il une piste ?

Merci

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


Re: [FRnOG] [TECH] TR-069 - Mikrotik

2019-10-24 Par sujet Kevin Thiou
j'ai trouvé ca :

https://mum.mikrotik.com/presentations/EU19/presentation_6365_1552304020.pdf

Le jeu. 24 oct. 2019 à 10:55, David Ponzone  a
écrit :

>
> > Le 24 oct. 2019 à 10:47, Romain Guitteau  a
> écrit :
> >
> > Bonjour,
> >
> > Je souhaite implémenter le protocole TR-069 pour envoyer des fichiers de
> configurations à mes routeurs Mikrotik. Connaissez vous des serveurs ACS
> simple d'utilisation et si possible open source et comment les configurer
> pour provisionner les routeur ?
> >
> > Cordialement
> >
> > Romain GUITTEAU—GIROIRE
> >
>
> Lesquels ?
>
> https://wiki.mikrotik.com/wiki/Manual:TR069-client#Tested_ACSs
>
> Comment ?
>
> Probablement le genre d’infos/configs le moins partagé du net, car cela
> présente une très forte valeur ajoutée.
> En plus c’est surtout un truc de gros FAI/carrier, et eux ne partagent
> rien.
> Bref bon courage tout seul dans ton coin :)
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


Re: [FRnOG] [TECH] Remplacement Smartedge SE600

2019-09-05 Par sujet Kevin Thiou
Merci pour la réponse,

je ne connais plus trop les gammes cisco, je sais que pour faire la
fonction LNS chez juniper j'ai besoin d'une licence qui coûte très chère.

C'est pareil pour un ASR ?

Le jeu. 5 sept. 2019 à 17:07, Christophe LUCAS 
a écrit :

> Salut,
>
> ASR1004/ASR1006 ESP40
>
> ++Christophe
>
> - Mail original -----
> De: "Kevin Thiou" 
> À: "frnog-tech" 
> Envoyé: Jeudi 5 Septembre 2019 16:17:03
> Objet: [FRnOG] [TECH] Remplacement Smartedge SE600
>
> Bonjour,
>
> je commence à réfléchir au remplacement de mes routeurs Ericsson SmartEdge
> SE600.
> Ils font bien le travail que je leur demande (LNS), le principal problème
> est la bande passante.
>
> Etant donné que je n'ai que des interfaces 1Gbps dessus, je suis obligé de
> multiplié les LAG.
> Il existe des cartes 10G en refurbished, j'y pense c'est pour comparer les
> couts/risque/possibilité d'évolution
>
> Quelles modèle de routeur de remplacement me suggéreriez vous ?
>
> Il me faut :
> - 3 ports 10Gbps minimum
> - capacité de gérer 20Gbps de trafic au moins
> - forcément double alim
> - pas forcément double carte de management
>
> Je ne donne pas le matériel auquel je pense pour ne pas aiguiller les
> réponses.
>
> Merci
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [TECH] Remplacement Smartedge SE600

2019-09-05 Par sujet Kevin Thiou
Bonjour,

je commence à réfléchir au remplacement de mes routeurs Ericsson SmartEdge
SE600.
Ils font bien le travail que je leur demande (LNS), le principal problème
est la bande passante.

Etant donné que je n'ai que des interfaces 1Gbps dessus, je suis obligé de
multiplié les LAG.
Il existe des cartes 10G en refurbished, j'y pense c'est pour comparer les
couts/risque/possibilité d'évolution

Quelles modèle de routeur de remplacement me suggéreriez vous ?

Il me faut :
- 3 ports 10Gbps minimum
- capacité de gérer 20Gbps de trafic au moins
- forcément double alim
- pas forcément double carte de management

Je ne donne pas le matériel auquel je pense pour ne pas aiguiller les
réponses.

Merci

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


Re: [FRnOG] [TECH] Modification de l'IRR

2019-09-02 Par sujet Kevin Thiou
Oui niveau AS-path j'ai un AS qui est derrière l'autre.

Et oui je veux juste mettre à jour l'AS34761 qui est derrière.

Merci pour la réponse.

Le lun. 2 sept. 2019 à 11:09, David Ponzone  a
écrit :

>
>
> > Le 2 sept. 2019 à 11:03, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > je gère deux AS, je route mes deux AS par une seule session BGP ce qui
> > modifie l'AS-Origin d'un des deux AS.
> >
> > Du coup ca ne correspond plus à ce qui est défini dans le RIPE
> >
> > Pour être dans les règles il faut que je fasse un import/export.
> >
> > Pouvez vous me confirmer que celui-ci est bon  ?
> >
> > Dans la base RIPE pour l'AS 35184 qui est mon AS "principale"
> > import from AS34761 accept AS34761
> > export AS8218 announce AS34761
> >
> > Est tout ce dont j'ai besoin ?
>
> Je suis pas sûr de suivre.
> Un de tes AS est derrière l’autre niveau AS-Path ou pas ?
> SI oui, ton objet RIPE semble ok (en ce qui concerne 34761, mais je
> suppose que c’est déjà à jour pour 35184).
> Tu peux aussi faire un objet AS-KEVIN qui contient les 2 AS, puis:
> export AS8218 announce AS-KEVIN
>
>

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


[FRnOG] [TECH] Modification de l'IRR

2019-09-02 Par sujet Kevin Thiou
Bonjour,

je gère deux AS, je route mes deux AS par une seule session BGP ce qui
modifie l'AS-Origin d'un des deux AS.

Du coup ca ne correspond plus à ce qui est défini dans le RIPE

Pour être dans les règles il faut que je fasse un import/export.

Pouvez vous me confirmer que celui-ci est bon  ?

Dans la base RIPE pour l'AS 35184 qui est mon AS "principale"
import from AS34761 accept AS34761
export AS8218 announce AS34761

Est tout ce dont j'ai besoin ?

Merci

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


Re: [FRnOG] [MISC] Les vendeurs, c'est comme la drogue

2019-07-29 Par sujet Kevin Thiou
Réponse à moi même à croire que FRNOg m'a inspiré.

Dans la conf de base du mode bridge il est en VPI/VCI : 0/35 et pas 8/35.

Le lun. 29 juil. 2019 à 15:14, Kevin Thiou  a écrit :

> Si quelqu'un réussit à faire fonctionner les modems Kasda en bridge, je
> suis preneur.
>
> J'ai essayé mais rien n'y fait.
>
> Le ven. 19 juil. 2019 à 16:21, Kevin CHAILLY | Service Technique <
> kchai...@adeo-informatique.com> a écrit :
>
>> Dans ma mémoire, CXR conseillait beaucoup 30a en ptm pour le VDSL, vu que
>> c'est le setup par défaut de leurs DSLAM.
>>
>> Les modems CXR étaient du Kasda Networks,
>> http://www.kasdanet.com/FRHCSZ/
>>
>> Je dois en avoir un ou deux de coté si quelqu'un veut faire des tests.
>> Nous les avons utilisé uniquement en bridge + ap wifi activé
>>
>> Kévin
>>
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de
>> Pierre-Loïc Carette - ALPESYS
>> Envoyé : vendredi 19 juillet 2019 16:06
>> À : David Ponzone ; Julien Escario <
>> julien.esca...@altinea.fr>
>> Cc : frnog@frnog.org
>> Objet : Re: [FRnOG] [MISC] Les vendeurs, c'est comme la drogue
>>
>> Nous dans le meme cas que toi.
>> On a testé ces modules sfp CXR mais ca n'a pas donné entiere
>> satisfaction...
>> Ca synchronisait pas correctement et pas aussi vite que des vrais modems
>> vdsl.
>> A mon sens il manque des profils VDSL dans le firmware.
>> Et surtout effectivement ca fonctionne pas en adsl.
>> De plus il faudrait qu'on puisse faire un minimum de config dessus et
>> surtout visualiser les logs de synchro.
>>
>>
>> 
>> From: frnog-requ...@frnog.org  on behalf of
>> David Ponzone 
>> Sent: Friday, July 19, 2019 3:38:44 PM
>> To: Julien Escario
>> Cc: frnog@frnog.org
>> Subject: Re: [FRnOG] [MISC] Les vendeurs, c'est comme la drogue
>>
>> >
>> > D'ailleurs, à ce propos, je n'ai toujours pas trouvé de modem
>> > ADSL/VDSL (juste un modem hein) qui me satisfasse pleinement. Le moins
>> > pourri pour le moment, c'est le Netgear DM200 mais son interface est
>> > totalement asthmatique.
>> >
>> > Quelqu'un aurait un truc qui va bien ? On cherche vraiment juste un
>> > modem, ça doit être trop simple pour les constructeurs
>>
>>
>> Julien, allô, c'est fini l'ADSL, y a du FTTH partout maintenant.
>> Légère anticipation des constructeurs c'est sûr.
>>
>> J'ai bien pensé à la solution SFP VDSL dans un Mikrotik.
>> A priori, ça marche bien en VDSL (parce que VLAN) mais en ADSL, j'ai cru
>> comprendre qu'ils avaient hardcodé un (ou plusieurs) VP/VC ATM dans le SFP,
>> qui correspond à un VLAN pour le Mikrotik, mais c'est pas configurable, et
>> le 8/35 ne serait pas présent (parce qu'à priori, c'est pas le VP/VC de
>> base dans beaucoup de pays européens).
>> Et je parle même pas de la pérennité du truc.
>> Dommage, c'était élégant.
>>
>> J'ai l'impression qu'on est que 3 avec ce problème d'A/VDSL sur la liste,
>> pas toi ? :)
>>
>>
>>
>> ---
>> 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] [MISC] Les vendeurs, c'est comme la drogue

2019-07-29 Par sujet Kevin Thiou
Si quelqu'un réussit à faire fonctionner les modems Kasda en bridge, je
suis preneur.

J'ai essayé mais rien n'y fait.

Le ven. 19 juil. 2019 à 16:21, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> Dans ma mémoire, CXR conseillait beaucoup 30a en ptm pour le VDSL, vu que
> c'est le setup par défaut de leurs DSLAM.
>
> Les modems CXR étaient du Kasda Networks,  http://www.kasdanet.com/FRHCSZ/
>
> Je dois en avoir un ou deux de coté si quelqu'un veut faire des tests.
> Nous les avons utilisé uniquement en bridge + ap wifi activé
>
> Kévin
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Pierre-Loïc Carette - ALPESYS
> Envoyé : vendredi 19 juillet 2019 16:06
> À : David Ponzone ; Julien Escario <
> julien.esca...@altinea.fr>
> Cc : frnog@frnog.org
> Objet : Re: [FRnOG] [MISC] Les vendeurs, c'est comme la drogue
>
> Nous dans le meme cas que toi.
> On a testé ces modules sfp CXR mais ca n'a pas donné entiere
> satisfaction...
> Ca synchronisait pas correctement et pas aussi vite que des vrais modems
> vdsl.
> A mon sens il manque des profils VDSL dans le firmware.
> Et surtout effectivement ca fonctionne pas en adsl.
> De plus il faudrait qu'on puisse faire un minimum de config dessus et
> surtout visualiser les logs de synchro.
>
>
> 
> From: frnog-requ...@frnog.org  on behalf of
> David Ponzone 
> Sent: Friday, July 19, 2019 3:38:44 PM
> To: Julien Escario
> Cc: frnog@frnog.org
> Subject: Re: [FRnOG] [MISC] Les vendeurs, c'est comme la drogue
>
> >
> > D'ailleurs, à ce propos, je n'ai toujours pas trouvé de modem
> > ADSL/VDSL (juste un modem hein) qui me satisfasse pleinement. Le moins
> > pourri pour le moment, c'est le Netgear DM200 mais son interface est
> > totalement asthmatique.
> >
> > Quelqu'un aurait un truc qui va bien ? On cherche vraiment juste un
> > modem, ça doit être trop simple pour les constructeurs
>
>
> Julien, allô, c'est fini l'ADSL, y a du FTTH partout maintenant.
> Légère anticipation des constructeurs c'est sûr.
>
> J'ai bien pensé à la solution SFP VDSL dans un Mikrotik.
> A priori, ça marche bien en VDSL (parce que VLAN) mais en ADSL, j'ai cru
> comprendre qu'ils avaient hardcodé un (ou plusieurs) VP/VC ATM dans le SFP,
> qui correspond à un VLAN pour le Mikrotik, mais c'est pas configurable, et
> le 8/35 ne serait pas présent (parce qu'à priori, c'est pas le VP/VC de
> base dans beaucoup de pays européens).
> Et je parle même pas de la pérennité du truc.
> Dommage, c'était élégant.
>
> J'ai l'impression qu'on est que 3 avec ce problème d'A/VDSL sur la liste,
> pas toi ? :)
>
>
>
> ---
> 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] Re: C2E Optique FFTO Orange

2019-06-27 Par sujet Kevin Thiou
Oui, mon problème c'est que le routeur est vers Marseilles.

ca ne va pas être simple.

Merci à Alexandre Rendour qui m'a fourni sa configuration que je vais
tester dès que j'aurais un tech sur place.

$Déclaration du Vlan:
/interface vlan
add interface=combo1 name=combo1-vlan2900 vlan-id=2900
$déclaration du bridge:
/interface bridge
add name=bridge-vlan2900-orange

$Intégration du Vlan dans le bridge:
/interface bridge port
add bridge=bridge-vlan2900-orange interface=combo1-vlan2900

$passage de la priorité COS à 2:
/interface bridge filter
add action=set-priority chain=forward new-priority=2
out-interface=combo1-vlan2900 passthrough=yes
add action=set-priority chain=output log-prefix=L2-COS new-priority=2
out-interface=combo1-vlan2900 passthrough=no

$création du dialer
/interface pppoe-client
add add-default-route=no allow=chap disabled=no
interface=bridge-vlan2900-orange name=Dialer1 password=PASSWORD user=USER

$désactiver le fast-path: TRES IMPORTANT
/ip settings
set allow-fast-path=no

Le jeu. 27 juin 2019 à 10:37, David Ponzone  a
écrit :

> > Le 27 juin 2019 à 09:13, Kevin Thiou  a écrit :
> >
> > Voici l'idée que je me fais de la conf à appliquer.
> >
> > /interface vlan
> > add interface=ether1 name=vlan2900 vlan-id=2900
> > /ip firewall mangle
> > add action=set-priority chain=forward new-priority=5
> out-interface=vlan2900
> >
> > L'avis de quelqu'un l'ayant déjà mis en place me serait d'un grand
> secours.
>
>
> D’après ma recherche rapide, c’est un chain=output qu’il faut utiliser
>
> Et à mon avis, le mieux c’est que tu mettes un wireshark sur ton ether1
> pour regarder ce qui sort.
>
>

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


[FRnOG] [TECH] Re: C2E Optique FFTO Orange

2019-06-27 Par sujet Kevin Thiou
Voici l'idée que je me fais de la conf à appliquer.

/interface vlan
add interface=ether1 name=vlan2900 vlan-id=2900
/ip firewall mangle
add action=set-priority chain=forward new-priority=5 out-interface=vlan2900

L'avis de quelqu'un l'ayant déjà mis en place me serait d'un grand secours.


Le jeu. 27 juin 2019 à 09:08, Kevin Thiou  a écrit :

> Bonjour,
>
> j'ai aujourd'hui la livraison de ma première C2E Orange.
>
> Je n'ai pas eu le temps de lire les STAS avant la livraison et je
> m’aperçois que ce n'est pas trivial.
>
> Mon routeur est un mikrotik RB2011
>
> Pour le tag 2900 c'est assez simple par contre pour ce qui est du 802.1p
> je ne sais pas comment le mettre en place.
>
> Dans les archives j'ai vu qu'il y avait un sujet mais pas toute la
> solution.
>
> Est il obligatoire de passé par un bridge pour appliquer le tag 802.1p ?
>
> Merci
>

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


[FRnOG] [TECH] C2E Optique FFTO Orange

2019-06-27 Par sujet Kevin Thiou
Bonjour,

j'ai aujourd'hui la livraison de ma première C2E Orange.

Je n'ai pas eu le temps de lire les STAS avant la livraison et je
m’aperçois que ce n'est pas trivial.

Mon routeur est un mikrotik RB2011

Pour le tag 2900 c'est assez simple par contre pour ce qui est du 802.1p je
ne sais pas comment le mettre en place.

Dans les archives j'ai vu qu'il y avait un sujet mais pas toute la solution.

Est il obligatoire de passé par un bridge pour appliquer le tag 802.1p ?

Merci

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


Re: [FRnOG] [TECH] acces extranet telehouse

2019-05-27 Par sujet Kevin Thiou
Merci pour l'info

Le lun. 27 mai 2019 à 15:10, Charles ENEL-REHEL 
a écrit :

> Incident de portail (peut-être) toujours en cours chez TELEHOUSE ?
>
> Pour mémoire à ceux qui ont zappé la communication de TELEHOUSE sur le
> sujet :
>
> *[Mise à jour du Mardi 21 mai 2019 à 16h00]*
>
>
>
> *Le portail client reste indisponible.*
>
> *La procédure de communication par téléphone et email pour vos opérations
> est donc toujours à utiliser (voir ci-dessous).*
>
> *Veuillez à nouveau nous excuser pour la gêne occasionnée.*
>
>
>
> *[Communication initiale du vendredi 17 mai 2019]*
>
>
>
> *Destinataires**: contacts «Portal Manager », clients TH1/TH2/TH3*
>
>
>
> *Cher Client,*
>
>
>
> *Le portail Telehouse est temporairement indisponible.*
>
>
>
> *Pour permettre la parfaite continuité de vos opérations, nous vous
> invitons à nous contacter de la manière suivante :*
>
>
>
> *Pour les demandes concernant TH1 Jeûneurs :*
>
> *Par email à l’adresse operations.jeune...@fr.telehouse.net
> *
>
> *Par téléphone au 01 53 00 12 00*
>
>
>
> *Pour les demandes concernant TH2 Voltaire :*
>
> *Par email à l’adresse operations.volta...@fr.telehouse.net
> *
>
> *Par téléphone au 01 56 06 40 40*
>
>
>
> *Pour les demandes concernant TH3 Magny-les-Hameaux :*
>
> *Par email à l’adresse operations.ma...@fr.telehouse.net
> *
>
> *Par téléphone au 01 30 07 36 86*
>
>
>
> *Nous vous tiendrons informés dès que la situation sera revenue à la
> normale ; veuillez nous excuser pour la gêne occasionnée.*
>
>
>
> *Telehouse France*
>
>
>
> Le lun. 27 mai 2019 à 15:03, Hugues Voiturier 
> a écrit :
>
>> Hello,
>>
>> Pareil ici, plus d’accès :/
>>
>>
>> Hugues
>> AS57199 - AS50628
>>
>> > On 27 May 2019, at 15:00, Kevin Thiou  wrote:
>> >
>> > Bonjour,
>> >
>> > suis je le seul a ne pas réussir à me connecter à l'extranet telehouse ?
>> >
>> > Récupération de mot de passe ne fonctionne pas non plus.
>> >
>> > Bonne journée
>> >
>> > ---
>> > 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/


[FRnOG] [TECH] acces extranet telehouse

2019-05-27 Par sujet Kevin Thiou
Bonjour,

suis je le seul a ne pas réussir à me connecter à l'extranet telehouse ?

Récupération de mot de passe ne fonctionne pas non plus.

Bonne journée

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


Re: [FRnOG] [TECH] Mikrotik RB2011 performance wifi

2019-05-14 Par sujet Kevin Thiou
Merci David mais parfois 60€ c'est trop.
Je me demande donc si il est possible d'avoir des perf équivalentes entre
mikrotik et technicolor.

Le mar. 14 mai 2019 à 14:44, David Ponzone  a
écrit :

> Solution: arrêter de jouer avec les WIFI embarqués des routeurs et mettre
> un AP sérieux à 60€
>
> J’ai tout eu avec des Technicolor, j’ai tout eu avec des Mikrotik. Ces
> trucs c’est de l’appoint, comme une LB.
>
> > Le 14 mai 2019 à 14:34, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > Nous passons notre parce de modem/routeur (technicolor) actuel en bridge
> et
> > ajoutons un mikrotik RB2011 pour la partie routage/wifi.
> >
> > Le retour que j'ai des clients c'est que le wifi est moins bon.
> >
> > Suis je le seul à avoir ce genre de problèmes ?
> > Avez vous des solutions pour améliorer le wifi sur ces routeurs ?
> >
> > Merci
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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


[FRnOG] [TECH] Mikrotik RB2011 performance wifi

2019-05-14 Par sujet Kevin Thiou
Bonjour,

Nous passons notre parce de modem/routeur (technicolor) actuel en bridge et
ajoutons un mikrotik RB2011 pour la partie routage/wifi.

Le retour que j'ai des clients c'est que le wifi est moins bon.

Suis je le seul à avoir ce genre de problèmes ?
Avez vous des solutions pour améliorer le wifi sur ces routeurs ?

Merci

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


[FRnOG] [BIZ] Zayo

2019-04-26 Par sujet Kevin Thiou
Bonjour,

y a t'il quelqu'un de Zayo dans l'assistance qui souhaiterait répondre à
mes questions ?

Je voudrais parler upgrade de mon transit actuel mais mon contact
commercial doit être ou très occupé ou très décédé car je n'ai jamais de
réponse à mes e-mail.

Merci

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


Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-19 Par sujet Kevin Thiou
Moi no plus je ne touche pas la MTU.

Merci Alexandre je vais effectivement vérifier je ne vois pas d'autre
raison au drop.

Le jeu. 18 avr. 2019 à 20:09, Alexandre DERUMIER  a
écrit :

> >>Quelles pourrait être la raison de leur disparition ? Si le paquet est
> trop
> >>gros, le switch va en faire plusieurs petits non ?
>
> Ca depend si le protocol/client spécifie le "do not fragment bit"  (DF).
>
> dans ce cas, ca drop.
>
> (par exemple, avec https c'est le cas généralement, avec que http non. )
>
>
>
> - Mail original -
> De: "Kevin Thiou" 
> Cc: "frnog-tech" 
> Envoyé: Jeudi 18 Avril 2019 10:31:35
> Objet: Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper
> ex3400
>
> J'ai continué à chercher, mais je me pose une question sur la disparition
> de mes paquets.
>
> Quelles pourrait être la raison de leur disparition ? Si le paquet est
> trop
> gros, le switch va en faire plusieurs petits non ?
>
> Le mer. 17 avr. 2019 à 10:47, Kevin Thiou  a écrit
> :
>
> > Effectivement il y a quelque chose qui joue avec ma MTU.
> > Sur la pieuvre, quelque soit la MTU que je configure, je me retrouve
> avec
> > une MTU à 1574 derrière le Pfsense (je soupçonne le scrubbing).
> >
> > Du coup je vais sortir le pfsense de la chaîne pour voir si c'est mieux.
> >
> > Merci de vos réponses.
> >
> > Le mar. 16 avr. 2019 à 17:00, Kevin Thiou  a
> écrit :
> >
> >> C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de
> rapport
> >> à la borne vu que les paquets sont bien envoyés en voix ou en vidéo.
> >>
> >> Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou 
> a
> >> écrit :
> >>
> >>> Bonsoir
> >>>
> >>> Peux-tu donner les caractéristiques de la pieuvre ?
> >>>
> >>> Envoyé de mon iPhone
> >>>
> >>> Kamel
> >>>
> >>> > Le 16 avr. 2019 à 16:09, Kevin Thiou  a écrit
> :
> >>> >
> >>> > Bonjour,
> >>> >
> >>> > j'ai un problème auquel je ne trouve pas de solution.
> >>> >
> >>> > Je test une nouvelle pieuvre qui a des capacités vidéo.
> >>> >
> >>> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo
> l'appel
> >>> > n'aboutie pas.
> >>> >
> >>> > J'ai fais des traces pour voir où cela coince. J'arrive à la
> >>> conclusion que
> >>> > les paquets INVITE sont perdus entre un esxi et l'interface du
> switch
> >>> où
> >>> > celui-ci est connecté.
> >>> >
> >>> > Ca me parait étrange, donc une de mes traces doit être bancale.
> >>> >
> >>> > Sur l'esxi je fais :
> >>> >
> >>> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
> >>> > The trace session is enabled.
> >>> > The session filter IP(src or dst) address is 172.19.136.58
> >>> > The session filter VLAN is 515
> >>> > The output file is capture
> >>> > No server port specifed, select 48586 as the port
> >>> > Local CID 2
> >>> > Listen on port 48586
> >>> > Accept...Vsock connection from port 1033 cid 2
> >>> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
> >>> > failedDestroying session 9
> >>> >
> >>> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options
> >>> analyzer
> >>> > :
> >>> > *set forwarding-options analyzer packet_capture input ingress
> interface
> >>> > ge-0/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input ingress
> interface
> >>> > ge-1/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input egress
> interface
> >>> > ge-1/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input egress
> interface
> >>> > ge-0/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture output interface
> >>> > ge-0/0/47.0*
> >>> >
> >>> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
> >>> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*
> >>> >
> >>> > Je me retrouve avec rien dans la capture.
> >>> >
> >>> > Quelqu'un aurait il une idée ?
> >>> >
> >>> > ---
> >>> > 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] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-18 Par sujet Kevin Thiou
J'ai continué à chercher, mais je me pose une question sur la disparition
de mes paquets.

Quelles pourrait être la raison de leur disparition ? Si le paquet est trop
gros, le switch va en faire plusieurs petits non ?

Le mer. 17 avr. 2019 à 10:47, Kevin Thiou  a écrit :

> Effectivement il y a quelque chose qui joue avec ma MTU.
> Sur la pieuvre, quelque soit la MTU que je configure, je me retrouve avec
> une MTU à 1574 derrière le Pfsense (je soupçonne le scrubbing).
>
> Du coup je vais sortir le pfsense de la chaîne pour voir si c'est mieux.
>
> Merci de vos réponses.
>
> Le mar. 16 avr. 2019 à 17:00, Kevin Thiou  a écrit :
>
>> C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de rapport
>> à la borne vu que les paquets sont bien envoyés en voix ou en vidéo.
>>
>> Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou  a
>> écrit :
>>
>>> Bonsoir
>>>
>>> Peux-tu donner les caractéristiques de la pieuvre ?
>>>
>>> Envoyé de mon iPhone
>>>
>>> Kamel
>>>
>>> > Le 16 avr. 2019 à 16:09, Kevin Thiou  a écrit :
>>> >
>>> > Bonjour,
>>> >
>>> > j'ai un problème auquel je ne trouve pas de solution.
>>> >
>>> > Je test une nouvelle pieuvre qui a des capacités vidéo.
>>> >
>>> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo l'appel
>>> > n'aboutie pas.
>>> >
>>> > J'ai fais des traces pour voir où cela coince. J'arrive à la
>>> conclusion que
>>> > les paquets INVITE sont perdus entre un esxi et l'interface du switch
>>> où
>>> > celui-ci est connecté.
>>> >
>>> > Ca me parait étrange, donc une de mes traces doit être bancale.
>>> >
>>> > Sur l'esxi je fais :
>>> >
>>> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
>>> > The trace session is enabled.
>>> > The session filter IP(src or dst) address is 172.19.136.58
>>> > The session filter VLAN is 515
>>> > The output file is capture
>>> > No server port specifed, select 48586 as the port
>>> > Local CID 2
>>> > Listen on port 48586
>>> > Accept...Vsock connection from port 1033 cid 2
>>> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
>>> > failedDestroying session 9
>>> >
>>> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options
>>> analyzer
>>> > :
>>> > *set forwarding-options analyzer packet_capture input ingress interface
>>> > ge-0/0/0.0*
>>> > *set forwarding-options analyzer packet_capture input ingress interface
>>> > ge-1/0/0.0*
>>> > *set forwarding-options analyzer packet_capture input egress interface
>>> > ge-1/0/0.0*
>>> > *set forwarding-options analyzer packet_capture input egress interface
>>> > ge-0/0/0.0*
>>> > *set forwarding-options analyzer packet_capture output interface
>>> > ge-0/0/47.0*
>>> >
>>> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
>>> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*
>>> >
>>> > Je me retrouve avec rien dans la capture.
>>> >
>>> > Quelqu'un aurait il une idée ?
>>> >
>>> > ---
>>> > Liste de diffusion du FRnOG
>>> > http://www.frnog.org/
>>>
>>>

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


Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-17 Par sujet Kevin Thiou
Effectivement il y a quelque chose qui joue avec ma MTU.
Sur la pieuvre, quelque soit la MTU que je configure, je me retrouve avec
une MTU à 1574 derrière le Pfsense (je soupçonne le scrubbing).

Du coup je vais sortir le pfsense de la chaîne pour voir si c'est mieux.

Merci de vos réponses.

Le mar. 16 avr. 2019 à 17:00, Kevin Thiou  a écrit :

> C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de rapport à
> la borne vu que les paquets sont bien envoyés en voix ou en vidéo.
>
> Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou  a
> écrit :
>
>> Bonsoir
>>
>> Peux-tu donner les caractéristiques de la pieuvre ?
>>
>> Envoyé de mon iPhone
>>
>> Kamel
>>
>> > Le 16 avr. 2019 à 16:09, Kevin Thiou  a écrit :
>> >
>> > Bonjour,
>> >
>> > j'ai un problème auquel je ne trouve pas de solution.
>> >
>> > Je test une nouvelle pieuvre qui a des capacités vidéo.
>> >
>> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo l'appel
>> > n'aboutie pas.
>> >
>> > J'ai fais des traces pour voir où cela coince. J'arrive à la conclusion
>> que
>> > les paquets INVITE sont perdus entre un esxi et l'interface du switch où
>> > celui-ci est connecté.
>> >
>> > Ca me parait étrange, donc une de mes traces doit être bancale.
>> >
>> > Sur l'esxi je fais :
>> >
>> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
>> > The trace session is enabled.
>> > The session filter IP(src or dst) address is 172.19.136.58
>> > The session filter VLAN is 515
>> > The output file is capture
>> > No server port specifed, select 48586 as the port
>> > Local CID 2
>> > Listen on port 48586
>> > Accept...Vsock connection from port 1033 cid 2
>> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
>> > failedDestroying session 9
>> >
>> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options
>> analyzer
>> > :
>> > *set forwarding-options analyzer packet_capture input ingress interface
>> > ge-0/0/0.0*
>> > *set forwarding-options analyzer packet_capture input ingress interface
>> > ge-1/0/0.0*
>> > *set forwarding-options analyzer packet_capture input egress interface
>> > ge-1/0/0.0*
>> > *set forwarding-options analyzer packet_capture input egress interface
>> > ge-0/0/0.0*
>> > *set forwarding-options analyzer packet_capture output interface
>> > ge-0/0/47.0*
>> >
>> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
>> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*
>> >
>> > Je me retrouve avec rien dans la capture.
>> >
>> > Quelqu'un aurait il une idée ?
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>

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


Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-16 Par sujet Kevin Thiou
C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de rapport à
la borne vu que les paquets sont bien envoyés en voix ou en vidéo.

Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou  a
écrit :

> Bonsoir
>
> Peux-tu donner les caractéristiques de la pieuvre ?
>
> Envoyé de mon iPhone
>
> Kamel
>
> > Le 16 avr. 2019 à 16:09, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > j'ai un problème auquel je ne trouve pas de solution.
> >
> > Je test une nouvelle pieuvre qui a des capacités vidéo.
> >
> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo l'appel
> > n'aboutie pas.
> >
> > J'ai fais des traces pour voir où cela coince. J'arrive à la conclusion
> que
> > les paquets INVITE sont perdus entre un esxi et l'interface du switch où
> > celui-ci est connecté.
> >
> > Ca me parait étrange, donc une de mes traces doit être bancale.
> >
> > Sur l'esxi je fais :
> >
> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
> > The trace session is enabled.
> > The session filter IP(src or dst) address is 172.19.136.58
> > The session filter VLAN is 515
> > The output file is capture
> > No server port specifed, select 48586 as the port
> > Local CID 2
> > Listen on port 48586
> > Accept...Vsock connection from port 1033 cid 2
> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
> > failedDestroying session 9
> >
> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options
> analyzer
> > :
> > *set forwarding-options analyzer packet_capture input ingress interface
> > ge-0/0/0.0*
> > *set forwarding-options analyzer packet_capture input ingress interface
> > ge-1/0/0.0*
> > *set forwarding-options analyzer packet_capture input egress interface
> > ge-1/0/0.0*
> > *set forwarding-options analyzer packet_capture input egress interface
> > ge-0/0/0.0*
> > *set forwarding-options analyzer packet_capture output interface
> > ge-0/0/47.0*
> >
> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*
> >
> > Je me retrouve avec rien dans la capture.
> >
> > Quelqu'un aurait il une idée ?
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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


[FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-16 Par sujet Kevin Thiou
Bonjour,

j'ai un problème auquel je ne trouve pas de solution.

Je test une nouvelle pieuvre qui a des capacités vidéo.

Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo l'appel
n'aboutie pas.

J'ai fais des traces pour voir où cela coince. J'arrive à la conclusion que
les paquets INVITE sont perdus entre un esxi et l'interface du switch où
celui-ci est connecté.

Ca me parait étrange, donc une de mes traces doit être bancale.

Sur l'esxi je fais :

*pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
The trace session is enabled.
The session filter IP(src or dst) address is 172.19.136.58
The session filter VLAN is 515
The output file is capture
No server port specifed, select 48586 as the port
Local CID 2
Listen on port 48586
Accept...Vsock connection from port 1033 cid 2
*Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
failedDestroying session 9

Sur le switch c'est un ex3400 j'ai configuré un forwarding-options analyzer
:
*set forwarding-options analyzer packet_capture input ingress interface
ge-0/0/0.0*
*set forwarding-options analyzer packet_capture input ingress interface
ge-1/0/0.0*
*set forwarding-options analyzer packet_capture input egress interface
ge-1/0/0.0*
*set forwarding-options analyzer packet_capture input egress interface
ge-0/0/0.0*
*set forwarding-options analyzer packet_capture output interface
ge-0/0/47.0*

qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
*sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*

Je me retrouve avec rien dans la capture.

Quelqu'un aurait il une idée ?

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


Re: [FRnOG] [BIZ] Re: Interco TH2 > PA5 & TH2 > PA6

2019-03-28 Par sujet Kevin Thiou
Pensez vous que les FAS annoncés sur lambdaparis soientt négociables ?

Le jeu. 28 mars 2019 à 11:46, Kevin Thiou  a écrit :

> Merci a tous pour les infos.
>
> Le jeu. 28 mars 2019 à 11:44, David Ponzone  a
> écrit :
>
>> Lambda passif: 225€/mois entre 2 DC parisiens
>>
>> https://lambdaparis.com/contacts/new
>>
>> Oui, une FON sera plus chère. Pas forcément beaucoup plus compte tenu du
>> fait qu’avec le bon matos, tu peux faire passer 6 Tbps dessus :)
>>
>> Le 28 mars 2019 à 11:25, Kevin Thiou  a écrit :
>>
>> J'imagine que le tarif est beaucoup moins cher si je commande une longueur
>> d'onde. Je me trompe ?
>>
>> je n'ai besoin que de brancher une paire de fibre vers PA5 et PA6.
>>
>> Le jeu. 28 mars 2019 à 11:12, Kevin Thiou  a écrit
>> :
>>
>> Bonjour,
>>
>> J'ai besoin de connaitre le prix d'une fibre noire (1 paire) entre TH2 >
>> P5 et TH2 > PA6.
>>
>> quelqu'un a une idée de tarif ? et des meilleurs prestataires ?
>>
>> Merci
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>

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


Re: [FRnOG] [BIZ] Re: Interco TH2 > PA5 & TH2 > PA6

2019-03-28 Par sujet Kevin Thiou
Merci a tous pour les infos.

Le jeu. 28 mars 2019 à 11:44, David Ponzone  a
écrit :

> Lambda passif: 225€/mois entre 2 DC parisiens
>
> https://lambdaparis.com/contacts/new
>
> Oui, une FON sera plus chère. Pas forcément beaucoup plus compte tenu du
> fait qu’avec le bon matos, tu peux faire passer 6 Tbps dessus :)
>
> Le 28 mars 2019 à 11:25, Kevin Thiou  a écrit :
>
> J'imagine que le tarif est beaucoup moins cher si je commande une longueur
> d'onde. Je me trompe ?
>
> je n'ai besoin que de brancher une paire de fibre vers PA5 et PA6.
>
> Le jeu. 28 mars 2019 à 11:12, Kevin Thiou  a écrit :
>
> Bonjour,
>
> J'ai besoin de connaitre le prix d'une fibre noire (1 paire) entre TH2 >
> P5 et TH2 > PA6.
>
> quelqu'un a une idée de tarif ? et des meilleurs prestataires ?
>
> Merci
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

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


[FRnOG] [BIZ] Re: Interco TH2 > PA5 & TH2 > PA6

2019-03-28 Par sujet Kevin Thiou
J'imagine que le tarif est beaucoup moins cher si je commande une longueur
d'onde. Je me trompe ?

je n'ai besoin que de brancher une paire de fibre vers PA5 et PA6.

Le jeu. 28 mars 2019 à 11:12, Kevin Thiou  a écrit :

> Bonjour,
>
> J'ai besoin de connaitre le prix d'une fibre noire (1 paire) entre TH2 >
> P5 et TH2 > PA6.
>
> quelqu'un a une idée de tarif ? et des meilleurs prestataires ?
>
> Merci
>

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


[FRnOG] [BIZ] Interco TH2 > PA5 & TH2 > PA6

2019-03-28 Par sujet Kevin Thiou
Bonjour,

J'ai besoin de connaitre le prix d'une fibre noire (1 paire) entre TH2 > P5
et TH2 > PA6.

quelqu'un a une idée de tarif ? et des meilleurs prestataires ?

Merci

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


Re: [FRnOG] [TECH] iptables me rendra fou

2019-01-29 Par sujet Kevin Thiou
Merci pour vos réponses malheureusement aucune piste ne me permet une
résolution.

J'y reviendrais mais la plus envie

Le lun. 28 janv. 2019 à 10:59, Guillaume Tournat  a
écrit :

> Le nom peut être rendu déterministe par une règle udev ou par inscription
> de la MAC address dans les fichiers /etc/sud config/network-scripts/ifcfg-*
>
>
> > Le 28 janv. 2019 à 09:09, Alexandre PIERRET <
> alexandre.pierret-fr...@loiklo.net> a écrit :
> >
> > De mémoire, en RH6 et avant, le système nomme initialement les ethX dans
> > l’ordre d’apparition, puis un script vient les renommer (pour suivre le
> > fichier de conf) par un jeu de taquin. Le problème est que ce script
> n’est
> > pas atomique et pendant le jeu de taquin, si une interface est détecté
> elle
> > peut prendre la place d’une interface cible (du jeu de taquin) pendant le
> > renommage. Et donc l'interface 'en cours de renommage' n'a pas de nom car
> > la place a déjà été prise entre temps.
> >
> > En RH7, par défaut, les interfaces sont nommées en fonction de leur
> > emplacement physique et donc elles ont leur nom définitif dès la
> détection.
> > Etant donné ce fonctionnement par défaut, il n’y a plus le script de
> > renommage dans RH7, le nom est donné par ordre d'apparition.
> >
> > Si on repasse au nommage legacy (ethX) sur du RH7, les interfaces sont
> donc
> > nommées uniquement suivant leur ordre de détection. Donc à chaque reboot,
> > elles peuvent changer de nom, on a eu le cas sur une sonde réseau
> notamment
> > qui possède un grand nombre d'interfaces.
> >
> > Sauf à vouloir implémenter un système maison de nommage d'interface, il
> est
> > fortement déconseillé de repasser en nommage legacy sur une machine qui
> > possède plus d'une interface à partir de la RH7.
> >
> > Alex
> >
> > On Sun, Jan 27, 2019 at 6:34 PM Jonathan Leroy <
> jonat...@unsigned.inikup.com>
> > wrote:
> >
> >>> Le dim. 27 janv. 2019 à 16:54, Johan Fleury  a
> écrit :
> >>> Je ne suis pas un grand fan ni de networkd, ni de resolvd, mais il faut
> >> reconnaître que ce dernier a des features intéressantes : validation
> >> DNSSEC, DNS over TLS avec fallback, etc.
> >>
> >> Oh la la malheureux, je te conseille de retirer ça, de présenter
> >> tes excuses, de dire que la journée n’avait pas été facile, etc... :)
> >>
> >> La dernière fois que j’ai dit publiquement du bien de systemd (sur
> >> FRSAG, pas ici), les gens d’accord avec moi sont venus me le dire
> >> majoritairement *en privé*, parce que tu comprends, l’avouer
> >> publiquement c’est prendre le risque de se faire traiter de tous les
> >> noms (j’exagère à peine).
> >>
> >> systemd, toutes les distribs y sont passées pour une raison : le tas
> >> de script bash utilisés précédemment est une horreur à maintenir et
> >> dans certains cas à utiliser. Ceux qui s’y opposent le font soit pour
> >> suivre le mouvement, soit parce qu’ils ne veulent pas trop remettre en
> >> question tout ce qu’ils ont appris il y a des années. Sûrement les
> >> mêmes qui t’expliquent qu’il n’y a pas de souci à utiliser qmail en
> >> 2019.
> >>
> >>
> >> ---
> >> 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/


[FRnOG] [TECH] Re: iptables me rendra fou

2019-01-25 Par sujet Kevin Thiou
Au niveau routage on est bien aussi :

172.22.0.0/24 via 172.31.254.1 dev tun4
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.254

Le ven. 25 janv. 2019 à 17:07, Kevin Thiou  a écrit :

> Bonjour, bonsoir,
>
> depuis quelques temps je me bats avec iptables pour un accès tout con mais
> que je ne parviens pas à faire fonctionner.
>
> ce que je souhaite :
>
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
>
> je vois les paquets arriver sur l'interface de la machine iptables avec un
> tcpdump :
>
> tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
> 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
> 0,nop,wscale 7], length 0
> 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
> 0,nop,wscale 7], length 0
>
> tous les prerouting (raw, mangle, nat) sont à accept.
>
>  iptables -vL -t mangle -n
> Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
> l'autoriser, j'ai donc mis les lignes suivantes :
>
> iptables -S FORWARD
> -P FORWARD DROP
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
> -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO
>
> et j'ai rien dans les logs.
>
> Où peuvent donc passer ces paquets ?
>
> Merci de votre aide.
>

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


[FRnOG] [TECH] iptables me rendra fou

2019-01-25 Par sujet Kevin Thiou
Bonjour, bonsoir,

depuis quelques temps je me bats avec iptables pour un accès tout con mais
que je ne parviens pas à faire fonctionner.

ce que je souhaite :

-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour

je vois les paquets arriver sur l'interface de la machine iptables avec un
tcpdump :

tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
0,nop,wscale 7], length 0
16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
0,nop,wscale 7], length 0

tous les prerouting (raw, mangle, nat) sont à accept.

 iptables -vL -t mangle -n
Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
 pkts bytes target prot opt in out source
 destination
Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
 pkts bytes target prot opt in out source
 destination
Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
 pkts bytes target prot opt in out source
 destination
Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
 pkts bytes target prot opt in out source
 destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
 pkts bytes target prot opt in out source
 destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
 pkts bytes target prot opt in out source
 destination

j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
l'autoriser, j'ai donc mis les lignes suivantes :

iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
-A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO

et j'ai rien dans les logs.

Où peuvent donc passer ces paquets ?

Merci de votre aide.

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


Re: [FRnOG] [TECH] Iperf

2018-12-07 Par sujet Kevin Thiou
Pas utilisé depuis longtemps mais jperf avait une gui windows et mac

Le ven. 7 déc. 2018 à 10:23, Arnaud BRAND  a
écrit :

> Je sais que ce n'est pas exactement ta question, mais
> http://proof.ovh.net/ utilise un plugin nperf qui marche plutôt pas mal.
> Tu peux envoyer et recevoir plusieurs centaines de Mbps sans soucis.
> Après je suppose que ça dépend au moins un peu de la pêche du PC qui
> fait tourner le plugin.
> Mais c'est plutôt pratique pour les incompétents.
>
> Potentiellement, en regardant le chargement/code du plugin tu trouveras
> peut-être même un/des serveurs iperf derrière
>
>
>
> Le 2018-12-07 08:49, David Ponzone a écrit :
> > Tous,
> >
> > 2 questions sur iperf:
> >
> > -y a-t-il un GUI pour Win/Mac ?  J’ai rien trouvé sauf un vieux truc
> > qui dépend de Java6….
> >
> > -y a-t-il un serveur ouvert sans limite en UDP ? :) Online semble
> > limiter l’UDP à 5Mbps maintenant, ce que je comprends bien entendu. Je
> > sais que je peux faire tourner le mien, mais c’est pour permettre à un
> > prestataire informatique incompétent de faire un test sans m’accuser
> > de tricher….
> >
> > Merci!
> >
> >
> > ---
> > 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] [ALERT] Problème TH2 ?

2018-11-26 Par sujet Kevin Thiou
environ oui :)

Le lun. 26 nov. 2018 à 17:06, David Ponzone  a
écrit :

> De 16h26 à 16h40 environ ?
>
>
> > Le 26 nov. 2018 à 17:00, Kevin Thiou  a écrit :
> >
> > Bonjour,
> >
> > je viens de perdre une partie de mes clients pendant un rien de temps.
> >
> > J'ai l'impression que le problème était situé à TH2 car les collectes ou
> > j'ai du secours à CBV n'ont pas bougé.
> >
> > Les plus grosses impactes sont sur les collectes avec un RAD mono-alim.
> >
> > Un problème électrique à TH2 ? Quelqu'un d'autre aurait eu le même
> > symptômes ?
> >
> > Merci
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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


[FRnOG] [ALERT] Problème TH2 ?

2018-11-26 Par sujet Kevin Thiou
Bonjour,

je viens de perdre une partie de mes clients pendant un rien de temps.

J'ai l'impression que le problème était situé à TH2 car les collectes ou
j'ai du secours à CBV n'ont pas bougé.

Les plus grosses impactes sont sur les collectes avec un RAD mono-alim.

Un problème électrique à TH2 ? Quelqu'un d'autre aurait eu le même
symptômes ?

Merci

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


[FRnOG] [ALERT] SFR BSOD

2018-09-26 Par sujet Kevin Thiou
Bonjour,

je suis le seul à avoir perdu SFR BSOD ?

Merci

PS: désolé pour le spam le premier est parti un peu vite dans la mauvaise ML

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


[FRnOG] [TECH] Problème BSOD SFR

2018-09-26 Par sujet Kevin Thiou
Bonjour,

je suis le seul à avoir perdu SFR BSOD ?

Merci

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


[FRnOG] [TECH] Mikrotik /system default-configuration

2018-09-04 Par sujet Kevin Thiou
Bonjour,

j'essai depuis quelques temps de changer la configuration par défaut des
mikrotik que nous déployons.

Pour moi il y a 2 manières de faire : Netinstall ou le Branding package
maker.

Pour Netinstall la documentation dit :
*Configure script* (*yes | no*; Default: *no*) If set, then Netinstall will
apply a custom configuration script after installing RouterOS. The file
must be in *.rsc* file format and must be produced by the export command
.
The configuration script will replace the device's default configuration
and will be applied each time you reset your device back to the default
configuration. Resetting the device without the default configuration is
not affected. This behaviour can be reverted using Netinstall and by
selecting Apply default config.

Malgré de multiples essais je n'arrive pas à faire garder la configuration
au routeur lorsque que je fais /system reset-configration

Branding Package Maker :

J'ai réussi à faire un fichier qui fonctionne, mais qui n'était pas complet.
J'ai l'impression qu'il y a un cache chez Mikrotik et que une fois le
fichier de conf poussé et le fichier dpk généré la conf ne bouge plus.
Le site affiche le bon fichier dans la partie à droite (upload) mais à la
génération il utilise un vieux fichier.

Suis-je le seul à avoir des problème sur ce site ?

Merci de votre clairvoyance.

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


Re: [FRnOG] [TECH] /31 sur Brocade NI-MLX-MR

2018-07-30 Par sujet Kevin Thiou
Salut,

je suis en 5.1 et je ne peux pas utiliser de /31, je crois que c'est la
version 5.3 mais je voulais être sur.

Le 30 juillet 2018 à 15:01, Romain Degez  a écrit :

> Salut Kevin,
>
> Difficile de te donner la version exacte mais de mémoire le support des
> /31 a été ajouté il y a plusieurs années (autour de la version 5.0 je
> dirais ?).
>
> ++
>
> --
> rd
>
>
> 2018-07-30 11:06 GMT+02:00 Kevin Thiou :
>
>> Bonjour,
>>
>> quelqu'un saurait si une mise à jour permet de faire accepter les /31 à un
>> Brocade NI-MLX-MR ?
>>
>> Merci
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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


[FRnOG] [TECH] /31 sur Brocade NI-MLX-MR

2018-07-30 Par sujet Kevin Thiou
Bonjour,

quelqu'un saurait si une mise à jour permet de faire accepter les /31 à un
Brocade NI-MLX-MR ?

Merci

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


Re: [FRnOG] [TECH] UDP Storm 1 vs Mikrotik 0

2018-07-23 Par sujet Kevin Thiou
Cela fait plusieurs fois que je me prends une bonne rasade de paquet UDP
sur mes Mikrotik RB2011.

Surtout sur des accès assez gros genre BSOD 500Mbps.

Je le vois parce que ma courbe de transit monte d'un coût.

Je mets une règle reject vers l'adresse en question avec une réponse icmp
network unreachable et à chaque fois ca s’arrête dans la seconde.

Il faudrait pouvoir bloquer les ip au niveau du transitaire mais j'ai pas
le niveau de service nécessaire :)

Le 20 juillet 2018 à 22:41, David Ponzone  a écrit
:

> Expiry attack ?
> https://www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.html
>
> Faut croire que MK n’aime pas ça, mais j’ai jamais vu le CPU monter très
> haut, mais ça doit pourtant être ça.
>
> Merci Olivier!
>
>
> > Le 20 juil. 2018 à 22:19, Olivier Benghozi 
> a écrit :
> >
> > Je vote pour des paquets IP avec TTL à 1
> >
> >> Le 20 juil. 2018 à 20:10, David Ponzone  a
> écrit :
> >>
> >> Contexte: un Mikrotik (RB3011 dernier firmware) qui termine des
> sessions PPPoE
> >> J’ai vu un flux de paquets UDP venant de l’IP publique d’un des clients
> PPPoE, port source aléatoire, allant tous vers une IP publique d’un abonné
> Timewarner.
> >> Débit du flux: autour de 90Mbps
> >> [...]
> >> Soit soit j’aurais dû en fait vérifier une 4ème fois, soit des mecs ont
> trouvé une attaque UDP qui font mal au serveur PPPoE du Mikrotik et ne vont
> pas plus loin.
> >
> >
> > ---
> > 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/


[FRnOG] [TECH] Re: Ipsec/L2TP/Mikrotik

2018-06-29 Par sujet Kevin Thiou
Auto réponse :)

il manquait juste une route.

dst-address= pref-src=
gateway= reachable distance=1
scope=30 target-scope=10

Si ca peut aider certains

Le 29 juin 2018 à 09:45, Kevin Thiou  a écrit :

> Bonjour,
>
> j'ai monté un tunnel en mode "Road Warrior" entre 2 routeurs mikrotik en
> suivant la doc : https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Road_
> Warrior_setup_with_Mode_Conf
>
> J'ai besoin de ce mode car je ne connais pas à l'avance les adresses de
> mes peer Ipsec.
>
> Le tunnel monte bien.
>
> Par contre je cherche ensuite à faire passer une session L2TP dans  ce
> tunnel Ipsec. Mais je ne monte pas le L2TP sur le mikrotik mais sur un
> autre équipement dans le réseau.
>
> Et c'est la que ça coince. La session utilise la table de routage du
> routeur pour établir la session et sort par l'interface avec la gateway
> mais pas par le tunnel Ipsec.
>
> J'imagine que cela a rapport avec les policy mais pas moyen de trouver
> comment faire pour que le trafic passe dans le tunnel.
>
> La doc ipsec est un peu légère chez mikrotik.
>
> Quelqu'un sait faire ça ?
>
>
>

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


[FRnOG] [TECH] Ipsec/L2TP/Mikrotik

2018-06-29 Par sujet Kevin Thiou
Bonjour,

j'ai monté un tunnel en mode "Road Warrior" entre 2 routeurs mikrotik en
suivant la doc :
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Road_Warrior_setup_with_Mode_Conf

J'ai besoin de ce mode car je ne connais pas à l'avance les adresses de mes
peer Ipsec.

Le tunnel monte bien.

Par contre je cherche ensuite à faire passer une session L2TP dans  ce
tunnel Ipsec. Mais je ne monte pas le L2TP sur le mikrotik mais sur un
autre équipement dans le réseau.

Et c'est la que ça coince. La session utilise la table de routage du
routeur pour établir la session et sort par l'interface avec la gateway
mais pas par le tunnel Ipsec.

J'imagine que cela a rapport avec les policy mais pas moyen de trouver
comment faire pour que le trafic passe dans le tunnel.

La doc ipsec est un peu légère chez mikrotik.

Quelqu'un sait faire ça ?

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


  1   2   >