RE: [FRnOG] Re: [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Michel Py 
>> Nicolas Parpandet a écrit :
>> Ca m'est arrivé plusieurs fois depuis orange de faire des traceroutes qui 
>> laissent
>> apparaitre des IPs privées sur le trajet en plein milieux  d'ips publiques...

> Stephane Bortzmeyer a écrit :
> Oui mais ça, c'est MAL et je n'ai pas l'intention de commettre le Mal.

Tu confonds tout. Le Mal, c'est çà :
https://www.ietf.org/rfc/rfc3514.txt


> PS : c'est surtout une violation de BCP 38 : on ne doit laisser sortir des 
> paquets
> que si leur adresse IP source est une adresse publique « légale » du réseau.

BCP 38 c'est bien, si les gens s'en servaient vraiment ça serait encore mieux.

En essayant d'être sérieux un trolldi, les adresses IP privées dans le 
traceroute c'est pas propre, mais c'est mieux que ce que la plupart des FAI 
nous servent ces jours-ci : 1 seul hop de 15000 kilomètres à travers 
MPLS/VPLS/Dieu-sait-quoi qui enlève toute la visibilité de traceroute.

La différence entre "avant" et "maintenant" c'est que maintenant tout le monde 
est aveugle.


Michel.

P.S. : ici, "çà" rend aveugle, pas sourd. :P happy trolldi.


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet David Ponzone 
Et le gros CCR de MT, il ferait pas l'affaire ?


David Ponzone



> Le 22 juil. 2016 à 18:51, raf  a écrit :
> 
>> Le 22/07/2016 à 15:55, Aurélien a écrit :
>> 
>> 
>> C’était bien mon idée oui. Les P ne font même que du label-switching du coup.
> 
> En LSR je pense que des qfx5100 font le boulot (avec quelques limitations à 
> connaitre, genre la taille de la pile des labels).
> Cela reste quand même très peu cher du port 10G.
> 
> -- 
> Raphaël Mazelier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet raf 

Le 22/07/2016 à 15:55, Aurélien a écrit :



C’était bien mon idée oui. Les P ne font même que du label-switching du coup.



En LSR je pense que des qfx5100 font le boulot (avec quelques 
limitations à connaitre, genre la taille de la pile des labels).

Cela reste quand même très peu cher du port 10G.

--
Raphaël Mazelier


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

[FRnOG] [TECH] Convertisseur automagique de PIT en KML

2016-07-22 Par sujet Jérôme Nicolle 
Plop,

Comme je continuais à recevoir des mails après le post Howto d'il y a 3
ans (https://www.mail-archive.com/frnog@frnog.org/msg22875.html), et que
j'ai un padawan développeur pas manchot sous la main, je lui ai fait
pondre ça (à coup de fouets naturellement) :

http://pitre.ceriz.fr

Droppez-y un .zip tel que reçu d'Orange Wholesale et il le convertira en
KMZ en quelques secondes (une grande ville peut prendre 3-5 minutes).

L'intérêt par rapport à la méthode QGIS est que :
- c'est automagique
- le KMZ est plus léger

Alors comme c'est une version alpha, on a aucun scrupule à prodder ça un
trolldi. Support en worst-effort, naturellement. Merci de bien vouloir
planter le merdier.

Le code n'est pas (encore ?) sur GitHub, parce qu'il a un effet
lacrymogène encore inexpliqué.

Enjoy !

@+

-- 
Jérôme Nicolle
06 19 31 27 14


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet Clement Cavadore 
Yo,

On Fri, 2016-07-22 at 17:05 +0200, Youssef Bengelloun-Zahr wrote:
> CER-RT ?

+1 :-)

-- 
Clément Cavadore


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet Youssef Bengelloun-Zahr 
CER-RT ?

Y.



> Le 22 juil. 2016 à 15:55, Aurélien  a écrit :
> 
> Merci pour ce retour.
> 
> 2016-07-22 15:40 GMT+02:00 Radu-Adrian Feurdean
> :
>> Si la limitation de 2 routes ne te pose pas de probleme, 920 en edge
>> c'est ok.
> 
> Je pense que ça devrait tenir assez largement pour l’instant, pour
> l’instant je m’oriente vers des VRF internet à route par défaut, et
> qui contiendraient globalement le routage interne seulement, et après
> je pense qu’en distribuant correctement les PE je ne devrais pas trop
> augmenter ce nombre de routes. Après il faut voir les limites exactes
> du matos évidemment.
> 
>> Sinon, les 920 peuvent marcher aussi pas mal en tant que transport, si
>> ton besoin de ports 10G reste assez limite (max 4 ports 10G par 920).
> 
> Oui, c’était une piste, mais je pensais double-étoiler l’ensemble des
> sites sur 2 sites pour simplifier l’ajout de sites.
> 
>> 
>> Quand je dis transport, je pense a a du 100% MPLS, avec internet dans un
>> VRF (donc les P n'ont pas a connaitre la full-table).
> 
> C’était bien mon idée oui. Les P ne font même que du label-switching du coup.
> 
>> Pour les alternatives:
>> - 7200 - tu oublies definitivement.
>> - si par 7200 tu voulais dire 7600, c'est de l'histoire anicenne. Si le
>> fait d'avoir de machines a laver dans la baie ne te pose pas de
>> probleme, ca pourait marcher (mais ca reste overkill de les deployer en
>> 2016-2017).
>> - MLXe - apart le prix, pourquoi pas. MLXe-8 ca commence a etre
>> overkill.
>> Sinon:
>> - Catalyst 6840 (plutot 6816) ou 6880.
>> - Je suis en train de tester des ZTE 5960 (48 x 1/10G, MPLS) pour
>> quelque-chose de similaire. A suivre.
>> - si les 4 ports 10G suffissent, toujours des 920.
> 
> Ça fait effectivement des machines à laver, ma piste la plus crédible
> était le MLXe-4 jusqu’ici, mais je vais voir ce que donnent ces
> alternatives au niveau budget. Merci pour les tips :)
> 
> Cordialement,
> -- 
> Aurélien Guillaume
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet Aurélien 
Merci pour ce retour.

2016-07-22 15:40 GMT+02:00 Radu-Adrian Feurdean
:
> Si la limitation de 2 routes ne te pose pas de probleme, 920 en edge
> c'est ok.

Je pense que ça devrait tenir assez largement pour l’instant, pour
l’instant je m’oriente vers des VRF internet à route par défaut, et
qui contiendraient globalement le routage interne seulement, et après
je pense qu’en distribuant correctement les PE je ne devrais pas trop
augmenter ce nombre de routes. Après il faut voir les limites exactes
du matos évidemment.

> Sinon, les 920 peuvent marcher aussi pas mal en tant que transport, si
> ton besoin de ports 10G reste assez limite (max 4 ports 10G par 920).

Oui, c’était une piste, mais je pensais double-étoiler l’ensemble des
sites sur 2 sites pour simplifier l’ajout de sites.

>
> Quand je dis transport, je pense a a du 100% MPLS, avec internet dans un
> VRF (donc les P n'ont pas a connaitre la full-table).
>

C’était bien mon idée oui. Les P ne font même que du label-switching du coup.

> Pour les alternatives:
>  - 7200 - tu oublies definitivement.
>  - si par 7200 tu voulais dire 7600, c'est de l'histoire anicenne. Si le
>  fait d'avoir de machines a laver dans la baie ne te pose pas de
>  probleme, ca pourait marcher (mais ca reste overkill de les deployer en
>  2016-2017).
>  - MLXe - apart le prix, pourquoi pas. MLXe-8 ca commence a etre
>  overkill.
> Sinon:
>  - Catalyst 6840 (plutot 6816) ou 6880.
>  - Je suis en train de tester des ZTE 5960 (48 x 1/10G, MPLS) pour
>  quelque-chose de similaire. A suivre.
>  - si les 4 ports 10G suffissent, toujours des 920.

Ça fait effectivement des machines à laver, ma piste la plus crédible
était le MLXe-4 jusqu’ici, mais je vais voir ce que donnent ces
alternatives au niveau budget. Merci pour les tips :)

Cordialement,
-- 
Aurélien Guillaume


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

Re: [FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet Radu-Adrian Feurdean 
On Fri, Jul 22, 2016, at 15:09, Aurélien wrote:

> J’ai pensé à une infra plutôt classique à base de OSPF/LDP/MPLS pour
> le transport, et de BGP pour la distribution L3VPN (v4,v6).
> 
> J’ai pensé à de l’ASR920 côté Edge (la configuration des interfaces
> semble permettre une livraison assez flexible des services, et le
> featureset semble assez complet), mais je cherche encore deux
> équipements de cœur pour relier mes edges, possiblement quelque chose
> en broke (MLXe-4 ou 8 avec des 4 ou 8x10G-M ? Cisco 7200 ?) Qu’en
> pensez-vous ?

Si la limitation de 2 routes ne te pose pas de probleme, 920 en edge
c'est ok.
Sinon, les 920 peuvent marcher aussi pas mal en tant que transport, si
ton besoin de ports 10G reste assez limite (max 4 ports 10G par 920).

Quand je dis transport, je pense a a du 100% MPLS, avec internet dans un
VRF (donc les P n'ont pas a connaitre la full-table).

Pour les alternatives:
 - 7200 - tu oublies definitivement.
 - si par 7200 tu voulais dire 7600, c'est de l'histoire anicenne. Si le
 fait d'avoir de machines a laver dans la baie ne te pose pas de
 probleme, ca pourait marcher (mais ca reste overkill de les deployer en
 2016-2017).
 - MLXe - apart le prix, pourquoi pas. MLXe-8 ca commence a etre
 overkill.
Sinon: 
 - Catalyst 6840 (plutot 6816) ou 6880.
 - Je suis en train de tester des ZTE 5960 (48 x 1/10G, MPLS) pour
 quelque-chose de similaire. A suivre.
 - si les 4 ports 10G suffissent, toujours des 920.


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

Re: [FRnOG] [BIZ] Zonage offre CELAN Orange

2016-07-22 Par sujet Radu-Adrian Feurdean 
On Fri, Jul 22, 2016, at 13:37, David Ponzone wrote:

> Détail important: envisage une porte C2E plutôt que CELAN
> Pourquoi ? Parce que tu peux commander une liaison CELAN sur une porte
> C2E, pas l’inverse.
> Donc avec une porte C2E, tu peux tout faire, et le C2E est plus
> intéressant financièrement en national car la partie extension nationale
> est mutualisée.

Par contre en CEE, le PPPoE c'est presque obligatoire vu les limitations
techniques de l'offre.


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Xavier Beaudouin 
Hello,

> Je crois que nous avons déjà eu la discussion, mais pour moi cela est
> surtout utile dans des configurations de grosses fabriques IP, pas pour
> le core. Mais avec l’avènement du tout automatisé je suis de moins en
> convaincu, d'autant que comme tu le souligne le support constructeur est
> des plus aléatoire.

Bon puisqu'on est vendredi :

Autant tout mettre en ipv6, voire pire en ipv6 link local et tunneliser le v4 
dans le v6


:D

/Xavier


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

[FRnOG] [TECH] Routeur de cœur MPLS

2016-07-22 Par sujet Aurélien 
Hello la liste,

Afin de scaler un peu mieux une infra (4 sites parisiens avec pas mal
de L2/vlan), je voudrais la doter d’un backbone de transport me
permettant d’assurer plus simplement la livraison (pour des besoins
internes) de services IP L3 (transit internet, VPNs) et L2 point à
point (à minima), avec un débit entre 1 à 4 x1 Gb/s (principalement)
et 10Gb/s (rarement). Je cherche quelque chose de bien éprouvé et de
facile à gérer, tout en étant raisonnable dans le coût, et permettant
de scaler assez facilement à une douzaine de sites. Le but est
principalement de livrer en DC dans des baies réseau, donc avec une
certaine densité de ports côté Edge.

J’ai pensé à une infra plutôt classique à base de OSPF/LDP/MPLS pour
le transport, et de BGP pour la distribution L3VPN (v4,v6).

J’ai pensé à de l’ASR920 côté Edge (la configuration des interfaces
semble permettre une livraison assez flexible des services, et le
featureset semble assez complet), mais je cherche encore deux
équipements de cœur pour relier mes edges, possiblement quelque chose
en broke (MLXe-4 ou 8 avec des 4 ou 8x10G-M ? Cisco 7200 ?) Qu’en
pensez-vous ?

J’aurais aimé avoir vos retours d’expérience sur ce type de use-case
et sur ce type de matériel, ou sur d’autres alternatives semblables en
termes de features/densité/prix que vous auriez en production.

J’ai également regardé du côté de l’OpenNetworking (autour des Dell
S4048-ON par exemple), sans qu’un choix évident pour la couche
logicielle ne se dégage pour ce type d’applications à cette échelle, à
moins que j’aie raté quelque chose.

Merci,

Cordialement,
-- 
Aurélien Guillaume


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

[FRnOG] [BIZ] Re: Zonage offre CELAN Orange

2016-07-22 Par sujet Fabien H 
Merci David & Jérôme pour vos reponses précises,
J'etudie tout ça..

Fabien


Le vendredi 22 juillet 2016, David Ponzone  a
écrit :
> Le 22 juil. 2016 à 12:50, Fabien H  a écrit :
>
> la zone de couverture de cette porte sur la région (en cuivre ou fibre)
> correspond bien à ce que Orange appelle la "Région administrative" dans
son
> fichier Excel "Couverture géographique des offres CE2O ou CELAN ou C2E
pour
> les accès sur fibre" ? :
>
>
http://www.orange.com/fr/content/download/13289/268065/version/5/file/Couverture%20g%C3%A9ographique%20et%20zonage%20tarifaire%20des%20offres%20CE2O-C2E-CELAN%20au%201%20septembre%202013.xls
>
> Oui, voilà, il faut regarder les colonnes région ATM et région Ethernet.
> T’es content quand t’es pas dans le Var (la plaque ne comporte qu’un
département) :)
> Mais ils ont le soleil et les cigales.
>
> En dehors de cette région administrative, Orange peut surement fournir du
> lien CELAN "en extension" sur la France entière ? Je ne trouve pas, dans
> l'annexe tarifaire,  le surcout FAS & ABO lorsqu'un lien est commandé en
> extension ?
>
>
http://www.orange.com/fr/content/download/29259/823020/version/2/file/annexe%206%203%209%20a%20-%20prix%20CE%20LAN%20applicable%20au%2015%20avril%202015.pdf
>
> Oui mais ce n’est pas un tarif régulé donc pas public.
> Pas de surcoût FAS. Surcoût abo environ 10-12€/Mbps (dégressif bien sûr
mais surtout au dessus de 20Mbps).
> Ton commercial va se faire une joie de te la communiquer, et tu vas
pleurer :)
>
> Les régions ATM et Ethernet Optique, c'est important aussi vis à vis de
> l'extension ?
>
> Ils sont en train de tuer progressivement le réseau ATM, donc ça
m’étonnerait qu’ils t’en parlent :)
> Je ne sais même pas si on peut encore prendre une porte ATM.
> Détail important: envisage une porte C2E plutôt que CELAN
> Pourquoi ? Parce que tu peux commander une liaison CELAN sur une porte
C2E, pas l’inverse.
> Donc avec une porte C2E, tu peux tout faire, et le C2E est plus
intéressant financièrement en national car la partie extension nationale
est mutualisée.
> Et quand tu as besoin de qualité :) (c’est vendredi, je pars en vacances
ce soir, j’ai droit à un petit troll), tu peux toujours commander une CELAN.
> Il n’y a pas si longtemps, les commerciaux Orange oubliaient de signaler
ce petit point technique :)
>
>

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

Re: [FRnOG] [BIZ] Zonage offre CELAN Orange

2016-07-22 Par sujet David Ponzone 
> Le 22 juil. 2016 à 12:50, Fabien H  a écrit :

> la zone de couverture de cette porte sur la région (en cuivre ou fibre)
> correspond bien à ce que Orange appelle la "Région administrative" dans son
> fichier Excel "Couverture géographique des offres CE2O ou CELAN ou C2E pour
> les accès sur fibre" ? :
> 
> http://www.orange.com/fr/content/download/13289/268065/version/5/file/Couverture%20g%C3%A9ographique%20et%20zonage%20tarifaire%20des%20offres%20CE2O-C2E-CELAN%20au%201%20septembre%202013.xls
>  
> 

Oui, voilà, il faut regarder les colonnes région ATM et région Ethernet.
T’es content quand t’es pas dans le Var (la plaque ne comporte qu’un 
département) :)
Mais ils ont le soleil et les cigales.

> En dehors de cette région administrative, Orange peut surement fournir du
> lien CELAN "en extension" sur la France entière ? Je ne trouve pas, dans
> l'annexe tarifaire,  le surcout FAS & ABO lorsqu'un lien est commandé en
> extension ?
> 
> http://www.orange.com/fr/content/download/29259/823020/version/2/file/annexe%206%203%209%20a%20-%20prix%20CE%20LAN%20applicable%20au%2015%20avril%202015.pdf
>  
> 

Oui mais ce n’est pas un tarif régulé donc pas public.
Pas de surcoût FAS. Surcoût abo environ 10-12€/Mbps (dégressif bien sûr mais 
surtout au dessus de 20Mbps).
Ton commercial va se faire une joie de te la communiquer, et tu vas pleurer :)

> Les régions ATM et Ethernet Optique, c'est important aussi vis à vis de
> l'extension ?

Ils sont en train de tuer progressivement le réseau ATM, donc ça m’étonnerait 
qu’ils t’en parlent :)
Je ne sais même pas si on peut encore prendre une porte ATM.

Détail important: envisage une porte C2E plutôt que CELAN
Pourquoi ? Parce que tu peux commander une liaison CELAN sur une porte C2E, pas 
l’inverse.
Donc avec une porte C2E, tu peux tout faire, et le C2E est plus intéressant 
financièrement en national car la partie extension nationale est mutualisée.
Et quand tu as besoin de qualité :) (c’est vendredi, je pars en vacances ce 
soir, j’ai droit à un petit troll), tu peux toujours commander une CELAN.
Il n’y a pas si longtemps, les commerciaux Orange oubliaient de signaler ce 
petit point technique :)



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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet William VINCENT 
C'est ce que disait Julien, mais comme j'ai vu la règle de NAT, je 
pensais que ça n'avait pas de rapport mais si, c'est la solution même 
pour le DR


ça fonctionne à présent

Merci à tous et bon week end :)




Le 21/07/2016 à 12:08, julien soula a écrit :

On Thu, Jul 21, 2016 at 11:47:16AM +0200, Richard DEMONGEOT wrote:

Hello,

salut,


Ça ressemble à un cas vecu; est-ce que la partie loader balancing est identique 
sur tes deux serveurs?

Dans la positive, tu a le lb1 qui loader balance :
- 50% du trafic sur lui; (Trafic ok)
- 50% du trafic sur son copain. (Blague)

Le lb2 recherche loadbalance :
- 50% sur lui (donc 25% du trafic originel :ok)
- 50% sur son copain (erreur). En effet, cette partie là est flaguee par les 
deux lb comme étant à traiter par l'autre, donc boucle et trafic perdu.

Pour corriger, sur le lb2 il suffit de ne pas configurer la note 1 dans les 
slaves.

pour eviter de trop differencier les fichiers de config et pour que
les backups puissent devenir master en cas de defaillance, on a adopte
une autre strategie.

Sur les backups, on a la regle "iptables -t nat -A PREROUTING -s
0.0.0.0/0 -d  -j REDIRECT". Ca permet de transformer l'IP
destination en celle du noeud lui-meme et donc d'eviter le lb.

Pour creer et supprimer la regle en fonction de l'etat maitre/escalve,
on utilise les parametres notify_master, notify_backup, notify_fault.

a+,


--
William VINCENT
Administrateur systèmes et réseaux
IRIT - UMR5505
Université Paul Sabatier
118 route de Narbonne
31062 TOULOUSE cedex 9

Tel : 05.61.55.69.38


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

[FRnOG] [BIZ] Zonage offre CELAN Orange

2016-07-22 Par sujet Fabien H 
Bonjour,
nous sommes en train d'étudier la possibilité d'ouvrir une porte CELAN dans
un DC ou Orange est présent.

Juste pour être sur et pour pas passer pour un bleu auprès des commerciaux
Orange :

la zone de couverture de cette porte sur la région (en cuivre ou fibre)
correspond bien à ce que Orange appelle la "Région administrative" dans son
fichier Excel "Couverture géographique des offres CE2O ou CELAN ou C2E pour
les accès sur fibre" ? :

http://www.orange.com/fr/content/download/13289/268065/version/5/file/Couverture%20g%C3%A9ographique%20et%20zonage%20tarifaire%20des%20offres%20CE2O-C2E-CELAN%20au%201%20septembre%202013.xls


En dehors de cette région administrative, Orange peut surement fournir du
lien CELAN "en extension" sur la France entière ? Je ne trouve pas, dans
l'annexe tarifaire,  le surcout FAS & ABO lorsqu'un lien est commandé en
extension ?

http://www.orange.com/fr/content/download/29259/823020/version/2/file/annexe%206%203%209%20a%20-%20prix%20CE%20LAN%20applicable%20au%2015%20avril%202015.pdf

Les régions ATM et Ethernet Optique, c'est important aussi vis à vis de
l'extension ?

Merci pour vos lumières,
Fabien

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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet David Ponzone 
Ah oui, ça doit être ça alors!
Les IP du backbone Orange sont pas annoncées ? Sauvage, qu’ils les rendent au 
RIPE sur le champ :)



> Le 22 juil. 2016 à 11:53, Pierre Emeriaud  a écrit :
> 
> Le 22 juillet 2016 à 11:46, David Ponzone  a écrit :
>> Oui et d’ailleurs je crois que depuis, Orange a compris qu’il fallait 
>> filtrer en sortie les paquets émis par des IP privées, et on a le droit à 
>> des * maintenant, plutôt que des privées.
> 
> Non. A tous les coups c'est à cause de l'urpf dans le réseau source.
> 
> Les ip du backbone orange ne sont pas annoncées, donc ça coince.


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

[FRnOG] Re: [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Stephane Bortzmeyer 
On Fri, Jul 22, 2016 at 11:38:07AM +0200,
 Vincent Bernat  wrote 
 a message of 26 lines which said:

> Cela ne permet pas seulement d'économiser des IP publiques, cela
> simplifie grandement la configuration.

Oui, mais ma question ne portait pas sur le fait d'utiliser des
interfaces non numérotées (c'est déjà décidé) mais sur le fait de
n'avoir qu'une seule adresse IP publique pour tous les routeurs.


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Pierre Emeriaud 
Le 22 juillet 2016 à 11:46, David Ponzone  a écrit :
> Oui et d’ailleurs je crois que depuis, Orange a compris qu’il fallait filtrer 
> en sortie les paquets émis par des IP privées, et on a le droit à des * 
> maintenant, plutôt que des privées.

Non. A tous les coups c'est à cause de l'urpf dans le réseau source.

Les ip du backbone orange ne sont pas annoncées, donc ça coince.


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet raf 

Le 22/07/2016 à 11:38, Vincent Bernat a écrit :

 ❦ 22 juillet 2016 09:46 CEST, Stephane Bortzmeyer  :




Fonctionnalité assez bien supportée sur les MX, rudement moins bien
sur les QFX et plus du tout sur les EX. Ce qui est très embêtant vu
qu'il faut que tout le monde supporte la chose.

Cela ne permet pas seulement d'économiser des IP publiques, cela
simplifie grandement la configuration.



Je crois que nous avons déjà eu la discussion, mais pour moi cela est 
surtout utile dans des configurations de grosses fabriques IP, pas pour 
le core. Mais avec l’avènement du tout automatisé je suis de moins en 
convaincu, d'autant que comme tu le souligne le support constructeur est 
des plus aléatoire.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet David Ponzone 
Oui et d’ailleurs je crois que depuis, Orange a compris qu’il fallait filtrer 
en sortie les paquets émis par des IP privées, et on a le droit à des * 
maintenant, plutôt que des privées.



> Le 22 juil. 2016 à 09:59, Nicolas Parpandet  a écrit :
> 
> 
> Ca m'est arrivé plusieurs fois depuis orange de faire des traceroutes qui 
> laissent apparaitre des IPs privées sur le trajet en plein
> milieux d'ips publiques...
> 
> Nicolas
> 
> - Mail original -
>> De: "Stephane Bortzmeyer" 
>> À: frnog-t...@frnog.org
>> Envoyé: Vendredi 22 Juillet 2016 09:46:16
>> Objet: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des 
>> routeurs
> 
>> Je pense que c'est surtout un question de goût mais je demande quand
>> même, pour les points techniques qui m'ont échappé.
>> 
>> Si on manque d'adresses IPv4 (publiques, évidemment), numéroter toutes
>> les pattes d'un routeur peut devenir difficile. Mettons qu'on mette
>> pas mal de pattes en « non numéroté » (exemple chez Juniper
>> )
>> et qu'on n'utilise qu'une seule adresse par routeur, « donneur » (pour
>> reprendre la terminologie JunOS) d'adresse pour toutes les
>> interfaces. Si cela ne suffit pas, si on n'a vraiment pas assez
>> d'adresses IPv4 pour tous les routeurs, quel est votre avis sur la
>> solution qui consisterait à avoir une seule adresse IPv4 publique pour
>> tous les routeurs, qui ne servirait que de source pour les ICMP ?
>> 
>> Ça ferait des traceroutes bizarres, je sais. Mais l'alternative serait
>> de n'utiliser que des adresses privées et, là, comme ces paquets ne
>> peuvent pas sortir d'un réseau bien géré, le traceroute serait encore
>> moins beau (et lent, car traceroute devrait attendre les timeouts).
>> 
>> 
>> 
>> ---
>> 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] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Vincent Bernat 
 ❦ 22 juillet 2016 09:46 CEST, Stephane Bortzmeyer  :

> Si on manque d'adresses IPv4 (publiques, évidemment), numéroter toutes
> les pattes d'un routeur peut devenir difficile. Mettons qu'on mette
> pas mal de pattes en « non numéroté » (exemple chez Juniper
> )
> et qu'on n'utilise qu'une seule adresse par routeur, « donneur » (pour
> reprendre la terminologie JunOS) d'adresse pour toutes les
> interfaces.

Fonctionnalité assez bien supportée sur les MX, rudement moins bien
sur les QFX et plus du tout sur les EX. Ce qui est très embêtant vu
qu'il faut que tout le monde supporte la chose.

Cela ne permet pas seulement d'économiser des IP publiques, cela
simplifie grandement la configuration.
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet gael_ajinn 
Normalement, les LB et les backend ne sont pas sur les memes serveurs, ca evite 
bien des soucis.

Il existe cependant une ruse pour mettre les LB et les backend sur les mêmes 
serveurs, mais c'est une ruse que personnellement j’évite d'utiliser.Elle fait 
appel a des scripts et a de la réécriture d'adresse IP via iptables, je trouve 
ça moyennement propre. Sans cette ruse, le risque est d'avoir des boucles ...


Le site qui présente la ruse : http://gcharriere.com/blog/?p=339

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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet Vincent Bernat 
 ❦ 22 juillet 2016 08:59 CEST, Matthieu Racine  :

>> Le fait que seul le master envoie des requêtes est normal. La différence
>> de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
>> donnerait quelques billes.
>
> Bonjour,
>
> Arrêtez moi si je dis une bêtise, mais pour moi le DR, ça sert à
> mettre des serveurs "derrière" des loads balancers. Bien que
> "derrière" ne soit pas le terme correct puisqu'il faut que les LB et
> les serveurs soient sur le même lien de broadcast.
> Le VRRP inclus dans Keepalived, c'est la cerise qui permet de redonder
> (bascule, pas de mode actif/actif) les LB.
>
> Encore une fois, je me trompe peut-être, mais on ne met pas keepalived
> sur les serveurs eux même pour faire du DR / LB, non ???

Si, c'est le mode "local node" :
 http://www.linuxvirtualserver.org/docs/LocalNode.html
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet William VINCENT 
Quand une requête ldap échoue, je viens de me rendre que j'ai une boucle 
énorme de ce type de paquets alors que le processus ldapsearch est coupé:


 3019967 210.902299375 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1556064 TSecr=0 WS=128
3019968 210.902301510 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1550054 TSecr=0 WS=128
3019969 210.902303495 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1550054 TSecr=0 WS=128
3019970 210.902318994 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1564080 TSecr=0 WS=128
3019971 210.902330565 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1564080 TSecr=0 WS=128
3019972 210.902332859 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1552056 TSecr=0 WS=128
3019973 210.902334857 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1552056 TSecr=0 WS=128
3019974 210.902336092 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1549052 TSecr=0 WS=128
3019975 210.902337782 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1549052 TSecr=0 WS=128
3019976 210.902399768 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1556064 TSecr=0 WS=128
3019977 210.902414141 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1556064 TSecr=0 WS=128
3019978 210.902416502 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1550054 TSecr=0 WS=128
3019979 210.902418457 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1550054 TSecr=0 WS=128
3019980 210.902419624 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1564080 TSecr=0 WS=128
3019981 210.902421431 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1564080 TSecr=0 WS=128
3019982 210.902455521 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1552056 TSecr=0 WS=128
3019983 210.902468494 ip.du.client -> ip.virtuelle TCP 74 [TCP 
Retransmission] 51756 > ldap [SYN] Seq=0 Win=29200 Len=0 MSS=1460 
SACK_PERM=1 TSval=1552056 TSecr=0 WS=128



Je n'ai aucune trace de ces requêtes sur le client, j'imagine donc que 
ce sont les serveurs ldap qui s'échange en boucle ces paquets mais pour 
arrêter le flood, je coupe l'interface réseau du client... Vraiment très 
étrange comme comportement


Le 22/07/2016 à 09:45, Guillaume Tournat a écrit :

En effet, il y a peut être confusion entre le (ou les) LB, et les backend 
servers.



Le 22 juil. 2016 à 08:59, Matthieu Racine  a écrit :



Le 21/07/2016 à 16:41, Vincent Bernat a écrit :

Le fait que seul le master envoie des requêtes est normal. La différence
de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
donnerait quelques billes.

Bonjour,

Arrêtez moi si je dis une bêtise, mais pour moi le DR, ça sert à mettre des serveurs 
"derrière" des loads balancers. Bien que "derrière" ne soit pas le terme 
correct puisqu'il faut que les LB et les serveurs soient sur le même lien de broadcast.
Le VRRP inclus dans Keepalived, c'est la cerise qui permet de redonder 
(bascule, pas de mode actif/actif) les LB.

Encore une fois, je me trompe peut-être, mais on ne met pas keepalived sur les 
serveurs eux même pour faire du DR / LB, non ???

Cordialement,
--
Matthieu


---
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] Re: [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Stephane Bortzmeyer 
On Fri, Jul 22, 2016 at 09:59:27AM +0200,
 Nicolas Parpandet  wrote 
 a message of 46 lines which said:

> Ca m'est arrivé plusieurs fois depuis orange de faire des
> traceroutes qui laissent apparaitre des IPs privées sur le trajet en
> plein milieux d'ips publiques...

Oui mais ça, c'est MAL et je n'ai pas l'intention de commettre le Mal.

PS : c'est surtout une violation de BCP 38 : on ne doit laisser sortir
des paquets que si leur adresse IP source est une adresse publique
« légale » du réseau.


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Nicolas Parpandet 

Ca m'est arrivé plusieurs fois depuis orange de faire des traceroutes qui 
laissent apparaitre des IPs privées sur le trajet en plein
milieux d'ips publiques...

Nicolas

- Mail original -
> De: "Stephane Bortzmeyer" 
> À: frnog-t...@frnog.org
> Envoyé: Vendredi 22 Juillet 2016 09:46:16
> Objet: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des 
> routeurs

> Je pense que c'est surtout un question de goût mais je demande quand
> même, pour les points techniques qui m'ont échappé.
> 
> Si on manque d'adresses IPv4 (publiques, évidemment), numéroter toutes
> les pattes d'un routeur peut devenir difficile. Mettons qu'on mette
> pas mal de pattes en « non numéroté » (exemple chez Juniper
> )
> et qu'on n'utilise qu'une seule adresse par routeur, « donneur » (pour
> reprendre la terminologie JunOS) d'adresse pour toutes les
> interfaces. Si cela ne suffit pas, si on n'a vraiment pas assez
> d'adresses IPv4 pour tous les routeurs, quel est votre avis sur la
> solution qui consisterait à avoir une seule adresse IPv4 publique pour
> tous les routeurs, qui ne servirait que de source pour les ICMP ?
> 
> Ça ferait des traceroutes bizarres, je sais. Mais l'alternative serait
> de n'utiliser que des adresses privées et, là, comme ces paquets ne
> peuvent pas sortir d'un réseau bien géré, le traceroute serait encore
> moins beau (et lent, car traceroute devrait attendre les timeouts).
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

2016-07-22 Par sujet Stephane Bortzmeyer 
Je pense que c'est surtout un question de goût mais je demande quand
même, pour les points techniques qui m'ont échappé.

Si on manque d'adresses IPv4 (publiques, évidemment), numéroter toutes
les pattes d'un routeur peut devenir difficile. Mettons qu'on mette
pas mal de pattes en « non numéroté » (exemple chez Juniper
)
et qu'on n'utilise qu'une seule adresse par routeur, « donneur » (pour
reprendre la terminologie JunOS) d'adresse pour toutes les
interfaces. Si cela ne suffit pas, si on n'a vraiment pas assez
d'adresses IPv4 pour tous les routeurs, quel est votre avis sur la
solution qui consisterait à avoir une seule adresse IPv4 publique pour
tous les routeurs, qui ne servirait que de source pour les ICMP ?

Ça ferait des traceroutes bizarres, je sais. Mais l'alternative serait
de n'utiliser que des adresses privées et, là, comme ces paquets ne
peuvent pas sortir d'un réseau bien géré, le traceroute serait encore
moins beau (et lent, car traceroute devrait attendre les timeouts).



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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet Guillaume Tournat 
En effet, il y a peut être confusion entre le (ou les) LB, et les backend 
servers. 


> Le 22 juil. 2016 à 08:59, Matthieu Racine  a écrit :
> 
> 
>> Le 21/07/2016 à 16:41, Vincent Bernat a écrit :
>> 
>> Le fait que seul le master envoie des requêtes est normal. La différence
>> de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
>> donnerait quelques billes.
> 
> Bonjour,
> 
> Arrêtez moi si je dis une bêtise, mais pour moi le DR, ça sert à mettre des 
> serveurs "derrière" des loads balancers. Bien que "derrière" ne soit pas le 
> terme correct puisqu'il faut que les LB et les serveurs soient sur le même 
> lien de broadcast.
> Le VRRP inclus dans Keepalived, c'est la cerise qui permet de redonder 
> (bascule, pas de mode actif/actif) les LB.
> 
> Encore une fois, je me trompe peut-être, mais on ne met pas keepalived sur 
> les serveurs eux même pour faire du DR / LB, non ???
> 
> Cordialement,
> --
> Matthieu
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet Matthieu Racine 


Le 21/07/2016 à 16:41, Vincent Bernat a écrit :


Le fait que seul le master envoie des requêtes est normal. La différence
de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
donnerait quelques billes.


Bonjour,

Arrêtez moi si je dis une bêtise, mais pour moi le DR, ça sert à mettre 
des serveurs "derrière" des loads balancers. Bien que "derrière" ne soit 
pas le terme correct puisqu'il faut que les LB et les serveurs soient 
sur le même lien de broadcast.
Le VRRP inclus dans Keepalived, c'est la cerise qui permet de redonder 
(bascule, pas de mode actif/actif) les LB.


Encore une fois, je me trompe peut-être, mais on ne met pas keepalived 
sur les serveurs eux même pour faire du DR / LB, non ???


Cordialement,
--
Matthieu


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