[FRnOG] [MISC] recherche IP

[Cyril CALMON TOTALCLOUD]

Bonjour,

Nous sommes à la recherche d'achat d' IP pour un /22 ou plus.

Si vous avez des contacts je suis preneur.

Merci



[https://www.totalcloud.fr/logos/logo-total-cloud2.jpg]

Cyril CALMON
Responsable de site
TOTALCLOUD
22 Rue Olympe de Gouges - 38400 SAINT MARTIN D'HERES
Ligne Directe : +33 4 81 09 06 99
GSM : +33 6 15 98 17 57




Totalcloud partenaire des BDL

[https://www.totalcloud.fr/logos/logobdl.png]



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

RE: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Michel Py]

> Oliver varenne a écrit :
> Ecoute, on va pas chercher. Si rien ne vous viens à l'esprit tant pis vais 
> rester
> en NV2, ça a l'air de tenir et le débit reste plus que correct comparé à 
> l'ADSL.

Tu as 2 options à explorer :
1. Inspection physique. La merde de pigeon sur le feed horn, çà fait ce genre 
de chose.
2. Tout éteindre et faire une analyse de spectre, ce qui va demander du matos.

Bon courage.

Michel.


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

[MISC] RE: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

Oui depuis au moins septembre dernier. Peut être même aout.
C'est arrivé soudainement. Pouf.

En gros je viens de tester: 
Je passe en Nstreme sans rien changer aux autres paramètres
Meme pas 40 secondes apres la connexion: déconnexion avec l'erreur "Extensive 
data loss"

Et la, il est 02h54 am... donc le télétravail ne rentre pas en ligne de compte

Ecoute, on va pas chercher. Si rien ne vous viens à l'esprit tant pis
Vais rester en NV2, ça a l'air de tenir et le débit reste plus que correct 
comparé à l'ADSL.


Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




-Message d'origine-
De : Michel Py  
Envoyé : vendredi 17 avril 2020 22:44
À : Oliver varenne ; 'Florent Rivoire' 

Cc : frnog-m...@frnog.org
Objet : RE: [FRnOG] [MISC] Question relative au protocoles utilisés par 
Mikrotik en Wifi

> Oliver varenne a écrit :
> Michel en fait ta théorie ne tient pas car j'ai également des décos la 
> nuit a 3h du mat. Je doute que le wifi soit a fond chez les gens la nuit...

Ben a part les rayons cosmiques et les extra-terrestres, on n'a pas grand-chose 
à se mettre sous la dent.
Cà faisait plusieurs mois que t'étais stable ?

Michel.


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

RE: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Michel Py]

> Oliver varenne a écrit :
> Michel en fait ta théorie ne tient pas car j'ai également des décos la
> nuit a 3h du mat. Je doute que le wifi soit a fond chez les gens la nuit...

Ben a part les rayons cosmiques et les extra-terrestres, on n'a pas grand-chose 
à se mettre sous la dent.
Cà faisait plusieurs mois que t'étais stable ?

Michel.


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

[FRnOG] [MISC] Monaco

[Julien OHAYON]

Bonjour,


Un de nos partenaires souhaite pouvoir fournir de la voix pour ses clients à 
Monaco via nos offres.


Avez-vous en tête un provider sur place ou un contact chez Monaco Telecom à 
partager ?


Merci d'avance

Julien

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

[MISC] Re: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

Michel en fait ta théorie ne tient pas car j'ai également des décos la nuit a 
3h du mat. Je doute que le wifi soit a fond chez les gens la nuit...

Si nstreme est aussi du tdma, alors je vois pas d'explication.

Bon, on saura pas...
J'ai tweake un peu plus en passant en 802.11n et en fixant a mcs13.
Comme ça c'est rapide et stable pour le moment.

Pourvu que ça dure.

Envoyé d’Outlook Mobile


From: Michel Py 
Sent: Friday, April 17, 2020 6:28:08 PM
To: 'Florent Rivoire' ; Oliver varenne 

Cc: frnog-m...@frnog.org 
Subject: RE: [FRnOG] [MISC] Question relative au protocoles utilisés par 
Mikrotik en Wifi

> Florent Rivoire a écrit :
> NB: par contre, n'oublie pas que le monde de la radio reste partiellement 
> empirique:

+1000. Il y a des fois ou çà défie toute logique, et on ne le répètera jamais 
assez.

> tu teste, tu vois ce qui marche le mieux pour toi, et tu garde ça :) Ca peut 
> être
> assez difficile de tout expliquer (trop de facteur que tu ne maitrise pas).

Olivier a été particulièrement méthodique quand il a monté son lien.

Michel.


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

RE: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Michel Py]

> Florent Rivoire a écrit :
> NB: par contre, n'oublie pas que le monde de la radio reste partiellement 
> empirique:

+1000. Il y a des fois ou çà défie toute logique, et on ne le répètera jamais 
assez.

> tu teste, tu vois ce qui marche le mieux pour toi, et tu garde ça :) Ca peut 
> être
> assez difficile de tout expliquer (trop de facteur que tu ne maitrise pas).

Olivier a été particulièrement méthodique quand il a monté son lien.

Michel.


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

Re: [MISC] RE: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[Florent Rivoire]

On Fri, Apr 17, 2020 at 5:51 PM Oliver varenne  wrote:
> Ceci dit, j'ai 2 antennes mikrotik en 2.4Ghz qui ont le spectral scan... 
> c'est con

Tes mikrotik en 2.4Ghz ont une radio qui ne pourra (physiquement)
scanner que les fréquences 2.4Ghz.
Donc pas le canal 5Ghz que tu utilise.

Cela ne t'aidera pas à comprendre ton soucis, désolé :p

-- 
Florent


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

Re: [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Florent Rivoire]

On Fri, Apr 17, 2020 at 5:08 PM Oliver varenne  wrote:
> Ma question est simple : qu’est ce qu’il s’est passé d’apres vous pour que 
> d’une heure à l’autre tout à coup je ne puisse plus utiliser nstreme ni 
> 802.11 et que je sois obligé de passer en TDMA ?
> Ou alors TDMA est super résilient aux mauvaises LOS, mais dans ce cas 
> pourquoi ça marchait moins bien que Nstreme avant ??

Une petite précision:

D'après ce que j'ai compris Nstreme et NV2 sont 2 protocoles
propriétaires Mikrotik, et les 2 sont des types "TDMA".
cf: https://en.wikipedia.org/wiki/802.11_non-standard_equipment#TDMA_and_polling

Ils ont donc tous les 2 un fonctionnement différent du protocole
standard (802.11*) qui est de type "CSMA".

Donc la raison de ton changement de comportement n'est pas à chercher
dans le fait d'être sur un protocole type TDMA ou pas (les 2 le sont).
Mais sûrement plus dans le détails de chaque protocole ou leur implémentation.

Et je n'ai pas vraiment de réponse la dessus.
Désolé :(

NB: par contre, n'oublie pas que le monde de la radio reste
partiellement empirique: tu teste, tu vois ce qui marche le mieux pour
toi, et tu garde ça :)
Ca peut être assez difficile de tout expliquer (trop de facteur que tu
ne maitrise pas).

Bon courage !

--
Florent


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

[FRnOG] [ALERT] problème DNS chez Free ?

[Arnaud Wetzel]

Bonjour à tous,
Depuis 20h hier soir, certains de nos DNS ne sont plus résolus par les
serveurs DNS de free.
(les serveurs 212.27.40.240,212.27.53.252 et 212.27.53.252). La totalité
des autres DNS qu'on a pu tester : autres FAI français, différents DNS
publiques interrogeables dans le monde - y compris ceux d' Online -
parviennent à résoudre.

Le plus étonnant est que certains des domaines DNS servis par les mêmes
serveurs DNS fonctionnent correctement depuis chez Free.

Les domaines à problème sont tous les domaines "*.kbrw.fr" et "*.
shoppingadventure.fr". On peut voir le problème sur le "A" de "kbrw.fr"
directement.

> test ci-après depuis une connexion Free.

```
dig A @212.27.40.240 kbrw.fr

; <<>> DiG 9.10.6 <<>> A @212.27.40.240 kbrw.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8612
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;kbrw.fr. IN A

;; Query time: 408 msec
;; SERVER: 212.27.40.240#53(212.27.40.240)
;; WHEN: Fri Apr 17 17:53:15 CEST 2020
;; MSG SIZE  rcvd: 36
```

Est ce que quelqu'un d'autre a ce type de problème sur ses domaines en ce
moment ? est ce qu'un incident sur les DNS Free est en court ?

Cordialement.

Arnaud

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

[MISC] RE: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

J'ai la cagne de remonter sur les 2 toits, démonter, remonter 
Nan mais pour de vrai j'aurai bien testé. Mais vraiment, c'est super casse 
gueule sur mon toit.

Ceci dit, j'ai 2 antennes mikrotik en 2.4Ghz qui ont le spectral scan... c'est 
con 😉

Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




-Message d'origine-
De : David Ponzone  
Envoyé : vendredi 17 avril 2020 17:49
À : Oliver varenne 
Cc : Michel Py ; frnog-m...@frnog.org
Objet : Re: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par 
Mikrotik en Wifi

Je t’avais dit de prendre de l’Ubiquiti, je l’avais dit :)

> Le 17 avr. 2020 à 17:46, Oliver varenne  a écrit :
> 
> Pas sur le model que j'ai: "failure: this device can not do spectral scan"
> De ce que j'ai vu, seul les krotik avec un chipset spécifique on ça...
> 
> J'ai que 2 outils: 
> Freq Usage
> Scan
> 
> Le premier, il scan 😉
> Le second te donne le % d'utilisation du canal.
> 


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

Re: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[David Ponzone]

Je t’avais dit de prendre de l’Ubiquiti, je l’avais dit :)

> Le 17 avr. 2020 à 17:46, Oliver varenne  a écrit :
> 
> Pas sur le model que j'ai: "failure: this device can not do spectral scan"
> De ce que j'ai vu, seul les krotik avec un chipset spécifique on ça...
> 
> J'ai que 2 outils: 
> Freq Usage
> Scan
> 
> Le premier, il scan 😉
> Le second te donne le % d'utilisation du canal.
> 


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

[MISC] RE: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

Pas sur le model que j'ai: "failure: this device can not do spectral scan"
De ce que j'ai vu, seul les krotik avec un chipset spécifique on ça...

J'ai que 2 outils: 
Freq Usage
Scan

Le premier, il scan 😉
Le second te donne le % d'utilisation du canal.




Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




-Message d'origine-
De : David Ponzone  
Envoyé : vendredi 17 avril 2020 17:42
À : Oliver varenne 
Cc : Michel Py ; frnog-m...@frnog.org
Objet : Re: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par 
Mikrotik en Wifi

Y a pas un analyseur de spectre intégré comme sur les Ubiquiti ?

> Le 17 avr. 2020 à 17:40, Oliver varenne  a écrit :
> 
> Oui je n'y ai pas pensé
> Ceci dit, mon ratio signal/bruit devrait être plus faible non?
> Il est à 41db, et ça n'a jamais trop bougé
> 


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

Re: [FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[David Ponzone]

Y a pas un analyseur de spectre intégré comme sur les Ubiquiti ?

> Le 17 avr. 2020 à 17:40, Oliver varenne  a écrit :
> 
> Oui je n'y ai pas pensé
> Ceci dit, mon ratio signal/bruit devrait être plus faible non?
> Il est à 41db, et ça n'a jamais trop bougé
> 


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

[FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

Oui je n'y ai pas pensé
Ceci dit, mon ratio signal/bruit devrait être plus faible non?
Il est à 41db, et ça n'a jamais trop bougé



Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




-Message d'origine-
De : Michel Py  
Envoyé : vendredi 17 avril 2020 17:34
À : Oliver varenne ; frnog-m...@frnog.org
Objet : RE: Question relative au protocoles utilisés par Mikrotik en Wifi

> Oliver varenne a écrit :
> Des interférences ? mais dans ce cas qui viendraient de quoi ? et surtout ça 
> m’impacte sur tout le spectre…

Je dis pas que c'est la bonne explication (ou la seule), mais la logique dit 
que, à cause du confinement justement, tes voisins utilisent WiFi beaucoup plus 
que d'habitude, possiblement en patatant la PIRE, et donc le bruit de fond 
augmente considérablement. T'étais déjà au taquet avec ta liaison, il suffit de 
pas beaucoup pour que çà tombe.

Michel.


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

[FRnOG] [MISC] RE: Question relative au protocoles utilisés par Mikrotik en Wifi

[Michel Py]

> Oliver varenne a écrit :
> Des interférences ? mais dans ce cas qui viendraient de quoi ? et surtout ça 
> m’impacte sur tout le spectre…

Je dis pas que c'est la bonne explication (ou la seule), mais la logique dit 
que, à cause du confinement justement, tes voisins utilisent WiFi beaucoup plus 
que d'habitude, possiblement en patatant la PIRE, et donc le bruit de fond 
augmente considérablement. T'étais déjà au taquet avec ta liaison, il suffit de 
pas beaucoup pour que çà tombe.

Michel.


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

RE: [FRnOG] [TECH] QSFP+ vs SFP28

[Michel Py]

> Laurent-Charles FABRE a écrit :
> late answer mais je viens juste de clicker sur le lien EBay qui montre un 
> jolie switch with "Front
> to back airflow" Autrement appelé PortSide Intake chez certain ou sens de 
> ventilation comme d'hab
> pour les autres. Tant qu'à y être, moi je préfère les switch en Back 2 Front 
> ou Port-Side exhaust
> en clair le coté port du switch monté à l'arrière de la baie.
> 1 - c'est du même coté que les ports des serveurs classiques -> plus facile a 
> câbler quand on est seul
> 2 - il y a souvent plus de dégagement à l'arrière de la baie pour câbler 
> tranquille
> 3 - on peut utiliser des DAC ou FO au plus court -> chuis pas maniaque mais 
> j'aime quand ça respire

J'ai souvent mentionné ici la différence. En usage ToR avec des serveurs dans 
la baie, effectivement il faut le monter ports derrière donc port-side exhaust, 
ce que Cisco appelle çà normal airflow.
Par contre si c'est dans un rack uniquement telco et qu'on s'en sert pour 
connecter sur du panneau de brassage ou d'autre switchs, on les monte ports 
devant, donc port-side intake, ce que Cisco appelle reverse airflow.

https://community.cisco.com/t5/switching/port-side-intake-vs-port-side-exhaust/td-p/2891499

Sur pas mal de modèles, le switch est le même, en changeant les alims et les 
ventilos on le retourne. Sur plusieurs modèles Cisco, les alims et les ventilos 
"reverse" ou port-side intake sont reconnaissables à une bande noire. Dans le 
doute, toujours demander au vendeur les photos des alims et les P/N.

Michel.


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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[Mathias B.]

Hello,

S'il s'agit en plus d'un port UDP, tu peux faire un DDoS par réflexion
sur je ne dis pas de bêtises.

Je confirme le fameux mail venant de la BSI qui envoie un mail à Hetzner
qui te le transmet pour traitement. Pas que j'en ai eu moi-même :)

Bonne journée ;)

Mathias B.
GPG: B662 E39E 8971 8E6B 8960 893C 4577 D41D 2F68 4552
Matrix: @l4p1n:l4p1n.ch

On 17.04.20 16:12, Boris Tassou via frnog wrote:
> tu as l'Allemagne qui vérifie ça, j'ai plusieurs dédiés/VPS chez Hetzner
> et quand tu oublie de virer le 111 sur l'extérieur, tu reçois un joli
> mail en allemand/anglais qui te dis que pour des raisons de sécurité,
> merci de le désactiver.
> 
> Le 17/04/2020 à 16:03, Guillaume GARNIER via frnog a écrit :
>> Salut à tous,
>>
>> question un brin naïve : ça sert à quelque chose d'avoir un port RPC
>> ouvert aux quatre vents ?
>>
>> ++
>>
>> Guillaume
>>
>> Le 17/04/2020 à 15:43, David Ponzone a écrit :
>>> C’était le port 111 (SUNRPC) donc c’est pas pour faire des stats
>>> Apache vs Nginx :)
>>>
 Le 17 avr. 2020 à 15:35, Rémy Grünblatt  a écrit :

 Bonjour,

 C'est quoi comme scan? Du banner grabbing j'ai déjà fait, pour avoir
 des
 statistiques par exemple. Et aussi car c'est rigolo à faire, pour
 l'expérience. Je ne m'interroge pas tellement de la démarche de
 l'ensemble des visiteurs de mon site web, je ne vois pas quelle serait
 la différence avec un scan de tout IPV4.

 ps: https://github.com/robertdavidgraham/masscan si vous voulez vous
 amuser aussi
>>>
>>> ---
>>> 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] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi

[Oliver varenne]

Salut à tous

Cette question est en misc car c’est pour du perso, je m’adresse à ceux qui 
m’avaient donné un coup de main sur ma liaison PTP en wifi.

Si vous vous en rappelez, j’ai monté sur mon toit et sur celui d’un bâtiment a 
3km deux antennes MikroTik
Apres des démarrages chaotiques liés à une LOS/fresnel pas super, j’ai réussi à 
obtenir en septembre dernier une solution a peu près stable qui me convenait 
bien mieux que mes 5Mbps en ADSL

entre -65 et -62 dbm (combiné sur les deux chaines),
5700Mhz et 20Mhz de largeur de canal (car ce canal n’est a priori pas utilisé)
173Mb/s en Tx/Rx rate
CCQ à 90 voir 100%

J’avais choisis d’utiliser du Nstreme car c’était le protocole le plus stable
J’obtenais un 80Mbps en down et 100Mbs en up. Je n’ai jamais compris pourquoi 
mon UP était plus élevé.
J’avais une déconnexion tous les 5 à 10 jours. Parfois ça tenait 15 jours.
Quand il pleuvait ou par fort vent, j’avais une ou deux deco. Pas plus

J’étais plutôt content. Ça n’a pas bougé de tout l’hiver.

Le premier jours du confinement, alors que nous étions un peu débordé en 
télétravail par les appels de clients souhaitant externaliser leur téléphonie, 
tout à coup, plus de net.
La connexion s’est mise à couper toutes les minutes, parfois ça tenant 2 
minutes…

J’ai réussi à stabiliser à nouveau le truc en passant cette fois au protocole 
NV2 (tdma)
Et la, 25 jours sans une déco !
-65 dbm en combiné sur les deux chaines
CCQ entre 80 et 92%, donc moins bien que Nstreme
Par contre, débit divisé par 2 ! j’ai du passer en 40Mhz de largeur, avec un 
fixed downlink à 40% pour avoir un débit en down de 75/80Mpbs et 40/45 Mbps en 
up


Alors, quand j’ai eu les soucis, je me suis dit que vu que ma zone de fresnel 
était déjà bien bouchée par les arbres, et qu’un arbre avait du faire des 
feuilles dans le passage, ou que les antennes avaient bougés, ou que quelqu’un 
saturait ce canal….

Mais…

  *   Meme qualité de reception ; donc pas de désalignement des antenne
  *   Si c’était les arbres, ça devrait ne pas trop passer en NV2 non plus ?
  *   Je ne vois pas d’utilisation du canal dans le soutils de mikrotik, et ça 
me fais pareil sur toutes les fréquences que j’ai utilisé
  *   Que je sois à 500mw (reception -75dbm) ou 10w (je sais ! reception 
-58dbm) j’ai exactement les mêmes coupures
  *   Une mise à jour des boitiers ne change rien (firmware/logiciel)
  *   Pourquoi dans tous les cas mon UP est plus élevé ? est ce parce que j’ai 
une obstruction proche de chez moi ou inversement ?

Ma question est simple : qu’est ce qu’il s’est passé d’apres vous pour que 
d’une heure à l’autre tout à coup je ne puisse plus utiliser nstreme ni 802.11 
et que je sois obligé de passer en TDMA ?
Ou alors TDMA est super résilient aux mauvaises LOS, mais dans ce cas pourquoi 
ça marchait moins bien que Nstreme avant ??
Des interférences ? mais dans ce cas qui viendraient de quoi ? et surtout ça 
m’impacte sur tout le spectre…


Cordialement,

[cid:fe3b40cd-31a8-4263-a719-d58b9badddce]

Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]
[cid:image005.jpg@01D614D6.2EBB9310]



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

Re: [FRnOG] [TECH] Trunk SIP redondant

[David Ponzone]

> Le 16 avr. 2020 à 18:17, Emmanuel DECAEN  a écrit 
> :
> 
> Bonjour,
> 
> Le 16/04/2020 à 09:54, David Ponzone a écrit :
>> J’avais pris la question d’Emmanuel comme une question concernant les 
>> opérateurs, et je me rends compte qu’effectivement sa question portait sur 
>> les trunks pour client finaux.
> 
> En fait, les deux aspects m'intéressent et les deux réponses mes conviennent.
> 
>> De toute façon la problématique reste la même, SIP reste SIP et copie le 
>> fonctionnement du legacy en ISDN/SS7, et rien n’a été prévu pour qu’une 
>> ressource téléphonique puisse être annoncée par 2 chemins.
> 
> C'est entièrement statique ?
> 
Oui
> Il n'y a pas moyen de dire techniquement "voici mes blocs" à l'opérateur 
> upstream (ou un peer) ?
> 

Même quand tu as tes propres ressources en numérotation, tu vas dire à 
l’opérateur « upstream » (c’est pas le bon terme en voix, car c’est pas ton 
upstream, les 2 opérateurs sont au même niveau techniquement, mais évidemment 
Orange est plus gros que toi) que tu détiens ces ressources et il t’envoie les 
appels venant de son réseau vers l’interco.
Il se trouve que l’interco avec Orange est obligatoire, donc Orange va faire 
également le transit d’un opérateur X vers toi.
Si tu veux continuer à recevoir des appels si ton(tes) interco(s) avec Orange 
est(sont) HS, tu peux jours monter une interco avec chacun des 3 autres 
puissants.
Mais ces 3 là sont pas régulés, donc soit tu vas la sentir passer, soit ça sera 
même un NO GO car pas assez de traffic.
Après tu peux aller chercher les autres opérateurs moins gros, mais une interco 
est symétrique au niveau technique et au niveau contractuel (donc 
responsabilité), donc tu risques d’avoir le même problème de NO GO car ils vont 
pas s’emmerder pour 0,00X% de leur traffic.
Sachant que le réseau orange doit être encore au moins 60% du traffic, tu peux 
comprendre où est le problème.

>> Sachant que l’opérateur qui détient la ressource touche en plus des 
>> reversements sur les appels entrants, et que la quasi-totalité du trafic 
>> utilise Orange (donc l’opérateur historique)  comme transit entre les 
>> opérateurs
> 
> En gros, si je comprends bien, il existe toujours un gros monopole de fait 
> avec Orange.
> 
Une grosse domination du marché plutôt. Y a plus de monopole au sens propre du 
terme (et là, y en a 2 ou 3 qui vont me tomber dessus), juste un gros 
déséquilibre, et quelques produits pas très bien régulés (c’est pas moi qui le 
dis).

>> (il y a très peu de peering, il n’est pas gratuit par définition, au mieux 
>> il y a compensation, et 3 ou 4 opérateurs cumulent 90% du trafic; il y a un 
>> colistier qui a tenté de montre un point de peering Voix: gros échec, il 
>> pourra peut-être nous donner sa vision du problème), on sent bien qu’on est 
>> sur un modèle très différent de l’IP, et je vois mal un changement à ce 
>> niveau à court-terme.
> 
> Et j'imagine que parler de l'aspect ci-dessous est un peu polémique ;-)
> 
> $ whois 3.3.e164.arpa.
> 
> domain: 3.3.e164.arpa
> descr:  domaine enum de la France, France Metropole
> remarks:Website: http://www.telecom.gouv.fr/ 
> 
> remarks:Email: admine...@industrie.gouv.fr 
> 

ENUM….vaste sujet.
Ca sert à rien actuellement ce truc.
Le seul usage que je connais, c’est comme base de routage dans ton propre 
réseau Voix.
On peut « espérer » qu’un jour, n’importe quel appel téléphonique dans le monde 
soit établi en P2P grâce à ENUM, mais euh, ça va pas être tout de suite :)
Je dis « espérer » parce que je ne sais pas certain si ça serait un progrès.


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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[Boris Tassou via frnog]

tu as l'Allemagne qui vérifie ça, j'ai plusieurs dédiés/VPS chez Hetzner 
et quand tu oublie de virer le 111 sur l'extérieur, tu reçois un joli 
mail en allemand/anglais qui te dis que pour des raisons de sécurité, 
merci de le désactiver.


Le 17/04/2020 à 16:03, Guillaume GARNIER via frnog a écrit :

Salut à tous,

question un brin naïve : ça sert à quelque chose d'avoir un port RPC 
ouvert aux quatre vents ?


++

Guillaume

Le 17/04/2020 à 15:43, David Ponzone a écrit :
C’était le port 111 (SUNRPC) donc c’est pas pour faire des stats 
Apache vs Nginx :)



Le 17 avr. 2020 à 15:35, Rémy Grünblatt  a écrit :

Bonjour,

C'est quoi comme scan? Du banner grabbing j'ai déjà fait, pour avoir 
des

statistiques par exemple. Et aussi car c'est rigolo à faire, pour
l'expérience. Je ne m'interroge pas tellement de la démarche de
l'ensemble des visiteurs de mon site web, je ne vois pas quelle serait
la différence avec un scan de tout IPV4.

ps: https://github.com/robertdavidgraham/masscan si vous voulez vous
amuser aussi


---
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] Intrinsec nous scanne

[Guillaume GARNIER via frnog]

Salut à tous,

question un brin naïve : ça sert à quelque chose d'avoir un port RPC 
ouvert aux quatre vents ?


++

Guillaume

Le 17/04/2020 à 15:43, David Ponzone a écrit :

C’était le port 111 (SUNRPC) donc c’est pas pour faire des stats Apache vs 
Nginx :)


Le 17 avr. 2020 à 15:35, Rémy Grünblatt  a écrit :

Bonjour,

C'est quoi comme scan? Du banner grabbing j'ai déjà fait, pour avoir des
statistiques par exemple. Et aussi car c'est rigolo à faire, pour
l'expérience. Je ne m'interroge pas tellement de la démarche de
l'ensemble des visiteurs de mon site web, je ne vois pas quelle serait
la différence avec un scan de tout IPV4.

ps: https://github.com/robertdavidgraham/masscan si vous voulez vous
amuser aussi


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



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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[Laurent Cheylus]

Bonjour,

On Fri, Apr 17, 2020 at 02:59:28PM +0200, David Ponzone wrote:
> Je viens de découvrir qu’Intrinsec faisait des scan à gauche à droite sur 
> l’ensemble des IPv4 (seulement France ou pas, je ne sais pas).
(...) 
> Quelqu’un connait leur motivation précises pour réaliser ces scans ?

J'ai pas la réponse pour Intrinsec précisèment mais des
services/sociétés qui font des scans des services dispo sur IPv4, y'en a
moult :

- évidemment le plus connu Shodan https://www.shodan.io/
- Censys https://censys.io/
- Onyphe (boite française) https://www.onyphe.io/

et je dois en oublier plein. Les 3 précédents proposent d'agréger des
données de scans et de pouvoir les interroger via site Web et API (avec
des business models / prix variés en fonction des besoins).

Des SSII, sociétés spécialisés Sécu (catégorie à laquelle appartient
Intrinsec) ou services (comme l'ANSSI) qui font du scan régulier, y'en a
plein aussi que ce soit public ou non.

Ca alimente une base interne et ils peuvent l'utiliser de différentes manières :
- vendre leur service ("bonjour on a trouvé tel ou tel
truc chez vous qui va pas, ça vous coutera X k€ pour un audit...")
- faire des études et communiquer dessus : "y'a X milliers de services
  RDP ouverts sur le Net qui sont pownables en 2 minutes" (sic)
- soit pour connaitre l'état de la menace (travail de l'ANSSI par
  exemple) en corrélant avec des vulnérabilités connues
- soit des actions moins recommandables (LIO "lutte offensive").

Evidemment y'a aussi tous les "amateurs" qui font ça pour différentes
raisons allant du Whitehat au Blackhat avec les outils dispo :

- le vénérable nmap
- masscan https://github.com/robertdavidgraham/masscan
- Zmap https://github.com/robertdavidgraham/masscan
- le tout mixé et agrégé dans une DB qui va bien + WepApp / API
  (développement par une équipe du CEA) IVRE - Network Recon Framework
  https://ivre.rocks/


A++ Laurent


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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[David Ponzone]

C’était le port 111 (SUNRPC) donc c’est pas pour faire des stats Apache vs 
Nginx :)

> Le 17 avr. 2020 à 15:35, Rémy Grünblatt  a écrit :
> 
> Bonjour,
> 
> C'est quoi comme scan? Du banner grabbing j'ai déjà fait, pour avoir des
> statistiques par exemple. Et aussi car c'est rigolo à faire, pour
> l'expérience. Je ne m'interroge pas tellement de la démarche de
> l'ensemble des visiteurs de mon site web, je ne vois pas quelle serait
> la différence avec un scan de tout IPV4.
> 
> ps: https://github.com/robertdavidgraham/masscan si vous voulez vous
> amuser aussi


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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[Rémy Grünblatt]

Bonjour,

C'est quoi comme scan? Du banner grabbing j'ai déjà fait, pour avoir des
statistiques par exemple. Et aussi car c'est rigolo à faire, pour
l'expérience. Je ne m'interroge pas tellement de la démarche de
l'ensemble des visiteurs de mon site web, je ne vois pas quelle serait
la différence avec un scan de tout IPV4.

ps: https://github.com/robertdavidgraham/masscan si vous voulez vous
amuser aussi

On 17/04/2020 15:26, David Ponzone wrote:

> C’est une question complexe et je ne tenterai pas d’y répondre, n’étant pas 
> juriste.
>
> Ce lien:
> http://www.infond.fr/2010/09/legalite-du-scan-de-port.html 
> 
> semble faire un bon résumé de la situation en France et dans d’autres pays.
> De ce que j’en comprends, non, le scan n’est pas considéré actuellement comme 
> illégal.
>
> Mais la légalité n’est pas la question, sinon j’aurais contacté un avocat :)
> C’est plus le but de la démarche qui m’intrigue, donc je me demandais si 
> quelqu’un sur FRNOG savait pourquoi ils faisaient ça.
>
>
>> Le 17 avr. 2020 à 15:11, Ramanou S. BIAOU  a écrit :
>>
>> David,
>>
>> Est-ce illégale de faire un scan d'une plage d'IP publique?
>>
>> Ramanou
>>
>> Le ven. 17 avr. 2020 à 14:59, David Ponzone > > a écrit :
>> Je viens de découvrir qu’Intrinsec faisait des scan à gauche à droite sur 
>> l’ensemble des IPv4 (seulement France ou pas, je ne sais pas).
>> Encore, que l’ANSSI fasse ça, je peux comprendre car ils préviennent des 
>> failles potentielles qu’ils trouvent.
>> Dans le cas d’un acteur privé, ça me surprend un peu car je ne me rappelle 
>> pas avoir été un jour prévenu par Intrisec d’une faille sur une de mes IP.
>>
>> Quelqu’un connait leur motivation précises pour réaliser ces scans ?
>>
>> Merci
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 
>>
>>
>> -- 
>> --BIAOU Ramanou--
>> --www.biaou.net --
>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Intrinsec nous scanne

[David Ponzone]

C’est une question complexe et je ne tenterai pas d’y répondre, n’étant pas 
juriste.

Ce lien:
http://www.infond.fr/2010/09/legalite-du-scan-de-port.html 

semble faire un bon résumé de la situation en France et dans d’autres pays.
De ce que j’en comprends, non, le scan n’est pas considéré actuellement comme 
illégal.

Mais la légalité n’est pas la question, sinon j’aurais contacté un avocat :)
C’est plus le but de la démarche qui m’intrigue, donc je me demandais si 
quelqu’un sur FRNOG savait pourquoi ils faisaient ça.


> Le 17 avr. 2020 à 15:11, Ramanou S. BIAOU  a écrit :
> 
> David,
> 
> Est-ce illégale de faire un scan d'une plage d'IP publique?
> 
> Ramanou
> 
> Le ven. 17 avr. 2020 à 14:59, David Ponzone  > a écrit :
> Je viens de découvrir qu’Intrinsec faisait des scan à gauche à droite sur 
> l’ensemble des IPv4 (seulement France ou pas, je ne sais pas).
> Encore, que l’ANSSI fasse ça, je peux comprendre car ils préviennent des 
> failles potentielles qu’ils trouvent.
> Dans le cas d’un acteur privé, ça me surprend un peu car je ne me rappelle 
> pas avoir été un jour prévenu par Intrisec d’une faille sur une de mes IP.
> 
> Quelqu’un connait leur motivation précises pour réaliser ces scans ?
> 
> Merci
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 
> 
> 
> -- 
> --BIAOU Ramanou--
> --www.biaou.net --
> 


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

[FRnOG] [TECH] Intrinsec nous scanne

[David Ponzone]

Je viens de découvrir qu’Intrinsec faisait des scan à gauche à droite sur 
l’ensemble des IPv4 (seulement France ou pas, je ne sais pas).
Encore, que l’ANSSI fasse ça, je peux comprendre car ils préviennent des 
failles potentielles qu’ils trouvent.
Dans le cas d’un acteur privé, ça me surprend un peu car je ne me rappelle pas 
avoir été un jour prévenu par Intrisec d’une faille sur une de mes IP.

Quelqu’un connait leur motivation précises pour réaliser ces scans ?

Merci


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

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

[David Ponzone]

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

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


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

Re: [FRnOG] [TECH] QSFP+ vs SFP28

[Laurent-Charles FABRE]

RE,

late answer mais je viens juste de clicker sur le lien EBay qui montre 
un jolie switch with "Front to back airflow"
Autrement appelé PortSide Intake chez certain ou sens de ventilation 
comme d'hab pour les autres.


Tant qu'à y être, moi je préfère les switch en Back 2 Front ou Port-Side 
exhaust en clair le coté port du switch monté à l'arrière de la baie.
1 - c'est du même coté que les ports des serveurs classiques -> plus 
facile a câbler quand on est seul
2 - il y a souvent plus de dégagement à l'arrière de la baie pour câbler 
tranquille
3 - on peut utiliser des DAC ou FO au plus court -> chuis pas maniaque 
mais j'aime quand ça respire


My 2 cents

Le 14/04/2020 à 18:31, Michel Py a écrit :

Julien Escario
Et par curiosité, y aurait-il une différence notable de latence ?

Cà dépend du switch. Sur pas mal de switch, tu peux configurer les ports QSFP+ 
soit en mode 4x10G, soit en mode 1x40G; faut parfois rebooter, donc à prévoir.


J'image que la décomposition en 4 canaux puis recomposition du QSFP+
doit rajouter quelques (dizaines de) ns dans la communication ?

Probablement, mais c'est la même chose en 40G qu'en 100G, le 100G étant du 
4x25G consolidé au lieu de 4x10G.
Pour le stockage, çà ne me parait pas important.


Note : dans mon use-case, c'est exclusivement du DAC puisque cluster de 
stockage Ceph.

J'aurais tendance à dire qu'au bout du compte c'est une histoire de gros sous. 
Le 40G çà ne coute presque plus rien aujourd'hui, alors que le 100G c'est 
encore assez cher. Faut pas oublier qu'il faut que tu mettes des cartes dans 
tes serveurs, il y a aussi à prendre en compte que les cartes 100G QSFP28 c'est 
souvent un slot PCIe x16, ce qui ne court pas les rues dans les serveurs.

Fais tes comptes pour passer en 40G, et/ou pour passer en 100G. La différence 
de prix vaut-elle ce que tu peux t'offrir aujourd'hui, toi seul peut répondre à 
cette question.

Je viens de regarder sur eBay vite fait, les cartes 100G c'est a peine plus de 
100 balles en ce moment, les switchs avec plein de ports 100G c'est quelques 
milliers d'euros, si c'était moi et je suis un avare notoire je partirais 
direct sur du 100G QSFP28.
Tu regardes çà par exemple : https://www.ebay.com/itm/402187758937
C'est sur qu'il faut allonger 5000 balles, mais t'es tranquille pour un bon 
moment.

Michel.



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



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

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

[Brahim AGALMOUCHE]

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

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

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

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

[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 13:52:19

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

> Je commencerais par un upgrade, sans garantir que ça règle quoi que ce
> soit, je vois rien à ce sujet dans les RN.
>
> Tu peux le reproduire en chargeant toi-même l’ADSL ?
> En saturant seulement l’entrant ?
> Seulement le sortant ?
>
>
> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE 
> a écrit :
>
> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
> 6.41.3.
>
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  17/04/20
> à 13:16:22
>
> Le ven. 17 avr. 2020 à 13:09, David Ponzone  a
> écrit :
>
>> Oui tu as raison, 5.9 minimum pour le 2011.
>>
>> Donc attendons que Brahim nous confirme la version d’OS (/system
>> resources print).
>>
>> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
>> écrit :
>>
>> Brahim parle peut-être de la version du firmware et non de RouterOS,
>> parce que je doute que le rb2011 supporte une aussi vieille version de rOS.
>>
>> Hugues
>> AS57199 - AS50628
>>
>> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>>
>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
>> ans ?
>>
>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
>> a écrit :
>>
>> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344,
>> v3.41.
>>
>> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN
>> (ADSL) qui se sature (lorqu'on atteint la BP de la synchro), pour la piste
>> du fastpath/track, je crois que ca va pas changer grand chose vu que les
>> perfs du CPU ne sont pas impactés, et que ca reste uniquement un souci de
>> priorisation des trames sortantes.
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>>
>

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

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

[David Ponzone]

Je commencerais par un upgrade, sans garantir que ça règle quoi que ce soit, je 
vois rien à ce sujet dans les RN.

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


> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE  a 
> écrit :
> 
> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est 
> 6.41.3.
> 
> 
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  17/04/20 à 13:16:22  
> 
> Le ven. 17 avr. 2020 à 13:09, David Ponzone  > a écrit :
> Oui tu as raison, 5.9 minimum pour le 2011.
> 
> Donc attendons que Brahim nous confirme la version d’OS (/system resources 
> print).
> 
>> Le 17 avr. 2020 à 13:04, Hugues Voiturier > > a écrit :
>> 
>> Brahim parle peut-être de la version du firmware et non de RouterOS, parce 
>> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>> 
>> Hugues
>> AS57199 - AS50628
>> 
>>> On 17 Apr 2020, at 12:59, David Ponzone >> > wrote:
>>> 
>>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 
>>> ans ?
>>> 
 Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE >>> > a écrit :
 
 Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, 
 v3.41.
 
 Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL) 
 qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du 
 fastpath/track, je crois que ca va pas changer grand chose vu que les 
 perfs du CPU ne sont pas impactés, et que ca reste uniquement un souci de 
 priorisation des trames sortantes.
 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ 
>> 
> 


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

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

[Brahim AGALMOUCHE]

Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
6.41.3.



[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 13:16:22

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

> Oui tu as raison, 5.9 minimum pour le 2011.
>
> Donc attendons que Brahim nous confirme la version d’OS (/system resources
> print).
>
> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
> écrit :
>
> Brahim parle peut-être de la version du firmware et non de RouterOS, parce
> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>
> Hugues
> AS57199 - AS50628
>
> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>
> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
> ans ?
>
> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
> a écrit :
>
> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344,
> v3.41.
>
> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL)
> qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du
> fastpath/track, je crois que ca va pas changer grand chose vu que les perfs
> du CPU ne sont pas impactés, et que ca reste uniquement un souci de
> priorisation des trames sortantes.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>

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

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

[David Ponzone]

Oui tu as raison, 5.9 minimum pour le 2011.

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

> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a écrit 
> :
> 
> Brahim parle peut-être de la version du firmware et non de RouterOS, parce 
> que je doute que le rb2011 supporte une aussi vieille version de rOS.
> 
> Hugues
> AS57199 - AS50628
> 
>> On 17 Apr 2020, at 12:59, David Ponzone > > wrote:
>> 
>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 
>> ans ?
>> 
>>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE >> > a écrit :
>>> 
>>> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.
>>> 
>>> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL) 
>>> qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du 
>>> fastpath/track, je crois que ca va pas changer grand chose vu que les perfs 
>>> du CPU ne sont pas impactés, et que ca reste uniquement un souci de 
>>> priorisation des trames sortantes.
>>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 
> 


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

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

[Hugues Voiturier]

Brahim parle peut-être de la version du firmware et non de RouterOS, parce que 
je doute que le rb2011 supporte une aussi vieille version de rOS.

Hugues
AS57199 - AS50628

> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
> 
> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 ans 
> ?
> 
>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE  a 
>> écrit :
>> 
>> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.
>> 
>> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL) 
>> qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du 
>> fastpath/track, je crois que ca va pas changer grand chose vu que les perfs 
>> du CPU ne sont pas impactés, et que ca reste uniquement un souci de 
>> priorisation des trames sortantes.
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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

[David Ponzone]

Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10 ans ?

> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE  a 
> écrit :
> 
> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.
> 
> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL) 
> qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du 
> fastpath/track, je crois que ca va pas changer grand chose vu que les perfs 
> du CPU ne sont pas impactés, et que ca reste uniquement un souci de 
> priorisation des trames sortantes.
> 


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

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

[Brahim AGALMOUCHE]

Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.

Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL)
qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du
fastpath/track, je crois que ca va pas changer grand chose vu que les perfs
du CPU ne sont pas impactés, et que ca reste uniquement un souci de
priorisation des trames sortantes.



[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 12:40:36

Le ven. 17 avr. 2020 à 12:35, David Ponzone  a
écrit :

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

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

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

[David Ponzone]

C’est pas faux, et bon débarras le LCD du 3011 qui a jamais servi à rien, et 
merci pour le chassis métal qui fait quand même plus sérieux.

Par contre, ça peut être un peu overkill pour un petit client, mais si le 
budget le permet….

> Le 17 avr. 2020 à 12:33, Hugues Voiturier  a écrit 
> :
> 
> Bonne règle qui peut être simplifiée par : 
> - Prends un RB4011, en plus d’avoir de la patate, ça fait joli chez le client.
> Plus sérieusement, l’avantage avec le RB4011, c’est que si même avec lui ça 
> merde, c’est que le souci est ailleurs :)
> 
> Hugues
> AS57199 - AS50628
> 
>> On 17 Apr 2020, at 12:30, David Ponzone > > wrote:
>> 
>> Très surprenant, j’ai jamais vu ça.
>> 
>> Quelle version de RouterOS ?
>> T’as contrôlé le CPU quand ta liaison surcharge ?
>> Il est assez fréquent de voir des CPE Mikrotik un peu sous-dimensionné, 
>> parce qu’on se fie un peu trop aux specs.
>> Si tu désactives le fastpath par exemple, parce qu’il te gêne (et il gêne 
>> plein de trucs), ou si t’as oublié de l’activer, ça peut faire une grosse 
>> différence.
>> Chez Mikrotik, je crois que la bonne règle quand on est pas sûr de soi c’est:
>> -cherche le modèle qui supporte ton traffic avec des paquets de 512 octets 
>> et 25 filtres
>> -prends le modèle au-dessus
>> 
>>> Le 17 avr. 2020 à 12:15, Brahim AGALMOUCHE >> > a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Je sollicite votre aide concernant une problématique de maintien des 
>>> sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.
>>> 
>>> En effet en constate que suite à une surcharge/congestion sur le lien WAN 
>>> sur le CPE Mikrotik, on perd la session PPPoE. 
>>> 
>>> Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP echo 
>>> reply, pour le faire on doit marquer ces trames pour les affecter à une 
>>> Queue et leur réserver de la bande passante.
>>> 
>>> Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers le 
>>> modem ADSL) on a comme condition dans les matchers que le champ Type dans 
>>> le header des trames Ethernet, ce qui fait qu’on arrive pas à matcher 
>>> uniquement les trames LCP echo reply.
>>> 
>>> La condition dans le matcher du filtre bridge (pour marquage des paquets) :
>>> 
>>> 
>>> Le type de paquet qu’on souhaite marquer :
>>> 
>>> 
>>> 
>>> Est-ce qu’on a un moyen pour affiner les conditions sur matching des frames 
>>> sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre cette 
>>> problématique de maintien des sessions lors de la congestion WAN autrement ?
>>> 
>>> D’avance merci pour vos retours.
>>> Cordialement.
>>> 
>>>  
>>> >>  
>>> >
>>>   Sender notified by 
>>> Mailtrack 
>>> >>  
>>> >
>>>  17/04/20 à 12:14:45 
>>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ 


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

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

[Hugues Voiturier]

Bonne règle qui peut être simplifiée par : 
- Prends un RB4011, en plus d’avoir de la patate, ça fait joli chez le client.
Plus sérieusement, l’avantage avec le RB4011, c’est que si même avec lui ça 
merde, c’est que le souci est ailleurs :)

Hugues
AS57199 - AS50628

> On 17 Apr 2020, at 12:30, David Ponzone  wrote:
> 
> Très surprenant, j’ai jamais vu ça.
> 
> Quelle version de RouterOS ?
> T’as contrôlé le CPU quand ta liaison surcharge ?
> Il est assez fréquent de voir des CPE Mikrotik un peu sous-dimensionné, parce 
> qu’on se fie un peu trop aux specs.
> Si tu désactives le fastpath par exemple, parce qu’il te gêne (et il gêne 
> plein de trucs), ou si t’as oublié de l’activer, ça peut faire une grosse 
> différence.
> Chez Mikrotik, je crois que la bonne règle quand on est pas sûr de soi c’est:
> -cherche le modèle qui supporte ton traffic avec des paquets de 512 octets et 
> 25 filtres
> -prends le modèle au-dessus
> 
>> Le 17 avr. 2020 à 12:15, Brahim AGALMOUCHE > > a écrit :
>> 
>> Bonjour,
>> 
>> Je sollicite votre aide concernant une problématique de maintien des 
>> sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.
>> 
>> En effet en constate que suite à une surcharge/congestion sur le lien WAN 
>> sur le CPE Mikrotik, on perd la session PPPoE. 
>> 
>> Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP echo 
>> reply, pour le faire on doit marquer ces trames pour les affecter à une 
>> Queue et leur réserver de la bande passante.
>> 
>> Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers le 
>> modem ADSL) on a comme condition dans les matchers que le champ Type dans le 
>> header des trames Ethernet, ce qui fait qu’on arrive pas à matcher 
>> uniquement les trames LCP echo reply.
>> 
>> La condition dans le matcher du filtre bridge (pour marquage des paquets) :
>> 
>> 
>> Le type de paquet qu’on souhaite marquer :
>> 
>> 
>> 
>> Est-ce qu’on a un moyen pour affiner les conditions sur matching des frames 
>> sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre cette 
>> problématique de maintien des sessions lors de la congestion WAN autrement ?
>> 
>> D’avance merci pour vos retours.
>> Cordialement.
>> 
>>  
>> >  
>> >
>>Sender notified by 
>> Mailtrack 
>> >  
>> >
>>  17/04/20 à 12:14:45  
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 

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

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

[David Ponzone]

Très surprenant, j’ai jamais vu ça.

Quelle version de RouterOS ?
T’as contrôlé le CPU quand ta liaison surcharge ?
Il est assez fréquent de voir des CPE Mikrotik un peu sous-dimensionné, parce 
qu’on se fie un peu trop aux specs.
Si tu désactives le fastpath par exemple, parce qu’il te gêne (et il gêne plein 
de trucs), ou si t’as oublié de l’activer, ça peut faire une grosse différence.
Chez Mikrotik, je crois que la bonne règle quand on est pas sûr de soi c’est:
-cherche le modèle qui supporte ton traffic avec des paquets de 512 octets et 
25 filtres
-prends le modèle au-dessus

> Le 17 avr. 2020 à 12:15, Brahim AGALMOUCHE  a 
> écrit :
> 
> Bonjour,
> 
> Je sollicite votre aide concernant une problématique de maintien des sessions 
> PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.
> 
> En effet en constate que suite à une surcharge/congestion sur le lien WAN sur 
> le CPE Mikrotik, on perd la session PPPoE. 
> 
> Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP echo 
> reply, pour le faire on doit marquer ces trames pour les affecter à une Queue 
> et leur réserver de la bande passante.
> 
> Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers le 
> modem ADSL) on a comme condition dans les matchers que le champ Type dans le 
> header des trames Ethernet, ce qui fait qu’on arrive pas à matcher uniquement 
> les trames LCP echo reply.
> 
> La condition dans le matcher du filtre bridge (pour marquage des paquets) :
>  
> 
> Le type de paquet qu’on souhaite marquer :
>  
> 
> 
> Est-ce qu’on a un moyen pour affiner les conditions sur matching des frames 
> sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre cette 
> problématique de maintien des sessions lors de la congestion WAN autrement ?
> 
> D’avance merci pour vos retours.
> Cordialement.
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  17/04/20 à 12:14:45  
> 


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

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

[Brahim AGALMOUCHE]

Bonjour,

Je sollicite votre aide concernant une problématique de maintien des
sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.

En effet en constate que suite à une surcharge/congestion sur le lien WAN
sur le CPE Mikrotik, on perd la session PPPoE.

Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP echo
reply, pour le faire on doit marquer ces trames pour les affecter à une
Queue et leur réserver de la bande passante.

Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers le
modem ADSL) on a comme condition dans les matchers que le champ Type dans
le header des trames Ethernet, ce qui fait qu’on arrive pas à matcher
uniquement les trames LCP echo reply.

La condition dans le matcher du filtre bridge (pour marquage des paquets) :

[image: image.png]
Le type de paquet qu’on souhaite marquer :

[image: image.png]

Est-ce qu’on a un moyen pour affiner les conditions sur matching des frames
sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre cette
problématique de maintien des sessions lors de la congestion WAN autrement ?

D’avance merci pour vos retours.
Cordialement.

[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 12:14:45

Re: [FRnOG] [TECH] Attributs RADUS

[David Ponzone]

J’ai trouvé ça:

https://social.technet.microsoft.com/forums/windowsserver/fr-FR/cd470773-5587-4644-b7c1-ac834caf3be1/nps-radius-envoie-multiple-tunnel-l2tp
 


Pas de réponse à la question, mais ça peut t’éclairer sur le principe d’usage 
de la forme Attribut = "1:truc"

> Le 17 avr. 2020 à 11:20, Kevin Thiou  a écrit :
> 
> 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/


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

[FRnOG] [TECH] Attributs RADUS

[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/

Re: [FRnOG] [BIZ] Contact Ciena gamme 51XX

[Benjamin Collet]

Bonjour,

On Fri, Apr 17, 2020 at 09:18:22AM +0200, Maxence Rousseau wrote:
> Je cherche un contact chez Ciena.
> 
> (Le formulaire sur leur site ne semble pas fonctionner ni avec Firefox
> 68.7.0 ni Chromium 80.0.3987.162.. )

Je peux te communiquer le contact de notre chargée de compte en privé
(si c'est un contact commercial que tu cherches).

> Tant qu'on y est, si vous avez des REX sur ces produits, je prends.

À $JOB on en est très satisfait en utilisation CPE/agrégation carrier
Ethernet sur les versions récentes. Le feature-set est complet, bien
documenté et la configuration, même si atypique (c'est pas du Cisco ou
du Juniper, mais c'est souvent le cas en équipement carrier Ethernet)
n'est pas tordue comme celle des RAD (que nous utilisons également).

On utilise du 3903 au 5160 (c'est le même SAOS pour tout ces modèles).

Si tu comptes t'en servir en équipement MPLS, mon avis est plus réservé,
j'ai eu pas mal de problèmes, mais c'était sur des vieilles versions et
dans le cadre de la reprise/migration d'un réseau racheté, donc on ne
s'est pas trop attardé sur la question et avons homogénéisé avec nos
standards. Ça a probablement évolué depuis.

My ¢2,
Benjamin

-- 
Benjamin Collet


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

[FRnOG] [BIZ] Contact Ciena gamme 51XX

[Maxence Rousseau]

Bonjour,


Je cherche un contact chez Ciena.

(Le formulaire sur leur site ne semble pas fonctionner ni avec Firefox 
68.7.0 ni Chromium 80.0.3987.162.. )


Tant qu'on y est, si vous avez des REX sur ces produits, je prends.


Bon confinement à tous


--
Maxence Rousseau
mrouss...@ate.info
ATE - Avenir télématique
http://www.ate.info
+33(0)3.28.800.300


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