Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2013-01-11 Par sujet Greg Villain 
C'est vraiment pas mal BIRD si tu peux faire abstraction de la CLI qui est 
exaspérante.
On s'en sert plutôt massivement chez nous sans vraiment aucun souci…
-
Greg

On Nov 4, 2012, at 11:19 AM, Raphaël Maunier 
raphael.maun...@jaguar-network.com wrote:

 
 On 4 nov. 2012, at 17:24, Thomas Mangin thomas.man...@exa-networks.co.uk 
 wrote:
 
 Sent from my iPad
 
 On 3 Nov 2012, at 21:39, Raphaël Maunier 
 raphael.maun...@jaguar-network.com wrote:
 
 Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire 
 tourner ton BGP.
 Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, 
 c'est Observium et j'ai même filé qq euros au projet :)
 
 Je vais eviter la discussion sur BIRD .. Je laisse ca aux gens de AMSIX :)
 Des retours sur Observium STP - compare a d autres solutions open source ?
 
 Ça tue tous les autres soft en Opensource pour la simplicité. Cependant, j'ai 
 un doute sur les perds sur un gros réseaux. Chez mon ancien employeur, on 
 avait monté pour voir, et juste une partie de naimix ont ecroulé la machine, 
 car le pooler est en php.
 Il y a sûrement des optims possible, mais on a pas pris le temps de chercher.
 
 Mais pour perso, monitorer les routeurs / serveurs de mes potes, j'ai fais 
 une VM sur un de mes serveurs, et en 3 coup de config en Shell  ça juste 
 marche sans se prendre la tête.
 En tout cas, Nagios, Zabbix and cie, c'est plus pour moi
 
 Thomas
 
 
 ---
 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] Routeurs BGP : Conseil de topologie

2013-01-11 Par sujet Greg Villain 
Je mets de l'eau dans ma Bud: on route pas avec - en vrai aucune idée des perfs 
en routage/fib.
On collecte des routes. 
-
Greg

On Jan 11, 2013, at 12:34 AM, Greg Villain fr...@tadcons.net wrote:

 C'est vraiment pas mal BIRD si tu peux faire abstraction de la CLI qui est 
 exaspérante.
 On s'en sert plutôt massivement chez nous sans vraiment aucun souci…
 -
 Greg
 
 On Nov 4, 2012, at 11:19 AM, Raphaël Maunier 
 raphael.maun...@jaguar-network.com wrote:
 
 
 On 4 nov. 2012, at 17:24, Thomas Mangin thomas.man...@exa-networks.co.uk 
 wrote:
 
 Sent from my iPad
 
 On 3 Nov 2012, at 21:39, Raphaël Maunier 
 raphael.maun...@jaguar-network.com wrote:
 
 Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire 
 tourner ton BGP.
 Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, 
 c'est Observium et j'ai même filé qq euros au projet :)
 
 Je vais eviter la discussion sur BIRD .. Je laisse ca aux gens de AMSIX :)
 Des retours sur Observium STP - compare a d autres solutions open source ?
 
 Ça tue tous les autres soft en Opensource pour la simplicité. Cependant, 
 j'ai un doute sur les perds sur un gros réseaux. Chez mon ancien employeur, 
 on avait monté pour voir, et juste une partie de naimix ont ecroulé la 
 machine, car le pooler est en php.
 Il y a sûrement des optims possible, mais on a pas pris le temps de chercher.
 
 Mais pour perso, monitorer les routeurs / serveurs de mes potes, j'ai fais 
 une VM sur un de mes serveurs, et en 3 coup de config en Shell  ça juste 
 marche sans se prendre la tête.
 En tout cas, Nagios, Zabbix and cie, c'est plus pour moi
 
 Thomas
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-07 Par sujet Dominique Rousseau 
Le Sat, Nov 03, 2012 at 11:09:54PM +0100, Raphaël Maunier 
[raphael.maun...@jaguar-network.com] a écrit:
[...]
 Tout simplement, je suis ton opérateur de transit, la session flappe
 sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau
 ça casse.
 
 Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta
 conf c'est ça où ça qui merde à cause du bidule truc chouette.
 
 Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas
 de test d'interop, je ne vais pas début, débrouille toi, ou reviens
 avec un routeur HW.

Donc si j'ai un ASR Cisco ou autre plateforme qui fait du routage
essentiellement software, c'est pas sérieux non plus ?
Et si c'est un Vyatta[1] vendu par Brocade, non plus ?

Ou alors le fait d'avoir acheté un produit sur l'étagère te rend
suffisament sérieux ?


[1] 
http://newsroom.brocade.com/press-releases/brocade-acquires-vyatta-a-pioneer-and-leader-in-s-nasdaq-brcd-0949599

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet  Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-05 Par sujet Xavier Beaudouin 

(...)


Je suis sur qu'en route par défaut sans peering, on aurait pu faire plus :) 
même si je suis pro Juniper, le 3560G, est le cisco qui m'aura le plus 
impressionné pour le rapport prix/qualité/performance.
Le cisco est d'ailleurs à mon avis encore en prod qq part chez Iguane :)

Bref, ipv6 je ne sais pas, mais ipv4, pour moins de 2k tu peux faire up2 4G 
finger un the nez :)


Je confirme j'ai fais le test avec un 3550 EMI, ca tennais très bien les 
8k-10k routes IPv4 sans pb... (bon avec quelques tweaks...).


Le passage d'un peer avec +10k routes en plus m'as fait passé en soft, 
mais je compte revenir en hardware sur les peering bientôt.


/Xavier


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

RE : Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet alain 
From : Jrme NicolleTo : Raphal Maunier; Cc : frnog@frnog.org; Subject : Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologieOn 03/11/2012 20:22, Raphal Maunier wrote:
 Encore une fois, si ton business en dpend, ne bidouille pas, si c'est du POC ou oui tu peux t'amuser.
 Je pars du principe que si a ne scale pas avec un support pro et constructeur, et aussi en perf, je passe mon chemin.

Pour moi a dpend de la confiance relative que tu apportes  des 
constructeurs plutt qu'aux dveloppeurs et intgrateurs de solutions 
logicielles.

Pour ma part, tant donn l'opacit des constructeurs et leur mauvaise 
volont  assurer un niveau de qualit et d'efficacit satisfaisant sur 
leurs gammes logicielles, l'open source est un choix pragmatique.

Je prends pour exemple quelques cas concrets de bugs dont 
l'identification et la rsolution a pris tellement de temps (en local, 
hors contrat de support, mais toujours moins cher que l'assurance 
appele contrat de support) qu'il eut t plus rapide de patcher et/ou 
documenter une implmentation open source que de s'obstiner dans la voie 
du 100% proprio-cher-garanti.

Je comprends parfaitement ton point de vue service provider : tes 
besoins ne permettent pas ces alternatives, que tu ne connais donc pas 
faute d'utilit. Pour certains de tes clients, tu pourrais tre  la 
limite de rentabilit mais tes accords avec les constructeurs, ou ton 
habitude de bosser avec eux fait que le jeu n'en vaut pas la chandelle.

Par contre en aucun cas tu ne peux critiquer la fiabilit de solutions 
open source. Le code est accessible, gnralement assez simple dans les 
morceaux qui nous concernent, pour une comprhension de la logique de la 
solution, et assez documente par des gens qui ont un tat d'esprit plus 
propice aux changes constructifs que les commerciaux de tes constructeurs.

La diffrence que tu sembles ne pas saisir est qu'on est pas l 
uniquement dans une logique de service provider mais aussi dans une 
logique d'intgrateur. Qu'un de tes employeurs ne soit pas staff pour 
se faire chier  intgrer du trs spcifique et prfre composer avec 
des briques sur tagre, c'est une vidence. Mais il y a des gens dont 
le mtier est de faire du sur mesure, et qui travaillent plus 
efficacement, par la faute mme des constructeurs, avec de l'open source 
qu'avec du cisco/juniper/whatever.

Les service provider et les intgrateurs sont complmentaires, c'est une 
vidence ds lors qu'on sort des sentiers battus. Et ta position tendant 
 ignorer cette vidence m'amne  me demander si ta stratgie est de 
t'adapter  ton client ou d'adapter ton client  ta logique. Un peu 
comme SAP dans le monde du progiciel, avec sa longue liste de cadavres 
d'entreprises mortes de la marche force vers le conformisme industriel.

Il y a de la place pour tout le monde, tu ne peux pas dnigrer le 
travail des intgrateurs sans te couper d'un pan entier du march et de 
la comptence.

Pour ma part, je respecte les orfvres de l'open source qui ont cre une 
vaste logithque, trs bien documente, capable aujourd'hui de rpondre 
 quasiment tous les besoins de nos clients, dont l'accs  Internet.

Et quand bien mme tu aurais raison quant  la fiabilit relative de 
certaines solutions eu gard au cot des assurances quasi obligatoire, 
vendues comme contrats de supports, tu peux admettre qu'on peut faire le 
choix de grer le risque d'exploitation inhrent  toute technologie en 
interne, en crant de l'emploi pour a, plutt qu'en se rendant 
volontairement dpendant de son constructeur. C'est un business model 
diffrent, que tu n'est certainement pas en position de critiquer sur ce 
point.

-- 
Jrme Nicolle
06 19 31 27 14


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Dominique Rousseau 
Le Sat, Nov 03, 2012 at 06:10:34PM +0100, Raphaël Maunier 
[raphael.maun...@jaguar-network.com] a écrit:
  La PME en question n'a généralement pas les moyens de se payer un
  routeur dit hardware, donc, c'est pas vraiment le sujet
 
 Ah ? Jcrois que tu fais trop de bidouille depuis des années pour ne
 pas savoir combien coûte un routeur en HW.
 Un sw avec du bgp en route par défaut ( qui suffit à 90%) des mecs, ça
 coûte vraiment pas cher et même si c'est genre 2 fois plus cher que un
 serveur à 1000 euros, comment dire, si une PME sait pas investir 1000
 euros de plus pour avoir un truc supporté, je dis que le pb n'est pas
 la ou on regarde hein :)

A 2kE, t'auras le switch L3, mais pas le contrat de support qui est
censé te permettre de pas avoir à savoir comment ça marche.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet  Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Thomas Mangin 
Sent from my iPad

On 3 Nov 2012, at 21:39, Raphaël Maunier raphael.maun...@jaguar-network.com 
wrote:

 Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire 
 tourner ton BGP.
 Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, 
 c'est Observium et j'ai même filé qq euros au projet :)

Je vais eviter la discussion sur BIRD .. Je laisse ca aux gens de AMSIX :)
Des retours sur Observium STP - compare a d autres solutions open source ?

Thomas


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Sylvain Vallerot 



On 04/11/2012 00:15, Raphaël Maunier wrote:

Première étape, faire découvrir au mec les peer-group et la simplification
de sa conf sur les communautés.
Donc, objectif l'aide, on gagne en cpu, et on peut lire la conf enfin, et
tout rentre dans l'ordre.



C'est sur qu'avec un Xeon Quad t'aurais pas eu le pb de grimper à 400% de
voir tes routes flaper. C'est des problèmes pour les gros opérateurs sérieux
ça, les petits avec des routeurs *nix ils peuvent pas comprendre  ;-)

C'est un peu comme les problèmes de tables de routage trop grosses, on vit
ça plutôt l'esprit tranquille avec des routeurs qui ont une RAM extensible à
16 voire 32G.

Blague a part il y a du bon dans les deux mondes, et il vaudrait mieux voir
comment les faire coopérer que de dire que tel ou tel est le meilleur, et
que si tu fais pas comme moi je te supporterai pas.

My 2 cents.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Raphaël Maunier 
On 4 nov. 2012, at 19:08, Sylvain Vallerot sylv...@gixe.net wrote:

 
 
 On 04/11/2012 00:15, Raphaël Maunier wrote:
 Première étape, faire découvrir au mec les peer-group et la simplification
 de sa conf sur les communautés.
 Donc, objectif l'aide, on gagne en cpu, et on peut lire la conf enfin, et
 tout rentre dans l'ordre.
 
 
 C'est sur qu'avec un Xeon Quad t'aurais pas eu le pb de grimper à 400% de
 voir tes routes flaper. C'est des problèmes pour les gros opérateurs sérieux
 ça, les petits avec des routeurs *nix ils peuvent pas comprendre  ;-)

Bah en l'occurrence, le mec fait 50G au total dont 2,5G en ipv6
 
 C'est un peu comme les problèmes de tables de routage trop grosses, on vit
 ça plutôt l'esprit tranquille avec des routeurs qui ont une RAM extensible à
 16 voire 32G.

Les routeurs HW ne stockent pas tout en ram, ils doivent gérer fib et rib.
Le truc ou je n'arrive toujours pas a comprendre c'est pourquoi ils limitent 
toujours les routeurs en mémoire ... Genre la mémoire coûte chère. Il a fallu 
attendre les dernières RE sur MX pour avoir 16gig de ram par exemple.
 
 Blague a part il y a du bon dans les deux mondes, et il vaudrait mieux voir
 comment les faire coopérer que de dire que tel ou tel est le meilleur, et
 que si tu fais pas comme moi je te supporterai pas.
 

Bah écoute, au prochain V6 labday, on monte 4 routeurs 2 bsd, 2 Linux avec du 
Bird et Quagga et on les bourrine avec Breakingpoint, heu Ixia :)
On va demander à HP et Dell de nous prêter chacun 2 machines identiques avec du 
10G et on teste ?
Juniper prêtera des MX, Brocade des MLX ou CER, et Cisco ... Fera une 
présentation :)

Deal ?

Commencez à préparer vos configs parce ça va être la boucherie !

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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Raphaël Maunier 

On 4 nov. 2012, at 17:24, Thomas Mangin thomas.man...@exa-networks.co.uk 
wrote:

 Sent from my iPad
 
 On 3 Nov 2012, at 21:39, Raphaël Maunier raphael.maun...@jaguar-network.com 
 wrote:
 
 Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire 
 tourner ton BGP.
 Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, 
 c'est Observium et j'ai même filé qq euros au projet :)
 
 Je vais eviter la discussion sur BIRD .. Je laisse ca aux gens de AMSIX :)
 Des retours sur Observium STP - compare a d autres solutions open source ?

Ça tue tous les autres soft en Opensource pour la simplicité. Cependant, j'ai 
un doute sur les perds sur un gros réseaux. Chez mon ancien employeur, on avait 
monté pour voir, et juste une partie de naimix ont ecroulé la machine, car le 
pooler est en php.
Il y a sûrement des optims possible, mais on a pas pris le temps de chercher.

Mais pour perso, monitorer les routeurs / serveurs de mes potes, j'ai fais une 
VM sur un de mes serveurs, et en 3 coup de config en Shell  ça juste marche 
sans se prendre la tête.
En tout cas, Nagios, Zabbix and cie, c'est plus pour moi
 
 Thomas
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Eric ROLLAND 
Le 03/11/12 13:10, Raphaël Jacquot a écrit :
 Bref, va te falloir apprendre la réalité des PME...
Raphael ++1

Le 03/11/12 15:38, Jérôme Nicolle a écrit :

 Tu voudrais dire que les opérateurs ne comprennent pas leurs clients ?
 On savait déjà l'inverse, mais ça explique pas mal de choses d'un cou

Jérome, Ca dépends de la taille C'est le monde des insectes. Yen a
des gros, des petits... tous ont leur place, tous se font bouffer.
Concernant vyatta, je pense que c'est pas une bonne piste. Pour plein de
raisons que je pourrais expliquer en MP.

Le 03/11/12 18:21, Raphaël Maunier a écrit :
 Je n'ai jamais , mais alors la jamais fais des routeurs en soft
Dommage...  Cisco, juniper en propose, ca réponds à une demande.

Le 03/11/12 21:35, Julien Boussu a écrit :
 Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, 
 pas une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à 
 une histoire de license permet bien plus de réactivité et de créativité pour 
 répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, 
 on peut l'être tout en respectant les règles de l'art.

Merci Julien je ne l'aurais pas mieux exprimé.

Le 03/11/12 23:22, Julien Boussu a écrit :
 Quoi qu'il en soit, je ne pense pas que l'argument L'opérateur ne supporte 
 pas est une raison pour penser que la solution UNIX est une bidouille

+1+1+1+1+1+1  ca doit faire mal quand on le vie...


 De plus, maintenant, ce n'est plus trop le cas, car la plupart des isp ont 
 des box, donc le temps ou tu avais ton modem Adsl sur ton Linux en direct 
 c'est ( quasi ) terminé .

Autant que j'en sache, les DSLAM Free (C'est pas du Huawei) sont sous
Debian. Le routage interne (uni et multicast sur du Cisco). Comme quoi
les deux sont compatibles pour peut qu'on se casse les dents dessus. ET
ca réponds à une logique économique.

Le 04/11/12 19:01, Radu-Adrian Feurdean a écrit :
 Par contre il y a une niche ou ca prend tout son sens, generalement
 comme solution temporaire, jusqu'a un certain niveau de
 debit/complexite.
 J'ai deja fait ca, ca a bien marche, j'ai prouve ce que j'ai eu a
 prouver, et 18 mois plus tard j'ai pu meme m'appuyer sur ca pour
 demander des $$$ pour quelque-chose de serieux.
+1 tout pareil...

Le 04/11/12 19:31, Jérôme Nicolle a écrit :
 On 04/11/2012 19:28, Sylvain Vallerot wrote:
 Malheureusement c'est à cause de ça que FR-IX n'a toujours pas pu
 finaliser son interconnexion avec le Touix, ce dernier ayant décidé
 de le faire avec un RS intermédiaire, ce qui n'est pas compatible
 avec la définition même de peering.

 Tu dis n'importe quoi là. On propage un VLAN dédié pour l'interco
 France-IX. Quant à l'interco FR-IX, elle n'est pas en place juste parce
 qu'il n'y a qu'un seul membre du TOUIX, déjà sur FR-IX 75, qui s'y
 intéresse.


Lulu, Cerise,
Vous venez chercher quand le GaillardIx ?. On aura bientot un pauvre
petit lien 100Mbs chez Axione, ou 200Mbs chez Covage (vers le TH2).  ?

My 2 balles,
Cordialement,
Eric ROLLAND
Réseau Artewan AS42929
ORG-ARTE2-RIPE

*Artefact communication interactive* | Bat. Artechnopole - 3 rue des
Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33
SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z |
TVA Intracom FR87444110936

www.artefact.fr http://www.artefact.fr - Communication interactive
www.artewan.fr http://www.artewan.fr - Opérateur de réseaux




*Découvrez Artechnopole http://www.artechnopole.fr, un espace IT de
380 M2, intégrant un Datacenter climatisé, ondulé et secouru. *


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Radu-Adrian Feurdean 
On Sun, Nov 4, 2012, at 21:24, Eric ROLLAND wrote:

 Autant que j'en sache, les DSLAM Free (C'est pas du Huawei) sont sous Debian. 

Que quelqu'un de plus avise me corrige, mais des DSLAM sous Debian c'est
comme les Juniper sous FreeBSD ou les VDX ou les F5/BigIP sous Linux :
il y a un OS qui sert a demarer l'engin, dont un logiciel proprio qui
est le control-plane (*), et le data-plane reste en ASIC (*).
(*): Pour des modeles entree de gamme, une partie du data-plane peut
aussi etre un procesus proprietaire.

Le Linux reste juste un boot-strapper solide, qui permet de demarer la
partie metier, qui elle generalement controle un ASIC qui fait le
boulot.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Guillaume Leclanche 
Le 4 novembre 2012 20:19, Raphaël Maunier 
raphael.maun...@jaguar-network.com a écrit :


 On 4 nov. 2012, at 17:24, Thomas Mangin thomas.man...@exa-networks.co.uk
 wrote:


 Des retours sur Observium STP - compare a d autres solutions open source ?

 Ça tue tous les autres soft en Opensource pour la simplicité. Cependant,
 j'ai un doute sur les perds sur un gros réseaux. Chez mon ancien employeur,
 on avait monté pour voir, et juste une partie de naimix ont ecroulé la
 machine, car le pooler est en php.
 Il y a sûrement des optims possible, mais on a pas pris le temps de
 chercher.


Observium ne fait pas de releases (svn update only), et n'a pas de quality
assurance autre que les devs l'utilisent. C'est à l'utilisateur de
s'assurer que ça marchera sur son infra.

Le poller n'est pas exactement en php, c'est un wrapper PHP autour de la
cli unix de netsnmp.

C'est exactement l'outil du bricoleur. Moi je l'utilise pour ... tester
snmp (il fait du snmp tout le temps sur les devices, ce qui permet d'avoir
du traffic de monitoring qui tourne pendant les autres tests). C'était un
soft lamentable niveau perfs il y a encore qqs mois mais ils ont fait un
gros effort pour implémenter un max de caching et du coup c'est devenu
utilisable.


 Mais pour perso, monitorer les routeurs / serveurs de mes potes, j'ai fais
 une VM sur un de mes serveurs, et en 3 coup de config en Shell  ça juste
 marche sans se prendre la tête.
 En tout cas, Nagios, Zabbix and cie, c'est plus pour moi


les devs d'observium te répèteront que observium ne remplace pas nagios et
n'est pas un outil d'alarming.

Guillaume

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

[TECH] Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Arnaud Launay 
Le Sun, Nov 04, 2012 at 08:15:09PM +0100, Raphaël Maunier a écrit:
 Bah écoute, au prochain V6 labday, on monte 4 routeurs 2 bsd, 2
 Linux avec du Bird et Quagga et on les bourrine avec
 Breakingpoint, heu Ixia :)
 On va demander à HP et Dell de nous prêter chacun 2 machines
 identiques avec du 10G et on teste ?
 Juniper prêtera des MX, Brocade des MLX ou CER, et Cisco ...
 Fera une présentation :)
 Deal ?


Bah, non.

Tu compares de l'incomparable. On a jamais dit qu'un quagga
pourrait tenir 10G de trafic, mais pour des petites pme qui font
du 100M en pointe, c'est plus que largement suffisant.

Donc pour ton test, pas de soucis, faisons le avec 100M de
trafic. Même 300 ou 400, tiens. Ça permettra de voir les limites.

Mais tu compares de l'incomparable. Pour la petite pme sans le
sou mais qui a quand même besoin d'avoir de la disponibilité et
*surtout* de l'indépendance vis à vis de ses fournisseurs, même
sans faire beaucoup de trafic, mais si le trafic a une importance
(hors quantité), quagga/bird/openbgp/machinpwet c'est une très
bonne solution. Ça coûte rien, le matos de spare yen a partout
dans les bureaux, ça tourne sans problème et c'est accessible.

La petite PME qui se retrouve avec 10G à router, elle a
clairement les moyens de débourser 10 ou 15k€ dans des routeurs
d'entrée de gamme, voire de 25-30 pour rentrer dans les gammes
solides de certains constructeurs (je parle bien sûr de deux
routeurs hein).

Si elle a 10G à router et pas les moyens de débourser un peu de
matos, elle a un vrai soucis et j'y mettrai pas un kopec.

Arnaud.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-04 Par sujet Fabien Delmotte 
Bonjour,

Exactement le linux ou bsd ne servent que de bootstrap et parfois donnent des 
petits plus .. Tftp, ssh, tcpdump, etc...

Cordialement

Fabien

Envoyé de mon iPhone

Le 4 nov. 2012 à 23:12, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net a 
écrit :

 On Sun, Nov 4, 2012, at 21:24, Eric ROLLAND wrote:
 
 Autant que j'en sache, les DSLAM Free (C'est pas du Huawei) sont sous Debian.
 
 Que quelqu'un de plus avise me corrige, mais des DSLAM sous Debian c'est
 comme les Juniper sous FreeBSD ou les VDX ou les F5/BigIP sous Linux :
 il y a un OS qui sert a demarer l'engin, dont un logiciel proprio qui
 est le control-plane (*), et le data-plane reste en ASIC (*).
 (*): Pour des modeles entree de gamme, une partie du data-plane peut
 aussi etre un procesus proprietaire.
 
 Le Linux reste juste un boot-strapper solide, qui permet de demarer la
 partie metier, qui elle generalement controle un ASIC qui fait le
 boulot.
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Fabien Delmotte 
Bonjour,

Juste une petite question concernant le choix d'un constructeur. Comment faire 
pour choisir le matos quand les tables de routage en IPv4 sont enormes et que 
l'IPv6 pointe son nez. Il me semble que les cartes supportant cela en hardware 
sont relativement onereuseset que nous ne savons pas si les dites cartes 
tiendront 1,2,3 ans.

Peut être qu'une solution mixte est envisageable pour certaines societes afin 
de ne pas faire exploser les budgets.

Fabien


On 3 nov. 2012, at 10:27, David Ramahefason r...@netfacile.net wrote:

 Bonjour,
 
 J'ai fait tourner un ISP pendant 4 ans sur du Gated (NetBSD puis FBSD)
 puis un autre sur Quagga sans problème lié au soft.
 A l'époque le problème venait plutôt du faible choix des interfaces 
 disponible.
 C'est possible mais j'en suis revenu :) à maintenir/faire évoluer je
 préfère avoir du constructeur mais ça peut être un moyen de démarrer
 une activité si on a pas les sous à mettre de suite dans du gros
 matériel (quoique maintenant faiut voir avec les PC actuels ce que
 l'on peut faire).
 Ensuite pour en revenir à la question principale, je suis de l'avis de
 Raphael: Keep it Simple, Murphy est déjà assez chiant comme ça :D
 
 Bon Week End
 
 Le 3 novembre 2012 08:58, Raphaël Maunier
 raphael.maun...@jaguar-network.com a écrit :
 
 
 On 3 nov. 2012, at 02:42, Manuel Guesdon ml+fr...@oxymium.net wrote:
 
 On Fri, 2 Nov 2012 23:01:42 +0100
 Raphaël Maunier raphael.maun...@jaguar-network.com wrote:
 | On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote:
 | Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point 
 est critique, il y a toujours une solution autre que le Linux supporté par 
 personne
 
 Oh, on doit trouver du support commercial dessus
 
 Oui, on doit ... Tu peux passer un coup de fil à ton opérateur, je ne suis 
 pas certain qu'il te débug ton routeur soft
 
 
 
 | C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre 
 implication.
 
 Hum, au moins tu as le sources (apres faut avoir les compétences).
 
 Combien de mecs qui l'installent savent lire un code source ? X% des gens 
 maîtrisent les fichiers de conf sans comprendre le protocole, Y% des gens 
 seront incapable de débug en cas de soucis car ils n'auront pas la maîtrise 
 des fondamentaux.
 Des fois, c'est le linux/UNIX qui déconne et pas le soft de routage et la... 
 C'est le drame
 
 Les
 solution cisco/machin/truc c'est la même chose sans les sources.
 En gros tu esperes que les gens qui ont pondu le truc soient
 compétents et motivés et tu prie pour que ca fixe effectivement le problème,
 qu'il n'y ait pas d'effet de bord etc.
 
 Oui, mais je préfère encore travailler avec un matos ou y a des équipes 
 dédiées qui bossent sur la résolution des bugs que d'attendre qu'un mec dans 
 sa cave fixe le pb du code qu'il a pondu et qui est super populaire.
 
 
 
 | Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend 
 généralement la 3 eme version du train dans lequel il souhaite aller.
 
 Pareil pour tout. Je ne pense pas qu'il y ait beaucoup d'allumés qui mettent
 en prod direct sans test ni rien une version x.0.0 ni sur des routeurs ni 
 sur
 de serveurs...
 
 Heu  Apt-get update, dist-upgrade ... Je suis sur que la plupart tourne 
 les dernières versions :)
 
 | Chez les constructeurs de routeurs, tu as plusieurs niveau de support et 
 d'escalade qui est fonction de ton type de maintenance, de ton parc 
 installé et de la visibilité que tu apportes sur le marché. Chez Juniper 
 par exemple ( c'est ce que je connais ), tu as ce mode de fonctionnement, 
 et tu es capable d'avoir un mec en ligne en moins de 45 minutes qui te 
 donnera des commandes à taper en CLI Shell qui tape directement l'Asic 
 pour réparer ton bousin si jamais c'est un bug avéré. Ensuite, les dev 
 bossent sur un bugfix.
 | Mais oui, je te l'accorde, ce n'est pas gratuit ...
 
 J'aimerais bien savoir pour 2 'petits' Cicsco/Juniper/Brocade (petits mais
 du genre qui fait ce que demandé par Simon: bgp  co) combien ca coute en
 achat+support annuel pour avoir en moins de 45mn un gars qui te fait réparer
 ton bousin en cli sur le champs :-)
 
 Ça dépend du matos, ça peut aller de qq centaines d'euros pour les tout 
 petits routeurs à qq milliers d'euros pour les gros routeurs backbone.
 
 
 Mais c'est vrai que ca peut servir: si ma mémoire est bonne il y a un an 
 quasi
 pile poil [ld]es Juniper avait connu un petit bug :-)
 
 Il faut compter un bug majeur visible tous les deux ans chez tous les 
 constructeurs :)
 
 Des bugs, ils en ont tous les jours et des trucs bien marrant des fois. Et 
 comme le disait Laurent des fois, la résolution c'est : alors il y a un bug 
 Mpls sur cett version, pour le résoudre ... Désactivez Mpls  Et la on 
 dit Merci monsieur, et on le traite de toute sorte de nom d'oiseaux en 
 lisant la doc et tout le monde pensera que tu as le syndrome de tourette :)
 
 
 
 Manuel
 
 --

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Xavier Beaudouin 
Hello

 Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de
 gérer des routeurs soft (pour quelque raison que ça soit: fiabilité,
 gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de
 $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en
 vaut la chandelle.
 
 Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est 
 critique, il y a toujours une solution autre que le Linux supporté par 
 personne et qui en cas de soucis pourra avoir des conséquences plus 
 désastreuses que les X k€ économisés au début de l'aventure.
 
 Donc, bien souvent le jeu n'en vaut pas la chandelle :)

Heu ça dépend. Evidement savoir entretenir un routeur soft coute plus 
d'argent (=temps) que un juniper, Cisco ou Brocade (quoi que sur le dernier, 
j'ai un doute par rapport a mon expérience personnelle).

 
 Le support de certains logiciels libres (quoique sans avoir aucune
 garantie d'un éditeur/construccteur derrière) n'a rien à envier (parfois
 la situation est même inverse) à certains editeurs/constructeurs.
 
 Lorsque tu vois que tes sessions BGP flappent, que tu poste un message
 sur la liste misc (OpenBSD dans mon cas) et que 45minutes plus tard tu
 as obtenu un patch corrigeant le problème...chapeau.
 
 C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre 
 implication.

Heu... Je sens le troll velu... Pour avoir eu l'expérience a Claudio (autheur 
de openbgpd), ce gars est très réactif et quand tu as un patch qui est un diff 
de bgpd.c... Tu sais que l'implication du patche est... pour bgp.

Alors que jinstall-12.1-R2.4-export.tgz (600Mo), tu es très sûr de ce qui a été 
changé (ou pas) dans ce JunOS. 

Sans compter le support : j'ai découvert ce probleme, support : ah bon ?, 
1h passe : tu peux essayer cette release?...

Vécu sur pas mal de constructeurs (au moins les 3 du début de mail)...

 Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend généralement la 
 3 eme version du train dans lequel il souhaite aller.
 Les rares cas ou un opérateur doit le faire c'est :
 
 - Support de nouvelles cartes : les constructeurs nous pipeautent depuis des 
 années en disant : Bah non, dans votre train actuel, c'est imposiibllle 
 de rajouter le support de votre carte. Généralement, on appuie sur le 
 bullshit button, mais sauf si tu es Verizon ou NTT ou un très gros, tu aura 
 juste l'effet du bouton et donc, t'es bien barré pour un upgrade.
 
 - Support d'un nouveau protocole
 
 - bug vraiment mais vraiment violent qui ne peut pas être fixé avec une 
 release de maintenance.

#define violent ? par ce ... des bugs violent j'en ai eu... mais ils étaient 
violent pour moi (pas pour les autres).

 Des exemples de ce genre j'en ai des cartons entier (baie dell MD1200i
 qui n'a plus aucun volume au reboot. le support dell te dit restore
 from backups)...
 
 justement, c'est la mon propos :) les fournisseurs de HW serveurs ont les 
 pires supports de la planète ! Les mecs ils optimisent rien, et ne savent pas 
 faire de débug

Pour dell (ou hp) même remarque que pour toi. D'ailleurs une des raisons pour 
lesquelles je préfère supermicro (ok y a pas de support mais du spare on site 
c'est toujours 1000 fois plus efficace qu'une GTR qui fait ce qu'elle veux).

 C'est comme tout, il faut s'y mettre, consacrer du temps, faire des
 tests, ...
 
 Sur la prod, tu ne fais pas de tests hein :)

Des fois on n'as pas le temps... Tu sais le commercial qui pousse, ou encore 
nos amis les constructeurs qui changent silencieusement le hardware (par ex... 
la marque qui commence par D...). Donc tu testes, tu valide et puis 3 mois plus 
tard: tiens ? pourquoi j'ai pas le même comportement

Xavier


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Jacquot 

On 2 nov. 2012, at 23:01, Raphaël Maunier raphael.maun...@jaguar-network.com 
wrote:

 On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote:
 
 On Fri, Nov 02, 2012 at 05:36:39PM +0100, Raphaël Maunier wrote:
 
 Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de
 gérer des routeurs soft (pour quelque raison que ça soit: fiabilité,
 gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de
 $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en
 vaut la chandelle.
 
 Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est 
 critique, il y a toujours une solution autre que le Linux supporté par 
 personne et qui en cas de soucis pourra avoir des conséquences plus 
 désastreuses que les X k€ économisés au début de l'aventure.
 
 Donc, bien souvent le jeu n'en vaut pas la chandelle :)
 

La PME en question n'a généralement pas les moyens de se payer un routeur dit 
hardware, donc, c'est pas vraiment le sujet
Quand au linux supporté par personne c'est un non sens. Avoir la possibilité 
de payer un fournisseur de linux commercial pour pouvoir lui brailler dessus 
quand ca fonctionne pas, c'est une problématique de DSI de grosse boite, qui ne 
veux surtout pas savoir comment ça fonctionne.
Quand a la possibilité de faire des procès pour éventuellement récupérer des 
dommages et intérêts, c'est tout autant hors sujet quand on parle de vraie 
PME...
Bref, va te falloir apprendre la réalité des PME...



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Jérôme Nicolle 

Bonjour Fabien,

On 03/11/2012 10:38, Fabien Delmotte wrote:

Juste une petite question concernant le choix d'un constructeur.
Comment faire pour choisir le matos quand les tables de routage en
IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les
cartes supportant cela en hardware sont relativement onereuseset
que nous ne savons pas si les dites cartes tiendront 1,2,3 ans.


Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est 
du ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez 
Juniper. Ces plate-formes (à l'exception de l'ASR) sont 100% soft, donc 
pas de souci avec le nombre de routes tant qu'il y a de la RAM.


Pour en arriver à du routage matériel, tu es sur des besoins qui 
justifient des budgets qui ne justifient plus de se prendre la tête avec 
autant de détail ou de bidouillage : une paire de naimix 80 et c'est 
réglé. Ou bien, moins cher (du niveau d'un ASR) : CER2024 de chez Brocade.



Peut être qu'une solution mixte est envisageable pour certaines
societes afin de ne pas faire exploser les budgets.


Là on va te répondre qu'une société n'a rien à foutre d'une full view. 
Une default + le 21 suffit et est déjà sur-dimensionnée dans la plupart 
des cas.


La full view en RIB sert à fournir du transit ou à faire des stats 
drôles, la full view en FIB sert à optimiser ton routage au poil de 
fourmi près.


Il y a donc deux approches : soit on monte des setups plus modestes 
quand on est pas assez fortunés pour jouer au grozopérateur, soit on 
rajoute des couches de bricolage qui feront hurler Raphaël et quelques 
autres puristes du chan qui ont probablement oublié leurs débuts.


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Jérôme Nicolle 

On 03/11/2012 13:10, Raphaël Jacquot wrote:

Bref, va te falloir apprendre la réalité des PME...


Tu voudrais dire que les opérateurs ne comprennent pas leurs clients ? 
On savait déjà l'inverse, mais ça explique pas mal de choses d'un coup ;)


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Fabien Delmotte 
Bonsoir,

Je n ai pas une grande habitude des PME. Mais d'apres ton explication un 
routeur de la marque  Mikrotik est suffisant (il me semble).

Cordialement

Fabien

On 3 nov. 2012, at 14:47, Jérôme Nicolle jer...@ceriz.fr wrote:

 Bonjour Fabien,
 
 On 03/11/2012 10:38, Fabien Delmotte wrote:
 Juste une petite question concernant le choix d'un constructeur.
 Comment faire pour choisir le matos quand les tables de routage en
 IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les
 cartes supportant cela en hardware sont relativement onereuseset
 que nous ne savons pas si les dites cartes tiendront 1,2,3 ans.
 
 Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est du 
 ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez Juniper. Ces 
 plate-formes (à l'exception de l'ASR) sont 100% soft, donc pas de souci avec 
 le nombre de routes tant qu'il y a de la RAM.
 
 Pour en arriver à du routage matériel, tu es sur des besoins qui justifient 
 des budgets qui ne justifient plus de se prendre la tête avec autant de 
 détail ou de bidouillage : une paire de naimix 80 et c'est réglé. Ou bien, 
 moins cher (du niveau d'un ASR) : CER2024 de chez Brocade.
 
 Peut être qu'une solution mixte est envisageable pour certaines
 societes afin de ne pas faire exploser les budgets.
 
 Là on va te répondre qu'une société n'a rien à foutre d'une full view. Une 
 default + le 21 suffit et est déjà sur-dimensionnée dans la plupart des cas.
 
 La full view en RIB sert à fournir du transit ou à faire des stats drôles, la 
 full view en FIB sert à optimiser ton routage au poil de fourmi près.
 
 Il y a donc deux approches : soit on monte des setups plus modestes quand on 
 est pas assez fortunés pour jouer au grozopérateur, soit on rajoute des 
 couches de bricolage qui feront hurler Raphaël et quelques autres puristes du 
 chan qui ont probablement oublié leurs débuts.
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Jérôme Nicolle 

On 03/11/2012 16:23, Fabien Delmotte wrote:

d'apres ton explication un routeur de la marque  Mikrotik est suffisant


Dans pas mal de cas, oui, mais ils ont leur limites et elles sont 
parfois surprenantes.


A l'heure actuelle, en contexte PME / petit hébergeur, je préfère encore 
du vyatta sur un serveur Dell ou équivalent que du mikrotik si c'est un 
setup que je ne serais pas seul à maintenir.


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 


On 3 nov. 2012, at 13:10, Raphaël Jacquot sxp...@sxpert.org wrote:

 
 On 2 nov. 2012, at 23:01, Raphaël Maunier 
 raphael.maun...@jaguar-network.com wrote:
 
 On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote:
 
 On Fri, Nov 02, 2012 at 05:36:39PM +0100, Raphaël Maunier wrote:
 
 Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de
 gérer des routeurs soft (pour quelque raison que ça soit: fiabilité,
 gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de
 $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en
 vaut la chandelle.
 
 Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est 
 critique, il y a toujours une solution autre que le Linux supporté par 
 personne et qui en cas de soucis pourra avoir des conséquences plus 
 désastreuses que les X k€ économisés au début de l'aventure.
 
 Donc, bien souvent le jeu n'en vaut pas la chandelle :)
 
 
 La PME en question n'a généralement pas les moyens de se payer un routeur dit 
 hardware, donc, c'est pas vraiment le sujet

Ah ? Jcrois que tu fais trop de bidouille depuis des années pour ne pas savoir 
combien coûte un routeur en HW.
Un sw avec du bgp en route par défaut ( qui suffit à 90%) des mecs, ça coûte 
vraiment pas cher et même si c'est genre 2 fois plus cher que un serveur à 1000 
euros, comment dire, si une PME sait pas investir 1000 euros de plus pour avoir 
un truc supporté, je dis que le pb n'est pas la ou on regarde hein :)

 Quand au linux supporté par personne c'est un non sens.

Opérateur, opérateur, ne déforme pas mes propos !


 Avoir la possibilité de payer un fournisseur de linux commercial pour pouvoir 
 lui brailler dessus quand ca fonctionne pas, c'est une problématique de DSI 
 de grosse boite, qui ne veux surtout pas savoir comment ça fonctionne.

Voilà pourquoi tu n'es pas DSO, tu n'as toujours pas compris le vrai rôle d'un 
DSI ..

 Quand a la possibilité de faire des procès pour éventuellement récupérer des 
 dommages et intérêts, c'est tout autant hors sujet quand on parle de vraie 
 PME...

Ça y est on t'a perdu dans les méandres de ton côté révolutionnaire !

 Bref, va te falloir apprendre la réalité des PME...

Heu, je crois que justement il faudrait que tu apprennes le risque à ne pas 
prendre comme dirait le Sbol.

Une PME aura plus de mal à supporter une archi de bidouille qu'une archi 
constructeur !
Ne pas oublier une chose, les opérateurs alternatifs ( genre mon précédent 
employeur et mon actuel ) ont une masse de PME comme client qu'ils soient pure 
player ou une PME ou dans un secteur qui n'est pas full dépendant du net.

Dans la plupart des cas, les mecs viennent vers nous pour justement parce que 
les mecs ont eu un mec qui avait installé le truc sous Linux il y a 2 ou 3 ans 
et il s'est barré.
Donc , nous on arrive et même pas en rêve on reprend l'archi ! 
Par contre, on arrive et y a du HW , on sait reprendre et faire évoluer en 
douceur.
 
 
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 
On 3 nov. 2012, at 14:47, Jérôme Nicolle jer...@ceriz.fr wrote:

 Bonjour Fabien,
 
 On 03/11/2012 10:38, Fabien Delmotte wrote:
 Juste une petite question concernant le choix d'un constructeur.
 Comment faire pour choisir le matos quand les tables de routage en
 IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les
 cartes supportant cela en hardware sont relativement onereuseset
 que nous ne savons pas si les dites cartes tiendront 1,2,3 ans.
 
 Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est du 
 ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez Juniper. Ces 
 plate-formes (à l'exception de l'ASR) sont 100% soft, donc pas de souci avec 
 le nombre de routes tant qu'il y a de la RAM.
 
 Pour en arriver à du routage matériel, tu es sur des besoins qui justifient 
 des budgets qui ne justifient plus de se prendre la tête avec autant de 
 détail ou de bidouillage : une paire de naimix 80 et c'est réglé. Ou bien, 
 moins cher (du niveau d'un ASR) : CER2024 de chez Brocade.
 
 Peut être qu'une solution mixte est envisageable pour certaines
 societes afin de ne pas faire exploser les budgets.
 
 Là on va te répondre qu'une société n'a rien à foutre d'une full view. Une 
 default + le 21 suffit et est déjà sur-dimensionnée dans la plupart des cas.
 
 La full view en RIB sert à fournir du transit ou à faire des stats drôles, la 
 full view en FIB sert à optimiser ton routage au poil de fourmi près.
 
 Il y a donc deux approches : soit on monte des setups plus modestes quand on 
 est pas assez fortunés pour jouer au grozopérateur, soit on rajoute des 
 couches de bricolage qui feront hurler Raphaël et quelques autres puristes du 
 chan qui ont probablement oublié leurs débuts.

Je n'ai jamais , mais alors la jamais fais des routeurs en soft. Je préfère 
orienter les mecs sur du neuf / broke sur des switchs en route par défaut, que 
de faire de la bidouille.

Même les gros ont commencé comme ça. Je me souviens quand Dailymotion est venu 
nous voir quand ils venaient de se lancer ( genre dans le premier mois ), on a 
installé un 3550 en bgp jusqu'à environ 1G puis un 3560G jusqu'à plus de 4G.
Bon on faisait cuire un œuf dessus quand on a atteint 5,2G parce qu'on avait un 
lag 2g sur le panap avec 8k routes dans le bousin.

Je suis sur qu'en route par défaut sans peering, on aurait pu faire plus :) 
même si je suis pro Juniper, le 3560G, est le cisco qui m'aura le plus 
impressionné pour le rapport prix/qualité/performance.
Le cisco est d'ailleurs à mon avis encore en prod qq part chez Iguane :)

Bref, ipv6 je ne sais pas, mais ipv4, pour moins de 2k tu peux faire up2 4G 
finger un the nez :)
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Jérôme Nicolle 

On 03/11/2012 18:21, Raphaël Maunier wrote:

Je n'ai jamais , mais alors la jamais fais des routeurs en soft.


C'est surprenant que tu critiques le principe avec tant de conviction 
dans ce cas.


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 
On 3 nov. 2012, at 20:14, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 03/11/2012 18:21, Raphaël Maunier wrote:
 Je n'ai jamais , mais alors la jamais fais des routeurs en soft.
 
 C'est surprenant que tu critiques le principe avec tant de conviction dans ce 
 cas.

Je ne risque pas des infrastructures sur des trucs bidouillé , c'est tout.

Le trucs pour jouer, c'est à la maison ou dans un lab pour faire mumuse, pas 
sur de la  prod. Dans ma cave, j'ai du pfsense pour m'amuser, mais clairement 
dans un monde pro, je ne prendrais pas ça, ou à la rigueur pour de l'oob et 
encore, des petits SRX ou s'étonne soft ou encore Fortinet, j'ai plus confiance 
, et les même pas 10% de diff à provisionner, je les prends :)
Même pour chez moi, j'hésite d'en prendre un.

Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC 
ou oui tu peux t'amuser.
Je pars du principe que si ça ne scale pas avec un support pro et 
constructeur, et aussi en perf, je passe mon chemin. 
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Jérôme Nicolle 

On 03/11/2012 20:22, Raphaël Maunier wrote:

Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC 
ou oui tu peux t'amuser.
Je pars du principe que si ça ne scale pas avec un support pro et 
constructeur, et aussi en perf, je passe mon chemin.


Pour moi ça dépend de la confiance relative que tu apportes à des 
constructeurs plutôt qu'aux développeurs et intégrateurs de solutions 
logicielles.


Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise 
volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur 
leurs gammes logicielles, l'open source est un choix pragmatique.


Je prends pour exemple quelques cas concrets de bugs dont 
l'identification et la résolution a pris tellement de temps (en local, 
hors contrat de support, mais toujours moins cher que l'assurance 
appelée contrat de support) qu'il eut été plus rapide de patcher et/ou 
documenter une implémentation open source que de s'obstiner dans la voie 
du 100% proprio-cher-garanti.


Je comprends parfaitement ton point de vue service provider : tes 
besoins ne permettent pas ces alternatives, que tu ne connais donc pas 
faute d'utilité. Pour certains de tes clients, tu pourrais être à la 
limite de rentabilité mais tes accords avec les constructeurs, ou ton 
habitude de bosser avec eux fait que le jeu n'en vaut pas la chandelle.


Par contre en aucun cas tu ne peux critiquer la fiabilité de solutions 
open source. Le code est accessible, généralement assez simple dans les 
morceaux qui nous concernent, pour une compréhension de la logique de la 
solution, et assez documentée par des gens qui ont un état d'esprit plus 
propice aux échanges constructifs que les commerciaux de tes constructeurs.


La différence que tu sembles ne pas saisir est qu'on est pas là 
uniquement dans une logique de service provider mais aussi dans une 
logique d'intégrateur. Qu'un de tes employeurs ne soit pas staffé pour 
se faire chier à intégrer du très spécifique et préfère composer avec 
des briques sur étagère, c'est une évidence. Mais il y a des gens dont 
le métier est de faire du sur mesure, et qui travaillent plus 
efficacement, par la faute même des constructeurs, avec de l'open source 
qu'avec du cisco/juniper/whatever.


Les service provider et les intégrateurs sont complémentaires, c'est une 
évidence dès lors qu'on sort des sentiers battus. Et ta position tendant 
à ignorer cette évidence m'amène à me demander si ta stratégie est de 
t'adapter à ton client ou d'adapter ton client à ta logique. Un peu 
comme SAP dans le monde du progiciel, avec sa longue liste de cadavres 
d'entreprises mortes de la marche forcée vers le conformisme industriel.


Il y a de la place pour tout le monde, tu ne peux pas dénigrer le 
travail des intégrateurs sans te couper d'un pan entier du marché et de 
la compétence.


Pour ma part, je respecte les orfèvres de l'open source qui ont crée une 
vaste logithèque, très bien documentée, capable aujourd'hui de répondre 
à quasiment tous les besoins de nos clients, dont l'accès à Internet.


Et quand bien même tu aurais raison quant à la fiabilité relative de 
certaines solutions eu égard au coût des assurances quasi obligatoire, 
vendues comme contrats de supports, tu peux admettre qu'on peut faire le 
choix de gérer le risque d'exploitation inhérent à toute technologie en 
interne, en créant de l'emploi pour ça, plutôt qu'en se rendant 
volontairement dépendant de son constructeur. C'est un business model 
différent, que tu n'est certainement pas en position de critiquer sur ce 
point.


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Julien Boussu 
Désolé de m'immiscer dans votre échange Pro/anti.
Je me permet de donner mon point de vue sur un débat qui aura aussi peu de 
réponse qu'un autre troll mondiale dans le monde des smartphone.

J'ai pendant longtemps déployé des solutions basées sur du BSD (Quagga, PF, 
racoon and co ….) et depuis 3-4 ans je déploie principalement du constructeur 
(Juniper, Cisco principalement).
Je n'ai pas le sentiment d'avoir plus ou moins de support avec l'un ou l'autre. 
Je peux pas dire que les constructeurs soient plus réactifs à mes problèmes 
quotidien que ne l'est la communauté Opensource autour de BSD. Sachant, dans le 
cas de Juniper par exemple, que Junos doit pas mal à Freebsd.
Je crois que la question et donc le choix finale ne se fait pas autour de ça 
mais plutôt autour de la fameuse question : Intégration verticale ou 
horizontale ?
(D'où ma référence au troll mondiale ….)

La première problématique que l'on a rencontré avec les solutions BSD est leur 
industrialisation et la capacité à le faire avec une croissance soutenue ainsi 
que la capacité à avoir une solution homogène et parfaitement intégrée à tous 
les niveaux. Avec ces solutions on récupère des briques à droite, à gauche en 
espérant que chacune respecte les RFC, les standards, appelez ça comme vous le 
voulez.
Et là, malgré que ce soit de l'Opensource, vous pouvez avoir de franche 
surprise et de sacrée crises de nerf.
Ajoutez à cela que chacune des briques n'évoluent pas toutes au même rythme et 
vous pouvez vous retrouver bloquer pendant pas mal de temps sur un problème 
parce que la brique d'à côté n'a pas évolué depuis une éternité.
Donc oui les solutions Opensource fonctionnent très bien mais leur intégration 
avec le reste du monde peut parfois laisser à désirer. Leur industrialisation 
peut s'avérer être aussi un vrai casse tête. Mais ce que j'aime bien dans 
l'idée de ces solutions, c'est la nécessité de recruter des gens avec une tête 
bien faite et pas simplement des gens ayant passé une certification 
constructeur et ne jurant que par ce constructeur parce qu'ils sont incapable 
d'utiliser autre chose.
Ce qui ne veut pas dire que dans les pro constructeurs, on ne trouve pas des 
gens avec des têtes bien faite. Il ne faut pas me faire dire ce que je n'ai 
pas dit.
Mais avec l'Opensource c'est un pré requis indispensable.

Le côté agréable des solutions constructeurs est justement leur intégration et 
leur industrialisation. Soit parce que le constructeur développe une gamme 
complète de solutions sur toutes les couches, soit parce qu'ils ont de bons 
partenariats permettant de faire évoluer toutes les briques au même rythme.
En revanche, je les haie quand ils m'expliquent que je dois de nouveaux 
m'affranchir d'une license pour rajouter la moindre fonctionnalité basique !! 
Et ce phénomène est plus ou moins énorme en fonction du constructeur. Suivez 
mon regard …. 
Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, pas 
une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à une 
histoire de license permet bien plus de réactivité et de créativité pour 
répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, 
on peut l'être tout en respectant les règles de l'art.

Pour le côté bidouille, on peut tout aussi bien en faire avec une solution 
constructeur qu'avec une solution Opensource. On fait de la bidouille quand on 
ne maîtrise pas la techno. Et il suffit de regarder l'implémentation de 
solutions constructeurs dans certaines entreprises pour s'apercevoir que la 
bidouille est fortement présente ….. PME et entreprises du CAC 40 confondues ….

Bref, ça ne fait qu'un éternel débat supplémentaire.

Le 3 nov. 2012 à 20:42, Jérôme Nicolle jer...@ceriz.fr a écrit :

 On 03/11/2012 20:22, Raphaël Maunier wrote:
 Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du 
 POC ou oui tu peux t'amuser.
 Je pars du principe que si ça ne scale pas avec un support pro et 
 constructeur, et aussi en perf, je passe mon chemin.
 
 Pour moi ça dépend de la confiance relative que tu apportes à des 
 constructeurs plutôt qu'aux développeurs et intégrateurs de solutions 
 logicielles.
 
 Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise 
 volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur leurs 
 gammes logicielles, l'open source est un choix pragmatique.
 
 Je prends pour exemple quelques cas concrets de bugs dont l'identification et 
 la résolution a pris tellement de temps (en local, hors contrat de support, 
 mais toujours moins cher que l'assurance appelée contrat de support) qu'il 
 eut été plus rapide de patcher et/ou documenter une implémentation open 
 source que de s'obstiner dans la voie du 100% proprio-cher-garanti.
 
 Je comprends parfaitement ton point de vue service provider : tes besoins 
 ne permettent pas ces alternatives, que tu ne connais donc pas faute 
 d'utilité. Pour certains de tes clients, tu pourrais être à la

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Radu-Adrian Feurdean 
On Sat, Nov 3, 2012, at 8:58, Raphaël Maunier wrote:
 
 Combien de mecs qui l'installent savent lire un code source ? X% des gens
 maîtrisent les fichiers de conf sans comprendre le protocole, Y% des gens
 seront incapable de débug en cas de soucis car ils n'auront pas la
 maîtrise des fondamentaux.
 Des fois, c'est le linux/UNIX qui déconne et pas le soft de routage et
 la... C'est le drame

Tu n'a pas du travailler dans des boites de linuxiens. Je ne parle pas
de boites qui utilisent Linux comme n'importe quelle autre produit. Je
parle de boites ou c'est l'alpha et l'omega, Linux or die. Oui, ca
existe, et je crois qu'on a des representants sur la liste.
Je parle la de boites ou les gens qui ne savent pas lire un code source
n'ont pas leur place. C'est un mode de fonctionnement totalement
different de ce que tu dois pratiquer habituellement, mais ca existe bel
et bien.

 Oui, mais je préfère encore travailler avec un matos ou y a des équipes
 dédiées qui bossent sur la résolution des bugs que d'attendre qu'un mec
 dans sa cave fixe le pb du code qu'il a pondu et qui est super populaire.

Tu n'as jamais du attendre 2 ans pour la correction d'un bug que tu as
du trouver apres seulement une mois de la mise en prod ?
Ou attendre 3 mois juste pour confirmer qu'il y a bien un bug, et non
pas un probleme de config de tton cote ?
Ah, non; tu devais acheter chez ton constructeur des metres cubes a la
fois, de quoi le garder en alerte permanente.
Mauvaise nouvelle, quand tu achetes juste une ou 2 paires de boitiers,
les choses changement violamment. C'est la que beaucoup de gens se
posent plusieurs fois la question d'utiliser une boite noire avec
support constructeur ou avoir une bricole a base d'open source. Et
dans certains cas, la bricole open-source gagne haut-la main, pas
seulement dans les boites des barbus (mentionnes plus haut).

 Ça dépend du matos, ça peut aller de qq centaines d'euros pour les tout
 petits routeurs à qq milliers d'euros pour les gros routeurs backbone.

Pour avoir le mec qui sait comment ca marche dans les 45 minutes ?
Pour les gros matos achetes en quantite probablement, mais pour les
petits boitiers achetes a moins de 10, il faut generalement se batailler
avec plusieurs niveaux de support juste pour confirmer qu'il y a bien un
probleme. Et non, le coup de j'ai le telephone de Laurent G. (ou
l'equivalent chez ton constructeur favori - s'il y en a un) ca ne marche
pas a tous les coups et pour tout le monde.

 un bug Mpls sur cett version, pour le résoudre ... Désactivez Mpls 

... et voila comment finir avec des solutions a base d'open source


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Radu-Adrian Feurdean 
On Sat, Nov 3, 2012, at 18:10, Raphaël Maunier wrote:

 Dans la plupart des cas, les mecs viennent vers nous pour justement parce
 que les mecs ont eu un mec qui avait installé le truc sous Linux il y a 2 ou 
 3 ans et il s'est barré.

Oui, mais il y a 2 ou 3 ans, c'etait la solution qui leur avait permis
d'avancer..
Et oui, si le mec aurait reste, ca aurait ete son boulot de passer sur
quelque-chose de plus serieux (et eventuellement ne pas arriver chez
vous).
Been there, done that.

 Donc , nous on arrive et même pas en rêve on reprend l'archi ! 

T'inquiete, baisser son pantalon devant le client, il y en a qui le
font, et il y aura toujours.
Il y a (malhereusement) de la place pour tout le monde dans
l'ecosysteme


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Radu-Adrian Feurdean 
On Sat, Nov 3, 2012, at 20:22, Raphaël Maunier wrote:

 Je ne risque pas des infrastructures sur des trucs bidouillé , c'est
 tout.

Ce que tu appelles bidouille, il y a d'autres qui appellent du
solide. 
OK, sur du 100% routage ca se discute, mais des qu'il y a d'autres
fonctionalites (notamment LB ou firewall), ca tourne vite a la guerre
ideologique.

N'oublie pas non plus que le 3650G que tu mets sur une plate-forme de
prod en DC, selon le constructeur c'est un desktop switch - access
(l'espece qu'on met dans un reseau bureautique). La c'est toi qui passe
dans le domaine de la bidouille, pour ne pas avoir suivi la bible. Pas
oublier que sur certains produits (3560/3750) la double alimentation
etait une salle bidouille seulement a moitie fonctionelle jusqu'a il y a
pas si longtemps que ca (l'arivee des 3560X/3750X, il y a meme pas 2
ans). Alors que la double alim c'etait donne pour un serveur, a meme pas
1000 EUR. Les choses sont un peu differentes aujourd'hui (mais le 3560X
reste un desktop switch selon Cisco), mais ca n'a pas toujours ete le
cas, et les anciens reflexes se manifestent encore.

Essaye d'asismiler le fait que le monde n'est pas (malhereusement) pas
tout noir ou tout blanc. Il y a plein de nuances de gris au milieu qui
nous font pourrir la vie parfois.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 
On 3 nov. 2012, at 20:42, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 03/11/2012 20:22, Raphaël Maunier wrote:
 Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du 
 POC ou oui tu peux t'amuser.
 Je pars du principe que si ça ne scale pas avec un support pro et 
 constructeur, et aussi en perf, je passe mon chemin.
 
 Pour moi ça dépend de la confiance relative que tu apportes à des 
 constructeurs plutôt qu'aux développeurs et intégrateurs de solutions 
 logicielles.
 
 Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise 
 volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur leurs 
 gammes logicielles, l'open source est un choix pragmatique.
 
 Je prends pour exemple quelques cas concrets de bugs dont l'identification et 
 la résolution a pris tellement de temps (en local, hors contrat de support, 
 mais toujours moins cher que l'assurance appelée contrat de support) qu'il 
 eut été plus rapide de patcher et/ou documenter une implémentation open 
 source que de s'obstiner dans la voie du 100% proprio-cher-garanti.
 
 Je comprends parfaitement ton point de vue service provider : tes besoins 
 ne permettent pas ces alternatives, que tu ne connais donc pas faute 
 d'utilité. Pour certains de tes clients, tu pourrais être à la limite de 
 rentabilité mais tes accords avec les constructeurs, ou ton habitude de 
 bosser avec eux fait que le jeu n'en vaut pas la chandelle.
 
 Par contre en aucun cas tu ne peux critiquer la fiabilité de solutions open 
 source.

Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire tourner 
ton BGP.
Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, 
c'est Observium et j'ai même filé qq euros au projet :)

 Le code est accessible, généralement assez simple dans les morceaux qui nous 
 concernent, pour une compréhension de la logique de la solution, et assez 
 documentée par des gens qui ont un état d'esprit plus propice aux échanges 
 constructifs que les commerciaux de tes constructeurs.
 
 La différence que tu sembles ne pas saisir est qu'on est pas là uniquement 
 dans une logique de service provider mais aussi dans une logique 
 d'intégrateur.

Si si je comprends parfaitement. Je conçois que des gens puissent utiliser de 
l'opensource pour faire tourner leurs serveurs web ou autre serveurs ...

 Qu'un de tes employeurs ne soit pas staffé pour se faire chier à intégrer du 
 très spécifique et préfère composer avec des briques sur étagère, c'est une 
 évidence.

Heu ? Tu es au courant de ce que je faisais avant hein ? Si y a bien qq qui 
faisais la stratégie d'ingénierie avant, c'était moi hein :)
Le choix a été fait de faire en sorte de se concentrer sur notre métier 
d'opérateur, et non pas d'integrateur de solutions sur notre propre backbone.
Vu qu'on est passé de 0 meg à plus de 400G en moins de 4 ans, avec une des 
meilleures progression dans le classement Renesys, je crois que j'ai plutôt 
fais le bon choix.


 Mais il y a des gens dont le métier est de faire du sur mesure, et qui 
 travaillent plus efficacement, par la faute même des constructeurs, avec de 
 l'open source qu'avec du cisco/juniper/whatever.
 
Encore une fois, tu as un gros pépins, avec des routeurs Opensource, tu es en 
galère. Avec une solution HW, tu trouveras très facilement qqn.

À l'inverse, tu as un MSSQL, tu trouveras plein d'experts cliclodrome mais 
incompétents au possible. Et par contre sur du Mysql, des mecs qui maîtrisent 
et qui franchement sont des vrais tueurs, tu en trouveras à la pele.

Dans ce cas la, y a pas photo l'opensource dépasse de très loin les solutions 
M$ et même OSX


 Les service provider et les intégrateurs sont complémentaires, c'est une 
 évidence dès lors qu'on sort des sentiers battus. Et ta position tendant à 
 ignorer cette évidence m'amène à me demander si ta stratégie est de t'adapter 
 à ton client ou d'adapter ton client à ta logique.

Faux ! Mes clients ou futurs clients viennent me/nous voir pour les aider à 
améliorer, optimiser leurs infrastructures.


 Un peu comme SAP dans le monde du progiciel, avec sa longue liste de cadavres 
 d'entreprises mortes de la marche forcée vers le conformisme industriel.

Encore une fois, dans les logiciels pour de l'IT, l'opensource ou le dev 
interne pour ton IT est souvent la meilleure solution.
Bon ensuite, tu es une grosse boite, tu es super fan d'opensource, et tu fais 
tout avec. Tu décide un jour de prendre un expert comptable pour mettre ta 
compta au carré. Montres lui ton soft Opensource pour la compta ... On a bien 
rire. Ne me dit pas, ouais, mauvais expert comptable, changer expert comptable 
... La ça passera juste pas hein :)
 
 Il y a de la place pour tout le monde, tu ne peux pas dénigrer le travail des 
 intégrateurs sans te couper d'un pan entier du marché et de la compétence.

Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , 
ça reste de la bidouille. Les opérateurs ne

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 
Relis ce que j'ai dis ... J'ai dis que quitte à faire un truc cheap, je préfère 
faire avec un truc supporté.
Bgp est supporté par Cisco, et du temps ou cisco me parlait encore ( avant 
qu'ils perdent l'AO en 2008), ils ont répondu aux questions BGP que j'avais sur 
le 3560.

Et pour l'opensource, j'ai répondu dans un autre mail :)

-- 
Raphaël Maunier

Mob : +33 6.86.86.81.76
skype : rmaunier

Sent from my iPad

On 3 nov. 2012, at 22:21, Radu-Adrian Feurdean 
fr...@radu-adrian.feurdean.net wrote:

 On Sat, Nov 3, 2012, at 20:22, Raphaël Maunier wrote:
 
 Je ne risque pas des infrastructures sur des trucs bidouillé , c'est
 tout.
 
 Ce que tu appelles bidouille, il y a d'autres qui appellent du
 solide. 
 OK, sur du 100% routage ca se discute, mais des qu'il y a d'autres
 fonctionalites (notamment LB ou firewall), ca tourne vite a la guerre
 ideologique.
 
 N'oublie pas non plus que le 3650G que tu mets sur une plate-forme de
 prod en DC, selon le constructeur c'est un desktop switch - access
 (l'espece qu'on met dans un reseau bureautique). La c'est toi qui passe
 dans le domaine de la bidouille, pour ne pas avoir suivi la bible. Pas
 oublier que sur certains produits (3560/3750) la double alimentation
 etait une salle bidouille seulement a moitie fonctionelle jusqu'a il y a
 pas si longtemps que ca (l'arivee des 3560X/3750X, il y a meme pas 2
 ans). Alors que la double alim c'etait donne pour un serveur, a meme pas
 1000 EUR. Les choses sont un peu differentes aujourd'hui (mais le 3560X
 reste un desktop switch selon Cisco), mais ca n'a pas toujours ete le
 cas, et les anciens reflexes se manifestent encore.
 
 Essaye d'asismiler le fait que le monde n'est pas (malhereusement) pas
 tout noir ou tout blanc. Il y a plein de nuances de gris au milieu qui
 nous font pourrir la vie parfois.
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Julien Boussu 

Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a 
écrit :

 Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux 
 , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en 
 cas de soucis ! CQFD 


Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce 
dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que 
je le fasse fabriquer à la chaine.
Est ce que cela reste de la bidouille ?

Je prends pas position hein, je cherche juste à comprendre l'histoire de la 
bidouille.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 

On 3 nov. 2012, at 21:35, Julien Boussu d...@xgs-france.com wrote:

 Désolé de m'immiscer dans votre échange Pro/anti.

Avec plaisir, pour une fois ça ne troll pas beaucoup, il y a eu des tentatives, 
mais bon ,c'est Frnog hein :)

 Je me permet de donner mon point de vue sur un débat qui aura aussi peu de 
 réponse qu'un autre troll mondiale dans le monde des smartphone.
 
 J'ai pendant longtemps déployé des solutions basées sur du BSD (Quagga, PF, 
 racoon and co ….) et depuis 3-4 ans je déploie principalement du constructeur 
 (Juniper, Cisco principalement).
 Je n'ai pas le sentiment d'avoir plus ou moins de support avec l'un ou 
 l'autre. Je peux pas dire que les constructeurs soient plus réactifs à mes 
 problèmes quotidien que ne l'est la communauté Opensource autour de BSD. 
 Sachant, dans le cas de Juniper par exemple, que Junos doit pas mal à Freebsd.
 Je crois que la question et donc le choix finale ne se fait pas autour de ça 
 mais plutôt autour de la fameuse question : Intégration verticale ou 
 horizontale ?
 (D'où ma référence au troll mondiale ….)
 
 La première problématique que l'on a rencontré avec les solutions BSD est 
 leur industrialisation et la capacité à le faire avec une croissance soutenue 
 ainsi que la capacité à avoir une solution homogène et parfaitement intégrée 
 à tous les niveaux. Avec ces solutions on récupère des briques à droite, à 
 gauche en espérant que chacune respecte les RFC, les standards, appelez ça 
 comme vous le voulez.
 Et là, malgré que ce soit de l'Opensource, vous pouvez avoir de franche 
 surprise et de sacrée crises de nerf.
 Ajoutez à cela que chacune des briques n'évoluent pas toutes au même rythme 
 et vous pouvez vous retrouver bloquer pendant pas mal de temps sur un 
 problème parce que la brique d'à côté n'a pas évolué depuis une éternité.
 Donc oui les solutions Opensource fonctionnent très bien mais leur 
 intégration avec le reste du monde peut parfois laisser à désirer. Leur 
 industrialisation peut s'avérer être aussi un vrai casse tête. Mais ce que 
 j'aime bien dans l'idée de ces solutions, c'est la nécessité de recruter des 
 gens avec une tête bien faite et pas simplement des gens ayant passé une 
 certification constructeur et ne jurant que par ce constructeur parce qu'ils 
 sont incapable d'utiliser autre chose.

C'est pour cela que les certifications haut niveau que ce soit chez Juniper ou 
Cisco sont un peu plus sélectives que les certifs pourries de M$
Je parle bien sur des certifs un peu haut niveau, pas la junos de base ou le 
ccna/ccnp qui n'ont mais pas une once de valeur lorsque je recrute qqn !

 Ce qui ne veut pas dire que dans les pro constructeurs, on ne trouve pas des 
 gens avec des têtes bien faite.

Oui, les certifs d'experts dénotent des mecs qui maîtrisent la partie protocole 
et partie soft/HW du constructeur.

 Il ne faut pas me faire dire ce que je n'ai pas dit.
 Mais avec l'Opensource c'est un pré requis indispensable.
 
 Le côté agréable des solutions constructeurs est justement leur intégration 
 et leur industrialisation. Soit parce que le constructeur développe une gamme 
 complète de solutions sur toutes les couches, soit parce qu'ils ont de bons 
 partenariats permettant de faire évoluer toutes les briques au même rythme.
 En revanche, je les haie quand ils m'expliquent que je dois de nouveaux 
 m'affranchir d'une license pour rajouter la moindre fonctionnalité basique !! 
 Et ce phénomène est plus ou moins énorme en fonction du constructeur. Suivez 
 mon regard …. 

Oui, j'aime bien Juniper, mais bon sur certains équipements, pour avoir de 
l'ipv6, il faut payer car des gens super bien pensant ( sûrement du marketing 
hein ) ont décidé de mettre l'ipv6 dans les licences de routage avancées... Ça 
fait juste 4 ans que je me bats avec eux.

Dernier truc à la mode, tu veux avoir des stats ipv6, il faut une licence ipfix 
sur les MX, et  C'est payant et pas genre 100 euros, mais plusieurs 
milliers de k€.
Si l'ipv6 n'a pas encore bien avancé, c'est aussi en grande partie à cause des 
constructeurs.


 Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, 
 pas une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à 
 une histoire de license permet bien plus de réactivité et de créativité pour 
 répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, 
 on peut l'être tout en respectant les règles de l'art.
 
 Pour le côté bidouille, on peut tout aussi bien en faire avec une solution 
 constructeur qu'avec une solution Opensource. On fait de la bidouille quand 
 on ne maîtrise pas la techno. Et il suffit de regarder l'implémentation de 
 solutions constructeurs dans certaines entreprises pour s'apercevoir que la 
 bidouille est fortement présente ….. PME et entreprises du CAC 40 confondues 
 ….
 
 Bref, ça ne fait qu'un éternel débat supplémentaire.
 
 Le 3 nov. 2012 à 20:42, Jérôme Nicolle jer...@ceriz.fr a écrit :
 
 On 03/11/2012 20:22, Raphaël

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 
Tout simplement, je suis ton opérateur de transit, la session flappe sans 
cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse.

Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf 
c'est ça où ça qui merde à cause du bidule truc chouette.

Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test 
d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW.

Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que les 
mecs du niveau 1, n'ont pas encore  le même niveau que les experts. Et, il ne 
faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas consommer du 
temps sur l'ingénierie pour faire valider le bug ou trouver la conf qui va bien 
pour l'interop...


Voilà :)

-- 
Raphaël Maunier

Mob : +33 6.86.86.81.76
skype : rmaunier

Sent from my iPad

On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote:

 
 Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com 
 a écrit :
 
 Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des 
 bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs 
 clients en cas de soucis ! CQFD 
 
 
 Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce 
 dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que 
 je le fasse fabriquer à la chaine.
 Est ce que cela reste de la bidouille ?
 
 Je prends pas position hein, je cherche juste à comprendre l'histoire de la 
 bidouille.
 
 
 Julien.
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Julien Boussu 
Mais sauf erreur de ma part, il n'est pas acquis que le problème vienne du 
routeur du client. Le problème peut certainement venir de chez toi.
Soit parce que ton routeur BGP a un vrai problème soit parce qu'il est possible 
qu'il ne respecte pas certains standards  !

Mais si le problème vient de chez ton client, dans les deux cas (Solution Unix 
ou constructeur), il a un problème de compétence ou de feignantise (C'est 
souvent le cas).

Rassure moi d'une chose, si ton client avec sa solution UNIX arrive avec une 
analyse bien couillue et qu'il démontre que le flat n'est pas de son fait, tu 
prends quand même en compte sa remarque et fais un minimum d'analyse chez toi 
ou tu attends qu'un client avec une solution constructeur vienne à son tour te 
le signaler ?

Quoi qu'il en soit, je ne pense pas que l'argument L'opérateur ne supporte 
pas est une raison pour penser que la solution UNIX est une bidouille.

Combien de client avec une belle solution contructeur valant plus milliers de 
K€ m'ont appelé pour signaler un dysfonctionnement alors qu'ils sont tout 
simplement pas foutu de maîtriser leur solution !
Où est la bidouille dans ce cas ….

Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-)

Julien.



Le 3 nov. 2012 à 23:09, Raphaël Maunier raphael.maun...@jaguar-network.com a 
écrit :

 Tout simplement, je suis ton opérateur de transit, la session flappe sans 
 cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse.
 
 Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf 
 c'est ça où ça qui merde à cause du bidule truc chouette.
 
 Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test 
 d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur 
 HW.
 
 Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que 
 les mecs du niveau 1, n'ont pas encore  le même niveau que les experts. Et, 
 il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas 
 consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la 
 conf qui va bien pour l'interop...
 
 
 Voilà :)
 
 -- 
 Raphaël Maunier
 
 Mob : +33 6.86.86.81.76
 skype : rmaunier
 
 Sent from my iPad
 
 On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote:
 
 
 Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com 
 a écrit :
 
 Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des 
 bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS 
 leurs clients en cas de soucis ! CQFD 
 
 
 Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que 
 ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et 
 que je le fasse fabriquer à la chaine.
 Est ce que cela reste de la bidouille ?
 
 Je prends pas position hein, je cherche juste à comprendre l'histoire de la 
 bidouille.
 
 
 Julien.
 ---
 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] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier - Franceix 
On 3 nov. 2012, at 23:22, Julien Boussu d...@xgs-france.com wrote:

 Mais sauf erreur de ma part, il n'est pas acquis que le problème vienne du 
 routeur du client. Le problème peut certainement venir de chez toi.
 Soit parce que ton routeur BGP a un vrai problème soit parce qu'il est 
 possible qu'il ne respecte pas certains standards  !

Oui, et c'est déjà arrivé, et très récemment :)

 
 Mais si le problème vient de chez ton client, dans les deux cas (Solution 
 Unix ou constructeur), il a un problème de compétence ou de feignantise 
 (C'est souvent le cas).
 
 Rassure moi d'une chose, si ton client avec sa solution UNIX arrive avec une 
 analyse bien couillue et qu'il démontre que le flat n'est pas de son fait, 
 tu prends quand même en compte sa remarque et fais un minimum d'analyse chez 
 toi ou tu attends qu'un client avec une solution constructeur vienne à son 
 tour te le signaler ?

Oui, c'est arrivé, parce que le mec il avait toutes les traces et que  Il 
maîtrisait la partie Juniper !
Et le soucis était ... Sur le lien de transport. 

Et quand tu reçois un mail sur ce genre d'incident c'est plutôt : marche pas, 
j'ai un corei7 avec 256G de Ram et la dernière beta de Bird, donc, c'est pas 
moi, c'est votre routeur !
Donc bon, tu comprendras qu'on ne prenne pas vraiment au sérieux ce genre de 
mails.

Sur 1 cas sur 100 tu as un mec qui en face est vraiment extrêmement compétent, 
et son mail est structuré, y a toutes les traces, les infos et un truc du genre 
: après avoir tout testé, je suspecte un soucis de communication bla bla bla, 
pourrions-nous faire un call pour en parler.
La les mecs de l'ingénierie, ne se posent pas de questions et contactent le mec 
directement.

 
 Quoi qu'il en soit, je ne pense pas que l'argument L'opérateur ne supporte 
 pas est une raison pour penser que la solution UNIX est une bidouille.

En routeur BGP, pour moi, c'est de la bidouille en tout cas.

 
 Combien de client avec une belle solution contructeur valant plus milliers de 
 K€ m'ont appelé pour signaler un dysfonctionnement alors qu'ils sont tout 
 simplement pas foutu de maîtriser leur solution !

Voilà pourquoi nous avons un job, et mon avis sur la question est que nos 
clients doivent se concentrer sur leur cœur de métier . Le routage, pour un 
pure player qui doit maîtriser son appli, c'est pas son métier, qu'il nous 
laisse le faire ( opérateur ou intégrateur ) .

 Où est la bidouille dans ce cas ….

Oui, mais en 2 TPS 3 mouvements, bam, ça tombe en marche et tu peux maintenir.
Une solution UNIX, imo, ça va prendre plus de temps et souvent devoir tout 
refaire.
 
 Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-)
MX FTW 
 
 Julien.

Raphaël 
 
 
 
 Le 3 nov. 2012 à 23:09, Raphaël Maunier raphael.maun...@jaguar-network.com 
 a écrit :
 
 Tout simplement, je suis ton opérateur de transit, la session flappe sans 
 cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse.
 
 Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf 
 c'est ça où ça qui merde à cause du bidule truc chouette.
 
 Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test 
 d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur 
 HW.
 
 Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que 
 les mecs du niveau 1, n'ont pas encore  le même niveau que les experts. Et, 
 il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas 
 consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la 
 conf qui va bien pour l'interop...
 
 
 Voilà :)
 
 -- 
 Raphaël Maunier
 
 Mob : +33 6.86.86.81.76
 skype : rmaunier
 
 Sent from my iPad
 
 On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote:
 
 
 Le 3 nov. 2012 à 22:39, Raphaël Maunier 
 raphael.maun...@jaguar-network.com a écrit :
 
 Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des 
 bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS 
 leurs clients en cas de soucis ! CQFD 
 
 
 Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que 
 ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique 
 et que je le fasse fabriquer à la chaine.
 Est ce que cela reste de la bidouille ?
 
 Je prends pas position hein, je cherche juste à comprendre l'histoire de la 
 bidouille.
 
 
 Julien.
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-03 Par sujet Raphaël Maunier 

On 3 nov. 2012, at 23:51, Julien Boussu julien.bou...@xgs-france.com wrote:

 
 Et quand tu reçois un mail sur ce genre d'incident c'est plutôt : marche 
 pas, j'ai un corei7 avec 256G de Ram et la dernière beta de Bird, donc, 
 c'est pas moi, c'est votre routeur !
 Donc bon, tu comprendras qu'on ne prenne pas vraiment au sérieux ce genre de 
 mails.
 
 Et si tu reçois un mail te disant j'ai un MX 5 avec la dernière release 
 recommandée par Juniper donc le problème est chez vous ? 

On vérifie le niveau optique et on lui demande s'il a pas un optique chinois 
tombé du camion dans son Mx5.
Car du bgp, entre MX/7600/ASR, ça frappe pas comme ça pour rien

 Tu le prends au sérieux ?

Ou

 
 Sur 1 cas sur 100 tu as un mec qui en face est vraiment extrêmement 
 compétent, et son mail est structuré, y a toutes les traces, les infos et un 
 truc du genre : après avoir tout testé, je suspecte un soucis de 
 communication bla bla bla, pourrions-nous faire un call pour en parler.
 La les mecs de l'ingénierie, ne se posent pas de questions et contactent le 
 mec directement.
 
 Je suis rassuré :-)
 
 En routeur BGP, pour moi, c'est de la bidouille en tout cas.
 
 Soit.
 
 Oui, mais en 2 TPS 3 mouvements, bam, ça tombe en marche et tu peux 
 maintenir.
 Une solution UNIX, imo, ça va prendre plus de temps et souvent devoir tout 
 refaire.
 
 De ton point de vue.
 Imagine le mec qui se retrouve à devoir traiter une conf bien tordu à base de 
 Cisco, qu'il ne pratique pas au quotidien, dont la logique peut parfois être 
 une insulte à l'être Humain avec une cli qui laisse perplexe. 
 Es tu toujours aussi convaincu de ton 2 TPS 3 mouvements ?

J'ai eu le cas récemment. Cisco 7600, une conf avec 40 000 route-map et 
communautés , routeur chargé à bloc.

Première étape, faire découvrir au mec les peer-group et la simplification de 
sa conf sur les communautés.
Donc, objectif l'aide, on gagne en cpu, et on peut lire la conf enfin, et tout 
rentre dans l'ordre.

2 semaines après, il rajoute plein de truc, et bam re-100% de cpu. Après débug 
et conseil, on trouve ( pas moi cette fois ci) , que une acl ipv6 puntait tout 
vers le cpu, on modifie l'acl, tout rentre dans l'ordre.

Pourquoi on a pris du temps à trouver ( plus d'une semaine sur l'acl ipv6 ) ? 
Parce que il n'avait pas son HW sous maintenance et qu'on a du faire tourner la 
conf pour trouver.
J'en parle ensuite à un mec qui parle cisco comme première langue , en 30 sec 
il me dit : le mec aurait pas rajouteé une acl ipv6 par hasard ?


 
 J'en reviens à l'intégration. Je partage tout à fait ton point de vue sur le 
 fait qu'en tant qu'opérateur tu ne puisses pas gérer tous les cas 
 d'architecture et conseil ton client de s'orienter vers des solutions que tu 
 pourras gérer. Ca me paraît sain.
 Tu sais que ça fonctionnera et tu pourras lui garantir son SLA.
 
 Maintenant, si j'ai en face de moi un mec qui maîtrise de A à Z sa solution 
 que je ne lui ai pas conseillé après tout ça le regarde.

Bien sur que oui :)  mais s'il a une merde, je ne pourrais pas l'aider, that's 
IT

 Le nerf de la guerre étant la compétence de celui qui la gère
et l'argent

 et c'est là où se trouve le point de départ de la bidouille.
 
 Julien.
 
 
 
 
 
 
 Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-)
 MX FTW 
 
 Julien.
 
 Raphaël 
 
 
 
 Le 3 nov. 2012 à 23:09, Raphaël Maunier 
 raphael.maun...@jaguar-network.com a écrit :
 
 Tout simplement, je suis ton opérateur de transit, la session flappe sans 
 cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse.
 
 Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta 
 conf c'est ça où ça qui merde à cause du bidule truc chouette.
 
 Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de 
 test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un 
 routeur HW.
 
 Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier 
 que les mecs du niveau 1, n'ont pas encore  le même niveau que les 
 experts. Et, il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne 
 vont pas consommer du temps sur l'ingénierie pour faire valider le bug ou 
 trouver la conf qui va bien pour l'interop...
 
 
 Voilà :)
 
 -- 
 Raphaël Maunier
 
 Mob : +33 6.86.86.81.76
 skype : rmaunier
 
 Sent from my iPad
 
 On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote:
 
 
 Le 3 nov. 2012 à 22:39, Raphaël Maunier 
 raphael.maun...@jaguar-network.com a écrit :
 
 Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des 
 bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS 
 leurs clients en cas de soucis ! CQFD 
 
 
 Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde 
 que ce dont ma solution BGP a besoin, que je le compile pour un hw 
 spécifique et que je le fasse fabriquer à la chaine.
 Est ce que cela reste de la bidouille ?
 
 Je prends pas position hein, je cherche juste à comprendre

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-02 Par sujet Gregory Colpart 
Salut,

On Mon, Oct 29, 2012 at 06:11:30PM +0100, Simon Morvan wrote:
 
 La problématique concerne la mise en place de deux routeur BGP dans une
 configuration assez simple et classique. Il y aura deux fournisseurs de
 transit IP et donc deux sessions BGP. Je prévois donc d'en terminer une
 sur chaque routeur. Ces deux routeur serviront de default gw (très
 probablement un master/slave en CARP) pour l'infrastructure derrière.
 
 La question qui se pose : est-il pertinent/souhaitable/découragé de
 mettre en place un lien direct back-to-back entre les deux routeurs ou
 faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
 default gw au LAN ?
 
 Question subsidiaire : quel est l'apport de demander, aux transitaires,
 la possibilité de mettre en place deux sessions BGP, soit une par
 routeur. Un réel intérêt en terme de HA par rapport à la complexité
 induite ?


Si tu as 2 routeurs pour une petite infra derrière, il serait
étonnant de ne pas mettre une redondance complète, surtout si tu
utilises OpenBSD :

- CARP sur ton LAN (default gateway) ;
- 1 session BGP avec tes 2 transitaires sur *chaque* routeur
  (donc 2x 2 sessions)... ou du CARP si tu ne peux pas avoir
  tes 2 sessions BGP avec un transitaire [*] ;
- le lien back2back n'est nécessaire que pour la synchro des
  états PF entre les routeurs, et sauf si tu as beaucoup de
  VoIP ou de bureau distant, ce n'est pas obligatoire
  (l'une des interfaces « LAN » fera très bien l'affaire).


[*] pour répondre à certaines critiques vues dans le thread :

- Une bascule CARP ne provoque pas de « mac flap » ou de gratuitous ARP ;
- OpenBGPD active (ou non) le transit en fonction de l'état de ton interface
  CARP (depend on carpN) : une bascule en simulant une panne, avec 1
  transitaire sur 2 en CARP, provoque un lag d'environ 10 à 20
  secondes pour les connexions entrantes sur l'interface « carpée » ;
- Avec 2 transitaires, il est quand même conseillé d'en avoir au
  moins un sur les deux avec une double session BGP.
- Un setup avec CARP n'a rien de complexe... c'est sûr que si tu
  introduis cela dans une équipe qui se borne à faire du Cisco/Juniper,
  un wiki ne sera pas suffisant à « Jean-Paul » pour gérer un incident.
  Mais là, c'est une question de compétences et d'organisation, pas de techno.
  skills, reactivity, cheap: pick two.


Ci@+
-- 
Gregory Colpart r...@evolix.fr  GnuPG:4096R/B8612B5D
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-02 Par sujet Rémi Laurent 
* Gregory Colpart - 02-11-2012 à 15h23:
 
 Si tu as 2 routeurs pour une petite infra derrière, il serait
 étonnant de ne pas mettre une redondance complète, surtout si tu
 utilises OpenBSD :
 
 - CARP sur ton LAN (default gateway) ;
 - 1 session BGP avec tes 2 transitaires sur *chaque* routeur
   (donc 2x 2 sessions)... ou du CARP si tu ne peux pas avoir
   tes 2 sessions BGP avec un transitaire [*] ;
 - le lien back2back n'est nécessaire que pour la synchro des
   états PF entre les routeurs, et sauf si tu as beaucoup de
   VoIP ou de bureau distant, ce n'est pas obligatoire
   (l'une des interfaces « LAN » fera très bien l'affaire).

À noter que le filtering PF sur les border routers avec deux (ou plus)
sessions avec des transitaires ou peering c'est particulièrement
périlleux.

Avec une synchro des états avec pfsync il est plus que conseillé
d'utiliser l'option defer ifconfig(8) et il y a parfois des délais
étranges sur des connexions asymétriques. Si par contre on n'utilise pas
pfsync il faut absolument utiliser les sloppy states, voir pf.conf(5)

My 2 cents aussi (ou alors j'ai raté l'option qui tue)

-- 
Rémi Laurent

  Phone: +352 26 10 30 61
  General Support: supp...@conostix.com
  GPG FP: 27F4 6810 2B0E 1AA0 CDAE  7C7B 3DC9 085A 0FA0 0601


signature.asc
Description: Digital signature

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-02 Par sujet Simon Morvan 
Le 02/11/2012 16:07, Rémi Laurent a écrit :
 À noter que le filtering PF sur les border routers avec deux (ou plus)
 sessions avec des transitaires ou peering c'est particulièrement
 périlleux.
Probablement. Et je garde ma paire de firewall OpenBSD existante en aval
des routeurs.

Merci à tous pour les différents pointeurs. Je vais continuer d'étudier
tout cela.

-- 
Simon


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-02 Par sujet Raphaël Maunier 
On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote:

 On Fri, Nov 02, 2012 at 05:36:39PM +0100, Raphaël Maunier wrote:
 Aussi, les opérateurs de transit, lorsqu'ils verront en cas de soucis qu'il 
 s'agit de routeurs sur Linux, et bien ils cesseront le débug et te diront 
 d'aller t'acheter un routeur ... à tord ou à raison, ce n'est pas la 
 question, c'est jusqu'à quel point tu fais confiance dans la solution ( 
 support, acceptation des équipes interne et externe ... )
 
 Bonsoir,
 
 Il est vrai qu'un routeur soft (Linux, *BSD, ...) ne te permet pas de
 bénéficier du support d'un constructeur, mais il faut s'éloigner du trop
 célèbre nobody ever got fired for buying $SHIT equipment.
 
 Avoir du support chez Cisco, Juniper pour un routeur, IBM, HP, Dell pour
 un serveur c'est bien, mais ça ne fait pas tout.
 
 Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de
 gérer des routeurs soft (pour quelque raison que ça soit: fiabilité,
 gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de
 $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en
 vaut la chandelle.

Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est 
critique, il y a toujours une solution autre que le Linux supporté par personne 
et qui en cas de soucis pourra avoir des conséquences plus désastreuses que les 
X k€ économisés au début de l'aventure.

Donc, bien souvent le jeu n'en vaut pas la chandelle :)
 
 
 Le support de certains logiciels libres (quoique sans avoir aucune
 garantie d'un éditeur/construccteur derrière) n'a rien à envier (parfois
 la situation est même inverse) à certains editeurs/constructeurs.
 
 Lorsque tu vois que tes sessions BGP flappent, que tu poste un message
 sur la liste misc (OpenBSD dans mon cas) et que 45minutes plus tard tu
 as obtenu un patch corrigeant le problème...chapeau.

C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre 
implication.

Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend généralement la 3 
eme version du train dans lequel il souhaite aller.
Les rares cas ou un opérateur doit le faire c'est :

- Support de nouvelles cartes : les constructeurs nous pipeautent depuis des 
années en disant : Bah non, dans votre train actuel, c'est imposiibllle de 
rajouter le support de votre carte. Généralement, on appuie sur le bullshit 
button, mais sauf si tu es Verizon ou NTT ou un très gros, tu aura juste 
l'effet du bouton et donc, t'es bien barré pour un upgrade.

- Support d'un nouveau protocole

- bug vraiment mais vraiment violent qui ne peut pas être fixé avec une release 
de maintenance.


Chez les constructeurs de routeurs, tu as plusieurs niveau de support et 
d'escalade qui est fonction de ton type de maintenance, de ton parc installé et 
de la visibilité que tu apportes sur le marché. Chez Juniper par exemple ( 
c'est ce que je connais ), tu as ce mode de fonctionnement, et tu es capable 
d'avoir un mec en ligne en moins de 45 minutes qui te donnera des commandes à 
taper en CLI Shell qui tape directement l'Asic pour réparer ton bousin si 
jamais c'est un bug avéré. Ensuite, les dev bossent sur un bugfix.
Mais oui, je te l'accorde, ce n'est pas gratuit ...

 
 Des exemples de ce genre j'en ai des cartons entier (baie dell MD1200i
 qui n'a plus aucun volume au reboot. le support dell te dit restore
 from backups)...

justement, c'est la mon propos :) les fournisseurs de HW serveurs ont les pires 
supports de la planète ! Les mecs ils optimisent rien, et ne savent pas faire 
de débug
 
 Quel constructeur/éditeur/... n'a jamais connu de bug majeur sur un de
 ses équipements ? Juniper ? Cisco ? Brocade ? Dell ? ... ?
 
 C'est comme tout, il faut s'y mettre, consacrer du temps, faire des
 tests, ...

Sur la prod, tu ne fais pas de tests hein :)
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-11-02 Par sujet Manuel Guesdon 
On Fri, 2 Nov 2012 23:01:42 +0100
Raphaël Maunier raphael.maun...@jaguar-network.com wrote:
| On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote:
| Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est 
critique, il y a toujours une solution autre que le Linux supporté par 
personne 

Oh, on doit trouver du support commercial dessus



| C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre 
implication.

Hum, au moins tu as le sources (apres faut avoir les compétences). Les
solution cisco/machin/truc c'est la même chose sans les sources.
En gros tu esperes que les gens qui ont pondu le truc soient
compétents et motivés et tu prie pour que ca fixe effectivement le problème,
qu'il n'y ait pas d'effet de bord etc.


| Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend généralement 
la 3 eme version du train dans lequel il souhaite aller.

Pareil pour tout. Je ne pense pas qu'il y ait beaucoup d'allumés qui mettent
en prod direct sans test ni rien une version x.0.0 ni sur des routeurs ni sur
de serveurs...


| Chez les constructeurs de routeurs, tu as plusieurs niveau de support et 
d'escalade qui est fonction de ton type de maintenance, de ton parc installé 
et de la visibilité que tu apportes sur le marché. Chez Juniper par exemple ( 
c'est ce que je connais ), tu as ce mode de fonctionnement, et tu es capable 
d'avoir un mec en ligne en moins de 45 minutes qui te donnera des commandes à 
taper en CLI Shell qui tape directement l'Asic pour réparer ton bousin si 
jamais c'est un bug avéré. Ensuite, les dev bossent sur un bugfix.
| Mais oui, je te l'accorde, ce n'est pas gratuit ...

J'aimerais bien savoir pour 2 'petits' Cicsco/Juniper/Brocade (petits mais
du genre qui fait ce que demandé par Simon: bgp  co) combien ca coute en
achat+support annuel pour avoir en moins de 45mn un gars qui te fait réparer
ton bousin en cli sur le champs :-)

Mais c'est vrai que ca peut servir: si ma mémoire est bonne il y a un an quasi
pile poil [ld]es Juniper avait connu un petit bug :-)


Manuel 

--
__
Manuel Guesdon - OXYMIUM


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-30 Par sujet Dominique Rousseau 
Le Mon, Oct 29, 2012 at 07:39:59PM +0100, Jérôme Nicolle [jer...@ceriz.fr] a 
écrit:
 On 29/10/2012 19:37, Raphael Maunier wrote:
 C'est MAL et c'est SALE :)
 
 Oui, mais ça reste techniquement possible, et dans de rare cas
 souhaitable parce que ça répond à un cas de figure pas si rare que
 ça.

J'vois pas trop le cas pratique où le besoin, c'est HSRP/CARP/VRRP

Parceque de toute façon, l'état de la session BGP sera pas transmis en
passant d'un routeur à l'autre, et que donc, forcément, ça va flapper.
Si le dimensionnement des upstreams est pas suffisant pour se permettre
que ça bascule, pendant un certain temps, sur un seul, y'a un problème
ailleurs que le fait que la bascule se fasse automagiquement ou
manuellement.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet  Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-30 Par sujet Frederic Dhieux 
Le 10/30/12 9:20 AM, Dominique Rousseau a écrit :
 J'vois pas trop le cas pratique où le besoin, c'est HSRP/CARP/VRRP

 Parceque de toute façon, l'état de la session BGP sera pas transmis en
 passant d'un routeur à l'autre, et que donc, forcément, ça va flapper.
 Si le dimensionnement des upstreams est pas suffisant pour se permettre
 que ça bascule, pendant un certain temps, sur un seul, y'a un problème
 ailleurs que le fait que la bascule se fasse automagiquement ou
 manuellement.


Bah non y'en a pas dans une archi propre. C'est l'exemple concret de
l'excès de sécurisation néfaste à l'archi. Si tu veux faire le truc
normalement et proprement dans les règles de l'art, tu as un transit par
routeur et 2 routeurs qui se parlent, avec des transits différent mais
chacun pouvant prendre le relai de l'autre entièrement et tu comptes sur
BGP pour faire les choses proprement. Si ton routeur est un poussif, tu
demandes ta route par défaut en plus de la full view juste au cas où
tout reset pour regagner un peu plus vite de la connectivité vers tout
le monde, et tu t'appuies sur ce protocole pour la redondance avec tes
routeurs en frontal et toute ta couche de redondance L2 derrière
indépendante de ce morceau là.

Si tu veux faire un truc tordu, tu mets du HSRP/VRRP/CARP pour ton
interco en te disant que tu auras toujours tous tes transits, quand ça
flappe ça reset ton BGP, ça entraine des calculs, éventuellement ça
reflappe plusieurs fois parce que c'est plus drôle et toute ton usine
passe son temps à recalculer les routes. Tu mets du niveau 2 au dessus
parce que les surcouches c'est mal mais que tu crois que c'est mieux
pour ton usine qui mérite bien de multiplier les cas de panne.

Dans la vraie vie, le mieux c'est que ta session BGP reste stable autant
que possible sur un L3 propre et épuré et que les problèmes avec ton
transit ça vienne de chez lui ou de ton routeur uniquement, de limiter
les risques au lieu de penser sur-redondance qui multiplie néfastement
les cas d'instabilité possibles. C'est pas parce que 2 méthodes de
redondance sont efficaces unitairement qu'elles feront bon mariage. A ce
niveau là, vraiment, vive KISS  comme dit précédemment.

Je ne parle même pas de la maintenabilité à plusieurs, des cas foireux
d'un port qui déconne sur un switch sans que le comportement soit franc,
etc. On est tous très intelligent (si si c'est notre ego qui nous l'a
dit), le collègue l'est toujours un peu moins parce qu'il n'a pas conçu
le truc (et que c'est notre ego qui l'a dit aussi) et à 5h du mat quand
c'est la merde on est toujours très intelligent mais ça se voit tout de
suite nettement moins parce qu'on a du mal à penser à tout et que la
magnifique archi ultra redondée ressemble maintenant à un Frankenstein
qui fait un AVC.

Pour finir, un transit par routeur, c'est bien, 1 session par transit
sur chaque routeur c'est mal, parce que s'il t'envoie de la merde (ou
qu'il déclenche un bug), il le fera sur tes 2 routeurs.

Il ne faut jamais oublier aussi que dans beaucoup de cas, le déclencheur
d'un problème n'est pas une simple panne ON/OFF qu'on a testé mais un
comportement anormal d'un équipement (ou d'un humain). Limiter les
fonctions, c'est limiter les risques.

Frederic


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

RE: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-30 Par sujet TROUSSE Fabrice 
100% d'accord !!
Simple, redondant et maintenable par les équipes de prod.

Fabrice

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Frederic Dhieux
Envoyé : mardi 30 octobre 2012 10:31
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

Le 10/30/12 9:20 AM, Dominique Rousseau a écrit :
 J'vois pas trop le cas pratique où le besoin, c'est HSRP/CARP/VRRP

 Parceque de toute façon, l'état de la session BGP sera pas transmis en 
 passant d'un routeur à l'autre, et que donc, forcément, ça va flapper.
 Si le dimensionnement des upstreams est pas suffisant pour se 
 permettre que ça bascule, pendant un certain temps, sur un seul, y'a 
 un problème ailleurs que le fait que la bascule se fasse 
 automagiquement ou manuellement.


Bah non y'en a pas dans une archi propre. C'est l'exemple concret de l'excès de 
sécurisation néfaste à l'archi. Si tu veux faire le truc normalement et 
proprement dans les règles de l'art, tu as un transit par routeur et 2 routeurs 
qui se parlent, avec des transits différent mais chacun pouvant prendre le 
relai de l'autre entièrement et tu comptes sur BGP pour faire les choses 
proprement. Si ton routeur est un poussif, tu demandes ta route par défaut en 
plus de la full view juste au cas où tout reset pour regagner un peu plus vite 
de la connectivité vers tout le monde, et tu t'appuies sur ce protocole pour la 
redondance avec tes routeurs en frontal et toute ta couche de redondance L2 
derrière indépendante de ce morceau là.

Si tu veux faire un truc tordu, tu mets du HSRP/VRRP/CARP pour ton interco en 
te disant que tu auras toujours tous tes transits, quand ça flappe ça reset ton 
BGP, ça entraine des calculs, éventuellement ça reflappe plusieurs fois parce 
que c'est plus drôle et toute ton usine passe son temps à recalculer les 
routes. Tu mets du niveau 2 au dessus parce que les surcouches c'est mal mais 
que tu crois que c'est mieux pour ton usine qui mérite bien de multiplier les 
cas de panne.

Dans la vraie vie, le mieux c'est que ta session BGP reste stable autant que 
possible sur un L3 propre et épuré et que les problèmes avec ton transit ça 
vienne de chez lui ou de ton routeur uniquement, de limiter les risques au lieu 
de penser sur-redondance qui multiplie néfastement les cas d'instabilité 
possibles. C'est pas parce que 2 méthodes de redondance sont efficaces 
unitairement qu'elles feront bon mariage. A ce niveau là, vraiment, vive KISS  
comme dit précédemment.

Je ne parle même pas de la maintenabilité à plusieurs, des cas foireux d'un 
port qui déconne sur un switch sans que le comportement soit franc, etc. On est 
tous très intelligent (si si c'est notre ego qui nous l'a dit), le collègue 
l'est toujours un peu moins parce qu'il n'a pas conçu le truc (et que c'est 
notre ego qui l'a dit aussi) et à 5h du mat quand c'est la merde on est 
toujours très intelligent mais ça se voit tout de suite nettement moins parce 
qu'on a du mal à penser à tout et que la magnifique archi ultra redondée 
ressemble maintenant à un Frankenstein qui fait un AVC.

Pour finir, un transit par routeur, c'est bien, 1 session par transit sur 
chaque routeur c'est mal, parce que s'il t'envoie de la merde (ou qu'il 
déclenche un bug), il le fera sur tes 2 routeurs.

Il ne faut jamais oublier aussi que dans beaucoup de cas, le déclencheur d'un 
problème n'est pas une simple panne ON/OFF qu'on a testé mais un comportement 
anormal d'un équipement (ou d'un humain). Limiter les fonctions, c'est limiter 
les risques.

Frederic


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Jérôme Nicolle 

On 29/10/2012 18:11, Simon Morvan wrote:

La question qui se pose : est-il pertinent/souhaitable/découragé de
mettre en place un lien direct back-to-back entre les deux routeurs ou
faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
default gw au LAN ?


Pas besoin de deuxième lien physique si tu ne compte pas atteindre la 
limite du premier, mais l'interco des deux ASBR edoit se faire sur un 
VLAN différent de la patte LAN



Question subsidiaire : quel est l'apport de demander, aux transitaires,
la possibilité de mettre en place deux sessions BGP, soit une par
routeur. Un réel intérêt en terme de HA par rapport à la complexité
induite ?


Intérêt très faible. Quand tu dois shutter un transit c'est plus souvent 
parce qu'ils se sont complètement chié dessus que pour une simple panne 
d'interface. Et quand tu perds un routeur, t'as probablement d'autres 
priorités que maintenir des routes optimales, tant que ça marche à peu près.


Par contre, rien ne t'interdit de monter du CARP sur tes liens WAN, tant 
que tu as un switch sérieux en frontal (qui devient le SPOF, donc compte 
plutôt deux switchs et deux pates WAN physiques sur tes routeurs) pour 
filtrer les merdes de L2 qui peuvent se propager.


@+

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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Raphael Maunier 


On Oct 29, 2012, at 6:26 PM, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 29/10/2012 18:11, Simon Morvan wrote:
 La question qui se pose : est-il pertinent/souhaitable/découragé de
 mettre en place un lien direct back-to-back entre les deux routeurs ou
 faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
 default gw au LAN ?
 
 Pas besoin de deuxième lien physique si tu ne compte pas atteindre la limite 
 du premier, mais l'interco des deux ASBR edoit se faire sur un VLAN différent 
 de la patte LAN
 
 Question subsidiaire : quel est l'apport de demander, aux transitaires,
 la possibilité de mettre en place deux sessions BGP, soit une par
 routeur. Un réel intérêt en terme de HA par rapport à la complexité
 induite ?
 
 Intérêt très faible. Quand tu dois shutter un transit c'est plus souvent 
 parce qu'ils se sont complètement chié dessus que pour une simple panne 
 d'interface. Et quand tu perds un routeur, t'as probablement d'autres 
 priorités que maintenir des routes optimales, tant que ça marche à peu près.
 
 Par contre, rien ne t'interdit de monter du CARP sur tes liens WAN, tant que 
 tu as un switch sérieux en frontal (qui devient le SPOF, donc compte plutôt 
 deux switchs et deux pates WAN physiques sur tes routeurs) pour filtrer les 
 merdes de L2 qui peuvent se propager.
 

Heu, t'es sérieux la ? 

Wan pour toi c'est bien vers le transitaire ? Ou tu es plutôt WAN vers le LAN 
du mec ou il ferait du VRRP / HSRP ?

Parce que si tu es plutôt dans la conception du WAN vers le transitaire avec du 
CARP c'est … sale !


 @+
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Jérôme Nicolle 

On 29/10/2012 18:43, Raphael Maunier wrote:

Heu, t'es sérieux la ?


Oui.


Wan pour toi c'est bien vers le transitaire ? Ou tu es plutôt WAN vers
le LAN du mec ou il ferait du VRRP / HSRP ?


WAN coté upstream, LAN coté serveurs ou eyeballs


Parce que si tu es plutôt dans la conception du WAN vers le transitaire
avec du CARP c'est … sale !


Waip. Mais ça marche bien quand c'est bien fait.

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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Raphael Maunier 
Comment tu peux baser une architecture avec  Mais, ça marche bien quand c'est 
bien fait ?

Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste marche est 
compatible avec tous les providers du monde.

Cessez de faire les Geo Trouvetou  avec des architectures non standardisées 
et complètement non supportées par les opérateurs !


On Oct 29, 2012, at 6:46 PM, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 29/10/2012 18:43, Raphael Maunier wrote:
 Heu, t'es sérieux la ?
 
 Oui.
 
 Wan pour toi c'est bien vers le transitaire ? Ou tu es plutôt WAN vers
 le LAN du mec ou il ferait du VRRP / HSRP ?
 
 WAN coté upstream, LAN coté serveurs ou eyeballs
 
 Parce que si tu es plutôt dans la conception du WAN vers le transitaire
 avec du CARP c'est … sale !
 
 Waip. Mais ça marche bien quand c'est bien fait.
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Jérôme Nicolle 

On 29/10/2012 19:04, Raphael Maunier wrote:

Comment tu peux baser une architecture avec  Mais, ça marche bien quand c'est bien 
fait ?


Parce que c'est le cas de toutes les architectures. Les meilleures 
machines et designs by the book, avec une conf pourrie, ça marche pas 
bien.



Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste marche est 
compatible avec tous les providers du monde.


Quand le provider facture 50 ou 100€ de plus pour la deuxième sessions 
sur le même port physique c'est du foutage de gueule. Mais c'est courant.



Cessez de faire les Geo Trouvetou  avec des architectures non standardisées 
et complètement non supportées par les opérateurs !


(prise de haut détectée)
Un mec qui annonce son réseau en BGP opère un réseau IP au même titre 
que ses upstreams, il est donc tout aussi opérateur que toi. Et s'il 
décide de la supporter, c'est son problème.


Techniquement, monter du HSRP/VRRP/CARP vers un upstream n'est pas sensé 
être visible pour cet upstream, à condition que le switch soit bien 
configuré. C'est donc totalement transparent.


Il se trouve que pour ce besoin particulier, c'est superflu. Surtout vu 
la complexité ajoutée. Mais ça reste techniquement possible.


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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Raphael Maunier 

On Oct 29, 2012, at 7:13 PM, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 29/10/2012 19:04, Raphael Maunier wrote:
 Comment tu peux baser une architecture avec  Mais, ça marche bien quand 
 c'est bien fait ?
 
 Parce que c'est le cas de toutes les architectures. Les meilleures machines 
 et designs by the book, avec une conf pourrie, ça marche pas bien.
 
 Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste marche 
 est compatible avec tous les providers du monde.
 
 Quand le provider facture 50 ou 100€ de plus pour la deuxième sessions sur le 
 même port physique c'est du foutage de gueule. Mais c'est courant.


Speed, price quality, pick two

 
 Cessez de faire les Geo Trouvetou  avec des architectures non 
 standardisées et complètement non supportées par les opérateurs !
 
 (prise de haut détectée)

Nan, pas du tout. Juste d'expérience, les trucs bidouillés, on passe des nuits 
et des mois à les virer 2 ans apres, parce que Jean-Paul s'est barré !

 Un mec qui annonce son réseau en BGP opère un réseau IP au même titre que ses 
 upstreams, il est donc tout aussi opérateur que toi. Et s'il décide de la 
 supporter, c'est son problème.

Et dans la vrai vie, c'est Jean-Paul qui maitrise, et c'est Jean-Pierre qui 
debug un soir à 4h du mat. Ils ont tous les 2 JEAN dans leur prénom, mais pas 
le même background.

Donc, Murphy étant notre pote, le wiki ce soir la est down, donc Jean-Pierre 
n'aura pas la doc, et il faudra comprendre ce qui a été fait.
Donc le mec va passer 3h à debug et l'impact sera plus important que de ne 
pas avoir cette superbe redondance bidouillée.

Trop de redondance, tue la redondance surtout quand c'est de la bidouille
 
 Techniquement, monter du HSRP/VRRP/CARP vers un upstream n'est pas sensé être 
 visible pour cet upstream, à condition que le switch soit bien configuré. 
 C'est donc totalement transparent.

C'est MAL et c'est SALE :)
 
 Il se trouve que pour ce besoin particulier, c'est superflu. Surtout vu la 
 complexité ajoutée. Mais ça reste techniquement possible.

Encore une fois, keep it simple ! IT DOES NOT SCALE !
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Jérôme Nicolle 

On 29/10/2012 19:37, Raphael Maunier wrote:

C'est MAL et c'est SALE :)


Oui, mais ça reste techniquement possible, et dans de rare cas 
souhaitable parce que ça répond à un cas de figure pas si rare que ça.



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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Joe Abley 

On 2012-10-29, at 14:37, Raphael Maunier raphael.maun...@jaguar-network.com 
wrote:

 On Oct 29, 2012, at 7:13 PM, Jérôme Nicolle jer...@ceriz.fr wrote:
 
 Speed, price quality, pick two

Je choisis speed et price quality !

(Do I win €5?)


Joe

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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Raphael Maunier 

Techniquement, je peux aller à 280 sur l'autoroute et pourtant, je respecte la 
vitesse limite de 110/120.

Il est souhaitable pour mon permis que je ne fasse pas des trucs de ce genre !

Donc, il est préférable pour ta plateforme de respecter les standards :)

-- 
Raphael MAUNIER
Jaguar Network France


On Oct 29, 2012, at 7:39 PM, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 29/10/2012 19:37, Raphael Maunier wrote:
 C'est MAL et c'est SALE :)
 
 Oui, mais ça reste techniquement possible, et dans de rare cas souhaitable 
 parce que ça répond à un cas de figure pas si rare que ça.
 
 
 -- 
 Jérôme Nicolle
 06 19 31 27 14
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Thomas Mangin 
Sent from my iPad

On 29 Oct 2012, at 18:39, Jérôme Nicolle jer...@ceriz.fr wrote:

 On 29/10/2012 19:37, Raphael Maunier wrote:
 C'est MAL et c'est SALE :)
 
 Oui, mais ça reste techniquement possible, et dans de rare cas souhaitable 
 parce que ça répond à un cas de figure pas si rare

Et tu fais quoi quand ton upstream vire son Cisco ou le gratuitous arp marche 
simplement car c'est le comportement par defaut de l'interface pour un 
Juniper ou ce n'est pas le cas et que ta bidouille tombe a l eau car le routeur 
refuse d apprendre la MAC ?

Ma reponse en temps que fournisseur : c est pas supporte, pas dans le contrat, 
et je ne veux pas que mes clients puissent impersonaliser n importe quoi.

CQFD: tu fais ce que tu veux mais je le recommende pas a d autres.

Thomas

Dans la meme veine on a des IP RFC1918 sur l interface et l'IP du /30 comme IP 
virtuelle. Je vous laisse aussi chercher pourquoi c est aussi une tres mauvaise 
idee :-)



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Arthur Fernandez - Liazo 

Le 29/10/2012 19:54, Jérôme Nicolle a écrit :

On 29/10/2012 19:46, Raphael Maunier wrote:


Techniquement, je peux aller à 280 sur l'autoroute et pourtant, je
respecte la vitesse limite de 110/120.

Il est souhaitable pour mon permis que je ne fasse pas des trucs de ce
genre !

Donc, il est préférable pour ta plateforme de respecter les standards :)


Tu m'as largué là, je vois absolument pas le rapport.

Rien n'interdit d'utiliser un protocole de niveau 2 pour assurer de la
redondance sur ton réseau, sauf architecture contractuelle avec le
transitaire en question...

L'excès de précautions n'est pas répréhensible, même si c'est un choix
fait au prix d'une maintenance plus complexe.


Ben, le transitaire n'a pas l'habitude de gérer ça car ca représente un 
cas particulier parmis ses X clients, et c'est pas forcément son fort...


pour le coup, il va voir un mac flap et pas comprendre ce qui se passe, 
penser à une maintenance client side sans avoir été informé.


ça c'est dans le meilleur des cas, dans le pire (et le plus courant des 
cas surement), il va faire péter un port security lors du flap, et le 
client final ne sera pas aidé...


KISS c'est toujours mieux, et quand cela ne suffit pas, alors on 
commence à se creuser la tête en faisant peser sur la balance l'ajout de 
complexité d'une part, l'apport qualitatif d'autre part; mais perso, en 
aucun cas je conseillerais l'ajout de complexité pour le plaisir ou la 
beauté du geste




--
Arthur Fernandez - Cofondateur
Mobile:+33.6.61.66.89.54, Fixe:+33.1.82.28.82.80, Fax:+33.1.82.28.82.70.
http://www.Liazo.fr/ - Réseaux, Applications, Haute disponibilité, Sécu.
3/7 rue Albert Marquet, 75020 Paris - Siret 51754198300022


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Jérôme Nicolle 

On 29/10/2012 20:18, Thomas Mangin wrote:

car le routeur refuse d apprendre la MAC ?


Il aura appris la mac virtuelle... C'est au switch client de faire le boulot

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


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Radu-Adrian Feurdean 
On Mon, Oct 29, 2012, at 06:11 PM, Simon Morvan wrote:

 La question qui se pose : est-il pertinent/souhaitable/découragé de
 mettre en place un lien direct back-to-back entre les deux routeurs ou
 faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
 default gw au LAN ?

Defaut GW via insert redundancy protocol here  sur le L2 commun, et de
preference une back-to-back pour l'IBGP. Mais selon tes
pretentions/situation, un VLAN dedie peut le faire aussi.

 Question subsidiaire : quel est l'apport de demander, aux transitaires,
 la possibilité de mettre en place deux sessions BGP, soit une par
 routeur. Un réel intérêt en terme de HA par rapport à la complexité
 induite ?

Usine a gas pas forcement utile.

Mes 0.02 RON (0.005 EUR)


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Christophe Baegert 
Le 29/10/2012 19:37, Raphael Maunier a écrit :
 Trop de redondance, tue la redondance surtout quand c'est de la bidouille
 Encore une fois, keep it simple ! IT DOES NOT SCALE !

Malheureusement ces excellents conseils ne sont pas sur la jolie
plaquette pour décrire la dernière solution de haute dispo à la mode,
donc le décideur il s'en fout. Lui il est prêt à payer pour avoir la
techno à la mode, et si tu arrives pas à faire 100% de dispo avec comme
indiqué sur la plaquette c'est toi qui es un nul...

Christophe



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Radu-Adrian Feurdean 
On Mon, Oct 29, 2012, at 07:04 PM, Raphael Maunier wrote:
 Comment tu peux baser une architecture avec  Mais, ça marche bien quand
 c'est bien fait ?
 
 Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste
 marche est compatible avec tous les providers du monde.

Oui, mais comme le disent certains le client est roi. Donc il peut se
permetre/il a le droit de demander n'importe quelle usine a gas (lire
centrale nucleaire).

Content de savoir que je ne suis pas le seul a penser que ce n'est pas
la voie a suivre..


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Manuel Guesdon 
Bonsoir,

On Mon, 29 Oct 2012 18:11:30 +0100
Simon Morvan gar...@zone84.net wrote:
| Je sais que le sujet est passé plusieurs fois sans forcément être le
| principal intérêt du thread à chaque fois.
| 
| La problématique concerne la mise en place de deux routeur BGP dans une
| configuration assez simple et classique. Il y aura deux fournisseurs de
| transit IP et donc deux sessions BGP. Je prévois donc d'en terminer une
| sur chaque routeur. Ces deux routeur serviront de default gw (très
| probablement un master/slave en CARP) pour l'infrastructure derrière.
| 
| La question qui se pose : est-il pertinent/souhaitable/découragé de
| mettre en place un lien direct back-to-back entre les deux routeurs ou
| faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
| default gw au LAN ?
| 
| Question subsidiaire : quel est l'apport de demander, aux transitaires,
| la possibilité de mettre en place deux sessions BGP, soit une par
| routeur. Un réel intérêt en terme de HA par rapport à la complexité
| induite ?

Donc tu veux avoir Transit1 sur routeur1 et Transit2 sur routeur2 ?
Avec du carp sur le lan. 
Si oui et si je ne suis pas trop fatigué, sans lien entre tes 2 routeurs:
- en sortie tu passeras sur un transit OU sur l'autre mais tu ne pourras pas
choisir.
- en entrée, si tes 2 routeurs annoncent ton prefixe, le transit sur le
routeur qui est carp slave t'enverra des packets dont ton routeur ne saura
pas quoi faire vu que son interface carp est slave donc 'down'.
Ca me parait un peu moyen comme config.

A la va vite je te dirais plutot:
- monte une session avec chaque transitaire sur chacun de tes routeurs
- fait dependre tes sessions de l'etat de ton interface carp (down - tu
shutdown les sessions des 2 transitaire sur le routeur en question, up tu les
active).
Mais c'est un peu crade

Le mieux sans doute, sans ajout de matériel:
- monte une session avec chaque transitaire sur chacun de tes routeurs
- met de l'ospf pour annoncer entre tes routeurs le prefix de ton lan. 
Le routeur dont le carp est UP annoncera en OSPF les prefixes, l'autre dont le
carp est down ne le fera pas mais saura qu'il faut passer par le 1er pour
envoyer les packets à destination du lan
- enventuellement un IBGP entre tes 2 routeurs (surtout si les transitaires
montent des sessions a partir de 2 routeurs chez eux par exemple). Dans ce
cas, attention à la propagation des routes à la fois entre tes 2 routeurs et
vers tes transitaures :-)

Manuel 
--
__
Manuel Guesdon - OXYMIUM


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Radu-Adrian Feurdean 
On Mon, Oct 29, 2012, at 07:13 PM, Jérôme Nicolle wrote:

 Quand le provider facture 50 ou 100€ de plus pour la deuxième sessions 
 sur le même port physique c'est du foutage de gueule. Mais c'est courant.

Vu le prix du transit, c'est presque normal.

 Un mec qui annonce son réseau en BGP opère un réseau IP au même titre 
 que ses upstreams, il est donc tout aussi opérateur que toi. Et s'il 
 décide de la supporter, c'est son problème.

E pas forcement. Il y en a qui le font juste pour avoir une
redondance : si l'upstream A tombe, il reste quand-meme l'upstream B
pour garder le service en marche.
Pour beaucoup de petits c'est aussi simple que ca.

 Techniquement, monter du HSRP/VRRP/CARP vers un upstream n'est pas sensé 
 être visible pour cet upstream, à condition que le switch soit bien 
 configuré. C'est donc totalement transparent.

Bonjour l'usine a gas. D'un autre cote, pour toi ca doit etre la
securite de l'emploi :) La, on peut comprendre :)


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Thomas Mangin 
Sent from my iPad

On 29 Oct 2012, at 19:21, Radu-Adrian Feurdean 
fr...@radu-adrian.feurdean.net wrote:

 Question subsidiaire : quel est l'apport de demander, aux transitaires,
 la possibilité de mettre en place deux sessions BGP, soit une par
 routeur. Un réel intérêt en terme de HA par rapport à la complexité
 induite ?
 
 Usine a gas pas forcement utile.

IMHO - seulement si ton fournisseur a deux routeurs et pas vraiment utile si tu 
as deux transitaires.

Thomas

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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Thomas Mangin 
Sent from my iPad

On 29 Oct 2012, at 19:33, Manuel Guesdon ml+fr...@oxymium.net wrote:

 son interface carp est slave donc 'down'.

Je n utilise pas carp .. je suis donc curieux : l interface est vraiment down 
ou c est seulement la MAC de l IP de service qui n'est pas annonce comme avec 
HSRP/VRRP ?

Thomas

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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Radu-Adrian Feurdean 


On Mon, Oct 29, 2012, at 08:28 PM, Christophe Baegert wrote:

 Malheureusement ces excellents conseils ne sont pas sur la jolie
 plaquette pour décrire la dernière solution de haute dispo à la mode,
 donc le décideur il s'en fout. Lui il est prêt à payer pour avoir la
 techno à la mode, et si tu arrives pas à faire 100% de dispo avec comme
 indiqué sur la plaquette c'est toi qui es un nul...

Le decideur se calme en general avec un devis bien fait. One extra 9 in
the SLA, 9 times the price.

Il restent bien-sur les vendures de reve, mais le retour a la realite ca
risque d'etre tres violent chez eux.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Manuel Guesdon 
On Mon, 29 Oct 2012 19:42:58 +
Thomas Mangin thomas.man...@exa-networks.co.uk wrote:
| On 29 Oct 2012, at 19:33, Manuel Guesdon ml+fr...@oxymium.net wrote:
| 
|  son interface carp est slave donc 'down'.
| 
| Je n utilise pas carp .. je suis donc curieux : l interface est vraiment 
down ou c est seulement la MAC de l IP de service qui n'est pas annonce comme 
avec HSRP/VRRP ?

En fait la mac annoncée que ce soit sur l'une ou l'autre des machines sera
00:00:5e:00:01:xx. xx etant le vhid que tu as indiqué à la config.
La mac ne change pas lors de la bascule, c'est simplement que le master
l'annonce et le slave non.
Par contre je ne sais plus si l'interface est vraiment marqué down ou si elle
est simplement vue comme tel par ospf  co. l'interface carp étant une 'vrai
interface' nommée carpXX que l'ont monte au dessus d'autre chose (un vlan,
une véritable nic, etc).

Manuel 

--
__
Manuel Guesdon - OXYMIUM


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Michael Hallgren 
Le lundi 29 octobre 2012 à 19:04 +0100, Raphael Maunier a écrit :
 Comment tu peux baser une architecture avec  Mais, ça marche bien quand 
 c'est bien fait ?
 
 Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste marche 
 est compatible avec tous les providers du monde.
 
 Cessez de faire les Geo Trouvetou  avec des architectures non standardisées 
 et complètement non supportées par les opérateurs !

+1
mh

 
 
 On Oct 29, 2012, at 6:46 PM, Jérôme Nicolle jer...@ceriz.fr wrote:
 
  On 29/10/2012 18:43, Raphael Maunier wrote:
  Heu, t'es sérieux la ?
  
  Oui.
  
  Wan pour toi c'est bien vers le transitaire ? Ou tu es plutôt WAN vers
  le LAN du mec ou il ferait du VRRP / HSRP ?
  
  WAN coté upstream, LAN coté serveurs ou eyeballs
  
  Parce que si tu es plutôt dans la conception du WAN vers le transitaire
  avec du CARP c'est … sale !
  
  Waip. Mais ça marche bien quand c'est bien fait.
  
  -- 
  Jérôme Nicolle
  06 19 31 27 14
  
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Michael Hallgren 
Le lundi 29 octobre 2012 à 19:13 +0100, Jérôme Nicolle a écrit :
 On 29/10/2012 19:04, Raphael Maunier wrote:
  Comment tu peux baser une architecture avec  Mais, ça marche bien quand 
  c'est bien fait ?
 
 Parce que c'est le cas de toutes les architectures. Les meilleures 
 machines et designs by the book, avec une conf pourrie, ça marche pas 
 bien.
 
  Keep it simple : BGP avec N ports avec /30 , /31 classique, ça juste marche 
  est compatible avec tous les providers du monde.
 
 Quand le provider facture 50 ou 100€ de plus pour la deuxième sessions 
 sur le même port physique c'est du foutage de gueule. Mais c'est courant.

Qui fait ça ??

 
  Cessez de faire les Geo Trouvetou  avec des architectures non 
  standardisées et complètement non supportées par les opérateurs !
 
 (prise de haut détectée)
 Un mec qui annonce son réseau en BGP opère un réseau IP au même titre 
 que ses upstreams, il est donc tout aussi opérateur que toi. Et s'il 
 décide de la supporter, c'est son problème.
 
 Techniquement, monter du HSRP/VRRP/CARP vers un upstream n'est pas sensé 
 être visible pour cet upstream, à condition que le switch soit bien 
 configuré. C'est donc totalement transparent.
 
 Il se trouve que pour ce besoin particulier, c'est superflu. Surtout vu 
 la complexité ajoutée. Mais ça reste techniquement possible.
 



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Simon Morvan 
Re-Bonsoir,

Le 29/10/2012 20:33, Manuel Guesdon a écrit :

 Donc tu veux avoir Transit1 sur routeur1 et Transit2 sur routeur2 ?
 Avec du carp sur le lan. 
 Si oui et si je ne suis pas trop fatigué, sans lien entre tes 2 routeurs:
 - en sortie tu passeras sur un transit OU sur l'autre mais tu ne pourras pas
 choisir.
A priori, un iBGP entre les deux routeur règle ce problème. La question
est plus entre lien dédié back-to-back ou vlan dédié via le switch coté
LAN. Radu et Jérôme divergent sur ce point sans que je ne puisse trop
comprendre les pros  cons.
 - en entrée, si tes 2 routeurs annoncent ton prefixe, le transit sur le
 routeur qui est carp slave t'enverra des packets dont ton routeur ne saura
 pas quoi faire vu que son interface carp est slave donc 'down'.
 Ca me parait un peu moyen comme config.
Pourquoi ? L'interface CARP est certes down, donc l'IP de service est
portée par l'autre routeur mais ça n'empêche pas le slave d'avoir une IP
physique dans le même subnet pour router des paquets vers le LAN.

 Le mieux sans doute, sans ajout de matériel:
 - monte une session avec chaque transitaire sur chacun de tes routeurs
 - met de l'ospf pour annoncer entre tes routeurs le prefix de ton lan. 
 Le routeur dont le carp est UP annoncera en OSPF les prefixes, l'autre dont le
 carp est down ne le fera pas mais saura qu'il faut passer par le 1er pour
 envoyer les packets à destination du lan
Comme l'utilisateur côté LAN c'est surtout la couche FW avant
d'atteindre les frontaux, je me demande si ça ne va justement pas se
régler à coup d'OSPF entre les deux routeur et le cluster de FW

-- 
Simon


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Simon Morvan 
Le 29/10/2012 20:21, Radu-Adrian Feurdean a écrit :
 On Mon, Oct 29, 2012, at 06:11 PM, Simon Morvan wrote:

  La question qui se pose : est-il pertinent/souhaitable/découragé de
  mettre en place un lien direct back-to-back entre les deux routeurs ou
  faut-il mieux se reposer sur le L2 qu'ils ont en commun pour servir de
  default gw au LAN ?
 Defaut GW via insert redundancy protocol here  sur le L2 commun, et de
 preference une back-to-back pour l'IBGP. Mais selon tes
 pretentions/situation, un VLAN dedie peut le faire aussi.

Justement, j'ai ce qu'il faut en interfaces pour le faire en
back-to-back. Mais quels sont les pros/cons entre un câble direct ou un
vlan dédié ?




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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Simon Morvan 
Le 29/10/2012 21:08, Manuel Guesdon a écrit :
 On Mon, 29 Oct 2012 19:42:58 +
 Thomas Mangin thomas.man...@exa-networks.co.uk wrote:
 | On 29 Oct 2012, at 19:33, Manuel Guesdon ml+fr...@oxymium.net wrote:
 | 
 |  son interface carp est slave donc 'down'.
 | 
 | Je n utilise pas carp .. je suis donc curieux : l interface est vraiment 
 down ou c est seulement la MAC de l IP de service qui n'est pas annonce 
 comme avec HSRP/VRRP ?
 En fait la mac annoncée que ce soit sur l'une ou l'autre des machines sera
 00:00:5e:00:01:xx. xx etant le vhid que tu as indiqué à la config.
 La mac ne change pas lors de la bascule, c'est simplement que le master
 l'annonce et le slave non.
 Par contre je ne sais plus si l'interface est vraiment marqué down ou si elle
 est simplement vue comme tel par ospf  co. l'interface carp étant une 'vrai
 interface' nommée carpXX que l'ont monte au dessus d'autre chose (un vlan,
 une véritable nic, etc).

L'interface carpXX est UP mais en mode BACKUP donc ne répond pas aux
sollicitations ARP :

carp107: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:00:5e:00:01:6b
priority: 0
carp: BACKUP carpdev vlan107 vhid 107 advbase 1 advskew 100
groups: carp
inet6 fe80::200:5eff:fe00:16b%carp107 prefixlen 64 scopeid 0x14
inet SNIP netmask 0xfff8 broadcast SNIP


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Aurélien 
Bonsoir,

2012/10/29 Clement Cavadore clem...@cavadore.net:

 Pour le reste, je dirais: Pourquoi ne pas faire les deux ? un back2back
 dédié avec un cout ospf faible, et un vlan via le switch lan avec un
 cout OSPF plus fort ?

 Ainsi, en nominal, ca passe par le back2back, et en cas de failure de
 cable ou de NIC, il y a un autre lien de backup pour le traffic entre
 les routeurs ? :)


Je plussoie.

Si tes routeurs le permettent, une autre option est de faire un
aggrégat LACP entre tes deux routeurs, et avoir une redondance et de
l'actif-actif, sans dépendre d'un niveau 2. Selon ta situation, tu
peux te passer de l'OSPF à 2 routeurs dans ce cas, mais tu te prendras
plus la tête quand tu voudras rajouter un deuxième site et des
nouveaux routeurs dans la boucle 2-3 ans plus tard :)

Cordialement,
-- 
Aurélien Guillaume


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Sylvain Vallerot 



On 29/10/2012 23:11, Simon Morvan wrote:

- en entrée, si tes 2 routeurs annoncent ton prefixe, le transit sur le
routeur qui est carp slave t'enverra des packets dont ton routeur ne saura
pas quoi faire vu que son interface carp est slave donc 'down'.
Ca me parait un peu moyen comme config.

Pourquoi ? L'interface CARP est certes down, donc l'IP de service est
portée par l'autre routeur mais ça n'empêche pas le slave d'avoir une IP
physique dans le même subnet pour router des paquets vers le LAN.


Il me semble qu'il manque un bout du cahier des charges ici. Quelle
est la fiabilité de la liaison LAN et de la connectivité entre les
deux routeurs ? carp aura-t-il un comportement satisfaisant si les
deux routeurs ne se voient plus ?

Le but est-il d'avoir toujours une passerelle accessible vers
l'extérieur depuis le LAN, d'émettre dynamiquement une annonce du
réseau vers internet, ou les deux ?



Le mieux sans doute, sans ajout de matériel:
- monte une session avec chaque transitaire sur chacun de tes routeurs
- met de l'ospf pour annoncer entre tes routeurs le prefix de ton lan.
Le routeur dont le carp est UP annoncera en OSPF les prefixes, l'autre dont le
carp est down ne le fera pas mais saura qu'il faut passer par le 1er pour
envoyer les packets à destination du lan

Comme l'utilisateur côté LAN c'est surtout la couche FW avant
d'atteindre les frontaux, je me demande si ça ne va justement pas se
régler à coup d'OSPF entre les deux routeur et le cluster de FW



Ca peut très bien se faire, mais dans ce cas l'aspect fonctionnel
qui nous intéresse n'est pas le firewalling mais le routage, et le
problème de la transition entre le routage statique et le routage
dynamique n'est donc que repoussé aux équipements plus loin dans le
backbone : Carp ou pas carp, la question demeure.


Pour ce qui est de la question subsidiaire : l'intérêt de dédoubler
les sessions de transit des transitaires sur les deux routeurs tient
à plusieurs critères, et notamment :

- similarité des transitaires, et importance de les conserver tous
 les deux en cas de panne ou pendant les maintenances

- possibilité de livrer chaque transit séparément ou non, depuis
 2 routeurs upstream ou non, et toutes déclinaisons

- fiabilité des laisons entre les deux routeurs, répartition de
 l'infrastructure

Une seule certitude : Carp côté WAN c'est proscrit, tout simplement
pas compatible avec BGP (ou bien il faut deux routeurs qui soient
gérés comme un seul routeur virtuel, je ne crois pas que ce soit le
cas dans la problématique posée).

Mes 2 cents.



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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Radu-Adrian Feurdean 


On Mon, Oct 29, 2012, at 11:19 PM, Simon Morvan wrote:

 Justement, j'ai ce qu'il faut en interfaces pour le faire en back-to-back. 

Fais-le.

 Mais quels sont les pros/cons entre un câble direct ou un vlan dédié ?

prix, debit, il y a des calculs a faire.


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

Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie

2012-10-29 Par sujet Manuel Guesdon 
On Mon, 29 Oct 2012 23:11:56 +0100
Simon Morvan gar...@zone84.net wrote:

| Re-Bonsoir,
| 
| Le 29/10/2012 20:33, Manuel Guesdon a écrit :
| 
|  Donc tu veux avoir Transit1 sur routeur1 et Transit2 sur routeur2 ?
|  Avec du carp sur le lan. 
|  Si oui et si je ne suis pas trop fatigué, sans lien entre tes 2 routeurs:
|  - en sortie tu passeras sur un transit OU sur l'autre mais tu ne pourras 
pas
|  choisir.
| A priori, un iBGP entre les deux routeur règle ce problème. La question
| est plus entre lien dédié back-to-back ou vlan dédié via le switch coté
| LAN. Radu et Jérôme divergent sur ce point sans que je ne puisse trop
| comprendre les pros  cons.

Oui, c'est pour ca que je disais que sans, ca poserait un peu problème :-)


|  - en entrée, si tes 2 routeurs annoncent ton prefixe, le transit sur le
|  routeur qui est carp slave t'enverra des packets dont ton routeur ne saura
|  pas quoi faire vu que son interface carp est slave donc 'down'.
|  Ca me parait un peu moyen comme config.
| Pourquoi ? L'interface CARP est certes down, donc l'IP de service est
| portée par l'autre routeur mais ça n'empêche pas le slave d'avoir une IP
| physique dans le même subnet pour router des paquets vers le LAN.

Effectivement ca devrait le faire.


|  Le mieux sans doute, sans ajout de matériel:
|  - monte une session avec chaque transitaire sur chacun de tes routeurs
|  - met de l'ospf pour annoncer entre tes routeurs le prefix de ton lan. 
|  Le routeur dont le carp est UP annoncera en OSPF les prefixes, l'autre 
dont le
|  carp est down ne le fera pas mais saura qu'il faut passer par le 1er pour
|  envoyer les packets à destination du lan
| Comme l'utilisateur côté LAN c'est surtout la couche FW avant
| d'atteindre les frontaux, je me demande si ça ne va justement pas se
| régler à coup d'OSPF entre les deux routeur et le cluster de FW

Dans l'absolu ca me semble le plus propre.

Manuel

--
__
Manuel Guesdon - OXYMIUM


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