RE: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF

[Michel Py]

> Emmanuel Halbwachsa écrit :
> OK, je vise peut-être un peu trop haut, mais au moins avoir les
> billes pour pouvoir faire « mes devoirs » et progresser. 

On apprend tous de manière différente; ceci étant dit, ce qui a marché pour moi 
et pour pas mal de gens que je connais :

RTFM
Lab
Google
RTFM
Lab
Google
RTFM
Lab
Google

Trouver un idiot pour faire quelque chose sur le réseau de prod (surtout pas le 
sien) :-D


> Mais évidemment. Ce que je cherche, c'est une formation qui me mette
> le pied à l'étrier, comme feu les formations BGP que faisait Renater
> il y 20 ans. La formation Rezopole semble être dans cet esprit

Je vois pas comment éviter d'avoir un lab qui reproduit ton environnement; la 
formation pourrait être plus profitable si tu as déjà un certain nombre 
d'heures de vol.

Mes $0.02


Michel.




> Surtout si c'est une config qui fait partie d'un environnement de
> taille.

Je parle de *mon* environnement, pas celui d'Orange.

> C'est comme lire le code que quelqu'un d'autre a écrit : si t'as
> jamais écrit de code, c'est pas de savoir vaguement ce que chaque
> instruction fait qui permet de le comprendre.

Je reprends l'idée de ton analogie : admettons que je connaisse et
pratique la programmation impérative (python) et fonctionnelle (lisp)
et que je veuille apprendre la POO. En 2 jours, je peux apprendre les
notions d'objet, de classe, d'instance, de méthode, d'héritage,
d'introspection, etc. Ensuite, je pourrais comprendre des petits codes
objet en python, bidouiller, pratiquer, déboguer. Et bien sûr, je ne
vais pas lire tout de suite comme un livre tout le code de KDE en C++.

> Ca n'existe pas. Le troubleshooting BGP, çà se fait avec le pair.

Oui, tu as raison, évidemment. J'avais dans l'esprit faire les vérifs
de base chez soi avant d'aller consommer le temps du pair. 

> Et le troubleshooting, çà se pratique en labo avant de le faire sur
> le réseau de prod.

Ben désolé, j'ai appris le réseau il y 20 ans directement dans le
grand bassin en héritant d'un réseau en vrac qu'il fallait remettre
d'équerre puis en construisant à marche forcée un réseau de
mini-campus en ayant appris ce qu'était un VLAN en moins d'une
demi-journée. Je n'ai pas eu le luxe de faire du labo avant, j'aurai
bien aimé. Et j'ai appris le troubleshooting sur le terrain, avec du
RTFM. Ça ne fait pas de moi un nageur de compétition, mais j'arrive à
nager sans boire la tasse. Et ceci grâce à des collègues sympas qui
ont partagé des confs sur lesquelles j'ai pu plancher qui ont répondu
à mes questions de newbie.

> Honnêtement, j'ai l'impression que t'es un peu à coté de tes pompes.

C'est possible. :-) 

> C'est pas 2 jours de crash course qui vont de donner une compétence
> d'Ingénieur Réseau

On va dire que je ne pars pas de zéro. ;-) 

Ce que je ne veux pas, c'est une formation qui va mettre une
demi-journée à expliquer en long et en large ce qu'est un AS, p. ex.

> et surtout pas BGP/VPN/MPLS.

Mais évidemment. Ce que je cherche, c'est une formation qui me mette
le pied à l'étrier, comme feu les formations BGP que faisait Renater
il y 20 ans. La formation Rezopole semble être dans cet esprit. 

Je ne cherche pas de baguette magique, mais je ne veux pas de
charlatan, c'est tout. 


-- 
Emmanuel


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

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

Re: [TECH] Re : [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

[Guillaume Barrot]

A priori , à froid, je dirai que c'est une limitation due à l'intégration
du Broadcom Tomahawk côté Qfx, pour avoir eu un cas assez similaire sur une
plateforme identique chez un autre constructeur.

L'ASIC est capable de traiter du trafic de type j'encapsule tout ce qui
arrive sur un port dans un tunnel VXLAN (comme prévu dans la RFC), mais
pour ce faire, faut avoir codé les bonnes primitives du SDK Broadcom, qui
semble-t-il n'est pas simple.

Il est probable que tu tombes sur un "yes it should work, but in fact it is
unsupported to have multiple encapsulation inside a VXLAN tunnel".

Dans un cas comme ça je bypasserai le sujet en faisant un VXLAN point à
point entre les deux CPE, plutôt qu'au niveau du PE. Vu du backbone, ça
redevient un pur flux IP/UDP. Ça supporte VXLAN basique la gamme EX2300 ?

Le ven. 7 sept. 2018 à 14:48, Fabien VINCENT (FrNOG) 
a écrit :

> Le 2018-09-07 14:28, Olivier FRUQUET a écrit :
>
> > Salut,
> > Merci pour vos réponses.
> > Alors j'ai déjà essayé avec plusieurs ethertypes, j'avais fixé le
> > 0x88a8 partout mais ça n'a rien changé.
> > Oui j'ai une MTU déclarée élevée partout, j'affinerai un peu plus tard,
> > là je veux juste que ça tombe en marche.
> > Juniper d'après ce que j'ai pu trouver en documentation taggues par
> > défaut en 0x8100.
> > Un lien vers un schéma fait vite fait sur un tableau :
> >
> https://image.noelshack.com/fichiers/2018/36/5/1536323250-schema-vxlan-olivier.jpg
> >
> > @Fabien VINCENT : en gros j'ai un trunk C-VLAN vlan-id-list 1-4092 qui
> > se fait tagguer par dessus en S-VLAN 1001 par les EX2300.
> > Je vais creuser un peu plus le pattern 4 de la doc Juni.
> > En gros les ports facing CE sur mes QFX ont la conf suivante :
> >
> > set interfaces xe-0/0/0 description "*** Liaison FON vers CUST1001
> > siege CPE port xe-0/1/3 ***;"
> > set interfaces xe-0/0/0 mtu 9216
> > set interfaces xe-0/0/0 flexible-vlan-tagging
> > set interfaces xe-0/0/0 encapsulation extended-vlan-bridge
> > set interfaces xe-0/0/0 unit 1001 vlan-id 1001
> >
> > Ensuite j'ai la conf suivante pour VXLAN :
> >
> > set vlans VLAN1001_CUST_QINQ interface xe-0/0/0.1001
> > set vlans VLAN1001_CUST_QINQ vlan-id 1001
> > set vlans VLAN1001_CUST_QINQ vxlan vni 1001
> > set vlans VLAN1001_CUST_QINQ vxlan ingress-node-replication
> >
> > set protocols evpn encapsulation vxlan
> > set protocols evpn extended-vni-list all
> > set protocols evpn multicast-mode ingress-replication
> > set protocols l2-learning decapsulate-accept-inner-vlan
> >
> > En me tagguant en 1001 un switch quelconque directement au cul d'un
> > QFX, j'arrive à pinguer de l'autre côté, donc je suppose que la couche
> > EVPN fonctionne bien, je n'ai pas testé du coup le flood and learn
> > multicast.
> >
> > J'ai essayé aussi avec le pattern 4 en pop and push mais pas mieux ...
> > La conf des ports de chaque EX2300 :
> >
> > set interfaces xe-0/1/2 description "*** Liaison vers coeur client
> > siege ***"
> > set interfaces xe-0/1/2 flexible-vlan-tagging
> > set interfaces xe-0/1/2 mtu 9216
> > set interfaces xe-0/1/2 encapsulation extended-vlan-bridge
> > set interfaces xe-0/1/2 unit 1001 vlan-id-list 1-4092
> > set interfaces xe-0/1/2 unit 1001 input-vlan-map push
> > set interfaces xe-0/1/2 unit 1001 output-vlan-map pop
> >
> > set interfaces xe-0/1/3 description "*** Liaison FON vers QFX spine1
> > ***"
> > set interfaces xe-0/1/3 flexible-vlan-tagging
> > set interfaces xe-0/1/3 mtu 9216
> > set interfaces xe-0/1/3 encapsulation flexible-ethernet-services
> > set interfaces xe-0/1/3 unit 1001 encapsulation vlan-bridge
> > set interfaces xe-0/1/3 unit 1001 vlan-id 1001
> >
> > J'ai testé tellement de choses que je me paume un peu, pour ça que j'ai
> > besoin d'un oeil extérieur :)
> >
> > Merci !
> > A plus
> > Olivier
> >
> > Le jeu. 6 sept. 2018 à 23:19, Fabien VINCENT (FrNOG)
> >  a écrit :
> >
> > Le 2018-09-06 19:51, Sebastien Maillet a écrit :
> > Sinon, en fonction de l'implémentation du qinq sur ton équipement tu
> > peux avoir des surprises si l'ethertype utilisé est 88a8 au lieu du
> > 8100 (tag Vlan).
> > Certains équipements ne reconnaissent pas l'ethertype 88a8 et du coup
> > ne savent pas lire le tag Vlan juste derrière.
> > Pas sûr que ça vienne de ça mais ça vaut le coup de l'avoir en tête et
> > vérifier ce point.
> > Sébastien
> >
> >  Message original 
> > Objet : Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
> > De : Michel Hostettler
> > À : Olivier FRUQUET
> > Cc : Jugurta Yennek ,frnog-tech
> >
> > J'me lance !
> > Vous êtes déclaré en jumbo frame ?
> > Michel
> >
> > - Mail original -
> > De: "Olivier FRUQUET" 
> > À: "Jugurta Yennek" 
> > Cc: "frnog-tech" 
> > Envoyé: Jeudi 6 Septembre 2018 18:28:37
> > Objet: Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
> >
> > Hello !
> > Yes MTU à 9216 sur toutes les interfaces.
> >
> > Olivier
> >
> > Le jeu. 6 sept. 2018 à 18:20, Jugurta Yennek  a
> > écrit :
> >
> > Hello Olivier,
> >
> > A tout hasa

Re: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF

[daniel Azuelos]

[ Mes questions & réponses sont dans le sens normal de lecture. ]

Le 07/09/2018, Michel Py  a écrit :

| | de faire du troubleshooting BGP tout seul
| 
| Ca n'existe pas. Le troubleshooting BGP, çà se fait avec le pair.
[...]

En effet et souvent dans la douleur.
En pratique le déminage de bouse avec le pair ça se ramène très souvent
au déminage « tout seul » (et à condition d'avoir plusieurs serveurs internes
dont les ébats sont soigneusement bloqués vers l'Internet) suivi de diplomatie
avec le pair pour lui faire un cours mais sans en avoir l'air.

Le plus pénible dans l'affaire c'est le système de gestion de tickets
d'incidents du pair qui souvent ne gère pas du tout les réponses
par courriel et oblige à faire des tonnes de copier-coller dans leur interface
web propriétaire à tendance sado-maso.

Lorsque ce déminage concerne le voisin en amont de ton pair :

mon AS BGP  --- AS de mon FAI   --- AS au dessus

je te raconte pas les tortures de diplomatie qu'il faut endurer pour arriver
à ce que ton pair fasse redresser une configuration de son AS au dessus.
Ex. pratique : l'AS au dessus a décidé qu'il n'annonce pas les routes
pour des blocs plus petits qu'un /24, pour tenir les perf. sans avoir à
muscler ses routeurs.
-- 
« Je reste optimiste. La vie m'a appris qu'avec le temps
le progrès l'emporte toujours. »
   Simone Veil

daniel Azuelos


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

Re: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF

[Emmanuel Halbwachs]

Michel Py (Fri 2018-09-07 18:08:25 +) :
> Il faut des années d'expérience pratique pour faire çà.

OK, je vise peut-être un peu trop haut, mais au moins avoir les billes
pour pouvoir faire « mes devoirs » et progresser. 

> Surtout si c'est une config qui fait partie d'un environnement de
> taille.

Je parle de *mon* environnement, pas celui d'Orange.

> C'est comme lire le code que quelqu'un d'autre a écrit : si t'as
> jamais écrit de code, c'est pas de savoir vaguement ce que chaque
> instruction fait qui permet de le comprendre.

Je reprends l'idée de ton analogie : admettons que je connaisse et
pratique la programmation impérative (python) et fonctionnelle (lisp)
et que je veuille apprendre la POO. En 2 jours, je peux apprendre les
notions d'objet, de classe, d'instance, de méthode, d'héritage,
d'introspection, etc. Ensuite, je pourrais comprendre des petits codes
objet en python, bidouiller, pratiquer, déboguer. Et bien sûr, je ne
vais pas lire tout de suite comme un livre tout le code de KDE en C++.

> Ca n'existe pas. Le troubleshooting BGP, çà se fait avec le pair.

Oui, tu as raison, évidemment. J'avais dans l'esprit faire les vérifs
de base chez soi avant d'aller consommer le temps du pair. 

> Et le troubleshooting, çà se pratique en labo avant de le faire sur
> le réseau de prod.

Ben désolé, j'ai appris le réseau il y 20 ans directement dans le
grand bassin en héritant d'un réseau en vrac qu'il fallait remettre
d'équerre puis en construisant à marche forcée un réseau de
mini-campus en ayant appris ce qu'était un VLAN en moins d'une
demi-journée. Je n'ai pas eu le luxe de faire du labo avant, j'aurai
bien aimé. Et j'ai appris le troubleshooting sur le terrain, avec du
RTFM. Ça ne fait pas de moi un nageur de compétition, mais j'arrive à
nager sans boire la tasse. Et ceci grâce à des collègues sympas qui
ont partagé des confs sur lesquelles j'ai pu plancher qui ont répondu
à mes questions de newbie.

> Honnêtement, j'ai l'impression que t'es un peu à coté de tes pompes.

C'est possible. :-) 

> C'est pas 2 jours de crash course qui vont de donner une compétence
> d'Ingénieur Réseau

On va dire que je ne pars pas de zéro. ;-) 

Ce que je ne veux pas, c'est une formation qui va mettre une
demi-journée à expliquer en long et en large ce qu'est un AS, p. ex.

> et surtout pas BGP/VPN/MPLS.

Mais évidemment. Ce que je cherche, c'est une formation qui me mette
le pied à l'étrier, comme feu les formations BGP que faisait Renater
il y 20 ans. La formation Rezopole semble être dans cet esprit. 

Je ne cherche pas de baguette magique, mais je ne veux pas de
charlatan, c'est tout. 


-- 
Emmanuel


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

Re: [FRnOG] [TECH] Mise en place NAT / Bridge FO SFR

[Radu-Adrian Feurdean]

On Fri, Sep 7, 2018, at 14:55, Thomas Cottier wrote:
> J'ai deux sites raccordés en FO chez SFR (offre SFR business connect)
> depuis peu.
> 
> SFR est venu installer son matériel dans nos baies ( ETX + oneaccess).
> Visiblement d'après le support technique et le support commercial, ils ne
> peuvent pas me faire de NAT 1-1, et le bridge demande une option
> supplémentaire (location de 2 ips / sites pour 40€ / mois)... Je suis pas à
> 40€ près, mais j'essaie d'économiser les IPv4 ;-). Donc...

Si tu as pris un service IP-VPN, c'est normal que le "mode bridge" n'est pas 
dispo ou c'est une option. Pour le NAT 1:1 c'est un peu plus discutable (par 
contre si ca n'a pas ete prevu en avant-vente ca peut finir en "on peut le 
faire, on vous envoie un devis") 

Si tu as pris de l'acces Internet sec, ca se discute, chez nous (Coriolis) on a 
un mode "bridge" (plus precisement une seule IP publique sur l'equipement du 
client - qui reccupere la responsabilite du NAT) livre depuis le port LAN du 
routeur (qui reste gere par nous).

> Est-ce une pratique normale? Ai-je un moyen de shunter leur routeur? De
> mettre le mien directement sur l'ETX? Voyez-vous une solution autre que ces
> âneries commerciales?

Shunter le routeur peut te mettre dans la situation ou les SLA sautent. 
D'habitude, le point de livraison du service est l'interface du routeur 
installe sur site (dans ton cas je suppose que c'est le OA). Regarde la 
description du service pour voir plus clair. OK, je comprends que les documents 
contractuels peuvent entre moins facilement disponibles, mais bon..


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

RE: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF

[Michel Py]

>> Michel Py a écrit :
>> Un crash course de 2 jours c'est pas suffisant pour couvrir tous les
>> aspects (en particulier si tu n'as jamais fait de route-maps (qui ne
>> sont pas uniques à BGP) çà va être court.
>> Quel est ton objectif à réaliser plus tard ?

> Emmanuel Halbwachs a écrit :
> Mes besoins à court terme : Être capable : sur un routeur, de comprendre une 
> conf BGP au premier coup d'œil

Il faut des années d'expérience pratique pour faire çà. Surtout si c'est une 
config qui fait partie d'un environnement de taille.
C'est comme lire le code que quelqu'un d'autre a écrit : si t'as jamais écrit 
de code, c'est pas de savoir vaguement ce que chaque instruction fait qui 
permet de le comprendre.


> de faire du troubleshooting BGP tout seul

Ca n'existe pas. Le troubleshooting BGP, çà se fait avec le pair.
Et le troubleshooting, çà se pratique en labo avant de le faire sur le réseau 
de prod.

Honnêtement, j'ai l'impression que t'es un peu à coté de tes pompes. C'est pas 
2 jours de crash course qui vont de donner une compétence d'Ingénieur Réseau et 
surtout pas BGP/VPN/MPLS.

Michel.


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

Re: [FRnOG] [TECH] Mise en place NAT / Bridge FO SFR

[Thomas Cottier]

Merci!

J'ai déjà demandé les IP supplémentaires, mais c'était surtout pour la
beauté du geste ;)

2018-09-07 19:47 GMT+02:00 Michel Py :

> > Thomas Cottier a écrit :
> > ils ne peuvent pas me faire de NAT 1-1,
>
> C'est pas qu'ils ne peuvent pas, c'est que le singe qui configure ne sait
> pas comment, ou que c'est pas dans leur système pousse-bouton, ou qu'ils
> veulent pas s'emmerder avec une config non-standard.
>
>
> > et le bridge demande une option supplémentaire (location de 2 ips /
> sites pour 40€
> > / mois)... Je suis pas à 40€ près, mais j'essaie d'économiser les IPv4
> ;-). Donc...
>
> Fais le. A la maison je me battrais mais au boulot je vais pas suer pour
> 40€ par mois.
>
>
>
> > Est-ce une pratique normale?
>
> Oui hélas.
>
>
> > Ai-je un moyen de shunter leur routeur? De mettre le mien directement
> sur l'ETX?
>
> Probablement, mais chaque fois qu'ils changent quelque chose tu vas passer
> des heures ou des jours à comprendre quoi, tu peux gagner une bataille mais
> tu vas perdre la guerre à l'épuisement.
>
>
> > Voyez-vous une solution autre que ces âneries commerciales?
>
> 
> Oui, yàkà se débarasser des marketeux, des vendeurs de pompes, des PDG qui
> comprennent rien, etc.
> L'internet pour les geeks par les geeks, nom de dieu.
> 
>
> Michel.
>
>

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

RE: [FRnOG] [TECH] Mise en place NAT / Bridge FO SFR

[Michel Py]

> Thomas Cottier a écrit :
> ils ne peuvent pas me faire de NAT 1-1,

C'est pas qu'ils ne peuvent pas, c'est que le singe qui configure ne sait pas 
comment, ou que c'est pas dans leur système pousse-bouton, ou qu'ils veulent 
pas s'emmerder avec une config non-standard.


> et le bridge demande une option supplémentaire (location de 2 ips / sites 
> pour 40€
> / mois)... Je suis pas à 40€ près, mais j'essaie d'économiser les IPv4 ;-). 
> Donc...

Fais le. A la maison je me battrais mais au boulot je vais pas suer pour 40€ 
par mois.



> Est-ce une pratique normale?

Oui hélas.


> Ai-je un moyen de shunter leur routeur? De mettre le mien directement sur 
> l'ETX?

Probablement, mais chaque fois qu'ils changent quelque chose tu vas passer des 
heures ou des jours à comprendre quoi, tu peux gagner une bataille mais tu vas 
perdre la guerre à l'épuisement.


> Voyez-vous une solution autre que ces âneries commerciales?


Oui, yàkà se débarasser des marketeux, des vendeurs de pompes, des PDG qui 
comprennent rien, etc.
L'internet pour les geeks par les geeks, nom de dieu.


Michel.


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

[TECH] [FRnOG] [JOBS] salaires en Polynésie française

[Ali D]

Bonsoir à tous,

Quelqu'un aurait une idée sur le salaire mensuel moyen (ou TJM) pour un
poste d' ingénieur télécom, avec 5 ans d'exp, dans le privé en Polynésie
française?

En vous remerciant

Ali

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

[FRnOG] [BIZ] Fwd: Cloud Native Networking Bootcamp Registration

[Luigi Iannone]

FYI


> Begin forwarded message:
> 
> From: Carole Reynaud mailto:creyn...@cisco.com>>
> Subject: Cloud Native Networking Bootcamp Registration
> Date: 4 September 2018 at 09:21:17 CEST
> To: Luigi Iannone  >
> Reply-To: Carole Reynaud mailto:creyn...@cisco.com>>
> 
> 
> Save the date for the Cloud Native Networking Bootcamp 2018 in Paris
> On October 18th and 19th 2018, Telecom ParisTech and Cisco will hold a Cloud 
> Native Networking Bootcamp to share knowledge, experience, and grow community 
> around open source cloud native network and network function virtualization 
> technologies.
> 
> This two-day event begins with a Conference on day 1, followed by hands-on 
> Workshops on day 2.
> 
> Click on "Register" to view the program and book your tickets.
> Looking forward to seeing you on Telecom ParisTech campus in Paris in October!
> 
> REGISTER
>  
> 
> 
> University - Industry Research Partnership
> Read how Cisco and Telecom ParisTech collaborates to develop new networking 
> architectures.
> 
> Visit NewNet@Paris website 
> 
> 
> Cisco Paris Innovation & Research Lab (PIRL)
> This event is co-organized by Telecom ParisTech and the Cisco Chief 
> Technology & Architecture Office in France. 
> 
> Visit PIRL website 
> 
>  
> 
>  
> 
> 
> 
> 
> 
> 
> 
> This email was sent to luigi.iann...@telecom-paristech.fr 
>  
> why did I get this? 
> 
> unsubscribe from this list 
> 
> update subscription preferences 
> 
>  
> Cisco Systems France · L'Atlantis · 11, rue Camille Desmoulins · Issy Les 
> Moulineaux 92130 · France 
> 
>  
> 


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

[FRnOG] [TECH] Location Temporaire Salle d'integration

[jgourmel]

Hello la liste,

Ceci n'est pas un trolldi: Je suis a la recherche d'espace en salle serveur 
pour effectuer l’intégration de l’équivalent de 4 baies, pour un mois environ. 
Un genre d'espace coworking pour admin IT.
Savez vous si cela se fait? 

Merci d'avance

Jeremy Gourmel


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

Re: [FRnOG] [TECH] Mise en place NAT / Bridge FO SFR

[Sébastien COUREAU]

Hello,

GRE ? C'est juste une idée en passant (et puis si c'est pas une bonne 
idée, c'est Trolldi !)


Lifo.

Le 2018-09-07 14:55, Thomas Cottier a écrit :

Hello!

J'ai deux sites raccordés en FO chez SFR (offre SFR business connect)
depuis peu.

SFR est venu installer son matériel dans nos baies ( ETX + oneaccess).
Visiblement d'après le support technique et le support commercial, ils 
ne

peuvent pas me faire de NAT 1-1, et le bridge demande une option
supplémentaire (location de 2 ips / sites pour 40€ / mois)... Je suis 
pas à

40€ près, mais j'essaie d'économiser les IPv4 ;-). Donc...

Est-ce une pratique normale? Ai-je un moyen de shunter leur routeur? De
mettre le mien directement sur l'ETX? Voyez-vous une solution autre que 
ces

âneries commerciales?


Thomas.

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



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

[FRnOG] [TECH] Mise en place NAT / Bridge FO SFR

[Thomas Cottier]

Hello!

J'ai deux sites raccordés en FO chez SFR (offre SFR business connect)
depuis peu.

SFR est venu installer son matériel dans nos baies ( ETX + oneaccess).
Visiblement d'après le support technique et le support commercial, ils ne
peuvent pas me faire de NAT 1-1, et le bridge demande une option
supplémentaire (location de 2 ips / sites pour 40€ / mois)... Je suis pas à
40€ près, mais j'essaie d'économiser les IPv4 ;-). Donc...

Est-ce une pratique normale? Ai-je un moyen de shunter leur routeur? De
mettre le mien directement sur l'ETX? Voyez-vous une solution autre que ces
âneries commerciales?


Thomas.

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

Re: [TECH] Re : [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

[Fabien VINCENT (FrNOG)]

Le 2018-09-07 14:28, Olivier FRUQUET a écrit :


Salut,
Merci pour vos réponses.
Alors j'ai déjà essayé avec plusieurs ethertypes, j'avais fixé le 
0x88a8 partout mais ça n'a rien changé.
Oui j'ai une MTU déclarée élevée partout, j'affinerai un peu plus tard, 
là je veux juste que ça tombe en marche.
Juniper d'après ce que j'ai pu trouver en documentation taggues par 
défaut en 0x8100.
Un lien vers un schéma fait vite fait sur un tableau : 
https://image.noelshack.com/fichiers/2018/36/5/1536323250-schema-vxlan-olivier.jpg


@Fabien VINCENT : en gros j'ai un trunk C-VLAN vlan-id-list 1-4092 qui 
se fait tagguer par dessus en S-VLAN 1001 par les EX2300.

Je vais creuser un peu plus le pattern 4 de la doc Juni.
En gros les ports facing CE sur mes QFX ont la conf suivante :

set interfaces xe-0/0/0 description "*** Liaison FON vers CUST1001 
siege CPE port xe-0/1/3 ***;"

set interfaces xe-0/0/0 mtu 9216
set interfaces xe-0/0/0 flexible-vlan-tagging
set interfaces xe-0/0/0 encapsulation extended-vlan-bridge
set interfaces xe-0/0/0 unit 1001 vlan-id 1001

Ensuite j'ai la conf suivante pour VXLAN :

set vlans VLAN1001_CUST_QINQ interface xe-0/0/0.1001
set vlans VLAN1001_CUST_QINQ vlan-id 1001
set vlans VLAN1001_CUST_QINQ vxlan vni 1001
set vlans VLAN1001_CUST_QINQ vxlan ingress-node-replication

set protocols evpn encapsulation vxlan
set protocols evpn extended-vni-list all
set protocols evpn multicast-mode ingress-replication
set protocols l2-learning decapsulate-accept-inner-vlan

En me tagguant en 1001 un switch quelconque directement au cul d'un 
QFX, j'arrive à pinguer de l'autre côté, donc je suppose que la couche 
EVPN fonctionne bien, je n'ai pas testé du coup le flood and learn 
multicast.


J'ai essayé aussi avec le pattern 4 en pop and push mais pas mieux ...
La conf des ports de chaque EX2300 :

set interfaces xe-0/1/2 description "*** Liaison vers coeur client 
siege ***"

set interfaces xe-0/1/2 flexible-vlan-tagging
set interfaces xe-0/1/2 mtu 9216
set interfaces xe-0/1/2 encapsulation extended-vlan-bridge
set interfaces xe-0/1/2 unit 1001 vlan-id-list 1-4092
set interfaces xe-0/1/2 unit 1001 input-vlan-map push
set interfaces xe-0/1/2 unit 1001 output-vlan-map pop

set interfaces xe-0/1/3 description "*** Liaison FON vers QFX spine1 
***"

set interfaces xe-0/1/3 flexible-vlan-tagging
set interfaces xe-0/1/3 mtu 9216
set interfaces xe-0/1/3 encapsulation flexible-ethernet-services
set interfaces xe-0/1/3 unit 1001 encapsulation vlan-bridge
set interfaces xe-0/1/3 unit 1001 vlan-id 1001

J'ai testé tellement de choses que je me paume un peu, pour ça que j'ai 
besoin d'un oeil extérieur :)


Merci !
A plus
Olivier

Le jeu. 6 sept. 2018 à 23:19, Fabien VINCENT (FrNOG) 
 a écrit :


Le 2018-09-06 19:51, Sebastien Maillet a écrit :
Sinon, en fonction de l'implémentation du qinq sur ton équipement tu 
peux avoir des surprises si l'ethertype utilisé est 88a8 au lieu du 
8100 (tag Vlan).
Certains équipements ne reconnaissent pas l'ethertype 88a8 et du coup 
ne savent pas lire le tag Vlan juste derrière.
Pas sûr que ça vienne de ça mais ça vaut le coup de l'avoir en tête et 
vérifier ce point.

Sébastien

 Message original 
Objet : Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
De : Michel Hostettler
À : Olivier FRUQUET
Cc : Jugurta Yennek ,frnog-tech

J'me lance !
Vous êtes déclaré en jumbo frame ?
Michel

- Mail original -
De: "Olivier FRUQUET" 
À: "Jugurta Yennek" 
Cc: "frnog-tech" 
Envoyé: Jeudi 6 Septembre 2018 18:28:37
Objet: Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

Hello !
Yes MTU à 9216 sur toutes les interfaces.

Olivier

Le jeu. 6 sept. 2018 à 18:20, Jugurta Yennek  a 
écrit :


Hello Olivier,

A tout hasard tu es good au niveau MTU sur tout le chemin ?

Jugurta

On 06/09/2018 17:32, Olivier FRUQUET wrote: Bonjour à tous,

J'ai un petit souci dans une configuration EVPN VXLAN avec Juniper, 
j'aurai besoin d'un avis de pros !
Nous avons une IP fabric composée de deux routeurs MX204 en guise de 
coeur, 2 QFX5110 en rôle de Provider Edges et 2 petits EX2300 en CPE 
chez le

client.
Le but est de relier via une fibre noire le site 1 et le site 2 du 
client

avec tous ses vlans à l'intérieur d'un tunnel VXLAN, de manière
transparente, sans avoir besoin de déclarer au préalable les vlans du
client justement...
On s'est tournés vers le Q-in-Q encapsulé dans du VXLAN (je partais sur
l'idée que mes QFX matcheraient le S-VLAN 1001 avec tous les vlans du
client à l'intérieur pour envoyer sur un VXLAN VNI 1001), mais ça ne 
marche pas ... on a suivi la doc de Juniper : 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-vxlan-flexible-vlan-tag.html 
,

en vain.
Toute la partie BGP marche bien, quand je tag simple l'uplink de mon CE
vers le QFX en 1001 ça marche bien, par contre quand j'envoie du Q-in-Q
depuis le CE il n'y a plus rien qui passe ! J'ai utilisé le pattern N°3 
de la documentation Juniper.


Si quelqu'un l'a déjà fait ou a

Re: [TECH] Re : [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

[Olivier FRUQUET]

Salut,
Merci pour vos réponses.
Alors j'ai déjà essayé avec plusieurs ethertypes, j'avais fixé le 0x88a8
partout mais ça n'a rien changé.
Oui j'ai une MTU déclarée élevée partout, j'affinerai un peu plus tard, là
je veux juste que ça tombe en marche.
Juniper d'après ce que j'ai pu trouver en documentation taggues par défaut
en 0x8100.
Un lien vers un schéma fait vite fait sur un tableau :
https://image.noelshack.com/fichiers/2018/36/5/1536323250-schema-vxlan-olivier.jpg

@Fabien VINCENT : en gros j'ai un trunk C-VLAN vlan-id-list 1-4092 qui se
fait tagguer par dessus en S-VLAN 1001 par les EX2300.
Je vais creuser un peu plus le pattern 4 de la doc Juni.
En gros les ports facing CE sur mes QFX ont la conf suivante :
set interfaces xe-0/0/0 description "*** Liaison FON vers CUST1001 siege
CPE port xe-0/1/3 ***;"
set interfaces xe-0/0/0 mtu 9216
set interfaces xe-0/0/0 flexible-vlan-tagging
set interfaces xe-0/0/0 encapsulation extended-vlan-bridge
set interfaces xe-0/0/0 unit 1001 vlan-id 1001

Ensuite j'ai la conf suivante pour VXLAN :
set vlans VLAN1001_CUST_QINQ interface xe-0/0/0.1001
set vlans VLAN1001_CUST_QINQ vlan-id 1001
set vlans VLAN1001_CUST_QINQ vxlan vni 1001
set vlans VLAN1001_CUST_QINQ vxlan ingress-node-replication
set protocols evpn encapsulation vxlan
set protocols evpn extended-vni-list all
set protocols evpn multicast-mode ingress-replication
set protocols l2-learning decapsulate-accept-inner-vlan

En me tagguant en 1001 un switch quelconque directement au cul d'un QFX,
j'arrive à pinguer de l'autre côté, donc je suppose que la couche EVPN
fonctionne bien, je n'ai pas testé du coup le flood and learn multicast.

J'ai essayé aussi avec le pattern 4 en pop and push mais pas mieux ...
La conf des ports de chaque EX2300 :

set interfaces xe-0/1/2 description "*** Liaison vers coeur client siege
***"
set interfaces xe-0/1/2 flexible-vlan-tagging
set interfaces xe-0/1/2 mtu 9216
set interfaces xe-0/1/2 encapsulation extended-vlan-bridge
set interfaces xe-0/1/2 unit 1001 vlan-id-list 1-4092
set interfaces xe-0/1/2 unit 1001 input-vlan-map push
set interfaces xe-0/1/2 unit 1001 output-vlan-map pop

set interfaces xe-0/1/3 description "*** Liaison FON vers QFX spine1 ***"
set interfaces xe-0/1/3 flexible-vlan-tagging
set interfaces xe-0/1/3 mtu 9216
set interfaces xe-0/1/3 encapsulation flexible-ethernet-services
set interfaces xe-0/1/3 unit 1001 encapsulation vlan-bridge
set interfaces xe-0/1/3 unit 1001 vlan-id 1001

J'ai testé tellement de choses que je me paume un peu, pour ça que j'ai
besoin d'un oeil extérieur :)

Merci !
A plus
Olivier

Le jeu. 6 sept. 2018 à 23:19, Fabien VINCENT (FrNOG) 
a écrit :

> Le 2018-09-06 19:51, Sebastien Maillet a écrit :
>
> Sinon, en fonction de l'implémentation du qinq sur ton équipement tu peux
> avoir des surprises si l'ethertype utilisé est 88a8 au lieu du 8100 (tag
> Vlan).
> Certains équipements ne reconnaissent pas l'ethertype 88a8 et du coup ne
> savent pas lire le tag Vlan juste derrière.
> Pas sûr que ça vienne de ça mais ça vaut le coup de l'avoir en tête et
> vérifier ce point.
> Sébastien
>
>  Message original 
> Objet : Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
> De : Michel Hostettler
> À : Olivier FRUQUET
> Cc : Jugurta Yennek ,frnog-tech
>
> J'me lance !
> Vous êtes déclaré en jumbo frame ?
> Michel
>
> - Mail original -
> De: "Olivier FRUQUET" 
> À: "Jugurta Yennek" 
> Cc: "frnog-tech" 
> Envoyé: Jeudi 6 Septembre 2018 18:28:37
> Objet: Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
>
> Hello !
> Yes MTU à 9216 sur toutes les interfaces.
>
> Olivier
>
> Le jeu. 6 sept. 2018 à 18:20, Jugurta Yennek  a écrit :
>
> Hello Olivier,
>
> A tout hasard tu es good au niveau MTU sur tout le chemin ?
>
> Jugurta
>
>
> On 06/09/2018 17:32, Olivier FRUQUET wrote:
>
> Bonjour à tous,
>
> J'ai un petit souci dans une configuration EVPN VXLAN avec Juniper,
>
> j'aurai
>
> besoin d'un avis de pros !
> Nous avons une IP fabric composée de deux routeurs MX204 en guise de
>
> coeur,
>
> 2 QFX5110 en rôle de Provider Edges et 2 petits EX2300 en CPE chez le
> client.
> Le but est de relier via une fibre noire le site 1 et le site 2 du client
> avec tous ses vlans à l'intérieur d'un tunnel VXLAN, de manière
> transparente, sans avoir besoin de déclarer au préalable les vlans du
> client justement...
> On s'est tournés vers le Q-in-Q encapsulé dans du VXLAN (je partais sur
> l'idée que mes QFX matcheraient le S-VLAN 1001 avec tous les vlans du
> client à l'intérieur pour envoyer sur un VXLAN VNI 1001), mais ça ne
>
> marche
>
> pas ... on a suivi la doc de Juniper :
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-vxlan-flexible-vlan-tag.html
>
> ,
> en vain.
> Toute la partie BGP marche bien, quand je tag simple l'uplink de mon CE
> vers le QFX en 1001 ça marche bien, par contre quand j'envoie du Q-in-Q
> depuis le CE il n'y a plus rien qui passe ! J'ai utilisé le pattern N°3
>
> de
>
> 

Re: [FRnOG] [TECH] Entrepot + rack, roaming wifi

[David Ponzone]

Je devine que c’est pour ne pas perdre la connexion à l’application quoiqu’il 
se passe au niveau du terminal (roaming qui rate, perte de couverture, etc…).


> Le 7 sept. 2018 à 10:30, Jerome Lien  a écrit :
> 
> WPA2 avec PMKID caching  >> actuellement on est en wpa2 mais  sans raduis,
> donc avec une psk
> 802.11r sans ARM > j'ai la meme config
> 
> par contre, nous comme expliqué avant nous n'avons pas de rdp, mais l'app
> directement sur les mobiles avec un communication simpliste en tcp
> A la base pourquoi avoir mis les mobiles en rdp ?
> 
> 
> Le mer. 5 sept. 2018 à 18:40, Jerome Lien  a écrit :
> 
>> Bonjour,
>> 
>> 
>> beaucoup de question posé alors je vais faire un résumé pour centrer les
>> besoins.
>> Philippe PATINOTE
>> 1> pas de wifi voisin, c'est deja un gros plus pour nous
>> 2> en règle général le maillage est fait en sorte pour avoir une antenne
>> directrice par allée, en quinconce. Les racks peuvent être rempli de
>> serviette en papier comme d'huile, de fruit légume ou bien même de produit
>> surgelé .. ce qui ne facilite pas le positionnement car cela change avec le
>> temps.
>> Aerohive n'utilise pas de contrôleur, les antennes propagent les infos
>> entre elles dont les infos de roaming et les voisins directs
>> 
>> 3> J'ai pu tester une couverture en 5ghz, deux points se sont révélé
>> bloquant, avec des fruits et légumes, la couverture et vraiment réduite par
>> rapport à du 2,4 et les mobile SEUIC ne supporte absolument pas le fast
>> roaming en 5ghz 
>> 
>> Gaëtan Ferez
>> Pas bête le système de RDP sur terminaux ... cela pourrait regler beaucoup
>> de soucis. Le hic est qu'ils ont absoulement voulu utiliser un app
>> developper en windev en directe sur les mobiles (Win CE ou android) avec un
>> échange de paquet en TCP.
>> 
>> En somme, si pendant un roaming le serveur envoi un paquet TCP ... il
>> peut être dropé. Actuellement pendant un roaming on perds 1 ping dans les
>> cas "bloquant" (sur base 1 ping seconde) et parfois le roaming est
>> complètement transparent.
>> 
>> configuration en WPA2 > déjà le cas
>> PMKID caching > je vais contrôler
>> 802.11r sans ARM   > je vais contrôler
>> 
>> Pour tester aussi de façon différente, je vais monter un serveur SIP qui
>> balance une musique et je vais tester mon roaming ainsi ... je suis curieux
>> du résultat.
>> 
>> Xavier Beaudouin>> pour le client j'ai remarqué aujourd'hui justement que
>> les fameux SEUIC dans certain cas  (1 fois en 20 roaming) il ne tente pas
>> de roaming et attendent simplement de perdre l'antenne pour en découvrir
>> d'autre (donc la on a une belle coupure de 2-3 secondes ), et sinon dans
>> les autres cas correcte, il s'annonce bien sur l'antenne voisine, lance la
>> reassociation et hop.
>> 
>> 
>> Le mer. 5 sept. 2018 à 09:18, Xavier Beaudouin  a écrit :
>> 
>>> Hello,
>>> 
 De mon côté, je n’ai pas eu ce genre de problème.
 
 Sur un entrepôt de 25000 m2 avec borne en omni dir + mesh, la couverture
 fonctionnait plutôt bien sans spécialement de déconnexion.
 Par contre, j’étais sur de l’Aruba. Côté clients, il s’agissait plutôt
>>> de Teklo
 XT15 ou 9515 avec application RDP monté sur des Fenwick donc roaming
>>> rapide.
 
 Disposition des bornes en quinconce et ca fait l’affaire, configuration
>>> en WPA2
 avec PMKID caching et 802.11r sans ARM
>>> 
>>> Normalement avec des constructeurs de bornes wifi qui savent ce qu'est le
>>> roaming
>>> comme Aruba / Cisco / Ubiquiti / Extreme (ou Enterasys) tu ne dois pas
>>> avoir de
>>> problèmes.
>>> 
>>> Ceci dit, une partie du "fast roaming" doit être gérée aussi par le
>>> client, donc
>>> si ton client est obsolète (coucou les windows CE en mousse), alors les
>>> pb ne seront
>>> pas réglés par une infra wifi de compet.
>>> 
>>> My 0,02€
>>> Xavier
>>> 
>>> 
>>> ---
>>> 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] Entrepot + rack, roaming wifi

[Jerome Lien]

WPA2 avec PMKID caching  >> actuellement on est en wpa2 mais  sans raduis,
donc avec une psk
802.11r sans ARM > j'ai la meme config

par contre, nous comme expliqué avant nous n'avons pas de rdp, mais l'app
directement sur les mobiles avec un communication simpliste en tcp
A la base pourquoi avoir mis les mobiles en rdp ?


Le mer. 5 sept. 2018 à 18:40, Jerome Lien  a écrit :

> Bonjour,
>
>
> beaucoup de question posé alors je vais faire un résumé pour centrer les
> besoins.
> Philippe PATINOTE
> 1> pas de wifi voisin, c'est deja un gros plus pour nous
> 2> en règle général le maillage est fait en sorte pour avoir une antenne
> directrice par allée, en quinconce. Les racks peuvent être rempli de
> serviette en papier comme d'huile, de fruit légume ou bien même de produit
> surgelé .. ce qui ne facilite pas le positionnement car cela change avec le
> temps.
> Aerohive n'utilise pas de contrôleur, les antennes propagent les infos
> entre elles dont les infos de roaming et les voisins directs
>
> 3> J'ai pu tester une couverture en 5ghz, deux points se sont révélé
> bloquant, avec des fruits et légumes, la couverture et vraiment réduite par
> rapport à du 2,4 et les mobile SEUIC ne supporte absolument pas le fast
> roaming en 5ghz 
>
> Gaëtan Ferez
> Pas bête le système de RDP sur terminaux ... cela pourrait regler beaucoup
> de soucis. Le hic est qu'ils ont absoulement voulu utiliser un app
> developper en windev en directe sur les mobiles (Win CE ou android) avec un
> échange de paquet en TCP.
>
>  En somme, si pendant un roaming le serveur envoi un paquet TCP ... il
> peut être dropé. Actuellement pendant un roaming on perds 1 ping dans les
> cas "bloquant" (sur base 1 ping seconde) et parfois le roaming est
> complètement transparent.
>
> configuration en WPA2 > déjà le cas
>  PMKID caching > je vais contrôler
> 802.11r sans ARM   > je vais contrôler
>
> Pour tester aussi de façon différente, je vais monter un serveur SIP qui
> balance une musique et je vais tester mon roaming ainsi ... je suis curieux
> du résultat.
>
> Xavier Beaudouin>> pour le client j'ai remarqué aujourd'hui justement que
> les fameux SEUIC dans certain cas  (1 fois en 20 roaming) il ne tente pas
> de roaming et attendent simplement de perdre l'antenne pour en découvrir
> d'autre (donc la on a une belle coupure de 2-3 secondes ), et sinon dans
> les autres cas correcte, il s'annonce bien sur l'antenne voisine, lance la
> reassociation et hop.
>
>
> Le mer. 5 sept. 2018 à 09:18, Xavier Beaudouin  a écrit :
>
>> Hello,
>>
>> > De mon côté, je n’ai pas eu ce genre de problème.
>> >
>> > Sur un entrepôt de 25000 m2 avec borne en omni dir + mesh, la couverture
>> > fonctionnait plutôt bien sans spécialement de déconnexion.
>> > Par contre, j’étais sur de l’Aruba. Côté clients, il s’agissait plutôt
>> de Teklo
>> > XT15 ou 9515 avec application RDP monté sur des Fenwick donc roaming
>> rapide.
>> >
>> > Disposition des bornes en quinconce et ca fait l’affaire, configuration
>> en WPA2
>> > avec PMKID caching et 802.11r sans ARM
>>
>> Normalement avec des constructeurs de bornes wifi qui savent ce qu'est le
>> roaming
>> comme Aruba / Cisco / Ubiquiti / Extreme (ou Enterasys) tu ne dois pas
>> avoir de
>> problèmes.
>>
>> Ceci dit, une partie du "fast roaming" doit être gérée aussi par le
>> client, donc
>> si ton client est obsolète (coucou les windows CE en mousse), alors les
>> pb ne seront
>> pas réglés par une infra wifi de compet.
>>
>> My 0,02€
>> Xavier
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

Re: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF

[Emmanuel Halbwachs]

Bonjour Michel,

Michel Py (Thu 2018-09-06 23:49:27 +) :
> Un crash course de 2 jours c'est pas suffisant pour couvrir tous les
> aspects (en particulier si tu n'as jamais fait de route-maps (qui ne
> sont pas uniques à BGP) çà va être court.

OK. :-)

> Quel est ton objectif à réaliser plus tard ?

Mes besoins à court terme :

Être capable : 

- sur un routeur, de comprendre une conf BGP au premier coup d'œil

- de discuter avec mon fournisseur (Renater) et son NOC en comprenant
  la totalité du discours technique sur des services existants
  (raccordement à 2 POP avec plusieurs L3VPN)

- de faire du troubleshooting BGP tout seul

- de décider localement de la préférence du trafic via tel ou tel POP
  (jouer sur les local prefs)

- de monter de nouveaux services avec Renater

Exemple de nouveau service à étudier : nous avons 2 campus
géographiques distincts, chacun connecté à un réseau de collecte
régional différent (mais tous opérés par Renater, ce qui simplifie
grandement la coordination humaine), et j'aimerai que l'on puisse
facilement passer un service derrière une IP d'un campus à l'autre
avec le minimum d'interruption.

Plus la satisfaction d'en apprendre un peu plus tous les jours.

Je n'ai pas envie de cramer de l'argent et du temps malheureusement
rares dans une formation bidon. :-)

-- 
Emmanuel Halbwachs  Resp. Réseau/Sécurité
Observatoire de Paris ✆ +33 1 45 07 75 54
Paris :  61   av. de l'Observatoire   F 75014 PARIS
Meudon : 11 (face 32) av. Marcellin Berthelot F 92190 MEUDON


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