Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

2020-05-09 Par sujet Frederic Dhieux

Bonjour,

D'une part la proposition a 20 ans de retard (c'est pas le premier à 
chercher à gratter de la place dans le header pour étendre l'IPv4), mais 
les problèmes sont les mêmes que pour IPv6 hormis la double stack.


La réalité (et c'est expliqué environ 50 fois dans le thread du RIPE), 
c'est que tu dois adapter quand même les équipements concernés, que le 
bit en question peut être réécrit ou reset ou utilisé et dans ce cas tu 
perds l'extension, que pire encore sur une non prise en compte de ce 
bit, tu peux te retrouver avec une IP dupliquée qui peut poser des 
problèmes sur des ACL et que comme dit Radu, à un moment en end point tu 
as une IP qui est 32 bits sans rien d'autre et que voilà.


Si c'est pour taper dans les trucs non prévus, autant exploiter la 
classe E 240.0.0.0/4 réservée pour utilisation future (quel futur ?). A 
priori Windows le gère pas, mais ce serait surement plus simple de 
débloquer ça qu'utiliser un bit "magique".


La proposition n'a aucun fondement concret, aucune sous couche 
technique, aucun POC, aucune proposition solide.


Le mec utilise une méthode bien à la mode pour essayer de se faire élire 
en promettant des trucs magiques (sa proposition anti-spam est du même 
accabit), c'est du Trump like quoi. Sachant que le RIPE n'est pas 
l'organisme qui décide de tout ça en plus.


Je suis effrayé de voir qu'un tel ce non sens a réussi à générer autant 
de volume de discussions et je m'inquiète de voir des gens croire en ce 
marabout de l'an 2020. Entre Trump et les débilités qu'on voit 
concernant Coronavirus et la 5G régulièrement, j'espère qu'au moins la 
communauté des membres du RIPE a globalement plus de discernement que ça.


Voilà que même au RIPE on se tape de promesses de politiciens...

Fred

Le 09/05/2020 à 16:51, Bruno LEAL DE SOUSA a écrit :

Bonjour Johann et bonjour à tous,

Merci pour ces explications mais j'ai juste répondu un peu vite et pas dans
le bon sens.
En effet lorsqu'on regarde en détail sa proposition et surtout ses méthodes
cela fait peur et l'application semble impossible voir catastrophique.

Après je pense que la réflexion qu'il a apporté a juste 10 ou 20 ans de
retard. Il aurait fallu y songer avant de propulseur IPv6.
Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
sécurité dans les années à venir à cause de ce changement trop brutal.
Un changement ne peut être réussi que quand il est adapté, pas trop brusque
et accompagné. Je trouve donc dommage que ce genre de proposition ou de
réflexion apparaissent bien trop tard.

Maintenant il est certain que ces propositions manquent de sens et de
possibilité de réalisation. Des belles promesses de politiciens encore...

Espérons qu'il ne réussisse pas à gagner le combat des élections.

Bonne journée à tous.

Bruno LEAL DE SOUSA
06.01.23.45.96

Le sam. 9 mai 2020 à 16:38, Johann  a écrit :


Bonjour Bruno,

Pour répondre un peu plus sur la partie technique, car j'imagine que
beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est
pas une insulte) pour juger en profondeur de celle-ci.

TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui
utiliserait la même structure de paquet et qui serait en plus
rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
l'apocalypse. Ça c'est la promesse papier électorale.

Humainement parlant, on aurait les IPv4 classiques
[0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
du header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
plage d'IP réservée est souvent difficile à utilisé dans le futur.

Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de
la technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
(don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
réseaux  pour la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce
qui est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.

Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)

Ce monsieur justifie que les bits de fragmentation sont "optional by
design" et que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU 

Re: [FRnOG] [TECH] Changement Cisco ?

2020-03-25 Par sujet Frederic Dhieux
Bonjour,

Pour du routeur pur, je suis passé de 7600/6500 à ASR900X il y a 6 ans
et j'en suis super content. C'est robuste, l'OS change mais quelque part
c'est assez familier avec des améliorations donc gagnant-gagnant à ce
niveau là et c'est rock solid chez nous.

Seul bémol pour moi comparativement à avant, avoir eu à payer une
licence pour les VRF (et encore on est toujours limités à 8 avec la
licence qu'on a choisi). Pour le reste c'est top, rien à dire en 6 ans.

Je ne vais pas encourager Cisco et leur façon de traiter le marché
parfois, mais faut reconnaitre que certains produits sont juste
efficaces et stables et pour moi l'ASR9K en fait partie.

Pour le contexte, chez nous qui ne sommes pas un opérateur, ça sert de
coeur avec les transits et peerings, une poignée de VRF, le MPLS bien
sûr et quelques tunnels L2 dessus et les edges en BGP (en mode client
BGP pour chaque BU) et des ACL sur les ports d'entrée internet. Et bien
sûr dual stack IPv4/IPv6.

Le 25/03/2020 à 14:05, Lucas Viallon a écrit :
> Merci pour ta réponse,
>
> Dans mon cas, j'ai vraiment tendance a rester cisco que je connais et dont
> le taux de satisfaction chez nous et de l'ordre de 99%,
> j'ai déjà essayé d'aller vers du juniper, du mikrotik ou du libre et
> sincèrement je m'en suis toujours mordu les doigts.
>
> Au niveau budget, je suis justement en train de le définir, on s'adaptera
> mais on préférera payer un peu plus chère pour du cisco
> que perdre du temps a retester d'autres plateformes
>
> au vu des conseils, je pense commander un ASR en 9900 pour tester, on verra
> bien
>
> Le mer. 25 mars 2020 à 12:43, Jérôme Nicolle  a écrit :
>
>> Salut Lucas,
>>
>> Le 25/03/2020 à 11:39, Lucas Viallon a écrit :
>>> Il y a quelqu'un qui a deja fait ce genre de changement ? vous etes
>> partie
>>> sur sur quelle gamme ?
>> Juniper MX / ACX / QFX le plus souvent, Arista ou Cumulus par ailleurs.
>>
>> Su tu restes en Cisco, de toute façon tu vas changer d'OS en passant à
>> IOS-XR donc quitte à refaire tout ton design autant en profiter pour
>> regarder à coté. En fonction de ce que tu veux en faire, il peut y avoir
>> un réel intérêt à changer de fabricant.
>>
>> N'oublies pas d'évaluer les NCS5500 aussi, ils en ont gros sous le pied.
>>
>> @+
>>
>> --
>> Jérôme Nicolle
>> +33 6 19 31 27 14
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Peering Free<->Verizon saturé ?

2020-03-23 Par sujet Frederic Dhieux
Il doit y avoir une solution de Visio chez eux. Auquel cas Free est en
droit bien entendu de demander plein d'argent à Verizon pour oser
utiliser ses tuyaux abonnés pour de la vidéo, surtout que l'abonné
envoie 1 vidéo et en reçoit plusieurs :o

Pardon on n'est pas encore vendredi.


Le 23/03/2020 à 13:20, Sébastien Lesimple a écrit :
> Comment qui disaient à la TV?
> "T'as Free, t'as tout compris"... Ou pas.
>
> Bon faut reconnaître que c'est pas prévu pour faire du pro en
> Teletravail et que l'AS702 de Verizon aujourd'hui porte plus grands
> choses de généraliste.
> Dailleurs VZ en France de nos jours, c'est Waterloo morne plaine.
>
> Le 23/03/2020 à 13:14, David Ponzone a écrit :
>> La morale c’est que le GP qui a choisi Free à la maison pour le prix doit 
>> maintenant assumer son choix.
>>
>> Et le FAI qui a choisi Cogent, idem :)
>>
>> Oui je sais, on est pas vendredi.
>>
>>> Le 23 mars 2020 à 12:50, Hervé BRY  a écrit :
>>>
>>> Bonjour,
>>>
>>> J'ai constaté une saturation entre Cogent (principal transitaire de Free)
>>> et Telia aux heures de pointe.
>>> Ca semble saturer aussi entre SFR et Telia.
>>>
>>> Pour ma part j'ai heureusement pu router ces deux destinations par un autre
>>> transitaire que Telia.
>>>
>>> Hervé BRY
>>> Administrateur Système
>>> Geneanet (http://www.geneanet.org)
>>>
>>>
>>> Le lun. 23 mars 2020 à 12:46, Ronan De Kermadec <
>>> rdekerma...@transnumeric.com> a écrit :
>>>
 Bonjour à tous,

 Avec l’adoption massive du télétravail la semaine dernière nous constatons
 de fortes lenteurs/pertes de paquets (environ 25%) pour tous nos
 utilisateurs connectés chez Free.

 Nous avons ouvert un ticket chez Verizon (notre ISP) qui a escaladé le
 ticket en interne. Verizon indique que le peering entre Free et Verizon
 (entre 194.149.166.34 et 146.188.112.253) est complètement saturé entre 9h
 et 12h puis entre 14h et 17h30. Free a été sollicité pour éventuellement
 planifier un upgrade mais Verizon n’a eu aucun retour de leur part pour le
 moment semble-t-il !

 J’ai tenté d’ouvrir un ticket chez Free à ce sujet afin de pouvoir
 échanger avec les équipes backbone malheureusement sans grand succès.

 Si quelqu’un de chez Free passe par là ou si vous connaissez quelqu’un qui
 pourrait faire avancer les choses, merci de prendre contact avec moi afin
 que je puisse vous donner plus de détails.

 Je ne pense pas que nous soyons les seuls à constater ce problème,
 y’a-t-il d’autre personnes qui subissent ces lenteurs ?

 Merci d’avance pour votre aide précieuse !

 Ronan


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


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


Re: [FRnOG] [ALERT] Intervention Equinix, changement de procédure d'accès à partir de demain

2020-03-22 Par sujet Frederic Dhieux
Hello,

C'est une période exceptionnelle et une situation exceptionnelle, il
faut faire avec. Les gens qui n'ont pas anticipé vont morfler, il faudra
faire au mieux avec les moyens du bord (les techs du DC), faire livrer
le matos et donner les consignes.

C'est pas comme si on ne l'avait pas vu arriver depuis des semaines
cette situation, sans compter la période des grèves massives où déjà on
aurait du réfléchir un peu plus à l'adaptation des outils de
télétravail. Critiquer un gouvernement qui a mal anticiper c'est facile
(et je le fais aussi), mais au final ils ne sont pas les seuls à avoir
mal géré la situation depuis 1 mois.

Bravo aux DC de maintenir un service pour le client. Il est courageux et
difficile d'interdire l'accès client, mais c'est une mesure raisonnable
pour limiter les risques dans ces lieux sensibles, on a besoin d'eux !

 Fred

Le 22/03/2020 à 17:34, Johann a écrit :
> Hello Arnaud,
>
> Entièrement d'accord avec toi. Mais il y a une différence entre ceux qui
> viennent faire des selfies devant une baie, et ceux qui travail pour faire
> cette continuité et absorbé l'augmentation de trafic des clients.
> Ceux-ci devraient pouvoir continuer à intervenir dans des conditions
> strict. Et ne me demande pas de laisser faire des manipulations complexes à
> Equinix, on a déjà vu les dégâts que ça peut occasionner...
> Clairement, si aucun accès n'est possible, on va avoir des problèmes sur le
> moyen terme.
>
> Johann
>
>
> Le dim. 22 mars 2020 à 17:14, Arnaud  a
> écrit :
>
>> C’est une très bonne chose !
>> Vous ne vous rendez pas compte de l’importance cruciale de ces sites
>> sensible en ce moment.
>> Les selphies devant les baies attendront (j’en ai vu sur twitter, et à
>> Paris !), en attendant, on doit tout faire pour protéger les techniciens
>> des DC qui se démènent en ce moment à faire toutes les interventions client
>> et maintenir la continuité technique des sites.
>> Gloire à eux !
>> Arnaud
>>
>>
>>
>>> Le 22 mars 2020 à 14:15, David Ponzone  a
>> écrit :
>>> Ils sont oufs.
>>> Si encore, ils étaient passés par la case « Appointment-only » comme ils
>> ont annoncé qu’ils feraient si nécessaire, on aurait pu sentir le truc
>> arrivé.
>>> Y a plus qu’à croiser les doigts.
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [MISC] Profitons bien de l'épidémie pour violer un peu la neutralité

2020-03-16 Par sujet Frederic Dhieux
Bonjour,

Oui je pense que les tuyaux posent moins de soucis que les services pas
taillés pour le nombre de connexions. Cette période va être
intéressante, on va sentir toutes les économies faites en mettant les
curseurs au plus bas dans les entreprises et organismes.

Genre j'ai vu des entreprises demander à des collaborateurs de ne pas
télétravailler car le VPN n'était pas taillé pour supporter tout le
monde :) C'est un peu dommage, surtout quand on a été préparé par les
grêves quelques semaines/mois avant =)

Le 16/03/2020 à 13:28, Alarig Le Lay a écrit :
> Le souci ne vient toujours pas de la taille des tuyaux. Ils ont résisté
> à la coupe du monde des 11 glandus derrière un ballon, ils résisterons à
> ça.
>
> On lun. 16 mars 12:50:06 2020, Nico G wrote:
>> Le core ça doit tenir sans problème. Certains lien edge peut être pas.
>> Le peering vers Netflix ou Google c’est du privé et c’est largement 
>> dimensionné. Le transit généraliste vers tel ou tel hébergeur c’est moins 
>> sur. D’autant plus qu’Orange n’a pas le peering dans le sang.
>>
>> Nicolas
>>
>>> Le 16 mars 2020 à 12:30, Richard Klein  a écrit :
>>>
>>> @David
>>> La question est de savoir si la saturation est sur le cœur et si les
>>> opérateurs et acteurs des télécoms seront tirer la leçon pour investir
>>> Et si payer une fibre un bras et se retrouver avec des ralentissements
>>> c'est les prochaines questions qui seront abordés par les clients...
>>>
 Le lun. 16 mars 2020 à 12:25, David Ponzone  a
 écrit :

 J’ai pas bien compris le rapport entre ma fibre et les sites web de
 support scolaire des écoles….

>> Le 16 mars 2020 à 12:06, Richard Klein  a écrit :
> Bonjour a tous depuis la maison pendant ma pause déjeuné.
> Je me fais l'avocat du diable...
> Question lorsque vous payez une fibre 500euros et lorsque vous payez 30
> euros en GP vos debits sont garantis pour la ligne GP ou Pro?
> :-)
>
> Richard
>
> Le lun. 16 mars 2020 à 11:44, GROS Jérôme  a écrit
 :
>> Pour l'école primaire chez moi :
>> https://beneylu.com/fr/beneylu-school-met-les-bouchees-doubles/
>> Bon là, même le message d'alerte ne fonctionne plus.
>>
>> On Mon, Mar 16, 2020 at 10:10:53AM +0100, David Ponzone wrote:
>>> Des sources de quoi ?
>>> Ben EcoleDirecte de mon fils: inutilisable à l’heure actuelle.
>>> VieScolaire de ma fille: inutilisable
>>> Kwyk dont se sert la prof de maths de mon fils: inutilisable toute à
>> l’heure, ça a l’air d’aller un peu mieux là.
>>> Paris Classe Numérique marchait pas ce matin (accès prof), mais ça
 semble
>> s’améliorer.
>>> Y a donc pas grand chose qui support les accès massifs et comme rien
 n’a
>> été fait pour les étaler dans le temps...
 Le 16 mars 2020 à 10:03, Michel Guillou  a écrit :

 Le Mon, 16 Mar 2020 09:52:07 +0100, vous écrivîtes :

> S’ils font ça, ils sont morts.
> Même certains profs comptent sur Youtube pour fournir le contenu que
>> le Ministère n’a pas.
> Je parle même pas des serveurs type EcoleDirect et autres, qui ont
>> gentiment explosé ce matin.
 Tu as des sources là-dessus ? Ça m'intéresse...

 Merci.

 --
 Michel Guillou
>>
>> ---
>> 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/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Les AS privés dans les AS-PATH

2018-06-05 Par sujet Frederic Dhieux


Le 04/06/2018 à 16:37, Clement Cavadore a écrit :
> On Mon, 2018-06-04 at 16:22 +0200, Julien Escario wrote:
>> A priori, ca n'a pas d'intérêt ni bon, ni mauvais si ce n'est
>> d'allonger artificiellement l'AS-PATH. Ceci dit, on est d'accords que
>> ca ne devrait pas sortir d'un AS ce genre de truc ?
>>
>> Vous filtrez ça ?
> Oui, et je t'encourage à le faire.
> Si jean-kevin ne sait pas configurer proprement ses routeurs, il y a
> fort a parier que tu ne veux pas voir ses annonces dans ta RIB/FIB :-)
Hello,

Ouais c'est bien le discours radical "il fait ça mal, il mérite pas que
j'apprenne ses routes", sauf que c'est arrivé parfois aussi à des gros
FAI français par exemple qui découpent leur réseau par zones comme ça et
oublient le remove-private-as, ça peut arriver à un petit qui a juste
loupé une ligne de conf. L'erreur est humaine, ce serait bien que ce
soit remonté par quelque système de suivi, mais je ne trouve pas que ce
soit matière à "bannir" un préfixe quand même (tant que ce n'est pas
l'AS final de l'as-path).

C'est mignon en plus, ça permet de vanner les gens un peu :D

Frédéric


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


Re: [FRnOG] [TECH] BGP et HSRP

2018-04-08 Par sujet Frederic Dhieux
Hello,

J'utilise de mon côté ce système pour des firewalls, c'est très souple
et efficace. Les 2 firewalls sont en BGP vers les routeurs edge et la
CARP est annoncée en next-hop.

Ca permet d'avoir une bascule très rapide, d'avoir une cohérence entre
les gateways actives pour les VLAN derrière et le master sur le BGP, ça
permet aussi de perdre le process BGP du master (ou de le couper) sans
changer le routage.

C'est de loin la solution la plus robuste et pratique pour ce contexte.

Après entre routeurs purs, la question se pose plus, mais ça ne me
choque pas dans l'absolu, si on a un L2 qui traine dans l'archi (c'est
peut-être là le point noir qui embête du monde. Admettons même tu as une
interco privée entre 2 routeurs pour le HSRP et du multihop eBGP pour
joindre ton copain, si l'interco privée pète, tes ports tombent, les IPs
et donc les 2 sessions. Une coupure (certes rare si c'est un agrégat)
tomberait l'ensemble. Donc à côté faudrait encore 2 sessions de backup
sur de la loopback pour parer à ce cas mais là c'est plus du tout élégant.

Bref pour du end point d'un L2 c'est vraiment sexy je trouve, mais dans
un contexte L3 pur, là comme ça je dirais que ça peut poser des effets
pervers.

Fred

Le 07/04/2018 à 18:22, Michel Py a écrit :
>> Antoine BOURAS a écrit :
>> Sinon, je ne te cache pas, quand j'ai vu ça j'ai eu mal aux yeux.
> C'est parce que t'as pas bien regardé ce que je proposais.
> J'aurais du préciser : eBGP entre 2 AS. Si c'était du iBGP, je suis au 
> courant qu'il faut ou full mesh ou route reflector ou confederation.
>
> On ne peut PAS avoir l'adresse virtuelle qui soit le router-ID.
> Dont il faut une session 2 sessions BGP et set next-hop l'adresse virtuelle 
> dans la route-map out.
>  AS1  AS2
> R1 192.168.0.1  <---eBGP--->  R3192.168.0.4
> R2 192.268.0.2  <---eBGP--->  R4192.168.0.5
> Virt   192.168.0.3Virt  192.168.0.6
> Une session BGP entre R1 et R3, une autre entre R2 et R4.
>
>
>> Il ne faut pas oublier que BGP est sur TCP ? Elle va faire comment la pauvre 
>> session TCP quand HSRP bascule ?
> Il y a 2 sessions TCP est aucune n'est sur HSRP.
>
>
>> il faut un Point à Point (physique) quand on fait du eBGP.
> Non pas forcément, eBGP multihop je fais çà tous les jours.
>
>
>> David Ponzone a écrit :
>> Ok mais HSRP/VRRP sert à quoi alors ?
> A réduire à presque zéro le temps de bascule quand le routeur active tombe 
> sans bidouiller dans les timers de BGP. Bidouiller les timers de BGP j'aime 
> pas, quand on a un routeur un peu poussif çà cause des problèmes.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



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


Re: [FRnOG] [ALERT] interxion aubervillier

2017-10-06 Par sujet Frederic Dhieux
Hello,

J'ai 2 liens à terre actuellement depuis 9h45 :
- TH2 - InterXion PAR5
- Condorcet - Equinix PA3

Frederic


Le 06/10/2017 à 10:17, Erik Linder a écrit :
> bonjour,
>
> est ce que vous observez des problemes sur Interxion aubervillier
>
> cdlt
> Erik
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [MISC] Re: [FRnOG] [JOBS] Ingénieurs et Consultants Réseaux (Avant-vente et Déploiement/Prestation)

2017-06-02 Par sujet Frederic Dhieux
Le 31/05/17 à 16:27, Arnaud Launay a écrit :

> (je passe en misc...)
>
> Le Wed, May 31, 2017 at 01:23:34PM +0200, Josselin Lecocq a écrit:
>> les recherches effectuées au sujet de l'entreprise chez qui on
>> candidate (réel intérêt, et pas juste besoin urgent et immédiat).
> Heu... Je ne connais personne qui travaille dans l'entreprise où
> ils sont /parce que/ c'est l'entreprise qu'ils voulaient.
>
> Tout ce qu'ils veulent, c'est un salaire pour pouvoir faire des
> choses avec, l'entreprise qui fournit le salaire, tout le monde
> s'en tape. C'est une belle vision très paternaliste de
> l'entreprise, mais il faudrait arrêter les oeillères.
>
> On n'est plus au 20ème siècle pour les lettres de motivation,
> mais on n'est plus non plus au 19ème siècle où on rentre dans une
> boîte pour toute sa vie, hein...
Bah écoute personnellement je considère le cadre de travail comme aussi
important que le salaire, parce que j'y passe une bonne partie de mes
journées et que j'aime faire quelque chose qui me plait, me motive, me
fait progresser. Gagner de l'argent c'est bien, mais si c'est pour
pester toute la journée sur ce que tu fais, travailler avec des gens qui
sont pas dans le même état d'esprit que toi, faire des trucs chiants,
non merci.

L'activité en elle même n'est pas le principal intérêt en général
effectivement, mais l'approche de la société, la manière de fonctionner,
l'ambiance, les moyens donnés pour faire des projets, la reconnaissance
et la confiance qu'on te donne comptent vraiment.

Tu peux trouver ça ridicule, moi je trouve ça ridicule dans notre
domaine (qui est souvent lié à une passion au départ) d'être un
mercenaire qui ne s'intéresse pas à ce qu'il fait dans son boulot.

Chacun sa vision des choses, on a la chance d'avoir un rapport de force
favorable aux postulants, mais un CV permet de voir la capacité de
synthèse et de présentation d'une personne, une lettre de motivation
permet de voir la capacité de rédaction et l'approche mentale de la
démarche (en regardant entre les lignes) voire le sérieux du candidats
(relecture, fautes).

Pour un poste qui inclut majoritairement de la représentation auprès de
clients, ça me parait tout à fait normal.

J'ajoute (et ça va te choquer) que le dernier candidat que j'ai pris
dans mon équipe m'a transmis une lettre de motivation pour montrer son
intérêt suite à l'entretien, sans que personne ne lui en demande.
Parfois au delà du capitalisme, il y a le cadre humain et les projets
professionnels qu'on aimerait avoir, plutôt que d'être un mercenaire
lambda dans une case.

Personnellement, j'ai eu des bons moments et des périodes difficiles
dans mes expériences, j'ai changé de boîte quand je n'avais plus la
flamme, parce que j'ai besoin de ça pour être bien dans mon boulot et
que ça compte pour moi. Quitte parfois à être moins bien payé le temps
de faire mes preuves. Qu'importe, je suis heureux de mon parcours, pas
forcément le meilleur plan de carrière au niveau valorisation, mais
celui qui me permet d'avoir le sourire au boulot comme à la maison et de
vivre de ce que je peux toujours appeler "ma passion".

On peut avoir une vision "cynique" ou une vision "naïve" des chose. Au
final l'important c'est de se sentir bien et que tout le monde y gagne
en restant lucide sur la réalité.

My 2 cents,

Frédéric


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


[FRnOG] [TECH] Problème de disparition de conf sur Cisco 3560G après panne électrique

2017-02-27 Par sujet Frederic Dhieux

Hello,

Ce matin j'ai quelques baies qui sont tombées électriquement (c'est la 
vie). Mais par contre chose très surprenante, mes deux 3560G en tête de 
baie ne sont pas revenus avec le courant bien qu'ils aient booté. Après 
quelques échanges avec le support du DC (un peu occupé par l'événement) 
et le déplacement d'un tech sur place, on a finalement constaté la même 
panne sur les deux 3560G :


Reset complet de la conf, plus de config.text, plus de 
private-config.text, vlan.dat remis à zéro sur la flash.


Alors bien sûr si un mec me disait ça l'instinct me dirait que la conf 
n'a pas été enregistrée, mais ces 3560G sont là depuis plus de 4 ans, 
ils ont eu de multiples reload d'upgrade d'OS, la conf est bien 
récupérée entièrement par rancid (la conf enregistrée, pas la running) 
et j'ai bien la belle trace de mon "dir flash:" tout rempli dans le même 
log rancid.


La question étant : Est-ce que ça vous est déjà arrivé sur ce type 
d'équipement ? Parce que le même problème sur 2 équipements en même 
temps de voir disparaître sa conf sur une panne électrique, j'avoue ça 
me sidère un peu quand même niveau probabilité.


Ca tourne sur du 15.0 dernière version depuis un moment, pas de manip 
depuis un moment non plus, tout était clean sans rien en pending...


Un bon lundi de merde sous la bénédiction de Saint Murphy quoi :)

Fred



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


Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

2016-10-03 Par sujet Frederic Dhieux
Hello,


Le 03/10/16 à 13:21, Pierre Colombier a écrit :
> Le problème avec IPV6, c'est surtout les mauvaises habitudes prises
> avec le nat depuis 15 ans.
>

Pour moi c'est surtout un problème de cible et de motivation. Ce qui me
semble être négligé, ce sont les différents niveaux sur lesquels il faut
travailler la question et leur motivation.

Favoriser les site IPv6 dans le référencement ferait faire un bond dans
le déploiement d'IPv6 en 6 mois déjà, donner un équivalent du CIR
(l'ARCEP si tu nous lis) aux sociétés qui sont IPv6 motiverait également
la démarche en France, avoir des discounts sur les prix des services
réseaux IPv6 (IXP, transit, etc) serait un autre point. Avoir tous les
FAI en IPv6, c'est une étape qu'on a longtemps attendu mais on y arrive.
Ca va jouer un rôle je pense, même si on ne verra pas un chamboulement
du jour au lendemain. Et pourquoi pas des peering policy plus souple
pour IPv6 ?

La complexité technique est différente selon les boîtes (sécu, presta,
historique, etc) et certains semblent oublier que toutes les structures
n'ont pas la même inertie, mais je ne pense pas que le plus gros frein
soit là au final (surtout depuis le temps que ça dure). C'est toujours
pareil, dans une société il y a une quantité d'efforts pour mener X
projets à bien. Après c'est un problème de charge, de priorités, de
motivation et de moyens. La motivation dans les équipes techniques ne me
semblent pas être le plus gros frein au final (pour les compétences, ça
n'est pas pire que sur d'autres sujets).

Il n'y a bien que pour les gens du réseau que le passage à IPv6 est une
évidence et c'est bien là le plus gros problème je pense. Je pense que
beaucoup d'admins se sentent un peu seuls quand il s'agit de pousser
IPv6 en interne.

> Le réseau d'entreprise "tout ouvert derrière une box qui fait nat" en
> IPv6, c'est le carnage...
>

Bien que ça me fasse vomir, saigner de partout, je préfère encore voir
une boîte mettre une IPv6 en frontal avec un NAT interne derrière que
rien du tout. C'est moche, ça me donne envie de baffer très fort, mais
si ça aide à changer les mentalités pour qu'un jour un mec de son côté
en regardant "Internet" se dise "merde tout le monde est en IPv6 et je
fais pas sérieux à pas l'avoir", bah amenez les bassines.

Frederic


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


Re: [FRnOG] Re: [TECH] "vous n'avez qu'à activer ipv6"

2016-02-28 Par sujet Frederic Dhieux



Le 28/02/2016 00:13, christophe.casale...@digital-network.net a écrit :

Ah, je faisais partie du groupe de travail IPng à l'époque

Je sais. Et j'espère que tu t'autoflagelles tous les jours pour ce crime.


Euh, je demande des précisions : si on ajoute des octets aux adresses
IPv4, sans rien toucher d'autre, on casse la compatibilité sur le

"sans rien toucher d'autre". Et là on l'a peut être pas bouzillé la
compatibilité des applis et du réseau ? La compatibilité et surtout
l'acceptation d'IPv6 aurait été bien supérieure si on avait évité de
pondre des adresses en hexa qui ramènent certains au temps où ils
utilisaient pctools sous msdos...


Ca aurait prolongé l'histoire de peu, ça aurait fini par faire des 
champs IP de 3 km et de toute manière le problème n'aurait pas vraiment 
changé puisqu'il aurait de toute manière fallu réécrire tout le code 
pour gérer le surplus. Parce qu'un routeur tout vieux tout pourri il 
traite sa table avec des espaces mémoires adaptés à IPv4 mais c'est pas 
non plus optimisé pour une extension. Les applis auraient eu des pbm 
aussi, les bases de données idem.



Le problème n'était pas de réecrire les piles TCP/IP des OS : c'est un
problème de communication et d'intégration :  rajouter quelques octets
permettait de conserver l'intégralité de l'adressage actuel les adresses
devenant 000.000.192.168.0.10, etc. Seulement les technobienpensants de
l'époque ont cru qu'il suffirait de crier au loup pour obliger les gens à
migrer massivement sous IPv6, et ça n'a pas marché.


C'est facile de toujours critiquer, faut juste bien se dire que dans 
tous les cas ré-adresser toute la pile du routeur à l'appli software, 
c'est énorme, qu'il y a naturellement de toute manière au moins 10 ans 
de délai normal à ce que le cycle des éléments en jeu soit à jour.


L'échec c'est que personne ne s'y est mis pour que 10 ans plus tard ce 
soit opérationnel, qu'il a fallu 5-10 ans pour que les équipements le 
gèrent, qu'après il a fallu 5 ans pour que les opérateurs s'y collent, 
que maintenant il va falloir 5-10 ans pour que les sysadmin l'intègrent 
et qu'on a pas encore vu la génération de devs qui va le supporter dans 
les softs si on généralise basiquement. Mais bon si un mec a pas 
l'environnement pour avancer, il ne s'y met pas, c'est un peu naturel aussi.



Enfin au final, IPv6 est un échec cuisant et ça *personne* ne peut le
contester (il n'y a qu'à voir le temps d'adoption prévu à l'origine, et la
réalité ou encore le FUD lancé en 2011 avec la "dernière adresse IP
disponible attribuée"...) J'avais déjà dit à ce moment là ou certains
m'ont "affectueusement" baptisé "Le Claude Allègre d'IP" que rien ne
changerait en 2012, ni en 2013, pas plus qu'en 2014. On est en 2016 et
l'essentiel du réseau tourne toujours en IPv4. Personne n'est mort,
Internet n'a pas arrêté de fonctionné...


On est dans la bidouille, de plus en plus de bidouille pour 
artificiellement prolonger la durée de vie d'IPv4 le temps qu'IPv6 
arrive. C'est assez facile de dire que c'est la faute à ci ou à ça, que 
c'est mal foutu, le problème de fond c'est la nature humaine qui veut 
que tant qu'on est pas au bord du précipice, on ne s'active pas à 
solutionner le problème si d'autres problème à plus court terme sont là 
(et il y en a toujours).



Au lieu de trop se regarder le nombril, trop "d'experts" oublient qu'il
faut également penser aux hommes et aux femmes qui sont derrière les
machines, car au final, le réseau, ce sont eux qui le font, et qui
décident vraiment de sa transformation, la preuve.


Tout changement majeur implique des contraintes et des problèmes de ce 
genre, là c'est un changement énorme. Faut peut-être arrêter 2 minutes 
aussi de toujours partir dans le drame à ce sujet, et dire c'est de la 
merde ou c'est mal fait ou autre. Un mec m'a dit un jour "ça fait chier 
IPv6, on va se retaper toutes les merdes d'IPv4 au début". Je pense que 
ça résume bien les choses : Oui il y a des bugs à se taper le temps que 
ce soit sec parce que pas encore assez de monde l'utilise (c'est un 
cercle vicieux), oui on va se taper des problèmes, mais à un moment 
faudra avancer parce que tout est comme ça dans l'informatique.


Manque pas grand chose, c'est pas un problème de comment c'est foutu, 
c'est un problème motivation des sociétés et un manque de formation des 
gens (qui existerait quelque soit le changement). Parce qu'aujourd'hui 
mettre IPv6, c'est perdre du temps, ça n'apporte rien à la société et 
c'est un risque d'avoir des problèmes sur la prod à un moment lors de la 
mise en place.


Après on y arrivera un jour, quand tous les FAI et les gros FDC seront 
passés à IPv6, ça commencera à faire réfléchir tous les autres à la 
nécessité d'y passer pour le futur. En attendant les gens qui ont besoin 
d'IPv4 serrent les dents, et ils vont les serrer encore un moment parce 
qu'il va falloir un moment avant d'avoir "optimisé" tout l'espace IPv4 
(acheté, réduit, nat-beurk-é, etc).


Bref, niveau 

Re: [FRnOG] Re: [TECH] "vous n'avez qu'à activer ipv6"

2016-02-28 Par sujet Frederic Dhieux

Hello,

Le 27/02/2016 23:17, Nicolas Parpandet a écrit :


Tout est possible ;), (je parle pas propreté ni architecture hein, juste de 
faisabilité !)
en réaffectant le champs TOS/DSCP par exemple (dont la fonction à déjà été 
modifiée par le passé),
  et pan 1 octet de gagné, on multiplie par 16 les ips mondiales disponibles ;),
sans parler de la possibilité d'utiliser les options également. Après en tant 
que fan d'ipv6 j'aurai jamais défendu une telle horreur,
mais cela aurait certainement été faisable !


Toujours plus de bidouille pour prolonger IPv4...

Frederic


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux


Le 19/02/2016 23:10, Alarig Le Lay a écrit :
À quoi bon faire de l’IPv6 si c’est pour mettre un NAT derrière ? À ce 
rythme, autant rester sur de l’IPv4, au moins tout le monde connait. 


Par non égoïsme pour que les choses avancent côté mise en place publique 
à défaut d'avancer en interne ?


Sachant que le problème de base est de pouvoir un jour aller sur 
Internet sans nécessiter d'IPv4, plus qu'avoir IPv6 jusqu'au fin fond du 
coeur des infras.


C'est moche mais bon comme on n'avance pas en faisant propre...


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux



Le 19/02/2016 18:43, Nicolas DEFFAYET a écrit :

On Fri, 2016-02-19 at 17:29 +0100, Frederic Dhieux wrote:

Bonjour,


Je ne comprends toujours pas qu'en 10 ans qu'on prévoit la pénurie,
aucun effort n'ait été fait pour préparer la possibilité d'utiliser
240.0.0.0/4 un jour. On se retrouve à réfléchir à des trucs compliqués
alors qu'un bloc "RESERVED Future use" d'il y a 27 ans ne sera jamais
exploité.

240.0.0.0/4 n'est pas utilisable sur beaucoup d'équipements et de
logiciels car ces derniers ne reconnaissent pas 240.0.0.0/4 comme un
adressage unicast valide.


C'est bien pour ça que je parle de 10 années en arrière et pas 
d'aujourd'hui. 10 ans ça commence à faire assez de temps pour envisager 
qu'on peut oublier ce qu'il y a avant. On est en plein dedans 
actuellement sur les certificats SSL avec SSLv3, RC4 & co pour les 
navigateurs.





Pourquoi pas les DNS root pour commencer ? En éteindre au fur et à
mesure en IPv4 et fermer le dernier à une date raisonnable d'ici 3 à 5
ans ? Pourquoi ne pas ralentir les performances d'IPv4 en aillant une
latence légèrement dégradée vers ceux ci dans le temps ? (même si c'est
pas très beau, disons moins geo-multiplier ces serveurs en IPv4)

Réduire les performances d'IPv4 est impossible, cela va à l'encontre des
SLA des opérateurs.


C'est bien pour ça que je parle de DNS root et non de dégrader le 
service chez les opérateurs eux même, qui eux aussi sont drivés par le 
business (de leurs clients)



Peut-être des tutos massivement diffusés aux sites webs déjà aiderait
aussi sur la manière de mettre une couche IPv6 publique facilement sans
tout changer.

Ce n'est pas un problème de tutos mais de support de l'IPv6 correct dans
les équipements et logiciels.


Je ne suis plus d'accord avec cet argument pour les équipements, il a 
été vrai pendant longtemps, mais maintenant ce n'est plus autant le cas. 
Le problème est maintenant plus sur la couche logicielle et les 
développeurs sont souvent complètement à l'ouest sur le sujet.


Qu'un admin puisse mettre en place des briques permettant d'intégrer une 
plateforme logicielle IPv4 dans un environnement IPv6 reste possible 
dans pas mal de cas du web classique, même s'il reste le gros problème 
des solutions client/serveur proprios (mais ça sera pas la majorité des 
gens du web ça).


Après faudra éduquer les devs, ça prendra encore une bonne génération, 
mais d'un point de vue admin c'est aujourd'hui souvent possible.



Nous les opérateurs on est sensibilisés à tout ça, mais est-ce que ça
touche autant les sites finaux hébergés ce problème ? Parce qu'eux ils
n'y pensent pas trop et leur seul problème c'est de pas perdre du temps
sur ce qui ne rapporte pas de l'argent.

Received: from m.syn.fr (m.syn.fr [195.154.64.190]) by
cabale.usenet-fr.net (Postfix) with ESMTP id 5801798A5949 for
<frnog@frnog.org>; Fri, 19 Feb 2016 17:31:16 +0100 (CET)
Ton mail a été reçu en IPv4 ;)

Ce n'est pas qu'une question de sensibilisation, énormément de personnes
sont sensibilisées mais très peu déploie l'IPv6 en pratique.


Hé le tiens aussi ! Tiens on va faire comme si on était exemplaires, on 
se répond en IPv6 la semaine prochaine ? :)


Je ne sais pas trop qui tu fréquentes dans le monde des sites webs, mais 
de mon côté à chaque fois que je croise un mec qui dev en PHP (par 
exemple, remplace par le langage à la mode qui te plaira le plus), il me 
dit : "ah oui ça a l'air sympa mais je sais pas comment ça marche, ma DB 
le gère pas, c'est la galère si je dois changer".


Autant les admins sont assez chauds pour s'y coller quand tu les 
motives, autant les devs ils tirent bien la gueule à l'idée de faire 
rentrer des adresses dans un autre format différent et de taille bien 
plus longue et tu les sens perdus quand tu leur dit qu'il va falloir 
manipuler des IPv6.


Pour le reste on en revient au problème de départ : Pas d'intérêt 
business, bas de la pile des projets.


Et pour les équipements, pas forcément besoin de tout avoir compatible 
IPv6 pour s'en sortir, pas besoin de tout transformer. Si déjà au départ 
les gens géraient la partie frontale publique, ça suffirait. Après tout 
y'a des gens qui font plein de NAT, c'est pas bcp moins propre d'avoir 
une IPv6 frontale et une plateforme IPv4 derrière et au moins on avance.


Bref pour moi IPv6 au niveau technique pure a besoin de passer plusieurs 
étapes pour s'imposer, pour moi la partie réseau opérateur et 
équipements est quasi accomplie, le plus gros frein reste la partie 
logicielle. J'aimerais bien un retour de profs en université ou école 
aussi pour savoir à quel point IPv6 est enseigné dans les cours, pas en 
cours réseau, mais dans les autres cours.


Frederic


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux

Salut,

C'est même juste impossible. Toutes les boîtes n'ont pas du LAMP ou 
techno moderne pour leurs services, parfois c'est des boites noires non 
prévues pour évoluer. Et faire un NAT peut ne pas fonctionner si c'est 
le même problème (surtout) côté postes clients.


Libérer un /8 ne changera pas non plus la face du monde, en tout cas ça 
ne fera que reporter le problème un tout petit peu plus loin.


Déjà ce serait bien que tout acheteur ou nouvel opérateur acquérant de 
l'IPv4 présente une plateforme IPv6 ready (minimum préfixes, DNS, site 
web fonctionnel en IPv6) avant d'avoir droit à des IPv4. Ensuite l'idée 
de favoriser IPv6 dans les moteurs de recherche est clairement un vrai 
accélérateur business de l'implémentation IPv6. Si Google fait ça, en 1 
an tous les sites importants sont IPv6 facile.


Je ne comprends toujours pas qu'en 10 ans qu'on prévoit la pénurie, 
aucun effort n'ait été fait pour préparer la possibilité d'utiliser 
240.0.0.0/4 un jour. On se retrouve à réfléchir à des trucs compliqués 
alors qu'un bloc "RESERVED Future use" d'il y a 27 ans ne sera jamais 
exploité.


Egalement ça serait bien un jour de mettre une vraie deadline 
raisonnable mais réelle pour IPv4 et que quelques éléments clés 
d'Internet coupent d'ici cette date.


Pourquoi pas les DNS root pour commencer ? En éteindre au fur et à 
mesure en IPv4 et fermer le dernier à une date raisonnable d'ici 3 à 5 
ans ? Pourquoi ne pas ralentir les performances d'IPv4 en aillant une 
latence légèrement dégradée vers ceux ci dans le temps ? (même si c'est 
pas très beau, disons moins geo-multiplier ces serveurs en IPv4)


A un moment de toute manière il va falloir motiver les gens autrement 
que par des belles paroles, si leur business n'est pas en jeu, ils ne 
bougeront pas. Pour certains ça semble un travail de fou alors qu'on 
parle de mettre au pire un reverse proxy web, des dns et du mail en IPv6 
sur une plateforme IPv4.


Peut-être des tutos massivement diffusés aux sites webs déjà aiderait 
aussi sur la manière de mettre une couche IPv6 publique facilement sans 
tout changer.


Nous les opérateurs on est sensibilisés à tout ça, mais est-ce que ça 
touche autant les sites finaux hébergés ce problème ? Parce qu'eux ils 
n'y pensent pas trop et leur seul problème c'est de pas perdre du temps 
sur ce qui ne rapporte pas de l'argent.


My 2 cents,
Frederic


Le 19/02/2016 16:41, Yann Pretot a écrit :

Salut,



Je ne pense pas qu'on puisse se permettre de couper totalement IPv4 aussi 
rapidement, 2 semaines, c'est clairement insuffisant pour migrer.

Si la plupart (je l'espère) des FAI peuvent déployer rapidement, certains doivent avoir 
des obstacles et contraintes, je pense à du matériel vieillissant chez l'abonné, à une 
architecture qui ne s'y prête pas vraiment... Madame Michu aura des problèmes de toute 
sorte avec "son Internet" qu'il va falloir solutionner, cela prendra du temps.

Tous les abonnés ont des installations différentes, qu'il faut prendre en compte, et qui, 
si rien n'est fait, empêcheront le tout de fonctionner (un exemple tout bête : le fils 
gamer qui a acheté un routeur chez Carrefour pour que sa XBOX "ait un meilleur 
ping").

Il ne faut pas non plus un déploiement à la va-vite qu'on ne peut plus toucher 
après, il faudrait trouver un moyen plus doux, qui forcerait tout le monde à se 
préparer, pas à déployer dans la douleur.



Rome ne s'est pas faite en un jour, le passage global à IPv6 ne se fera pas en 
deux semaines ;)



Yann PRETOT

Association Oxid Telecom





 On ven., 19 févr. 2016 16:24:43 +0100 Josselin Lecocq 
josselin.lec...@quantic-telecom.netwrote 




Salut la liste,

  


Et si au lieu de discuter des soins palliatifs à apporter à l'IPv4

mourant on arrêtait l'acharnement thérapeutique ?

  


Est-ce qu'un IPv6 flag day, sans retour, serait vraiment si impossible

que ça ? Si demain Google, Facebook, Netflix et une poignée de FAI

décidaient de couper l'IPv4, je pense qu'en moins de 2 semaines tout le

monde migrerait vers IPv6, dans la douleur certes, mais qu'importe.

  


Mais peut-être suis-je trop naïf... Quoi qu'il en soit, je trouve que

c'est un bon sujet de discussion pour un vendredi.

  

  


Josselin Lecocq

Quantic Telecom

  

  


Le 19/02/2016 16:14, Jérôme Nicolle a écrit :

 Salut Pierre,



 Le 19/02/2016 14:39, Pierre Colombier a écrit :

 Il me semble probable que les escrocs/rentiers dont tu parles gagnent

 leur combat d'arrière garde mais qu'ils ne feront que précipiter

 l'abandon de leur "ressource rare".



 Je crois que c'est bien là le problème : on a une tendance naturelle, et

 tout à fait défendable, à nous laisser aller doucement vers une voie de

 garage, tout simplement parce qu'on ne prends pas le temps de défendre

 nos positions.



 On est tous sur la brèche dès lors que notre présence est fragilisée,

 c'est à dire qu'on est plus en mesure d'obtenir les ressources dont on a

 besoin pour exister.



 Si le marché devient 

Re: [FRnOG] [TECH] Vraie IP et fausse IP ?

2016-02-17 Par sujet Frederic Dhieux

Hello,

En parlant de notre cher gouvernement, si en bonus (à la place sur 
certains cas) du crédit impôt recherche qui sert à récupérer un peu de 
ses impôts généreusement donnés à l'état ils donnaient une "prime" aux 
sociétés françaises ayant déployé IPv6, en même temps que les moteurs de 
recherche favoriseraient les sites en IPv6 (très bonne idée ça), le 
projet IPv6 en bas de la pile qui prend la poussière face à toutes les 
priorités business avancerait peut-être un peu plus côté fournisseurs de 
contenu.


Tant qu'à verser des sous aux entreprises pour les aider sur leur "R", 
autant que ça soit sur des choses vraiment utiles à tout le monde.


Sinon la pratique de free... Au début Ils ont fait le choix de donner 
une IP par abonné en fixe, de faire du peering ouvert pour avoir une 
bonne qualité de service, maintenant ils saturent leur réseau, font 
payer cher le peering et mutualisent leurs IPv4. Après si les gens 
considèrent toujours Free comme le sauveur parce qu'ils n'ont pas à 
subir quelques Euros de plus à payer chaque mois pour maintenir la 
qualité du service, à un moment effectivement pourquoi s'embêter... (la 
fierté d'avoir un truc propre ne doit plus trop être un objectif de 
free, juste avoir plus d'abonnés lors de la publication des résultats et 
pour ça le marketing et les ventes privées semblent suffire)


Frederic

Le 17/02/2016 11:10, Jérôme BERTHIER a écrit :

Bonjour,

Le 16/02/2016 11:52, Xavier Beaudouin a écrit :
ou le trucs comme les impôts par ex pouvaient au moins avoir un 
service dispo en IPv6


ça fait juste 5 ans que toutes les administrations y ont été 
explicitement invitées :

http://circulaires.legifrance.gouv.fr/pdf/2011/12/cir_34250.pdf

Bon faudrait peut être passer à la phase obligation. :-\
Voilà, voilà...




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


Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

2015-10-08 Par sujet Frederic Dhieux


Le 08/10/15 17:24, Raphael Mazelier a écrit :
>
>  
>
> Tu viens de pointer le problème. Tu recherche de la souplesse et un
> opérateur/hébergeur présent world-wide, donc gros. C'est à priori
> antinomique mais je me trompe peut être, et il existe peut être la
> perle rare.
>
> Cdt,

Ah bah c'est le challenge, sinon je poserais pas la question ici ;)
(sait-on jamais, même des idées qui seraient bonnes à prendre)


Le 08/10/15 17:29, David Ponzone a écrit :
> Tu peux essayer BSO.
> Ils ont de la présence sur au moins 3 des 5 lieux que tu veux.
>
>

Yep, je connais bien. Ils ont presque l'emprunte suffisante et la
souplesse pour le proposer c'est vrai, après je pense qu'ils ne
conviendront pas forcément tout de même (capacité sur certains points,
support local en cas de pbm). C'est un peu en pensant à eux que je me
suis dit que c'était peut être jouable.

Après sinon prendre du hosting pur à chaque endroit et prendre du Level
3 en direct sur chaque PoP, mais ça va me coûter cher en cross connects,
logistique, gestion administrative et non bundleisé.

Frédéric


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


Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

2015-10-08 Par sujet Frederic Dhieux
Hello,

Merci pour ces premiers retours, de ce que je vois Liazo ne sort pas
vraiment de l'Europe de l'ouest et Zayo n'est pas vraiment présent sur
le continent asiatique ou en ME. Vu l'emprunte à couvrir un des 3 tier-1
serait plus simple mais ils sont en général moins souples également sur
ce qu'ils vendent.

Frédéric

Le 08/10/15 17:04, Sylvain sbu a écrit :
> Bonjour
> De mémoire ; je crois que liazo c est faire. Ex Neo.
> Pour le denier point il faut voir avec eux. Mais ça m étonnerait
> Bon courage.
> Sbu


Le 08/10/15 17:05, Arnaud Launay a écrit :
> Le Thu, Oct 08, 2015 at 05:04:08PM +0200, Sylvain sbu a écrit:
>> De mémoire ; je crois que liazo c est faire. Ex Neo.
> Heu ? Zayo non ? :)
>
> Ou alors il s'est passé des trucs :-D
>
>   Arnaud.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Ip d'interco bgp

2015-09-14 Par sujet Frederic Dhieux



Le 14/09/2015 22:12, Raphael Mazelier a écrit :



J'ai pas dit que cela devait être forcement le cas en nominal, certain 
le font (jaguar de souvenir), d'autre (moi le premier) non. En 
revanche avoir un /24 en stock qui peut servir en cas de besoin, et le 
dédier temporairement à tel ou tel besoin c'est quand même bien 
pratique. (surtout quand il s'agit de dépanner un client).




C'est moche et ça va faire râler du monde, mais au pire dans l'urgence 
de la situation prendre un subnet d'interco dans RFC1918 c'est peut-être 
un moindre mal le temps de trouver une solution plus propre et pérenne.


Frédéric


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


Re: [FRnOG] [TECH] Contact free VoIP

2015-07-30 Par sujet Frederic Dhieux

Hello,

Y'a un mec qui passe de temps en temps, pas trop mal placé je crois, il 
s'appelle Xavier Niel. Avec un peu de chance il répondra un soir :D


Frédéric

Le 30/07/2015 15:47, Oceanet - Cédric BASSAGET a écrit :
Ce que mon opérateur m'a toujours dit : c'est a l'appelant qui 
n'arrive pas a joindre un numéro de contacter son fournisseur. Ce que 
j'ai fait.
Mon opérateur (entrant) ne voit pas l'appel arriver sur sa plateforme, 
donc ils ne peuvent pas faire grand chose...


Personne de chez free sur cette ML ...?

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

On 30/07/2015 15:26, David Ponzone wrote:
La démarche est la même: c'est un problème de routage entre 2 OP qui 
ont une interconnexion avec Orange. Ils doivent se parler directement.


David Ponzone



Le 30 juil. 2015 à 15:21, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Ce n'est pas un numéro porté, c'est un numéro d'une tranche 
attribuée par l'arcep.

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 15:09, David Ponzone wrote:
Le plus simple c’est de remonter le problème à ton opérateur (celui 
qui a porté les numéros) et lui demander de remonter un problème de 
porta.


Le 30 juil. 2015 à 14:33, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :



Ca marche depuis partout sauf depuis le fax free
Pas d'escalade possible selon la hotline, le fax, personne s'en 
sert, ça impacte pas assez de monde pour qu'on s'y intéresse...


OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 14:17, David Ponzone wrote:
Si tu appelles la SDA depuis une ligne voix Free, ça marche ?
Et depuis un autre alternatif qui utilise l’APNF ?

Si tu as des échecs aussi, c’est que c’est ta SDA portée qui 
n’est pas déclarée correctement à l’APNF.



Le 30 juil. 2015 à 14:15, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Le fax sortant free ne marche pas vers la SDA en question
Si j'envoie un fax vers un autre numéro, ça fonctionne
Si j'appelle la SDA depuis une ligne témoin la SDA fonctionne.

En gros elle ne marche pas depuis le fax free, mais pas de 
problème depuis ailleurs.

Je ne peux pas tester le fax entrant pour l'instant.

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 14:10, David Ponzone wrote:
C’est le sortant de Free qui ne marche pas ?
Si tu envoies un fax vers ton num de portable par exemple, tu 
reçois l’appel  ?
Et l’entrant vers ta SDA fax Free (dans l’autre sens donc) 
marche de manière parfaite ?



Le 30 juil. 2015 à 13:55, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Bonjour,
Après avoir passé 30 minutes au tel avec le 3244 et avoir eu 
comme résultat à mon problème votre cas est isolé, du coup on 
ne fera rien pour corriger votre problème, et en plus le fax 
est utilisé par très peu de gens..., je suis à la recherche 
d'un contact chez free qui pourrait m'aider a corriger un 
problème de routage de SDA pour de l'envoi de fax.
La SDA fonctionne bien depuis divers lignes témoin (orange, 
sfr, même free mobile !) mais impossible d'envoyer un fax 
dessus depuis l'interface free (l'appel n'arrive pas chez nous).


Merci pour vos retours en MP.
Cédric


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



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



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


Re: [FRnOG] [ALERT] OVH down ?

2015-07-29 Par sujet Frederic Dhieux


Le 29/07/15 16:23, Gaëtan Allart a écrit :
 Sans vouloir troller, on ne peut pas mettre sa production sur un hébergeur 
 low-cost et ne pas tolérer quelques minutes d’indisponibilité.

 Gaëtan

Hello,

Je ne peux qu'être d'accord, c'est un choix conscient et il faut
l'assumer. Je ne comprends pas qu'on puisse autant se scandaliser pour
un service low cost, les gens veulent toujours le beurre et l'argent du
beurre.

Tout a un prix, souvent lié à celui que le client paye (surtout à ce
qu'il ne paye pas en fait).

Frédéric


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


Re: [FRnOG] [ALERT] OVH down ?

2015-07-29 Par sujet Frederic Dhieux



Le 29/07/2015 18:33, Olivier Varenne a écrit :

Mouais.

Sans vouloir prendre la défense d'OVH, ils sont quand même honnêtes et avoue 
que l'erreur vient d'un problème humain
Combien de boites se seraient retranchées dans un silence complet voir auraient 
accusé le voisin pour ne pas subir les foudres des clients ?


Ne nous méprenons pas, je ne critique pas OVH en disant que c'est du low 
cost, ils font très bien leur métier pour ce qu'ils proposent et le 
rapport qualité/prix est plutôt bon. On peut aussi dire de même pour 
Online dont le service est très bon par rapport au prix.


Et OVH a souvent fait preuve d'une certaine transparence appréciable 
quand ils font des erreurs.


C'est surtout les clients qui se scandalisent alors qu'ils payent une 
misère tous les mois pour plein de services que je critique :)


Frédéric


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


Re: [FRnOG] [ALERT] Banques CIC et CM HS ?

2015-07-20 Par sujet Frederic Dhieux

Hello,

Attention, une partie du /16 est annoncée par Neustar, dont les NS (en 
/24) et le site lui même (dans une autre /24), ils semblent avoir un 
service via Neustar DNS + protection DDoS donc.


145.226.0.0/18 -  AS8255
145.226.64.0/18 - AS8255
145.226.128.0/18 -  AS8255
145.226.30.0/24 - AS19905 (un des NS)
145.226.45.0/24 - AS19905 (le site www)

Fred

Le 20/07/2015 16:33, Pierre DOLIDON a écrit :

Ah oui, j'ai pas pensé a vérifier Twitter.

j'ai l'impression que c'est carrément 145.226.0.0/16 qui n'est pas 
joignable en fait.




Le 20/07/2015 16:31, Clement Cavadore a écrit :

Problème DNS généralisé chez Euro-Information.
J'y ai aussi droit chez moi:
https://twitter.com/acontios_net/status/623117726840713216

Clément Cavadore

On Mon, 2015-07-20 at 16:29 +0200, Pierre DOLIDON wrote:

Bonjour

ce n'est que moi ou,

http://creditmutuel.fr/ : HS
https://www.cmcicpaiement.fr/ : HS
https://www.cmcicpaiement.fr/ : HS

et donc par extension les serveurs de paiement des TPE électroniques
https://ssl.paiement.cic-banques.fr/paiement.cgi : HS aussi


any news ?

a priori ils auraient planifié une mise a jour chez eux (dixit l'un de
mes clients)
et le standard téléphonique desdites banques a explosé...

Pierre.



---
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] A deux qui ont une petite salle ...

2015-06-30 Par sujet Frederic Dhieux
C'est pour ça qu'on met des sprinklers dans les salles serveurs
d'ailleurs, c'est pour les rafraichir l'été, CQFD.

Sinon tant qu'on est dans les bidouilles, il parait que la bière est une
bonne manière de combattre la chaleur :
http://www.ina.fr/video/RCC9712053545/la-canicule-et-la-biere-video.html

Frederic

Le 30/06/15 14:43, Jeremy a écrit :
 Il fait déjà chaud ici ^^

 Le 30/06/2015 14:39, Bensay 1 a écrit :
 En effet à deux c'est toujours mieux :)

 A+

 Benjamin L

 Le 30 juin 2015 à 14:38, Frédéric GANDER fgan...@corp.free.fr a
 écrit :



 - Mail original -
 De: Jeremy li...@freeheberg.com
 À: frnog-tech frnog-t...@frnog.org
 Envoyé: Mardi 30 Juin 2015 14:28:12
 Objet: [FRnOG] [TECH] A deux qui ont une petite salle ...

 Bonjour,

 Demain, il fera plus de 35°c à l'ombre sur presque tout le pays. Les
 gros datacenter ne sont que très rarement impactés par ces
 températures
 extrêmes.
 oui ils ont déjà investit dans :
 http://www.gardena.com/fr/gestion-eau/arrosage-enterre/

 ;)

 A+


 ---
 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] Cisco Nexus Leap second

2015-06-30 Par sujet Frederic Dhieux
Hello,

Le 30/06/15 15:44, Jérôme BERTHIER a écrit :
 Le 30/06/2015 15:38, Paillet Cedric a écrit :
 equipment 100% bloqué... pas de console (juste le msg d'erreur), pas
 de mgmt, tous ports giga down physiquement !
 Sans commentaire :-\

 Quel modèle ? Quel nx-os pour info ?


A priori particulièrement tout ce qui touche à la virtu et aux
environnement de ce style :

http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation


Frederic


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


Re: [FRnOG] [TECH] Open-Source Web-based IPAM

2015-06-29 Par sujet Frederic Dhieux
Hello,

Le 29/06/15 14:20, Raphael Mazelier a écrit :


 On utilise phpipam avec bonheur. Pas vu/eu de probleme avec.

Migré de GestioIP à phpIPam et c'est le jour et la nuit de notre côté.
Je dirais pas que c'est parfait, mais c'est un peu le bonheur
effectivement, interface propre et assez ergonomique.

Les faiblesses :
- Taux d'occupation relatif aux IPs déclarées, pas aux subnets assignés
- La preview de taux d'occupation met 3 plombes à se loader quand on a
des gros subnets
- Comme bcp d'autres softs de genre, l'IP de network et de broadcast
sont non utilisables, dommage quand on déclare un subnet en réalité
prévu pour de l'anycast ou une /31 d'interco.
- L’authentification peut se faire sur LDAP mais sur la version où
j'avais voulu tester le pass était facilement visible, donc ça n'a pas
été fait chez nous et on se tape un login commun de gestion et un login
commun d'admin.

Les points qui m'ont convaincu :
- Segementation possible en plusieurs sections pour gérer de l'interne
privé, publique, du client, de l'IPv6 à part, etc
- VRF / vlan plutôt bien gérés
- Formulaire avec un bouton de check de reverse DNS pour remplir
automatiquement le hostname d'une IP
- Base de données cohérente
- Esthétique
- Recherche efficace
- Droits utilisateurs entre admin et opérationnel
- URL copy/pastables au lieu du CGI moisi de GestioIP plus simple pour
envoyer entre admins
- Resize de subnet intégré à l'interface
- Bonne visibilité des trous entre les subnets dans un bloc (GestioIP
c'était juste impossible pour ça)
- Champs personnalisés (présent aussi sur GestioIP mais c'est plus
pratique à gérer sur phpipam)

Pour moi c'est un produit pas parfait mais qui remplit très bien son rôle.

Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-29 Par sujet Frederic Dhieux
Le 29/06/15 18:30, Damien Fleuriot a écrit :

 Quitte à jeter un pavé dans la marre, on peut se demander, légitimement, si
 IBM, HP, DEC, Ford, Daymler, Apple... ont vraiment besoin de /8s

Bien sûr que non, mais il est bien trop tard pour pleurer là dessus,
pour le cas d'IBM tout leur parc et leurs postes sont adressés avec
depuis des lustres. Il faut arrêter de pleurer sur des erreurs d'il y a
plus de 30 ans (3 ans avant la réservation de 10/8 pour l'usage privé).

C'est toujours plus facile de regarder derrière avec beaucoup de recul,
mais c'est devant que ça se passe.

Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-27 Par sujet Frederic Dhieux
Hello,

Alors pour donner un contexte plus précis, je pense plus à une démarche
interne dans une entreprise qu'à convaincre un client en jouant sa
crédibilité sur un timing impossible à estimer réellement. Egalement je
ne considère pas dans la manoeuvre remplacer IPv4 par IPv6 et mélanger
la communication entre les deux par un NAT tout aussi moche.

Pour moi la démarche c'est d'abord de configurer les briques en IPv4 ET
en IPv6 une par une et de pouvoir un jour se dire tiens la chaine est
complète, on peut utiliser le service en IPv6 quand on est en IPv6 sur
un autre end point

Jeune et con depuis un paquet d'années =) En tout cas pas blasé c'est
sûr. Plus concrètement, ça coûte tant que ça de configurer les 2 stacks
sur un équipement quand on l'installe de nos jours ? Je ne parle pas de
finaliser le projet et d'avoir ISO entre IPv4 et IPv6 ou de se
débarrasser d'IPv4, je parle juste de déployer de la connectivité IPv6
quand on déploie des nouveaux équipements/services pour petit à petit
compléter le puzzle.

L'exemple donné précédemment avec le routeur et le NAT, franchement à
lire les propos on dirait qu'il faut refaire toute l'archi du truc et
que c'est un projet énorme alors que ce n'est pas le cas.

Et quoi qu'on en dise, la pénurie IPv4 a accéléré un peu les choses ces
dernières années auprès d'opérateurs conséquents (aux US par exemple).
Donc en pratique IPv6 va exister de plus en plus mécaniquement. Il ne
faut pas rêver, IPv4 va perdurer pendant des lustres, mais un jour ça
deviendra compliqué de ne pas avoir d'IPv6 et ce sera beaucoup plus
chiant de tout reconfigurer d'un coup plutôt que d'avoir plus que
quelques briques à changer parce que le reste est déjà IPv6 ready.

My 2 cents,
Frederic

P.S. : Après c'est sûr, si j'étais un businessman qui lance une startup
avec une vision qui ne dépasse pas 18 mois, moi aussi j'en aurais rien à
faire.
Le 27/06/15 06:23, Michel Py a écrit :
 Frederic Dhieux a écrit :
 Est-ce qu'on est vraiment obligé à un moment de faire un truc
 batard entre v4 et v6 et de translater de l'un à l'autre ?
 Ben oui, puisque plus personne ne croie plus à IPv6 sera déployé l'année 
 prochaine et on pourra enlever le dual-stack dans 2 ou 3 ans. Le disque est 
 rayé.


 En tout cas ça ne coute pas grand chose de configurer IPv6 à côté d'IPv4 
 dans 95% des cas.
 Tu viens le faire gratos pour mes clients ?


 Je suis intéressé d'ailleurs par la raison qui te pousse à vouloir faire du 
 NAT entre les 2 du coup ?
 Pas moi. Les gens qui croient que IPv6 only avec NAT 466464 çà va remplacer 
 CGN.


 A ce moment là il ne faut jamais mettre à jour tant que ça tourne et il ne 
 faut jamais rien faire
 évoluer... C'est évident aussi qu'on colle pas direct le truc sur la prod la 
 plus sensible.
 A mon avis t'as pas encore pris assez de coups de pieds au cul à te battre 
 contre des moulins à vent.


 Mais je comprends qu'on puisse être fatigué de se battre pour un truc 
 pendant 15 ans oui.
 Ben justement je pense que t'es pas assez fatigué. Essaies de ne pas 
 m'expliquer comment être jeune et con. Je suis vieux et con.


 Il y a 15 ans IPv6 était un jouet pour faire mumuse, un monde à
 part qui n'était pas encore vraiment intégré au monde réel.
 Ah ouai ouai, et aujourd'hui IPv6 c'est un jouet pour faire mumuse, un monde 
 à part qui n'est pas encore vraiment intégré au monde réel.

 La différence, c'est que depuis 15 ans que j'entends des conneries qui 
 prédisent le déploiement imminent (une chanson que j'ai chanté moi-même) 
 maintenant si je vois pas l'élimination d'IPv4 en 3 ans je n'écoute plus le 
 même disque rayé.

 IPv6 avec 10 ou 15 ans de plus à se taper dual-stack, je reste à IPv4. Comme 
 tout le monde, à part ceux qui ont des milliards à ne pas savoir ou les 
 dépenser.

 Le déploiement d'IPv6, c'est un troll usé. Même un trolldi. Franchement, je 
 préférerais le retour de Christine Albanel ou de Michel Riguidel. Au moins, 
 c'étaient des trolls à qui tout le monde donnait des croquettes.

 Michel.


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



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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-26 Par sujet Frederic Dhieux


Le 26/06/15 14:52, Samuel Thibault a écrit :

 Et en v6, tu peux mettre en place la même infra, juste le NAT en moins
 (mais garder le firewall bien sûr). Il te faut un subnet séparé
 pour ton infra, bien sûr, tout comme tu as déjà un subnet séparé
 RFC1918. Je ne vois aucune difficulté de réflexion.

Pareil, je capte pas où est le chamboulement, mettre une intero v6
publique comme il y a l'IP publique v4 et mettre un subnet public routé
v6 à la place d'un subnet v4 RFC1918 et faire du routage firewallé au
lieu de faire du routage NATé (le NAT c'est un peu un routeur firewall
avec des règles de translation d'IP quand même à la base non ?)

Je suis en train de pleurer du sang à lire encore des histoires qui
mélangent NAT et sécurité pour justifier de garder une affreuse
rustine qu'est le NAT et de ne pas mettre IPv6.

En gros ce qui change entre IPv4 NAT et IPv6 :
- Le subnet interne derrière la boiboite est non translaté par le firewall
- Le blocage des ports entrants par défaut vers le subnet interne

On est loin d'un truc foufou... Après les mecs qui ont peur de ne pas
bien firewaller et qui préfèrent un boitier NAT parce que si c'est pas
bien configuré au moins rien ne fonctionne...

Frédéric


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-26 Par sujet Frederic Dhieux


Le 26/06/15 19:24, Michel Py a écrit :
 Moi ca fait 15 ans que j'ai commencé et pour l'instant j'ai perdu mon temps. 
 En plus, les arguments comme quoi IPv6 va éliminer NAT sont not seulement pas 
 étanches, mais carrément faux. Il y a plus de méthodes NAT pour V6 que pour 
 v4 : NAT46, NAT64, NAT464, NAT66, et j'en oublie. C'est 2 fois le travail et 
 3 fois les emmerdes. En plus de devoir administrer double stack, va donc 
 poser la question suivante au blaireau qui est au téléphone parce qu'il peut 
 pas accéder www.maboite.com : t'essaies d'accéder avec IPv4, ou avec IPv6 ?
 Euuuhhh


Est-ce qu'on est vraiment obligé à un moment de faire un truc batard
entre v4 et v6 et de translater de l'un à l'autre ? De mon côté j'ai pas
vraiment trouvé le besoin de faire des ponts entre 2 stacks qui arrivent
à vivre en parallèle. Après pour le debug c'est potentiellement plus
chiant, mais à ce jour désactiver IPv6 en cas de problème règle
rapidement et sans impact le point si on ne veut pas perdre de temps. En
tout cas ça ne coute pas grand chose de configurer IPv6 à côté d'IPv4
dans 95% des cas.

Je suis intéressé d'ailleurs par la raison qui te pousse à vouloir faire
du NAT entre les 2 du coup ?

 Damien Fleuriot a écrit :
 Concernant le fait que ce soit plus ou moins pénible que du v4,
 c'est tout bête : le v4 c'est déjà en place et maîtrisé ;)
 +1

C'est marrant de lire ça dans un domaine en perpétuelle évolution. C'est
un peu notre métier aussi d'appréhender les nouvelles technos et de les
mettre en place.
 +1 En plus, si quelque chose foire pendant que tu fais tes mises à
 jour, c'est forcément ta faute. Pourquoi t'es allé bidouiller sur le
 réseau de prod qui marchait bien avant que tu foutes tes mains dedans 

Fais moi penser à ne jamais envoyer un CV là où tu bosses :) A ce moment
là il ne faut jamais mettre à jour tant que ça tourne et il ne faut
jamais rien faire évoluer...

C'est évident aussi qu'on colle pas direct le truc sur la prod la plus
sensible.

Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-26 Par sujet Frederic Dhieux


Le 27/06/15 02:55, Michel Py a écrit :

 Quand tu auras perdu 15 ans de ta vie as essayer de faire marcher IPv6, on 
 pourra en reparler. Tu faisais quoi à propos d'IPv6, il y a 15 ans ? moi 
 j'étais sur le 6bone.

Il y a 15 ans IPv6 était un jouet pour faire mumuse, un monde à part qui
n'était pas encore vraiment intégré au monde réel. Les équipementiers
balbutiaient des fonctionnalités incomplètes et buggées, les IPv4 ne
manquaient pas réellement, c'était plus un truc d'universitaires
qu'autre chose même. Je me rappelle avoir pesté sur des équipements
réseaux BGP qui supportaient fièrement IPv6 mais pas BGP4.

Mais je comprends qu'on puisse être fatigué de se battre pour un truc
pendant 15 ans oui. Une pensée pour Nerim, Renater et d'autres au passage.

Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-26 Par sujet Frederic Dhieux


Le 26/06/15 15:21, Damien Fleuriot a écrit :



 En ce qui concerne remplacer des intercos v4 par des v6, c'est bien là
 le problème, il n'y en a pas des intercos v4 actuellement.

Ah bon ? Ton subnet d'IPv4 publiques c'est quoi ? C'est l'interco IPv4
vers ton bloc client privé IPv4.

 Quant au fait de mélanger le NAT et la sécurité, pas d'amalgame, à
 aucun moment je n'ai dit que le NAT était la seule solution.
 Néanmoins, affirmer que le NAT ne protège pas est une erreur.

Affirmer aveuglément que le NAT protège c'est une erreur.

 Certes il y a des alternatives -comme utiliser des intercos pour
 router des préfixes- , mais le NAT apporte, d'une manière différente,
 un mécanisme de protection des serveurs de backend.



Mais tu le fais déjà sans le savoir avec le NAT...

 J'ai l'impression que vous abordez tous le sujet du simple point de
 vue d'un admin réseau, qui veut des choses propres et carrées.
 Gardez à l'esprit qu'il faut composer avec l'existant et les
 contraintes du métier; en d'autres termes, on n'a pas toujours le choix.


On est bien sur FRnOG ? L'existant on en a tous et on bosse justement à
l'améliorer. La première chose c'est de maitriser l'existant et la cible
pour aller du point A au point B. Après il y a les contraintes, mais là
manifestement c'est pas vraiment une contrainte, c'est plus une
incompréhension je pense.

 Je peux vendre à mon employeur 15 jours homme pour tot remettre au
 propre dans les whatmille projets, ou 0 jours homme pour conserver
 l'existant mais pas d'IPv6.
 Vous pensez bien que la discussion va aller assez vite... et pas
 nécessairement dans mon sens.

On en revient à ce qu'on dit : Le problème n'est pas technique, le
problème c'est que les gens ont peur de se pencher sur le sujet, au
mieux estiment correctement que ça va prendre du temps, au pire estiment
que c'est un chantier titanesque (ce qui est faux niveau réseau et
système, ce qui peut être vrai niveau BDD et dev)

La réalité c'est qu'en réseau tu peux très facilement implémenter IPv6
en parallèle de ton existant sans impact et donc le faire 1h par ci 1h
par là pour te détendre et finalement arriver au bout d'un an à un
truc qui ressemble à quelque chose sans l'avoir passé comme un vrai
projet chronophage. Tout comme j'estime de mon côté que la bonne
démarche et de se dire qu'à chaque changement d'équipement ou
installation d'un nouveau service, il faut appliquer la mise en place
d'IPv6 dans le processus. C'est pris sur le temps de chaque projet sans
être trop pénalisant et ça ajoute petit à petit les pièces au puzzle.

Et un jour on finit par se rendre compte qu'on a quasiment toutes les
briques en place pour déployer un service IPv6 et que le projet IPv6 ne
semble plus aussi compliqué qu'on ne l'aurait cru.

Le plus gros problème au départ c'était les équipements réseaux,
aujourd'hui c'est de moins en moins le cas après de nombreuses années.
Il reste donc surtout la partie applicative qui freine, mais c'est en
aval du réseau et du système, donc non bloquant pour nous.

Ca prend du temps à diluer dans les différentes tâches, mais en quelques
années c'est possible et surtout c'est mieux que de dire trop
compliqué, trop long, on arrivera jamais à le faire passer et de
n'avoir rien commencé 5-10 ans plus tard.

My 2 cents.


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-26 Par sujet Frederic Dhieux


Le 26/06/15 15:13, Damien Fleuriot a écrit :

 Pour le contexte vis-à-vis de l'existant :

 [ router ] pub
   |
 [ FW ] pub + 1918
   |
 [ lb ] 1918
   |
 [ web ] 1918


 Ici router et FW sont dans la même /27, et sont les seuls à avoir des IPs
 publiques.
 LB et web ont des IPs RFC1918.

 Gardez bien en tête qu'il faut composer avec l'existant.

[ router ] interco 1 pub
  |
[ FW ] interco 2 pub (je comprends pas trop le role du routeur avant en fait) + 
subnet client IPv6
  |
[ lb ] subnet client IPv6
  |
[ web ] subnet client IPv6


Tu bloques les ports vers le subnet client en entrée sur le firewall qui
par ailleurs est tout autant un routeur qu'au moment où il faisait du NAT.

Pour moi translater des IPv4 via un NAT, c'est du routage, donc ça ne
change pas grand chose. C'est même plus simple. Au lieu d'avoir une
table de translation NAT on a une table d'états de firewalling.

Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-25 Par sujet Frederic Dhieux

Le 25/06/2015 11:21, Manu a écrit :


Non, y'a pas de cinglés d'IPV4. Désolé, mais la réalité est que non, 
ça n'est pas simple. IPV6 est (un peu) plus compliqué à comprendre 
qu'IPV4. Et l'un dans l'autre, on reste sur l'effort n'en vaut pas la 
chandelle (1).




Hello,

Autant dire que c'est compliqué pour migrer toutes les parties 
applicatives, faire des ALTER sur les bases, de changer du code 
historique et de gérer les 2 en parallèle je comprends, autant dire 
qu'IPv6 en lui même est compliqué je ne vois pas trop par rapport à tout 
ce qu'on apprend continuellement dans le monde IT.


Après c'est toujours le même problème derrière de fond : Personne veut 
consacrer des JH en quantité correcte pour y passer et ça passera 
toujours derrière tout ce qui est pour hier. Là dessus on est bien 
d'accord :)



Frederic


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


Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

2015-06-25 Par sujet Frederic Dhieux

Le 25/06/2015 11:53, Frédéric GANDER a écrit :


mais euh c'est le problème des fai pour l'ipv6 de faire les confs automatiques, 
pour les hébergeur/serveur c'est juste configurer une ip :)
et globalement les conf pour le v4 sont déjà automatiques, Dhcp ca marche 
bien ;)

la ou ça traîne c'est qu'en dehors des grands fournisseurs de contenu il n'y a 
pas bcp d'ipv6
mais bon le jour ou les fai vont arrêter de fournir du v4 ... mais c'est sur 
l'ipv6 chez les fai en france c'est pas forcement encore ca.




Pour moi c'est clairement la bascule, le jour où les FAI sont IPv6 et où 
ça générera une vraie part du trafic sur Internet (avec les gros FDC), 
les autres FDC se poseront enfin sérieusement la question et se 
sentiront réellement en retard techniquement.


Un FDC qui met de l'IPv6, ça se sent pas, les FAI ça fait tout de suite 
beaucoup de monde derrière qui bascule.


Frederic


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


Re: [FRnOG] [ALERT] Problème chez level3 ? avec Free

2015-06-14 Par sujet Frederic Dhieux

Le 14/06/2015 12:37, Clement Cavadore a écrit :
Rajoute à cela le fait qu'apparamment Free peere avec l'AS leakeur, du 
coup les rogue aspath étaient carrément préférés aux legit. 


Yep, de toute façon le leak concernait les préfixes des opérateurs qui 
peeraient avec AS4788 de ce qui a été reporté.




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


Re: [FRnOG] [ALERT] Problème chez level3 ? avec Free

2015-06-14 Par sujet Frederic Dhieux

Hello,

La conséquence violente d'un prepend massif des préfixes Free légitimes 
annoncés aux transitaires. Les autres FAI ont été moins touchés pour 
cette raison.


Frédéric

Le 12/06/2015 16:27, Youssef Bengelloun-Zahr a écrit :

Salut,

Probablement lié au leaking de routes depuis l'AS4788 de ce matin. Level3 a
morflé grave en Asie.

Nous aussi on a remarqué des grosses pertes en transitant depuis notre lien
FREE vers d'autres destinations.

Y.



Le 12 juin 2015 16:25, Clement Cavadore clem...@cavadore.net a écrit :


Bonjour Thierry,


On Fri, 2015-06-12 at 16:22 +0200, Thierry Del-Monte wrote:

Bonjour à tous,

Nous rencontrons des problèmes entre level3 et Free, et certains clients
nous remontent des problèmes d'accès depuis la plaque nord américaine
utilisant Level3.
Nous avons fait le nécessaire en interne (reroutage), et ouvert un
incident chez level3.
Mais avez-vous les mêmes symptômes ??

Leak Level3/Malaysian Telecom:
http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/

--
Clément Cavadore


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







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


Re: [FRnOG] [BIZ] Baies sur Téléhouse 2 - 3ème étage

2015-02-20 Par sujet Frederic Dhieux
Faudrait ajouter vue imprenable sur la cage de free et ses CRS dans
l'annonce, ça donne tout de suite un charme d'annonce immobilière en plus =)

Frédéric

Le 20/02/15 16:09, Frédéric GANDER a écrit :
 ba c'est un environnement cristallin pas comme les voisins qui ont des 
 chaises désuètes
 ca fait vendre ;)


 - Mail original -
 De: Julien Follenfant jfollenf...@gmail.com
 À: Romain MAZET - BSO Network Solutions romain.ma...@bsonetwork.com
 Cc: frnog-...@frnog.org frnog-...@frnog.org
 Envoyé: Vendredi 20 Février 2015 15:43:14
 Objet: Re: [FRnOG] [BIZ] Baies sur Téléhouse 2 - 3ème étage

 Tu es commercial maintenant ?


 Envoyé de mon iPhone

 Le 20 févr. 2015 à 15:41, Romain MAZET - BSO Network Solutions
 romain.ma...@bsonetwork.com a écrit :


 Bonjour à tous,

 Nous venons d'avoir quelques baies d'un client qui viennent de se
 libérer, ceci au troisième étage  du datacenter dans une cage
 privative.
 Nous n'avons eu aucune coupure électrique ! depuis au moins 5  ans
 (si ce n'est plus ) donc si jamais des personnes sont intéressées
 n'hésitez pas à me contacter en privé.

 Disponible de suite.

 Ce n'est pas un troll du vendredi :)

 Cdt,



 ---
 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] IOS XR et BGP Path attributes

2015-02-19 Par sujet Frederic Dhieux

Le 19/02/2015 11:11, Bertrand Yvain a écrit :

On Wed, Feb 18, 2015 at 08:31:11PM +0100, Frederic Dhieux wrote:

Essaye en ajoutant ça ? :

router bgp X
bgp enforce-first-as disable


Ce n'est pas le problème.  Le NLRI est considéré comme mal formé et je 
ne vois pas en quoi.



C'est pourtant le message typique :
- BGP error on attribute 2 : Problème d'AS PATH
- Update malformed : Problème de cohérence pour le préfixe donné par la 
ligne NLRIs


De ce que je comprends du paquet, l'AS PATH reçu est 3215 197161 avec 
en nexthop 37.77.38.12 (Hopus). A vue de nez je dirais que l'AS d'Hopus 
est le remote-as de la session BGP vu le fonctionnement d'Hopus et que 
donc l'ASR reçoit 3215 197161 en AS PATH alors qu'il s'attend à 
recevoir 44530 3215 197161 (ce que semblent confirmer les communautés 
associées 44530:*). Du coup l'ASR considère qu'il y a un problème sur 
l'attribut 2 BGP qui est malformé par rapport au remote-as défini.


Après je fais des suppositions par rapport au paquet que tu as collé, 
mais ça me semble être le cas le plus crédible et surtout c'est vraiment 
le message classique affiché quand on a ce problème sur un ASR (souvent 
vu lorsqu'on se connecte à un route-server de point d'échange).


Si tu n'as pas essayé, je pense que ça vaut le coup de le faire. Si je 
me trompe par rapport à ta situation, je veux bien la réponse finale, ça 
m'intéresse :)


Frédéric


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


Re: [FRnOG] [TECH] IOS XR et BGP Path attributes

2015-02-18 Par sujet Frederic Dhieux

Le 18/02/2015 15:51, Bertrand Yvain a écrit :

Salut la liste !

Un comportement étrange sur un ASR 9k qui tourne en IOS XR 5.1.3.

Certains NLRI sont considérés comme malpolis.  Dans un show bgp 
update in error neighbor detail, je peux trouver, par exemple :


Error flags: 0x0200
Discarded attributes: 0
Final action: TreatAsWdr

Error elements: 1
[1] Error 0x0200, Field Attr-data, Attribute 2 (Flags 0x40, 
Length 10)

Error data: [40020a02020c8f00030229] (13 bytes)
Action: TreatAsWdr

NLRIs: IPv4 Unicast  16 chars
   195.42.148.0/23

Reset/notification information:
  Reason None, Postit type Update malformed
  Notification code 3, sub-code 11
  Notification data [40020a02020c8f00030229] (13 bytes)

Message data: 69 bytes
     
  00450200 2A40 01010040 020A0202
  0C8F 00030229 40030425 4D260C80
  0404 C008 08ADF200 02ADF204
  E217C32A 94

Or 40020a02020c8f00030229 me semble tout à fait correct, compte 
tenu que c'est un session avec la capability AS4.


Une idée ?



Hello,

Un AS transparent sur l'AS path ? (genre route server ou AS privé ?)

Essaye en ajoutant ça ? :

router bgp X
 bgp enforce-first-as disable

Cordialement,
Frédéric


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


Re: [FRnOG] [TECH] IOS XR et BGP Path attributes

2015-02-18 Par sujet Frederic Dhieux

Le 18/02/2015 20:31, Frederic Dhieux a écrit :

Le 18/02/2015 15:51, Bertrand Yvain a écrit :

Salut la liste !

Un comportement étrange sur un ASR 9k qui tourne en IOS XR 5.1.3.

Certains NLRI sont considérés comme malpolis.  Dans un show bgp 
update in error neighbor detail, je peux trouver, par exemple :


Error flags: 0x0200
Discarded attributes: 0
Final action: TreatAsWdr

Error elements: 1
[1] Error 0x0200, Field Attr-data, Attribute 2 (Flags 0x40, 
Length 10)

Error data: [40020a02020c8f00030229] (13 bytes)
Action: TreatAsWdr

NLRIs: IPv4 Unicast  16 chars
   195.42.148.0/23

Reset/notification information:
  Reason None, Postit type Update malformed
  Notification code 3, sub-code 11
  Notification data [40020a02020c8f00030229] (13 bytes)

Message data: 69 bytes
     
  00450200 2A40 01010040 020A0202
  0C8F 00030229 40030425 4D260C80
  0404 C008 08ADF200 02ADF204
  E217C32A 94

Or 40020a02020c8f00030229 me semble tout à fait correct, compte 
tenu que c'est un session avec la capability AS4.


Une idée ?



Hello,

Un AS transparent sur l'AS path ? (genre route server ou AS privé ?)

Essaye en ajoutant ça ? :

router bgp X
 bgp enforce-first-as disable



Plus propre, pardon (pour le neighbor concerné uniquement) :

router bgp X
 neighbor remote-IP
   enforce-first-as


Frédéric


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


Re: [FRnOG] [ALERT] Pertes de paquets sur franceix

2015-01-13 Par sujet Frederic Dhieux
Bonjour,

1) Demander sur la mailing FranceIX directement est peut-être plus
adapté/rapide/efficace ?

2) Rien à signaler chez nous

Frédéric

Le 13/01/15 11:35, OCEANET - Cédric BASSAGET a écrit :
 Bonjour à tous,

 On constate pas mal de perte de paquets depuis une dizaine de minutes
 sur franceix, en faisant un mtr vers 8.8.8.8.
 Est-ce que vous constatez également des problèmes via franceix ?

 Merci
 Cédric


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


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


Re: [FRnOG] [TECH] Conseil switches

2015-01-05 Par sujet Frederic Dhieux
Hello,

Le 05/01/15 10:11, Mathieu Poussin a écrit :
 Hello,

 Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne 
 devrait pas y avoir de soucis par rapport à du trunk comme tu fais.

Je pense qu'il parle du cas où un stack bug ou part en vrille et je
trouve la question légitime, j'ai déjà vu des stacks partir en vrille et
crasher l'ensemble de ses éléments par le passé et là ta redondance elle
fait un peu une sale tête. Pour de l'agrégation je trouve que c'est
bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne
trouve pas que ce soit une bonne idée même si avec du Juniper tu as une
meilleure gestion de la capacité réseau (mais aussi du coup un mode
dégradé quand l'un tombe)

 Chez Juniper tu a les EX2200 qui semblent correspondre à ce que tu cherches.
 Chez HP, tu as les (plus tant) nouvelles gammes suite au rachat de H3C, 
 regarde du côté des 5120 (Et honnêtement le nouvel OS Comware est bien plus 
 puissant que l'OS Procurve, c'est comparable à un IOS)

 Pour avoir utilisé les deux, Juniper est plus intéressant, mais la CLI est 
 complètement différente de Cisco/HP (mais bien plus puissante/flexible)

De mon côté je trouve l'idée de prendre des bons vieux Cisco 2960G
plutôt bonne. C'est un bon produit plus très cher, robuste et éprouvé
(sans licences ajoutées) depuis des années et qui ne souffre pour moi
que d'un réel défaut : être mono-alimenté. Avec du budget sinon monter
sur une génération plus moderne et double alimentée.

Après à la question est-ce que ça sera plus robuste qu'avant ?, je
dirais que ça a des chances, mais que 5 ans sans panne c'est quand même
pas mal aussi non ?

Cordialement,
Frédéric


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


Re: [FRnOG] [TECH] Conseil switches

2015-01-05 Par sujet Frederic Dhieux

Le 05/01/15 11:10, Simon Morvan a écrit :

 Disons que le stacking me permettrait aussi à terme de double attacher
 mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une
 simple paire de 2960 à part en faisant du spanning-tree jusqu'au
 serveur, non ?

Tu veux faire de la redondance active/backup ou utiliser les 2 lien en
actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher
sur le stacking. Si c'est de la redondance active/backup, il faut juste
gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC
des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge
entre les 2 interfaces du serveur.

Frédéric


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


Re: [FRnOG] [TECH] Conseil switches

2015-01-05 Par sujet Frederic Dhieux
Le 05/01/15 11:10, Simon Morvan a écrit :

 Disons que le stacking me permettrait aussi à terme de double attacher
 mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une
 simple paire de 2960 à part en faisant du spanning-tree jusqu'au
 serveur, non ?

Tu veux faire de la redondance active/backup ou utiliser les 2 lien en
actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher
sur le stacking. Si c'est de la redondance active/backup, il faut juste
gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC
des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge
entre les 2 interfaces du serveur.

Frédéric


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


Re: [FRnOG] [TECH] Conseil switches

2015-01-05 Par sujet Frederic Dhieux

Le 05/01/15 11:20, Simon Morvan a écrit :
 Je pense que si le budget le permet, je préfère maximiser l'usage des
 liens. C'est pour ça que je pensais aux derniers modèles de la gamme
 2960 qui sont stackables, justement. Avec un truc type RPS2300, le
 problème de la double alimentation est réglé. Le seul souci, c'est que
 c'est une nouvelle gamme, peut-être pas exempte de bug, surtout sur la
 partie stacking. Peut-être qu'une paire de 3750 en refurb vaut plus le
 coup pour stacker, finalement.

Je ne sais pas pour les dernier 2960 en stack, des 3750 le feraient a
priori bien de leur côté effectivement. Pour les RPS, quand j'avais
testé, je constatait que la bascule du power actif au backup entrainait
un reload du switch (le switching électrique n'était pas transparent) et
vu le temps que ça met à booter, j'étais pas ravi de la solution. C'est
différent selon les modèles ?


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


Re: [FRnOG] [MISC] C'est nous qu'on est les meilleurs

2014-11-26 Par sujet Frederic Dhieux

Le 26/11/14 10:18, Stephane Bortzmeyer a écrit :
 http://www.vanityfair.fr/actualites/france/articles/rani-assaf-l-associe-fantome-de-xavier-niel/16660

 « le forum du French Networks Operators Group (FRnOG), un site
 fréquenté par à peine 250 informaticiens, les meilleurs »

Hello,

Après les écoles d'ingé, les médias nous font le marketing bullshit de
l'élite de la nation ça y est =) Je note par ailleurs que les gens du
réseau sont considérés comme une race supérieure d'informaticiens
puisque ce sont les meilleurs de cet ensemble particulièrement large :D

Quand on voit ça, on a envie de donner raison à Rani d'aller se planquer
loin de toutes ces conneries :D

Frédéric


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


Re: [FRnOG] [MISC] GS - opérateur

2014-10-27 Par sujet Frederic Dhieux

Le 27/10/14 16:10, Raphael Maunier a écrit :
 Parce que le mec qui fait le splice c’est pas le meme mec qui fait un simple 
 patch. Ce ne sont pas
les meme compétences...
 Le temps nécessaire pour faire un patch n’est pas le meme que pour un
splice.


Hello,

Sans compter le fait qu'une erreur de patching est tout de suite plus
chiante à corriger et qu'une demande de repatching en urgence est
également plus pénible.

L'idée de le proposer en service premium spécifique à certains circuits
est pas mal, mais le généraliser me semble encore compliquer la gestion
MMR qui est déjà parfois un peu difficile.

Frédéric

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


Re: [FRnOG] [MISC] GS - opérateur

2014-10-26 Par sujet Frederic Dhieux
Bonjour,

Ce n'est pas ce qu'on m'a répondu le jour où j'ai posé la question (mars
2013) :

Pour répondre à votre question sur les autres opérateurs acceptés dans
les datacenters COLT, seul OBS est accueilli sauf pour celui des Ulis où
SFR est en cours de connexion. Par conséquent, toutes demandes de
liaisons Internet, Lan2Lan, VPN...etc devra se faire via COLT, OBS ou
SFR (Datacenter Les Ulis).

Et quand le prix d'un lien intersite proposé par Colt vers/depuis son
site est 3 fois le prix du marché...

De mon côté ce n'était qu'une demande pour voir, mais je pense qu'il
faut vous mettre d'accord dans votre équipe commerciale ;)

Cordialement,
Frédéric

Le 26/10/14 08:26, Fedotova, Claire Svetlana Four a écrit :
 Bonjour, 
 Ce n'est pas une blague: tous les DC de Colt sont carrier neutral, stratégie 
 depuis 2012. 


 Sent from my iPhone

 On 25 oct. 2014, at 21:58, Raphael Mazelier r...@futomaki.net wrote:



 Est-ce que quelqu'un connaît d'autres DC ayant ce genre de politique 
 vertueuse ?
 A mon sens les DCs d'Iliad sont très carrier neutral. Et DC4 devrait être 
 encore mieux selon certaines sources (cross connect encore moins cher...)

 -- 
 Raphael Mazelier


 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 [Colt Disclaimer]
 This email is from an entity of the Colt group of companies. Colt Group S.A.,
 K2 Building, Forte 1, 2a rue Albert Borschette, L-1246 Luxembourg, R.C.S.
 B115679.  Corporate and contact information for our entities can be found at
 http://colt.net/uk/en/Colt-Group-of-Companies/index.htm. Internet
 communications are not secure and Colt does not accept responsibility for the
 accurate transmission of this message. Content of this email or its
 attachments is not legally or contractually binding unless expressly
 previously agreed in writing by Colt


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


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


Re: [FRnOG] [TECH] PRA et ISO

2014-10-14 Par sujet Frederic Dhieux
Dans le cas de problématiques de fonctionnement synchrone, il arrive
qu'il y ait un maximum oui. Par contre 30 km c'est peu pour un maximum...

Le 14/10/14 11:53, thomas.lorenz...@orange.fr a écrit :
 max 30km ??

 Comment c'est possible de définir un max ?

 Thomas
  






 Message du 14/10/14 10:50
 De : Fedotova, Claire Svetlana Four 
 A : Florian Cristina , frnog@frnog.org 
 Copie à : 
 Objet : RE: [FRnOG] [TECH] PRA et ISO

 Bonjour, 
 Avec modeste expérience de quelques RFP dans ce domainbe - min 5, 10 km - 
 Max 30 km. 
 Dépend de besoins des clients concernant réplications synchrones et de ses 
 équipements, ainsi que le mode de fonctionnement actif/actif ou 
 actif/passif...
 Chaque RFP est une surprise...dépend aussi du cabinet de consulting qui le 
 rédige, ainsi que des prestataires d'infogérance, car ils ne veulent pas 
 envoyer leurs équipes loin et à un budget significatif. 
 Donc parfois, il y a des restrictions qui n'ont rien avoir avec les 
 contraintes techniques. 
 Cdt, 
 Claire 

 -Message d'origine-
 De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
 Florian Cristina
 Envoyé : mardi 14 octobre 2014 09:50
 À : frnog@frnog.org
 Objet : [FRnOG] [TECH] PRA et ISO

 Bonjour,

 Est-ce qu'il existe une norme/livre blanc/iso qui recommande/impose une 
 distance minimum entre 2 datacenters dans le cadre d'un PRA ?

 On me souffle que oui dans le domaine bancaire, mais je n'ai rien trouvé en 
 documentation publique. C'est pourquoi je me demande si m'on interlocuteur 
 n'a pas confondu PCA et PRA.

 Cordialement,
 Florian CRISTINA.

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 [Colt Disclaimer] This email is from an entity of the Colt group of 
 companies. Colt Group S.A., K2 Building, Forte 1, 2a rue Albert Borschette, 
 L-1246 Luxembourg, R.C.S. B115679. Corporate and contact information for 
 our entities can be found at 
 http://colt.net/uk/en/Colt-Group-of-Companies/index.htm. Internet 
 communications are not secure and Colt does not accept responsibility for the 
 accurate transmission of this message. Content 
 of this email or its attachments is not legally or contractually binding 
 unless expressly previously agreed in writing by Colt 
 --- 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] Lien optique qui clignote.

2014-10-14 Par sujet Frederic Dhieux
Le comportement pourrait faire penser à un optique qui en chauffant perd
ses qualités, surtout si c'est de la mauvaise qualité. Je l'ai déjà eu
sur du DWDM, mais là c'est plus étonnant.

Je mise en tout cas sur l'optique. Au prix des optiques de nos jours, ça
vaut le coup de mettre un peu plus cher pour être tranquille ;)

Frédéric

Le 14/10/14 14:38, Pierre Colombier a écrit :

 Je donne suite a plusieurs réponses en même temps.

 Les SFP sont du no-name pas cher. Il n'y a pas d'infos sur la force du
 signal reçu. Vu le prix des trucs, je ne m'attends pas à de la
 super-qualité ni à une super durée de vie. Simplement, je suis surpris
 par ce genre de panne intermittente. A la limite, j'aurais compris que
 ça crashe et que ça reparte après un reboot à froid jusqu'au prochain
 crash. Si tel avait été le cas, j'aurais simplement changé les SFP et
 basta. Mais que les montées et descentes de la liaison ne semblent pas
 liées du tout aux reset du hardware, je trouve ça surprenant.

 Pour la suggestion du spare, 100% d'accord, d'ailleurs j'en ai déjà.
 J'hésitais juste à ouvrir les pochettes scellées.

 Ce qui m'inquiétait, c'est que ça puisse être un problème de fibre
 optique altérée. C'est un switch périphérique dont les 2 liens
 d'uplink passent dans le même câble optique posé il y a environ 1an.
 Si c'est des SFP foireux, c'est pas un problème, je change Par
 contre, si c'est une des fibres qui commence déjà à merder, ça me met
 un gros doute sur la pérennité des 5 autres.
 Note : Le câble de fibre passe en extérieur sur le toit du bâtiment.
 Il n'est soumis à aucune contrainte mécanique particulière mais Il est
 exposé au soleil et aux intempéries et donc à d'assez fortes
 variations de températures. ça peut jouer ?

 Merci pour vos retours.




 Le 14/10/2014 14:13, Olivier Benghozi a écrit :
 Pas besoin d'atténuation en LX/LH ni en LR: les optiques émettent
 moins fort que ce qu'elles peuvent recevoir au max.
 Par contre des SFP avec DOM permettent de connaitre la puissance
 reçue, comme l'écrit David.


 Le 14 oct. 2014 à 12:47, Sebastien Lesimpleslesim...@laposte.net  a
 écrit :

 Et tu as reçu tes mesures lors de la livraison de tes FO?
 Tu as éventuellement besoins d'un atténuateur tout simplement.

 Le 14 oct. 2014 à 12:36, David Ponzonedavid.ponz...@gmail.com  a
 écrit :

 2 suggestions:

 1) si tes SFP le permettent, vérifie la puissance du signal reçu
 pendant la coupure et compare avec le reste du temps
 2) au prix d’un SFP, achète du SPARE!

 My 0,02€


 Le 14 oct. 2014 à 12:30, Pierre Colombierpcdw...@pcdwarf.net  a
 écrit :

 Bonjour,

 j'ai une liaison optique en 1000Base LX d'environ 300m sur de la
 fibre monomode qui s'est mise à tomber une à deux fois par jours
 sans raison apparente pendant des durées variant de quelques
 secondes à plusieurs heures.

 Vendredi le lien est tombé plusieurs heures.
 J'ai débranché/rebranché les fibres, retiré et replacé le module
 SFP, rebooté les switches
 ça n'est pas revenu.
 Et puis magiquement, c'est revenu 2 heures plus tard sans toucher
 à rien.
 J'ai à nouveau trituré toutes les connectiques, retiré et remis
 les modules SFP, c'est toujours bien revenu tout de suite.

 Je ne dispose pas d'appareils de mesure pour contrôler moi même
 les fibres mais j'ai un crayon laser.
 Si j'en juge par la forte brillance du point rouge en sortie de
 fibres (assez fort pour projeter une grosse tache rouge sur le mur
 à 1 mètre de distance), la fibre n'est pas coupée, les soudures
 sont OK et on est très très loin des limites en termes d'atténuation.

 Est-il possible que ce soit juste un module SFP qui déconne par
 moments, indépendamment du fait qu'on le débranche/rebranche ?


 Note : il y a deux liens avec du spanning tree donc il n'y a rien
 de critique pour le moment.
 Par contre, toutes les fibres font partie du même câble et je suis
 un peu inquiet.
 En tout cas, j'aimerai comprendre ce qui se passe.

 Si certains ont des idées / suggestions de manipes , je suis preneur.

 D'avance merci.

 Pierre Colombier.


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




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


Re: [FRnOG] [TECH] Quel mode de bonding pour du multi-switch ?

2014-10-12 Par sujet Frederic Dhieux
Hello,

Pour moi ça s'arrête à KISS : Se compliquer la vie pour exploiter les 2
liens 1G vers 2 switchs différents avec de la répartition c'est ajouter
une complexité qui peut se transformer en problèmes par la suite. Je
recommanderais chaudement le active-backup quand on n'est pas en mode
stack (que je ne recommande pas non plus en général parce qu'un stack
qui bug c'est plus rien qui fonctionne)

Je trouve plus dommage de s'exposer à des problèmes que d'avoir un lien
en standby.  Après c'est une question d'orientation/priorité entre
stabilité et performances et chacun fait ses choix.

My 2 cents,
Frederic

Le 10/10/14 16:07, Florian Taboul a écrit :
 Merci à tous pour vos réponses.
 Je vais essayer de répondre à tous ici.

 Lilian : quand tu dis pas trop mal, tu as eu des difficultés à quel
 niveau ? 

 Gurvan : je n'ai pas d'arp inspection prévu sur cette infra donc ça
 devrait le faire.

 Olivier : effectivement le active-backup est ma solution de repli si
 je n'arrive pas à faire ce que je veux. Mais je trouve que c'est
 dommage de perdre la moitié de la capacité lorsque ça fonctionne. Dans
 cette situation là, il vaut mieux donc un switch de backup de moins
 bonne qualité que le principal, c'est à voir.

 David, Raphael : c'est bien ce qu'il me semblait, le LACP sur
 plusieurs switch n'est pas mature, ou trop propriétaire à mon gout
 pour les marques où ça tourne bien.


 --- lil...@devclic.fr wrote:

 From: Lilian - Devclic lil...@devclic.fr
 To: fl...@muchomail.com
 Subject: Re: [FRnOG] [TECH] Quel mode de bonding pour du multi-switch ?
 Date: Fri, 10 Oct 2014 13:50:26 +0200

 Bonjour,

 J'ai déjà essayé du mode 6 et ça fonctionne pas trop mal.

 Le trafic est bien géré globalement.


 Le 10/10/2014 13:45, Florian Taboul a écrit :

 Bonjour Gurvan et merci de ta réponse.

 Si je ne m'abuse, le mode 802.3ad (lacp) n'est pas utilisable en 
 multi-switch.

 Bien sur ça peut fonctionner selon la marque en stack, mais justement je 
 ne souhaite pas utiliser une seule et unique marque de switchs, mais 
 différentes marques qui ne supportent pas le stackage entre elles. C'est là 
 qu'est le problème :)

 --- inulo...@gmail.com mailto:inulo...@gmail.com wrote:

 From: Inulogic - Free-H inulo...@gmail.com mailto:inulo...@gmail.com
 To: frnog-t...@frnog.org mailto:frnog-t...@frnog.org
 Subject: Re: [FRnOG] [TECH] Quel mode de bonding pour du multi-switch ?
 Date: Fri, 10 Oct 2014 13:22:24 +0200

 Bonjour,

 Et pourquoi pas le mode 4, le bond-mode 802.3ad (lacp) ?
 Agrégation de lien de base et en soit ça fait HA.

 Techniquement, il me semble que le stackage de switch sur du modèle
 relativement récent ne pose aucun problème, bien au contraire, à moins
 d'utiliser des fonctions très exotiques.
 De mon côté j'ai du stack de Juniper EX4200 (en 2 ou en 3) et je fais
 du 802.3ad en 2 x 1Gbits ou 4 x 1Gbits sous Debian/Centos et VMware.

 Gurvan.

 Le 10 octobre 2014 12:56, Florian Taboul fl...@muchomail.com 
 mailto:fl...@muchomail.com a écrit :

 Bonjour à la liste,

 Voilà, je vais devoir mettre en place une petite infra de serveurs 
 équipés
 chacun de 2 ports réseau Gigabit.

 J'aimerais, pour améliorer la disponibilité et maximiser la capacité 
 réseau,
 les connecter à 2 switchs différents (de marque différente donc
 non-stackables).

 Si je veux donc faire du bonding, je vais devoir gérer ça côté 
 logiciel sur
 mon OS Linux.

 En lisant la doc sur le bonding
 (https://www.kernel.org/doc/Documentation/networking/bonding.txt), on
 constate qu'il ne semble pas y avoir de mode permettant à la fois la 
 haute
 disponibilité ET l'aggrégation des liens. Ils conseillent les modes
 active-backup ou broadcast pour du HA, et balance-rr pour de
 l'aggrégation.

 Pourtant, mais je ne m'y connait peut-être pas suffisamment pour voir 
 le
 problème, le mode balance-alb semble faire ce que je veux. Je 
 n'arrive pas
 à voir le problème que je pourrais rencontrer dans cette situation.

 En fait, vous allez surement me dire pourquoi tu ne prends pas 2 
 switchs
 stackables et basta ?, et bien parce que pour moi, prendre 2 switchs
 identiques (ou presque), fabriqués à la même période avec du matériel
 quasi-identique ne me met pas en confiance dans l'éventualité d'une 
 panne
 matérielle (idem pour le logiciel qui est identique sur les 2).
 Voilà pourquoi je préfère 2 switchs de 2 marques différentes. Et pour
 l'instant à ma connaissance, il n'existe pas un protocole assez 
 répandu pour
 faire du LACP sur plusieurs switchs.

 Quelle(s) solution(s) envisageriez-vous à ma place ? Ou qu'avez-vous 
 déjà
 mis en place dans une telle situation ?

 Merci par avance.

 Cordialement,
 Florian


 

Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?

2014-09-23 Par sujet Frederic Dhieux

Le 23/09/14 13:11, Radu-Adrian Feurdean a écrit :

 Bref, ces ERX et autres reliquats, on vote tous pour leur destruction à la 
 prochaine AG du RIPE ?
 Non.



Yep, tout ça ressemble à une énième chasse aux sorcières en période de
pénurie...

Je rebondis là dessus du coup. Si les gens mettaient plus d'énergie à
déployer IPv6 qu'à chercher des méthodes pour continuer en IPv4, on
serait déjà dans le futur.

Alors on va dire que beaucoup n'ont pas de problème en IPv4 et ne vont
pas faire l'effort de déployer IPv6 et qu'à cause d'eux les autres
doivent bien trouver des solutions, mais bon le jour où ces gens se
sentiront un peu seuls et derniers de la classe, ça se passera peut-être
mieux aussi.

Au passage, pas merci aux FAIs qui devraient être les moteurs dans
l'histoire parce que leurs eyeballs ont de la valeur pour basculer vers
IPv6 aussi, pas juste pour le peering. D'ailleurs comme l'argent est
souvent le facteur bloquant, l'état devrait favoriser les FAIs qui
fournissent de l'IPv6 aux français et pénaliser les FAIs qui ne le font
pas. Le combat se situe là pour moi, les fournisseurs de contenu
suivront plus facilement derrière et les gens qui ont besoin de plus
d'IPs sont souvent dans ces 2 secteurs. Bien sûr je prends l'exemple de
la France, mais ça s'applique à l'Europe tout aussi bien.

Avec ces axes on pourrait avancer :
- L'Etat/Europe subventionne un peu les FAIs qui fournissent IPv6 et
mettent une amende à ceux en retard
- Les FAIs refusent de peerer avec les gens qui ne font pas de trafic IPv6

Ca bougerait surement un peu plus de cette manière et on éviterait de
bricoler IPv4 continuellement parce que passer à IPv6 n'est pas
important pour le business.

Les IX pourraient aussi jouer un rôle en offrant une tarification plus
avantageuse aux gens qui décident de peerer sur les RS IPv6, pourquoi
pas... C'est un peu subjectif et difficile à défendre, mais ça montre un
certain engagement. Après y'aura toujours des gens pour tricher et juste
monter la session et annoncer un préfixe, mais a contrario ça donne
aussi rapidement l'impression qu'IPv6 s'est généralisé et qu'on y
arrive. Peut-être ce genre de discussion pourrait être à creuser plus
que comment on peut récupérer des IPv4 non ?

My 2 cents,
Frédéric


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


Re: [FRnOG] [TECH] Howto? effectuer des tests de debits? Et faire les rapports!

2014-09-20 Par sujet Frederic Dhieux

Bonjour Jeremy,

Un bon moyen sans investir dans du matériel est d'utiliser iperf (modes 
client/server) en bidirectionnel entre les 2 points pour tester le 
débit. Le man donnera des infos sur les différents paramètres.


Et un classique ping sur 1 paquets de taille max MTU (pas avec 1 
seconde entre chaque paquet bien sûr) pour tester le loss et la bonne 
tenue du lien.


Cordialement,
Frédéric

Le 20/09/2014 23:58, Jerem a écrit :

Bonjour la liste :D

Petite question. Premiere fois que j’en pose une d’ailleurs donc j’espère ne 
pas commettre d’impaires sinon n’hésitez pas à me pourrir!

Dans le cadre de mon travail je mets de plus en plus souvent en place des 
systèmes de communications comme des ponts wifi ou encore des liaisons VPN 
entre des agences distantes et notre siege, base sur des offres fibres ou 
parfois 4g.
  
Lors de ma prochaine intervention technique de ce type je vais bosser sur une liaisons point a point basee sur les radios Ubiquiti Rocket M5 Titanium. Une fois en place, j’aimerais effectuer des tests de debits a mettre dans mon rapport d’installation.


Je souhaiterais standardiser cette procedure pour toutes nos interventions 
future et souhaiterais savoir si vous aviez des recommandations a me faire a ce 
sujet: Quels outils utilisez vous? Ya fil une méthodologie que vous me 
recommanderiez?
Par exemple, je me dis qu’il y a surement plus propre qu’une capture d’écran 
speedtest quand on tests les liens FAI :D

Merci d’avance pour vos réponse

Jeremy

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



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


Re: [FRnOG] [BIZ] Nouvel acquéreur de Free

2014-09-19 Par sujet Frederic Dhieux

Le 19/09/14 13:32, jean-y...@lenhof.eu.org a écrit :

 Le 2014-09-19 13:26, Eric ROLLAND a écrit :
 Bonjour la liste,
  C'est pas le tweet le plus attendu de la journée, mais ca se regarde
 :
  https://twitter.com/AS42929/status/512924285053452289 [1]

  Bon trolldi à toutes et tous,
  Eric ROLLAND
  AS42929 - RE515-RIPE


 Pour moi qui ait travaillé avec des monéticiens dans ma vie
 précédente, on parle ici d'acquéreur au sens monétique du terme...
 Je ne vois donc pas le pb...


Une, c'est la société qui fait l'encaissement des paiements CB des
clients de Free qui a changé, c'est juste un prestataire de paiement donc.

Cordialement,
Frederic


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


[FRnOG] [TECH] Perturbations hier soir à 22h ?

2014-09-09 Par sujet Frederic Dhieux
Hello,

Je fais un peu le tour de mes graphs et je vois des perturbations hier
soir à partir de 22h pendant environ 4h, surtout via le transit Tata
(constaté par un autre opérateur également)

C'est principalement du trafic international dans mon cas, sur Level 3
c'est moins visible mais il semble y avoir eu une légère baisse aussi.
Mes latences vers les US et le Canada via Tata ont pas mal augmenté sur
cette période ainsi que vers l'Angleterre et d'autres pays d'Europe.

Est-ce que quelqu'un aurait des infos sur ce sujet ? (par curiosité)

Merci :)

Cordialement,
Frederic


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


Re: [FRnOG] [TECH] Perturbations hier soir à 22h ?

2014-09-09 Par sujet Frederic Dhieux
Merci pour l'info, j'ai ouvert un ticket chez Tata, effectivement voilà
leur retour :

Kindly note that in the event of ongoing major outage in our network in
Europe, we faced another outage in Paris, due to which our capacity
between London-Paris was down from approx 20:00 UTC, 8th Sept'14 to
00:15 UTC, 9th Sept'14.

However, Our team balanced traffic at around 21:16 UTC, 8th sep'14 to
alleviate congestion. 

This lead to congestion on other available capacity in this region,
leading to packet loss. Our teams balanced traffic as much as possible
during this outage to minimize the impact.

We see normal traffic on our backbones since this outage was restored
and most of our customers have pushed traffic back on their transit
links with us.

Frederic

Le 09/09/14 15:24, Raphael Mazelier a écrit :
 Alors hier soir Tata a un *gros* incident sur leur backbone Europe,
 doublé d'un incident en France.
 La ou ça devient moins clair, c'est que même via les autres le traffic
 vers les US était perturbé.(loss et +30/40ms).

 Début 22H30, Fin 00H.


 Le 09/09/2014 15:02, Frederic Dhieux a écrit :
 Hello,

 Je fais un peu le tour de mes graphs et je vois des perturbations hier
 soir à partir de 22h pendant environ 4h, surtout via le transit Tata
 (constaté par un autre opérateur également)

 C'est principalement du trafic international dans mon cas, sur Level 3
 c'est moins visible mais il semble y avoir eu une légère baisse aussi.
 Mes latences vers les US et le Canada via Tata ont pas mal augmenté sur
 cette période ainsi que vers l'Angleterre et d'autres pays d'Europe.

 Est-ce que quelqu'un aurait des infos sur ce sujet ? (par curiosité)

 Merci :)

 Cordialement,
 Frederic


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


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


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


Re: [FRnOG] [ALERT] Saturation Level / Orange ?

2014-09-04 Par sujet Frederic Dhieux
Bonjour,

A cette heure ci ou le soir ?

Frederic

Le 04/09/14 12:02, Fabien V. a écrit :
 Bonjour,

 Suite à plusieurs incidents, nous avons identifié des lenteurs provenant de 
 notre transitaire Level 3 vers Orange/3215.

 Nous avons rerouté par Cogent le 3215 et avons constaté la disparition des 
 lenteurs / débits faibles. Quelqu'un sur la liste aurait des informations qui 
 nous permettrait de confirmer ce comportement ?

 ​Merci d'avance pour toute aide ou information ;)
 ​
 Fabien VINCENT
 --


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


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


Re: [FRnOG] [ALERT] Saturation Level / Orange ?

2014-09-04 Par sujet Frederic Dhieux
Ceci étant pas de problème de mon côté en basculant un préfixe via
Level3 à cet instant, la latence est optimale :)

Frederic

Le 04/09/14 12:10, Frederic Dhieux a écrit :
 Bonjour,

 A cette heure ci ou le soir ?

 Frederic

 Le 04/09/14 12:02, Fabien V. a écrit :
 Bonjour,

 Suite à plusieurs incidents, nous avons identifié des lenteurs provenant de 
 notre transitaire Level 3 vers Orange/3215.

 Nous avons rerouté par Cogent le 3215 et avons constaté la disparition des 
 lenteurs / débits faibles. Quelqu'un sur la liste aurait des informations 
 qui nous permettrait de confirmer ce comportement ?

 ​Merci d'avance pour toute aide ou information ;)
 ​
 Fabien VINCENT
 --


 ---
 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] Un remplaçant a ma Sup720-3BXL ?

2014-08-30 Par sujet Frederic Dhieux

Bonjour Olivier,

Je me suis posé la même problématique il y a un peu plus d'un an. On 
était déjà en 2x1G sur de nombreux ports de transits mais il nous 
fallait passer sur du 10G pour simplifier les choses et éviter les N 
agrégats sur le réseau, notamment en DWDM.


Après avoir fait le tour des prix pour upgrader les châssis, cartes de 
sup, ajouter des cartes 10G j'ai vite décidé qu'à ce prix là autant 
partir sur une solution de nouvelle génération plutôt que de s'entêter 
sur du matos vieillissant en claquant des coût d'upgrade massifs.


Du coup je ne saurais trop te conseiller de passer directement à 
l'ASR9001 qui est pour moi le meilleur produit pour ce besoin tant que 
tu n'as pas trop de ports à mettre sur ton coeur. La puissance de 
traitement est importante, tu peux voir très loin avec ce produit (plus 
qu'avec un châssis et les cartes les moins chères).


En face chez Juniper tu trouveras également de bons produits, mais comme 
discuté dans un autre thread il faut taper au dessus du MX80 pour avoir 
un produit aux capacités équivalentes.



Les axes d'étude chez nous étaient les suivants si le détail intéresse :
- Les 7600/6500 sont vieillissants et plus sujet à des pannes
- Leur consommation électrique est double par rapport à un ASR9001 (sur 
certains PoP ça n'est pas négligeable)

- L'encombrement également est important
- Le coût des cartes 10G et des cartes de sup pour upgrader est de 
plusieurs 10aines de KEuros, là où un ASR9001 se touche bien en dessous 
de 50K (je tape large pour éviter le débat des prix).

- Passer d'un coeur de réseau broké à un coeur neuf et avec support

2 concurrents ont émergé (Brocade a très vite été écarté malgré un prix 
très attractif) :


Cisco :
+ Continuité avec le parc en full Cisco
+ l'ASR est un routeur mature très bon
+ IOS XR se rapproche de ce qui se fait chez Juniper et marque une 
évolution notable par rapport à IOS

+ Performances
+ Stabilité
- La CLI est quand même un vrai cran en dessous de Juniper
- Moins de fonctionnalités, notamment de Cluster/vchassis
- Prix plus élevé que son concurrent

Juniper :
+ La CLI
+ Très à la mode chez les opérateurs, beaucoup de transitaires sont sous 
Juniper

+ Prix
- Historiquement j'ai vu plus de bugs et d'incidents impliquant du 
Juniper (annonce BGP qui fait crasher le routeur, comportement 
incohérent entre routing et forwarding), même si ça reste rare
- Le MX80 qui est l'équivalent en format de l'ASR9001 est loin d'en 
avoir les performances, il faut taper du MX240 pour commencer à parler 
et c'est plus un routeur compact, le prix n'est plus intéressant à ce 
moment là
- le M104 nous a été présenté comme la solution mais il n'était pas 
encore vraiment sorti chez des clients, hors de question de prendre du 
matériel non éprouvé
- Intégration dans un parc full Cisco, normalement ça se passe bien, 
mais la vie des fois...


La conclusion :

- L'ASR9001 était le produit idéal pour une bonne partie de nos sites 
et s'est imposé de lui même, ça compensait le prix des châssis plus 
chers sur les sites principaux


- On a fait des tests matériels avec les 2 fabricants qui ont montré 
que les 2 se comportaient bien en lab


- Le temps de négociation a été très (trop) long, beaucoup plus que 
prévu, mais on a eu des prix intéressant (bonne période, mise en 
concurrence)


- Commercialement c'est compliqué avec les 2 parties, entre l'ego, la 
soif de vendre, les méthodes, les partenaires, etc.


- On n'a pas payé plus cher au final la solution Cisco par rapport à 
Juniper. Une meilleure négo d'une part et aussi le fait que l'ASR9001 
était tout simplement le meilleur sur son segment à tous les niveaux 
(qualité, perfs, prix)



Maintenant les conditions dépendent beaucoup de ce qu'on cherche et des 
interlocuteurs commerciaux en face. Egalement du temps que tu as pour 
travailler la partie commerciale.


Techniquement si le budget est un souci, ou que tu veux des 
fonctionnalités ou que tu veux suivre la mode, Juniper est devant. Si tu 
axes en priorité sur les perfs et la stabilité dans la continuité de ce 
que tu avais au détriment du confort d'utilisation (CLI) et de quelques 
fonctionnalités, Cisco pour moi représente un meilleur choix.


Sur du chassis compact 2U, je pense que là il n'y pas photo entre les 2 
et que l'ASR9001 n'a pas de rival au niveau, sur du châssis à cartes, la 
différence de prix fait plus réfléchir à perfs équivalentes.


J'ai aussi entendu dire que le support Juniper en ce moment était un peu 
en baisse (préparation de rachat ?), à discuter avec les gens qui savent 
et qui ont ouvert des tickets dernièrement voir si c'est une mauvaise 
expérience isolée ou un phénomène global. Je ne vais pas me permettre de 
juger un support que je n'utilise pas. Côté Cisco le peu que j'ai eu 
affaire avec eux ça s'est bien passé pour le moment (on est à 2 tickets 
sur des fonctionnalités, c'est trop peu pour avoir un vrai jugement 
également)


Bref, tout ça pour dire qu'entre les 2 il n'y a pas 

Re: [FRnOG] [TECH] Un remplaçant a ma Sup720-3BXL ?

2014-08-30 Par sujet Frederic Dhieux

Le 30/08/14 22:18, Jeremy a écrit :
 Salut Fred,

 Je suis curieux, pourquoi avoir écarté d'office Brocade ? Dans la
 gamme des chassis, le MLXe-4 ou MLXe-8 (ou MLX si conso électrique pas
 importante) peut très bien faire l'affaire non ? Voire même une gamme
 Netiron avec un CER + carte 10G ?
 Perso, jamais été emmerdé sur ces gammes là. Bon après, chacun son
 expérience sur chaque matériel. Sur les FCX en switching, c'est une
 autre affaire. Et accessoirement le support est en carton. Hormis ça,
 le prix reste un argument de poids sur cette marque.


Salut Jérémy,

Plusieurs choses en fait :

1) Comme l'a dit Radu, une somme importante de nuits blanches sur les
XMR et CER notamment pour divers bugs. C'est cher payé en temps homme.

2) Tous ces bugs étaient supportables à une époque où l'équipe technique
et l'équipe commerciale étaient proches du client et le TAC à peu près
réactif. Ce n'est plus le cas je trouve d'après mes dernières expériences.

3) L'OS qui n'évolue pas, les fonctionnalités qui n'avancent pas
vraiment non plus. La CLI est d'un autre âge comparativement à ce qui se
fait ailleurs, le snmp n'a pas été au point non plus pendant des années
(je ne sais pas aujourd'hui).

4) La volonté chez nous de privilégier la stabilité bien avant le
budget. Et il y a le prix à l'achat qui peut paraître un argument de
poids et les coûts cachés derrière quand ça ne se passe pas bien. La
différence peut vite se réduire en prenant tout en compte.


Brocade c'est une solution quand on a un budget serré, une archi simple,
qu'on veut des perfs correctes et qu'on est prêt à passer du temps
humain dessus quand on veut faire des choses un peu plus évoluées. Ce
n'était pas notre cas.

2 routeurs, 2 transits, un site ça se passe très bien en général. Sur un
réseau plus large avec plusieurs sites, des liens longue distance, du
MPLS, de l'IP et du transport et tout le toutim, c'est un peu plus piégé.

C'est aussi une question de criticité des services. Un site web
inaccessible 2 minutes, c'est moche mais c'est pas dramatique. Sur
d'autres services c'est problématique.

Sinon le MLX normaux ça ne supporte plus les full view de mémoire non ?
Même en mettant une carte de management plus récente il me semble qu'on
doit changer le châssis et les cartes de ligne non ? L'offre de Brocade
était à base de MLXe pour info, je leur avait dit que ce n'était pas la
peine de présenter des CER(-RT) en face des ASR et MX.

Frédéric

P.S. : Sur les CER j'ai connu le BFD qui n'était pas en CPU secondaire
(pbif) et qui était en priorité basse par rapport au reste. Du coup les
voisins ne recevaient plus les signaux quand le routeur recalculait ses
routes, reroutaient à leur tour et boule de neige. La version suivante
de mémoire passait le BFD en pbif, par contre le polling snmp des
valeurs des optiques dans le CER (puissance optique, etc) entrainait une
montée à 100% du CPU principal (je ne suis même pas sûr que ça ait été
corrigé ça). Il fallait aussi faire attention aux protocoles dans
lesquels tu déclarais le BFD (OSPF/BGP/MPLS) parce que ça fonctionnait
plus ou moins correctement selon là où on le mettait. Bref, quand c'est
stable avec ce que tu utilises c'est cool, quand ça ne l'est pas c'est
pénible, surtout sur un réseau multisite.




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


Re: [FRnOG] [TECH] Compatibilité MPLS entre Juniper - Cisco

2014-08-29 Par sujet Frederic Dhieux

Le 29/08/14 10:34, Xhinfray a écrit :
 Personnellement je gere un backbone d'une 50aine de PE. Le coeur est en 
 juniper mx960 et les autres PE sont du cisco 7600. Le tout fonctionne très 
 bien depuis plusieurs années. 

Même avis, ça ne devrait pas poser de problème là dessus :)

Toutefois pour répondre à l'autre question, l'équivalent MX80 chez Cisco
serait l'ASR9001, bien qu'il soit un peu plus coûteux et performant, ça
me semble le plus proche.

Cordialement,
Frédéric


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


Re: [FRnOG] [TECH] Compatibilité MPLS entre Juniper - Cisco

2014-08-29 Par sujet Frederic Dhieux
Hello,

On est d'accord que la capacité d'un MX80 n'est pas celle d'un 9001,
reste que les 2 produits ont le même positionnement : Core router de PoP
périphérique compact 2U avec quelques ports 10G et possibilité de mettre
du 1G, de tenir une full view BGP et de gérer des peerings.

Je ne vois pas l'ASR1K dans ce registre, mais le MX80 correspond à ce
cahier des charges.

D'ailleurs c'est le produit que m'avait proposé Juniper à l'époque en
face de l'ASR9001 où je comparais pour changer notre backbone.
Effectivement derrière les capacités du 9001 ont fait la différence.
Juniper est revenu avec du MX104 tout juste sorti mais pas encore
vraiment sur le marché. Je pense qu'ils ont sorti le MX104 justement
parce qu'ils ont pris conscience de la faiblesse du MX80 face à
l'ASR9001 sur ce type de produit (core router compact pour PoP périphérique)


Le 29/08/14 14:21, aymeric marchand a écrit :
 L'asr 1k tu peux monter avec un 1013 avec une ESP200.

On parle de quel taille de chassis là ? ;) Pas trop comparable pour le coup

 Le 9001 c'est 120Gb/s max avec licence.

Quelle licence ? C'est une licence pour passer un 9001-S en 9001, mais
le 9001 normal n'a pas besoin de licence pour exploiter ses 120 Gbps de
capacité (4 ports built-in + 2 cartes 4x10G full rate).

 Après pour moi l'ASR 1K c'est plus du CPE que du core backbone.

+1

Frédéric


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


Re: [FRnOG] [TECH] Compatibilité MPLS entre Juniper - Cisco

2014-08-29 Par sujet Frederic Dhieux

Le 29/08/14 15:11, David Ponzone a écrit :
 Le 29 août 2014 à 14:39, aymeric marchand aymeric.marchand.e...@gmail.com a 
 écrit :
 Pour les bugs dans les 2 cas tu en auras.
 Et payer 15% de support annuel pour avoir des correctifs ou des solutions de 
 contournement….
 Ah le business-model de l’informatique est vraiment fabuleux :)

Des bugs il y en a chez tous, mais pour le moment je n'ai ouvert des
tickets au support que pour des questions de fonctionnalités concernant
les ASR. Autant Cisco Nexus on avait essuyé des plâtres, autant l'ASR ça
se passe vraiment bien.

Après je ne sors pas trop des sentiers battus sur du core router et je
lui fais pas faire des trucs spéciaux dans tous les sens, mais avec
d'autres constructeurs ça m'avait pas empêché d'avoir des merdes à une
époque :)

Frédéric


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


Re: [FRnOG] [TECH] Compatibilité MPLS entre Juniper - Cisco

2014-08-29 Par sujet Frederic Dhieux
Je pense que ça s'applique à beaucoup de constructeurs les 2 ans. Enfin
ça varie en fonction du succès du produit aussi...

Le 29/08/14 15:58, David Ponzone a écrit :
 T’as dérogé à la règle d’or: quand un produit Cisco sort, tu attends 2 ans, 
 et tu peux y aller.
 SI t’as pas le choix, tu fais un stock de guronzan et tu mets le numéro du 
 TAC en speed-dial.

 Le 29 août 2014 à 15:34, aymeric marchand aymeric.marchand.e...@gmail.com a 
 écrit :

 C'est marrant mon expérience est plus inverse. Bon le Nexus j'ai pas
 utilisé beaucoup de fonctionnalité, c'était surtout pour les ports 10G avec
 du 5548.

 Pour l'ASR avec de la crypto avec VRF ça n'a pas été la même chose, surtout
 quand ils ont ajouté la Suite B... Mais à partir de la 3.7-3.8 j'ai eu
 beaucoup moins de problème.


 Le 29 août 2014 15:29, Frederic Dhieux frede...@syn.fr a écrit :

 Le 29/08/14 15:11, David Ponzone a écrit :
 Le 29 août 2014 à 14:39, aymeric marchand 
 aymeric.marchand.e...@gmail.com a écrit :
 Pour les bugs dans les 2 cas tu en auras.
 Et payer 15% de support annuel pour avoir des correctifs ou des
 solutions de contournement….
 Ah le business-model de l’informatique est vraiment fabuleux :)
 Des bugs il y en a chez tous, mais pour le moment je n'ai ouvert des
 tickets au support que pour des questions de fonctionnalités concernant
 les ASR. Autant Cisco Nexus on avait essuyé des plâtres, autant l'ASR ça
 se passe vraiment bien.

 Après je ne sors pas trop des sentiers battus sur du core router et je
 lui fais pas faire des trucs spéciaux dans tous les sens, mais avec
 d'autres constructeurs ça m'avait pas empêché d'avoir des merdes à une
 époque :)

 Frédéric


 ---
 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] Compatibilité MPLS entre Juniper - Cisco

2014-08-29 Par sujet Frederic Dhieux

Le 29/08/14 16:06, David Ponzone a écrit :
 Ca dépend du cours des 720x / 7301. S'il remonte, à cause de #512k par
 exemple, l'asr 1k reprend du terrain. Mais à 500€- le gigot de LNS, même
 en prenant la conso en compte, il va falloir que les droïdes
 pousse-propales tirent un peu les propales vers le bas.
 DIs, faudra que tu me dises où tu as un 7204VXR/NPEG1 à 500€.
 La dernière fois que j’ai regardé, c’était quand même un peu plus que ça.
 Après, l’autre argument, c’est le 1U d’un ASR1001. La place en baie, ça a un 
 prix aussi.
 Et tu peux quand même agréger plus de choses sur un seul 1001 en 1U, qu’avec 
 un 7204 de 3U.

On peut aussi discuter de la conso électrique qui a tout autant un coût
en DC. Quand on voit ce que consomment les vieux routeurs Cisco...

Frédéric


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


Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

2014-08-28 Par sujet Frederic Dhieux

Le 28/08/14 18:56, David Ponzone a écrit :
 Le 28 août 2014 à 18:47, Pierre-Yves Maunier pymaunier+li...@gmail.com a 
 écrit :
 VRRP :
 - les 2 routeurs doivent avoir leur pate vers le serveurs dans le même L2 
 donc probablement vers un switch qui peut faire SPOF (sauf si c'est un 
 chassais)
 Doit y avoir un moyen de mettre 2 switchs en stack et de connecter le serveur 
 en LAG, un lien sur chaque switch.
 Est-ce que les hyperviseurs supportent LAG, c’est peut-être là que ça bloque.


vswitch, switchs en stack, même combat pour moi. Quand ton cluster/stack
tombe, ta redondance fait une sale tête :/

/plus confiance, déjà vécu

Frédéric


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


Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau

2014-08-19 Par sujet Frederic Dhieux
Bonjour,

Le 19/08/14 10:42, Benjamin BILLON a écrit :
 100Mo/s et c'est jugé par beaucoup comme étant relativement lent...
 Par qui, par exemple ? La grogne est généralement sur le débit de la
 connexion internet, pas sur celui du câblage horizontal. 

Au hasard quand on travaille sur un filer ou en partage avec d'autres
postes sur des données d'un certain volume ?

Cordialement,
Frédéric


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


Re: [FRnOG] [TECH] Cisco 7600 - 3BXL - incident 12/08 à 09h50

2014-08-13 Par sujet Frederic Dhieux
Hello,

J'en vois 498K à cet instant. Je dirais dans tous les cas que c'est
jouer avec le feu que de ne pas se donner de marge de sécurité là
dessus. Même à 460K, on est quand même pas loin des 512K et un
événement peut rapidement provoquer des problèmes :/ (d'autant plus si
on a des vrf à côté en bonus)

Sur nos anciens 7600 j'avais déjà passé la limite à 768K il y a un an
par sécurité justement.

Eventuellement sinon agréger les petits préfixes des /8 asiatiques voire
non européennes selon l'activité pour réduire le nombre de routes peut
aussi aider le temps de mettre les mamies 3BXL à la retraite :)

Cordialement,
Frédéric

Le 13/08/14 14:18, Anthony Sibiodon a écrit :
 BOnjour
 J'ai aussi vu cette augmentation de route 500 000 routes au lieu de 460
 000 auparavant de mémoire.

 Cordialement,

 Anthony SIBIODON








 Le 13/08/2014 14:12, « Nicolas KARP » li...@karp.fr a écrit :

 Bonjour,

 Nous avons atteint les limites en terme de routes sur nos 7600 hier matin
 à
 09h50:

 *Aug 12 09:49:56 %CFIB-SP-3-CFIB_EXCEPTION: FIB TCAM exception for IPv4
 unicast. Packets through some routes will be dropped.*
 *Aug 12 09:49:57 Use mls cef maximum-routes to modify the FIB TCAM
 partition or/and consider a hardware upgred.*
 *Aug 12 09:49:57 Examine your network and collect the necessary
 information
 from this setup. *
 *Aug 12 09:49:57 The only way to recover from this state is by reload the
 router.*


 Ça n'a pas duré assez longtemps pour qu'on trouve pourquoi mais en tout
 cas, nos 7600 se sont mis à faire un peu n'importe quoi pour certains
 préfixes.
 Nous avons donc appliquer la commande magique pour augmenter le nombre de
 routes et nous les avons rebooter.

 D'autres opérateurs/hébergeurs ont été impactés :
 http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-7000
 032566/

 Ce que je comprends pas, c'est qu'on était à 95% il y a 2 jours et tout
 d'un coup on atteint la limite. Vous savez ce qu'il s'est passé ?

 ​Merci d'avance.​

 Nicolas

 ---
 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] [JOBS] Administrateur système Linux chez Planet-Work

2014-07-24 Par sujet Frederic Dhieux

Le 24/07/2014 14:57, Sebastien Lesimple a écrit :

Ouais bottom Line, certains se sont comportés comme des trouduc...

Pour ceux qui postent les job le signal est back off t'as rien a foutre ici, 
pour ceux qui ont besoin d'un job pour payer les factures a la fin du mois 
c'est va voir pôle emploi.

Et si on laissaient les gens faire comme il le sentent?
Je sais ça fait trop libéralisme débridé mais quand on est pas directement 
concerne, a quoi ça sert de flinguer?

Seb.



Hello,

Complètement d'accord, cette manière de tomber systématiquement sur les 
gens qui postent des annonces ici ne véhicule qu'un message : Les 
donneurs de leçons qui agressent incessamment toute personne qui agit 
différemment de ce qu'ils souhaitent sont ici chez eux et toute personne 
qui ne se conforme pas à leur façon de penser ne mérite que de dégager 
ou d'être brûlé sur l'autel de la mailing. Bravo l'ouverture d'esprit et 
la tolérance.


Une annonce est une annonce, chacun adopte ses codes ou parfois ceux de 
sa boîte tout simplement. Si les gens s'y retrouvent tant mieux, si ça 
ne leur convient pas, qu'ils passent à autre chose. Ce besoin de vouloir 
éduquer d'un ton sévère les gens ne donne qu'une envie : Quitter la 
mailing et ne plus rien y mettre.


Factuellement : Reprenez les annonces postées sur la mailing depuis 1 an 
et regardez les réponses. C'est un sport national de flinguer les 
annonces et c'est bien dommage. Et si vous pensez c'est parce qu'elles 
sont toutes pourries, posez-vous un peu des questions sur votre jugement.


Se taper un mail d'annonce bien ou mauvais ça passe tout seul, se taper 
les 50 mails de critiques en reply derrière c'est un bruit très pénible 
en plus d'être négatif pour la communauté.


Frederic



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


Re: [FRnOG] [TECH] Statut adresses IPv4 .0

2014-07-21 Par sujet Frederic Dhieux

Le 21/07/2014 20:04, fr...@jack.fr.eu.org a écrit :

Donc, pour résumer, si je comprends bien, parcqu'une bande de dirigeants
ont une turpitude hideuse et on décidés de donner la gestion des
boiboites à des developpeurs en dilettante, il faut jeter quelque 16
millions d'IP tout à fait valide pour le reste ? C'est bien cela ?


Parce que ce n'est pas à ton client de payer les pots cassés de ton 
combat et être pénalisé par rapport au client voisin, c'est à toi de 
sacrifier ces IPs ou de les assigner à des services où ça ne pose pas de 
problème.


Combattre les aberrations du monde Internet c'est beau, le faire 
supporter à quelques clients en disant pas de bol c'est pour la bonne 
cause, ferme là c'est tout de suite moins beau.


Quand je vends un service à un client, j'entends lui vendre une qualité 
optimale et équivalente à mes autres clients. Parce qu'au delà de toute 
cause personnelle, je veux qu'il soit content de ce que je lui vends et 
qu'il profite d'Internet entier et complet. Les IPs à problème, ça sera 
pour moi ou pour des services particuliers et tant pis je prends sur moi 
de faire tampon et ça reste mon combat que j'assumerai.


On peut s'énerver aussi des bogons pas à jour qui peuvent pénaliser des 
blocs IPs, mais ça au moins c'est pas trop difficile à changer.



C'est cher payé l'incompétence, m'est avis, m'enfin, chacun voit midi à
sa porte, j'imagine ..


Oui c'est cher payé, surtout en période de pénurie, mais c'est la vie. 
Les ressources se raréfient, on a plus autant le loisir de sacrifier des 
IPs mal traitées. OVH fait certainement ça parce qu'Octave cherche des 
IPs depuis un moment et utilise donc tout ce qu'il a même celles qui 
posent problème, enfin j'imagine bien ça vu la quantité d'IPs qu'il utilise.


Maintenant j'en reviens à ce que je dis au dessus : Est-ce à ton client 
de payer l'incompétence d'un autre ? Ce n'est pas vraiment ma 
perception d'un service. C'est mon problème et c'est à moi de le 
supporter, pas à lui.


Il ne faut pas faire comme si le problème n'existait pas parce qu'il ne 
devrait pas exister. Il faut se battre pour qu'il n'existe plus. Ensuite 
on peut fonctionner normalement. C'est comme sur un équipement réseau. 
Quand tu as un bug, tu le contournes le temps d'avoir le correctif. Ce 
n'est pas normal et tu mets la pression à ton équipementier, mais en 
attendant tu fais avec parce que tu veux que ton service fonctionne.


Frederic


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


Re: [FRnOG] [TECH] - Panne de clim en salle 101 Iliad DC2

2014-07-09 Par sujet Frederic Dhieux

Le 09/07/2014 09:21, Laurent CARON a écrit :

On 09/07/2014 09:19, Raphaël HOAREAU wrote:

Bonjour,

Pas de soucis dans notre cold en salle 101. Températures normales.


Nous avons rencontré ce problème en rangée D (la température redescend).




Bonjour,

Pareil sur cette salle (40°C), par contre pas de problème au 1er étage.

Frédéric


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


Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2

2014-04-08 Par sujet Frederic Dhieux

Hello,


Le 08/04/14 12:27, Radu-Adrian Feurdean a écrit :


On Tue, Apr 8, 2014, at 11:40, David Ponzone wrote:

Sans parler des points d'arrivée des fibres sous-marines, si on voulait
juste isoler la France du reste du monde.

La France n'etant pas une ile, il faut couper du cable pendant bien
longtemps avant de l'isoler le pays. Et pas que du sous-marin.
En effet, si tous les cables sous-marins arrivant en France etait
coupes, l'impact serait plus grand pour d'autres (Asie, Moyen Orient),
et la France sera minimalement impacte (tout comme la Grande-Bretagne).
Il y a BEAUCOUP de capacite terrestre qui relie la France au monde
exterieur.


Je suis d'accord, il ne faut pas exagérer le fantasme sur le chaos Internet en France lié 
à TH2 ou aux liens sur Paris. Sinon c'est que beaucoup de gens font mal leur métier. 
Quand je prends un lien vers d'autres pays, je fais comme tout opérateur 
normal dans le monde d'Internet : Je prends 2 chemins distincts, je m'assure 
que les chemins de fibre ne passent pas par le même PoP (TH2, SFR, Gardinoux ou autre 
points connus). Ca passe en général par Londres, par Francfort, par Bruxelles pour le 
Nord de l'Europe typiquement.

Pour la fibre noire dans Paris c'est pareil, beaucoup de sites ont plusieurs 
arrivées distinctes qui permettent de faire en sorte que les fibres ne se 
croisent jamais. A moins d'une erreur humaine et d'un manque de sérieux dans 
l'étude du projet, il est facile en France de s'assurer des chemins diversifiés 
en redondance. D'autant que les gens dont c'est le métier de passer de la fibre 
ont déjà prévu ça (et que les fournisseurs donne même régulièrement le kmz qui 
va bien).

En se renseignant un peu aussi, on évite de prendre un opérateur de transit IP 
qui remonte sur le même PoP que les autres, beaucoup de Tier1 sont présents sur 
des sites différents de TH2 en coeur de réseau également (Level 3 remonte tout 
sur Nanterre, d'autres sont sur SFR Netcenter ou en propre et maintenant 
plusieurs vont mettre un coeur sur Iliad DC3).

Les points de peering sont en général un bonus qualité, c'est acceptable de 
les perdre et à ma connaissance sur Paris il suffit d'être chez Equinix, InterXion ou Telecity pour 
avoir une alternative à TH2 pour les IX parisiens.

Et il ne faut pas chercher longtemps pour trouver des pays où la situation est 
bien plus compliquée qu'en France. Hong Kong par exemple où il est difficile de 
se faire livrer un circuit international ailleurs que chez Mega IAdvantage 
(enfin on peut, mais ça passe par ce PoP quand même). A New York les PoPs 
historiques 60 Hudson Street et 111 8th sont quasi incontournables aussi et 
franchement TH2 a l'air ultra moderne à côté (surtout pour Hudson Street).

Tout le monde est à TH2 mais beaucoup ont aussi une redondance ailleurs (hormis 
peut-être sur de la collecte), du coup ça impacte du monde, mais la résilience 
est souvent là pour éviter le drame.

Les serveurs de données sont souvent ailleurs (au prix de la baie sur TH2...), 
du coup c'est pas le plus compliqué à sécuriser qui se trouve sur TH2. Je me 
souviens de la panne de Redbus, c'était plus un problème de données sur site 
que de réseau au final qui avait impacté le web français.

Du coup, qui faut-il blâmer si ça tombe ? Pour moi pas le datacenter, pas celui 
qui fournit les liens (qui sait présenter des chemins distincts et livrer sur 
d'autres PoP), pas non plus les grands opérateurs de transit qui ne se 
concentrent pas sur TH2 uniquement. Par contre peut-être l'opérateur final qui 
fait des économies et se permet quelques SPOF sur son réseau en concentrant 
trop son coeur sur uniquement TH2.

De là à dire que la France dépend trop de TH2, on n'y est pas je trouve. Qui 
ici craint pour son activité globale si TH2 tombe ? Et pourquoi ? Parce que le 
fournisseur (pas cher et unique ?) n'est pas présent ailleurs ? Parce que ça 
coûte plus cher d'avoir un autre point de raccordement ailleurs ? La question 
n'est-elle pas plus économique que technique au final ? Les infrastructures 
permettent de faire les choses bien, on a ce qu'il faut techniquement en France 
et personnellement j'ai jamais été bloqué techniquement pour redonder une infra 
sur Paris.

My 2 cents,
Frederic


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


Re: [FRnOG] [ALERT] chaleur en ce 9 mars

2014-03-09 Par sujet Frederic Dhieux

Ca a l'air de revenir, je suis redescendu de 39,9°C à 36,2°C là... (au 3eme)

Impacté sur le 1er et le 3eme. Pas eu de retour de TH2 encore par contre 
pour avoir les infos sur ce qu'il se passe.


Frédéric

Le 09/03/2014 21:45, Raphael Mazelier a écrit :

2eme et 3eme.
Une panne de climatisation un 9 mars...
C'est vraiment des champions TH2.



Le 09/03/2014 21:35, Julien (JaXX) Banchet a écrit :

Bonsoir

Pareil au 3ème, j’ai déjà de l'impacte

JaXX./.

--
De: Pierre-Olivier Lompre pier...@gmail.com
Répondre: pier...@gmail.com pier...@gmail.com
Date: 9 mars 2014 at 21:27:01
À: Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr
Cc: frnog-al...@frnog.org frnog-al...@frnog.org
Sujet:  Re: [FRnOG] [ALERT] chaleur en ce 9 mars


Bonsoir
  Je confirme de notre coté sur la salle NERIM (11-15 est). Température
élevée.
  Pierre-Olivier
Le 9 mars 2014 20:09, Bruno CAVROS / SKIWEBCENTER a
écrit :

Bonsoir,



Meteo France annonce des records en ce 9 mars, il semble qu'il en 
soit de

même au 137 boulevard voltaire...



Sauna, hamman inclus ?



Bonne soirée



Bruno



SKIWEBCENTER

Tel: +33 3 21 15 15 98 Fax: +33 3 21 15 15 99

www.skiwebcenter.com / i...@skiwebcenter.com




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


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

--
Julien (JaXX) Banchet


---
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] Gamme Juniper ?

2014-03-05 Par sujet Frederic Dhieux
Le 3/5/14 5:13 PM, Thomas Mangin a écrit :
 On 5 Mar 2014, at 15:56, Xavier Beaudouin k...@oav.net wrote:
 Les open policy qui ne peerent pas sur les routes servers - joker.

 Non. peerer sur un route server comporte des risques, comme par example la 
 separation du chemin BGP et des données qui fait que la session peut rester 
 up quand les donnees vont vers un trou noir. Un risque que certaines 
 organisations refusent. 

+1, accessoirement c'est plus chiant d'isoler quelqu'un qui fait des
saloperies avec ses annonces également et si les 2 RS tombent (bug,
problème, etc), tu perds tout le monde d'un coup et ça peut poser
quelques problèmes de qualité.

Les RS c'est bien, mais pour moi il ne faut pas le voir comme du fiable.
C'est là où tu mets les gens avec qui tu as envie de peerer mais qui ne
représentent pas un besoin qualitatif réel pour toi.

Frédéric


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


Re: [FRnOG] [MISC] FRNOG 22.0 - RC1

2014-02-27 Par sujet Frederic Dhieux
Bonjour,

Il y a un point que je ne comprends pas. Le FRnOG est (je cite)  une
plate-forme d'échange d'informations entre professionnels du réseau et
de la sécurité. Les conférences durant la réunion sont techniques et
visent un public technique dans le domaine du réseau et de la sécurité.
Comment un captcha basé sur une question basique technique sur un
composant de la vie du réseau (certes un peu démodé mais quand même)
peut rebuter quelqu'un d'aller à cette réunion s'il se sent concerné par
les sujets abordés ?

Si ce capcha déstabilise la personne, qu'en sera-t'il des sujets
techniques abordés ? Des termes utilisés dans les présentations ?
Franchement, je ne comprends pas là...

Bonne journée,
Frédéric

Le 2/27/14 10:50 AM, technicien hahd a écrit :
 Un petit retour d'expérience sur ce captcha.

 Nous sommes un fai associatif rural qui existe depuis 10 ans et qui regroupe 
 une centaine d'abonnés. J'ai remonté l'info de la prochaine réunion FRnOG à 
 l'actuel président de l'asso, qui n'est pas de formation technique, et qui 
 trouvait intéréssant que notre asso s'y rende.

 À la vue de ce captcha, il a instantanément abandonné l'idée. Pas parce qu'on 
 est pas capable de trouver la solution du captcha en cherchant sur le web 
 mais 
 à cause du message qu'il porte: ça ressemble plus à un si tu ne sais pas ce 
 que c'est, tu n'as rien à faire à notre réunion qu'à un outil de prévention 
 des bots.

 Un captcha pour lutter contre les bots de spam qui n'est pas une barrière 
 d'entrée déguisée se doit d'être trivial à résoudre, généralement une simple 
 opération arithmétique ou une question du niveau de quelle est la première 
 lettre de l'alphabet?.

 Ce captcha est certainement aussi efficace contre les bots qu'un autre, mais 
 il 
 a aussi une certaine efficacité à limiter la participation des humains. 

 AMHA cette barrière d'entrée déguisée est une forme de FUD qui ne va pas dans 
 le sens de l'objectif affiché en accueil du site web FRnOG.


 On Wednesday 26 February 2014 15:29:19 Guillaume Leclanche wrote:
 Salut,

 visiblement tu n'étais pas inscrit sur la liste en janvier 2013 sinon tu
 saurais que tous ceux qui l'étaient et viennent de lire ton message ont eu
 soudainement des sueurs froides en pensant à la boîte de Pandore que tu
 viens d'ouvrir.

 https://www.mail-archive.com/frnog@frnog.org/msg22017.html

 Bonne lecture ;)
 Guillaume



 Le 26 février 2014 13:41, Florent Peterschmitt flor...@peterschmitt.fr a

 écrit :
 On 26/02/2014 01:17, Philippe Bourcier wrote:
 Bonjour,

 La prochaine réunion FRNOG sera le 4 Avril 2014.

 Programme (beta) et inscription sur :
 http://www.frnog.org/?page=frnog22


 Cordialement,
 C'est terriblement frustrant, un captcha dont on ne connaît pas la
 réponse :°

 --
 Florent Peterschmitt   | Please:
 flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
 http://florent.peterschmitt.fr |  * Send PDF for documents.
 Proudly powered by FLOSS   |  * Trim your quotations. Really.

| Thank you :)
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/

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


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


Re: [FRnOG] [MISC] FRNOG 22.0 - RC1

2014-02-27 Par sujet Frederic Dhieux
Je me désinscris de ce pas d'ailleurs, le doute m'envahit, on ne
respecte même plus le vendredi ici. Je pense qu'il faut faire quelque chose.

Le 2/27/14 11:18 AM, Florent Peterschmitt a écrit :
 Effectivement, c’est là une belle boîte que j’ai ré-ouvert !

 Après avoir lu le mail de Frederic Dhieux sur la question, je ne peux
 qu’être d’accord avec lui : étant une véritable tanche sur la question
 des réseaux, je pense qu’une telle réunion serait pour moi trop « high
 level ».

 Il n’empêche que c’est frustrant ;P

 On 26/02/2014 21:29, Guillaume Leclanche wrote:
 Salut,

 visiblement tu n'étais pas inscrit sur la liste en janvier 2013 sinon tu
 saurais que tous ceux qui l'étaient et viennent de lire ton message ont eu
 soudainement des sueurs froides en pensant à la boîte de Pandore que tu
 viens d'ouvrir.

 https://www.mail-archive.com/frnog@frnog.org/msg22017.html

 Bonne lecture ;)
 Guillaume



 Le 26 février 2014 13:41, Florent Peterschmitt flor...@peterschmitt.fr a
 écrit :

 On 26/02/2014 01:17, Philippe Bourcier wrote:
 Bonjour,

 La prochaine réunion FRNOG sera le 4 Avril 2014.

 Programme (beta) et inscription sur :
 http://www.frnog.org/?page=frnog22


 Cordialement,
 C'est terriblement frustrant, un captcha dont on ne connaît pas la
 réponse :°

 --
 Florent Peterschmitt   | Please:
 flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
 http://florent.peterschmitt.fr |  * Send PDF for documents.
 Proudly powered by FLOSS   |  * Trim your quotations. Really.
| Thank you :)


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



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


Re: [FRnOG] [TECH] Routeurs cisco

2014-02-25 Par sujet Frederic Dhieux
Bonsoir,

Le 2/25/14 6:41 PM, Jérôme Nicolle a écrit :

 un conseil, vu tes besoins, utilise un vrai routeur (2811 trop faible).
 j'ai appris par expérience qu'un switch est au top si tu t'en sert pour
 switcher, rien d'autre, même s'il a les capacité de faire autre chose
 sauf si tu passes sur des modèles 76XX (10.000 fois plus cher)avec plein
 de ram.

 Pour ce besoin c'est bien de switchs dont il a besoin. Le 6500 (pas
 7600) pourrait convenir, c'est une question d'architecture de câblage
 pour le coup. Et non, un 6k ça coute pas cher, plutôt moins qu'un
 3560G pour une config à plusieurs linecard 48 ports giga. 6509+SUP32
 rempli de 6548GE-TX tu vas toucher ça à moins de 2.5k€, contre 3.5k€
 au cours actuel du 3560G 48 ports.


Outre la place que ça prend un 6509 (enfin 2 pour le coup avec la
redondance), on peut aussi parler de sa conso électrique, c'est pas
forcément une bonne affaire dans la durée au prix actuel de
l'électricité en DC.

Frederic


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


Re: [FRnOG] [TECH] Routeurs cisco

2014-02-25 Par sujet Frederic Dhieux

Le 25/02/2014 20:10, Radu-Adrian Feurdean a écrit :


Son probleme etant parmi autres choses, la licence IPBase :)



C'est un faux problème, pour le 3560G la version IOS 12.2 IP Services 
est téléchargeable sur le site Cisco librement maintenant. La 15.0 par 
contre n'est publiquement accessible que pour IPBase. On peut déjà faire 
pas mal de chose avec la 12.2.


Frédéric


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


Re: [FRnOG] [TECH] Routeurs cisco

2014-02-24 Par sujet Frederic Dhieux
Le 2/24/14 6:07 PM, Michel Py a écrit :
 Jeremy a écrit:
 depuis qu'on a démarré 1500 routes statiques sur chaque équipements
 (2), on a de gros bagots à chaque fois qu'on rajoute une route.
 J'aimerais bien savoir comment tu en arrives à autant de routes. Combien de 
 serveurs tu héberges ?

 Michel.


Hello,

Je me posais la même question, est-ce qu'une refonte et une optimisation
du design ne serait pas plus efficace que la recherche d'un équipement
gérant mieux 1500 routes statiques ?

Frédéric


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


Re: [FRnOG] Re: [MISC] L'Internet européen

2014-02-17 Par sujet Frederic Dhieux

Hello,

Oui complètement, de la même manière que le statut de l'AMS-IX avec son 
lancement aux US a posé un gros débat sur le droit américain applicable 
en Europe si la société devenait américaine pour la gestion des 2.


Ce qui ne me plait pas, c'est que si on dépend autant des américains 
pour faire passer des données d'Europe à Europe (Level 3, Cogent, etc), 
c'est a priori parce qu'on n'est pas assez bons dans ce qu'on fait en 
Europe. On a les tuyaux, on a pour moi de meilleurs points d'échange, on 
a des gros opérateurs européens. D'ailleurs je ne suis pas si sûr avec 
tout ça que tant de données passent par des acteurs américains au final 
en Europe pour de l'échange Europe Europe (enfin si, après tout Cogent a 
réussi à séduire du monde en faisant des prix ridicules, si ça se trouve 
c'est l'état américain qui les finance en fait ? :D ).


Par contre que les services US soient utilisés (Google, Facebook et MS) 
en applicatif et que ça pose un problème, j'y crois beaucoup plus. Que 
les points d'échanges européens soient compromis sans que le droit 
américain y soit pour quelque chose aussi. Et même pourquoi pas un TAP 
placé sur du cross connect par un datacenter de marque américaine ?


Pour finir, je pense toujours que le protectionnisme est un aveu d'échec 
dans un monde de compétitivité. C'est parfois nécessaire mais ça reste 
toujours pour moi un choix du pauvre. La grande Europe ce n'est pas 
encore ça...


Frédéric

Le 17/02/2014 11:14, Kavé Salamatian a écrit :

Stéphane,

si ca passe par un opérateur ou un acteur européen cela signifie que ça passe 
par la surveillance des états-unis. C’est pas important que ça passe 
physiquement par le territoire américain qui est important, c’est que ça passe 
par la juridiction américaine qui compte !

Kv
Le 17 févr. 2014 à 10:46, Stephane Bortzmeyer bortzme...@nic.fr a écrit :


On Mon, Feb 17, 2014 at 10:40:47AM +0100,
Alarig Le Lay ala...@swordarmor.fr wrote
a message of 138 lines which said:


L’idée n’est pas de faire un réseau limité à l’Europe mais d’éviter
que tout passe systématiquement par les USA.

La connectivité de l'Europe actuelle étant ce qu'elle est, un
traceroute entre Alice et Bob, lorsqu'ils sont tous les deux en
Europe, reste en général en Europe.

Prétendre qu'actuellement « tout passe systématiquement par les USA »
est clairement faux.


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


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



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


[FRnOG] [TECH] Reroutages et problèmes sur Internet

2014-02-11 Par sujet Frederic Dhieux
Hello,

Je vois pas mal de choses se passer depuis ce matin vers 10h (reroutages
sur pas mal d'opérateurs, services Google down, etc). Rien qui nous
impacte, mais vous avez une idée de ce qui se passe ?

Frédéric


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


Re: [FRnOG] [TECH] Reroutages et problèmes sur Internet

2014-02-11 Par sujet Frederic Dhieux
C'est curieux que Google (dns et google.com) soit down un temps à cause
d'une coupure fibre, pour le reste des reroutages par contre c'est
plutôt cohérent.

Frederic

Le 2/11/14 4:09 PM, Raphael Maunier a écrit :
 C’est depuis hier cette attaque, ce matin c’est clairement la fibre qui est 
 tombé. Normalement ça devrait revenir sous peu

 Raphael

 On 11 Feb 2014, at 10:06, Thomas Pedoussaut tho...@pedoussaut.com wrote:

 Ou peut etre le DDOS en cours (via amplification ntp)

 http://tech.slashdot.org/story/14/02/11/0349259/ddos-larger-than-the-spamhaus-attack-strikes-us-and-europe

 On 02/11/2014 03:36 PM, Raphael Maunier wrote:
 Hello,

 Coupure fibre sur l’Allemagne

 Raphael


 On 11 Feb 2014, at 09:26, Frederic Dhieux frede...@syn.fr wrote:

 Hello,

 Je vois pas mal de choses se passer depuis ce matin vers 10h (reroutages
 sur pas mal d'opérateurs, services Google down, etc). Rien qui nous
 impacte, mais vous avez une idée de ce qui se passe ?

 Frédéric


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


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


Re: [FRnOG] [MISC] Amplifications NTP

2014-02-01 Par sujet Frederic Dhieux
Il y a 2-3 semaines un serveur chez un client dont le ntp était ouvert 
par erreur a été utilisé pour de l'amplification, c'était effectivement 
assez visible en volume sortant chez nous et plutôt agressif.


Sans Netflow on ne l'aurait surement pas vu avant un moment...

Ecritel y'a une semaine, Colt ces derniers jours, il y a peut-être des 
gens qui trouvent le marché de l'anti-DDoS en France pas assez 
florissant en ce moment :p


Frédéric

Le 01/02/2014 14:55, David Ramahefason a écrit :

COLT en souffre sur Paris depuis qq jours.
  
--

David Ramahefason


Le 1 février 2014 at 14:54:36, Thierry Wehr (t.w...@widevoip.com) a écrit:

Hello tous

certaines infrastructures doivent prendre très chère avec les amplifications 
NTP en cours !

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

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



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


Re: [FRnOG] [MISC] Amplifications NTP

2014-02-01 Par sujet Frederic Dhieux
Le 2/1/14 10:15 PM, Raphael Maunier a écrit :
 On 01 Feb 2014, at 22:02, Radu-Adrian Feurdean 
 fr...@radu-adrian.feurdean.net wrote:

 On Sat, Feb 1, 2014, at 18:18, Raphael Maunier wrote:
 Un routeur c’est pas comme une voiture ou tu réceptionnes pas la caisse
 et tu l’utilise direct.
 Si on devait avoir des voitures comme les routeurs, apres l'achat il
 faudrait automatiquement faire :
 - changer les penus
 - faire une vidange
 - flasher l'ordinateur de bord (avec la derniere version qui a telle ou
 telle fonctionalite et pas tel ou tel bug)
 - faire une vingtaine de reglages cote moteur faute de quoi on risque
 d'arriver a l'hosiptal ou au cimitiere au lieu de chez soi.
 C’est bien ce que je dis, tu dois forcement faire des choses sur tout les 
 routeurs que ce soit, Juniper, Cisco, Brocade ( surtout ) , and cie.
 Tu ne peux pas juste passer ta commande, prendre le routeur, et faire le 
 wizard BGP :)

 En gros, on fait du tuning de routeur :)
 Oui, sauf que la on est dans plein bug-fix.
 Y a plein de bugs que pleins de gens ne voient pas parce que les règles 
 d’ingénierie sont bonnes des le depart.

 C’est justement que je connais bien Juniper que je ne fais pas 100% confiance 
 et que je fais en sorte de ne pas avoir ce genre de problème.
 J’ai en ce moment plus de 4 ou 5 bugs complement pourris avec Juniper et des 
 trucs bien débiles. L’avantage, c’est que je peux tester facilement, avoir 
 accès du lab pour trouver ou ça coince !

 Il faut arrêter de croire que parce que j’utilise et que j’en ai vendu que 
 chez Juniper est tout rose pour moi aussi :) 
 J’ai fais 3 nuits debug bien agréables sur du junos ou d’une version à une 
 autre tu n’as pas le meme comportement.
 Pareil lorsque tu changes de version ( c’est le cas pour le NTP par exemple 
 ), il y a des failles qui apparaissent.
  
 Ils sont super fort pour aussi changer certains paramètres de configuration, 
 ou d’une version x.x vers x.y et  , tu dois changer tes templates. ( je 
 crois que ça c’est la chose la plus pénible que j’ai en ce moment )

 Bref, les constructeurs font et feront toujours de la merde, on le sait tous, 
 et c’est au client de se prémunir, de réparer, et d’avoir une meilleure reduc 
 la prochaine fois que ton gentil commercial viendra te payer à bouffer !


Je vais être taquin : Je croyais que ça juste marche-ait Juniper ? :p

On en revient à ce que je disais sur un autre sujet, la qualité d'un
constructeur dépend aussi de l'habitude qu'on en a.

 Imagine que chaque fois que tu fais un telnet depuis un routeur, le
 serveur telnet s'active…..
 Bah il faut s’y attendre !

Je dirais qu'il faut plutôt le redouter et en être choqué quand ça arrive :/

La confiance n'exclut pas le contrôle, mais le contrôle peut entamer la
confiance...


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


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


Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

2014-01-31 Par sujet Frederic Dhieux
Le 1/31/14 11:10 AM, Sylvain Vallerot a écrit :


 On 30/01/2014 20:46, Edelwin Khaelos wrote:
 Stop les chamailleries et attaques ad hominem, plz...

 S'agit pas de ça, on parle de l'importance de la relation
 dans les processus de sécurité.


Personnellement je parlais du système et de ses incohérences plutôt,
mais bon tu sembles vouloir orienter la discussion sur ce pauvre gardien
dont la seule critique que j'ai faite et d'avoir cherché une excuse pour
expliquer l'incohérence du système.

Et je n'ai pas pris la peine de répondre car effectivement je trouvais
que le ton ne donnait pas envie de le faire (après je manque de sommeil
et on a essayé de me faire passer un cross to MMR 12 000 Euros le 12FO
hier, donc je suis moins tolérant que d'habitude peut-être :) ).

/end of story

 Au fait en ce moment je participe au test du nouveau portail
 de TH, j'imagine que je ne suis pas le seul ? C'est à mon
 sens une bonne manière de faire progresser les choses pour
 eux, que d'intégrer les remarques des clients.



Tester un produit c'est bien, faire une enquête auprès des clients avant
c'est mieux :)


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


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


Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

2014-01-31 Par sujet Frederic Dhieux
Le 1/31/14 5:11 PM, Clement Cavadore a écrit :
 On Fri, 2014-01-31 at 17:02 +0100, Frederic Dhieux wrote:
 me faire passer un cross to MMR 12 000 Euros le 12FO
 hier, donc je suis moins tolérant que d'habitude peut-être :) ). 
 What ?!?
 Il y a un moment, faut arrêter de se croire sur le marché US, et arrêter
 de se foutre de la gueule du monde, un breakout, même SM, c'est pas ce
 prix là... même si le mec passe une journée à le passer, et qu'il est
 payé à prix d'or !

 Par curiosité, combien en récurrent ? 50€/mois/paire, c'est ca ? :)
Un cross connect temporaire pour migrer, un espèce de record de foutage
de gueule =)

Bref, n'allons pas dans le H.S. ;)


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


Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

2014-01-30 Par sujet Frederic Dhieux

Le 30/01/2014 11:30, Sylvain Vallerot a écrit :



On 30/01/2014 02:31, Frederic Dhieux wrote:

Et surtout ça fait près de 1 mois que je fais des
migrations 2 à 3 nuits par semaine sur ce site sans que rien ne
me soit signalé quant à la péremption de cette pièce d'identité :D


Le système de TH demande une pièce d'identité valable mais pas
qu'elle soit en cours de validité. Simplement si c'est pas le cas,
le système le signale.

En fait c'est plutôt ce gardien qui était pas très au courant de
ce détail, du coup il a probablement rien forcé du tout, d'ailleurs
je doute qu'il en ait la possibilité.



le côté erratique de la chose est pénible au possible...


Comme de se pointer sur un site avec une CI périmée sans savoir
si la procédure le permet par exemple ?  ;-)



Excuse moi, mais à ma connaissance, quand je passe plusieurs années à 
utiliser cette même CI et que du jour au lendemain on me dit que ça pose 
un problème, je ne considère pas que ce soit un cas normal et le mot 
erratique prend tout son sens. Quand un DC me dira à la première visite 
que ça ne convient pas, je n'irai pas pleurer sur mon sort, là par 
contre quand je passe 15 jours à aller sur ce site quasi toutes les 
nuits et que le comportement change sans cohérence, je pense que je suis 
en droit de trouver ça anormal.



L'erreur est humaine je dirais. Oui c'est parfois pénible et sur ce
site un peu plus de rigueur serait parfois la bienvenue car on a
moins la patience quand on est pressé.

Par contre d'expérience 30 secondes de patience avec le sourire
peuvent vous rendre les relations bien plus agréables, et vous
enlever beaucoup d'épines du pied parce que les gens sont aussi
plus souples.



Qu'est-ce qui te fait dire que je n'ai pas été aimable et patient avec 
la personne ? Je l'ai été, je suis entré, ce qui ne m'empêche pas d'être 
un peu agacé de l'incohérence et de le partager ici dans un sujet tout à 
fait approprié (ce que j'aurais gardé pour moi si le sujet n'était pas 
en cours).




Bonne journée,
Sylvain




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



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


Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

2014-01-29 Par sujet Frederic Dhieux
Ah bah faut croire que l'envie de multiplier les expériences négatives
les motive là :)

Ce soir en allant sur ce même site, le premier gardien de nuit me dit
que ma pièce d'identité est expirée d'après le système. Il est vrai
qu'elle l'est depuis quelques années cette carte d'identité, pour autant
je ne me fais jamais refouler sur les DC avec (et j'y vais souvent sur
plusieurs différents). Et surtout ça fait près de 1 mois que je fais des
migrations 2 à 3 nuits par semaine sur ce site sans que rien ne me soit
signalé quant à la péremption de cette pièce d'identité :D

J'aime bien quand ce gardien me dit que surement c'est parce que ce sont
ses collègues que j'ai eu, alors que c'est souvent lui qui me reçoit à
cette heure tardive et que c'est bien le système qui gueule là pour le
coup :D

Je passe sur la porte de la salle dans laquelle je suis où j'ai mes
accès sont mis sur le badge une fois sur deux...

Autant ça me saoule les procédures chiantes et pas très optimisées mais
je peux comprendre, autant le côté erratique de la chose est pénible au
possible... Bien sûr un permis de conduire n'est pas accepté, mais bon
au moins il a forcé le système pour me laisser entrer.

Ma petite histoire de nuit d'inter =) (et mes 20 min pour accéder à ma baie)

Bonne nuit,
Frederic


Le 1/29/14 7:14 PM, Philippe Marrot a écrit :
 Bonjour,

 Puisque le sujet est lancé, il serait peut être interessant de mettre en
 place un panorama actualisé
 (façon indice de qualité) des accès aux DC parisiens, pourquoi pas ?

 J'en profite pour un coup de gueule concernant l'acceuil technique d'un DC
 de Paris 11ème...

 Entre les erreurs d'interco internes, les changements de procédure décidés
 sans communication,
 et surtout la mauvaise volonté permanente de l'équipe qui se semble se
 croire à la Sécu,
 je n'ai jamais vu une telle fumisterie (y a pas d'autres mots)

 Je passe aussi sur les cartes d'accès qui ne sont pas bien activées une
 fois sur 2,
 jusqu'au le tourniquet à l'acceuil qui déconne,, bref , peut vraiment mieux
 faire...

 PM.








 Le 24 janvier 2014 20:30, Thierry Del-Monte tdelmo...@integra.fr a écrit :

 Le 24/01/2014 19:16, Clement Cavadore a écrit :

 En ce qui me concerne, je trouve que le plus efficace, ca a toujours été
 les badges nominatifs qu'on emporte avec nous + biométrie.
 Au moins, si tu es permanent, tu n'as pas besoin d'intéragir avec les
 droides a l'entrée, ni à faire la queue s'il y a affluence.


 Par contre, chaque fois qu'il faut faire des autorisation, c'est presque
 systématique, et quel que soit le DC: On a rien recu. C'est facheux,
 quand même... surtout quand tu SAIS que le mail est parti :-)

 On Fri, 2014-01-24 at 19:11 +0100, Nathan delhaye wrote:

 Personellement, je n'ai jamais vu de soucis avec les badges nominatifs.

 Par contre c'est vrai que c'est assez casse-pied de devoir faire deux
 fois
 les accès entre PA2 et PA3. Et pour certains ce n'est pas si exceptionnel
 que ca...
   Le 24 janv. 2014 18:30, Radu-Adrian Feurdean 
 fr...@radu-adrian.feurdean.net a écrit :

  On Fri, Jan 24, 2014, at 15:00, Nathan delhaye wrote:
 Suffit de demander un accès permanent si vous y allez souvent...

 Mais meme quand on a le badge permanent, si on gagne pas la lotterie des
 badges a son propre nom, il faut perdre chaque fois du temps avec le
 re-enregistrement des empreintes + programmation du badge.

 Quand on fait partie des hereux gagnants, il reste uniquement la partie
 entree dans le campus (gere par DRT), et le fait qu'on a quand-meme
 50% de chance de devoir attendre derriere X autres personnes qui
 entrent/sortent du site. Pas exactement probleme de procedure, mais de
 capacite d'accueil.

 Par contre ce qui rend les choses penibles c'est le fait de ne pas avoir
 un acces permanent (deja evoque) ou de ne pas etre client direct, du
 coup devoir passer par X autre intermediaires avant d'arriver sur une
 liste d'access. La faute dans ce cas n'est pas toujours du cote du DC.

 Autre cas exceptionnel (je sais pas si ca evolue les 12 derniers mois),
 c'est quand on a des choses a faire entre PA2 et PA3, ou chaque site a
 son propre system d'acces et on peut etre amenes a repeter la procedure
 chaque fois qu'on change de site (alors que les deux sont a 100m l'un de
 l'autre et geres par les memes).

  la procédure consiste a mettre 3 fois sa main sur le détecteur et doit
 durer moins d'une minute... on peut pas dire que ce soit très
 contraignant quand même.

 Sauf quand on y est a 3 ou 4. Ou quand on doit attendre encore X
 personnes qui sont dans la meme situation. Tout ca parce qu'ils ont que
 rarement des bagdes a alouer par personne de facon permanente (voir
 plus haut).

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


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

 Clément, c'est hasbeen les mails ;-)
 Maintenant y a le portail web et franchement sur Equinix et Interxion
 c'est plutôt bien foutu et j'ai jamais 

Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

2014-01-20 Par sujet Frederic Dhieux
Bonjour,

Forcément je partage un certain agacement sur le sujet. On prévoit
toujours 10 min à parfois 30 min dans le planning rien que pour cette
partie qui consiste à entrer sur le site.

Les raisons sont en général (ça liste tous les DC) :
- Mauvais fonctionnement des outils et non maitrise par la personne à
l'entrée
- Procédure compliquée qui pourrait être optimisée par de meilleurs
outils (souvent)
- Personne à l'entrée débordée par le travail quand il y a du monde (et
des livraisons)
- Recherche du badge de la personne dans un tiroir rempli de tas de badges
- Badge expiré annuellement sans prévenir par mail (ravi quand tu es en
urgence à 3h du mat et que le site est sans personnel youpi). A noter
que par contre en temps normal c'est le site le plus simple et rapide
puisque badge + emprunte palmaire et aucun humain
- Système rétinien qui fonctionne pas
- Personnel de sécurité en ronde et personne à l'accueil (pour le site
ou le DC)

Plutôt que de distribuer les mauvais points, je dirais aujourd'hui
qu'Iliad a le meilleur fonctionnement avec Level 3 le Capitole (sauf
l'histoire de l'expiration auto annuelle sans prévenir pour ce dernier).

Souvent je préfère d'ailleurs aller de nuit en DC, tu sais que tu peux
attendre parfois que le mec revienne de ronde ou que tu le réveilles,
mais en général une fois que tu as la personne, elle s'occupe de toi
pleinement.

Le problème je trouve, c'est que les DC font des procédures poussées
pour la sécurité (c'est bien), mais adaptent mal des outils pour
celles-ci, rendant le fonctionnement compliqué pour tout le monde et
surtout pour un personnel d'abord formé à la sécurité du batiment.

On sait aussi qu'un salaire c'est un coût et que le fait d'avoir peu de
personnel et de rassembler les fonctions n'aide pas.

De toute façon en règle générale les DC sont un vortex temporel, tu
penses passer un certain temps au départ et inexorablement quand tu sors
tu as fait un plus grand bond dans le temps que prévu :D

Frederic


Le 1/20/14 10:07 AM, Clement Cavadore a écrit :
 Bonjour,

 J'aimerais lançer une discussion auprès des gens habitués à accéder aux
 datacenters: Quelle est votre opinion concernant la facilité d'accès aux
 diverses salles machines que vous fréquentez ?

 En ce qui me concerne, j'ai eu l'occasion, depuis une grosse dizaine
 d'années, de visiter plusieurs datacenters de la place Parisienne (et
 d'ailleurs), et force est de constater que la facilité/rapidité/etc
 d'accès est très variable (pas forcément dans le bon sens), en fonction
 des procédures de sécurité en vigueur dans $datacenter, de la taille de
 celui-ci, et des interlocuteurs que l'on a en face de soi. 


 Selon que l'on soit permanent ou pas, que l'on aie un badge ou un tag
 (qu'on conserve ou non), une autorisation temporaire, et selon l'heure
 d'accès, je trouve tout de même étonnant de si fréquemment tomber à
 l'entrée sur des espèce de droïdes, qui ne savent rien faire d'autre que
 dérouler leur procédure. Sauf que quand leur procédure est broken, on
 ne sait plus trop comment s'en sortir pour pouvoir accéder au site. 
 Qui n'a jamais eu droit au ah, on n'a pas reçu le mail, ou ya pas eu
 d'autorisation de faite, faut la refaire ? Pas plus tard qu'il y a
 quelques jours, je me suis retrouvé à devoir attendre plus d'une heure
 pour entrer dans un gros datacenter Parisien,  avec ce genre d'excuses à
 l'entrée. Alors même que le mail était VRAIMENT parti (log de MX à
 l'appui), et que c'est quasi systématique dans ledit DC.


 Ma question est donc: Quel est votre retour d'expérience sur ce sujet ?
 Est-ce qu'il y a, à vos yeux, des bons et des mauvais élèves parmi les
 DC sur leurs procédures d'accès ? Trouvez vous tolérable de devoir
 attendre plus de 10 minutes pour rentrer sur un site ?
 Evidemment, j'aurais tendance à vouloir éviter de mettre trop de
 business dans les salles où l'accès (qu'il soit pour moi, ou pour mes
 clients) est SYSTEMATIQUEMENT compliqué... Mais est-ce que c'est, pour
 vous vraiment un mal nécessaire, au nom de la sécurité ? 
 Qu'en pensent les exploitants des datacenters ?


 Merci d'avance !



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


Re: [FRnOG] [TECH] Switch supermicro

2014-01-06 Par sujet Frederic Dhieux
Le débat peut durer longtemps, au final la réalité en creusant c'est que 
chacun a une expérience plus poussée avec tel ou tel constructeur et 
sait mieux utiliser les best pratices de l'un ou de l'autre pour 
éviter/contourner les mauvais comportements.


Et il en va de même pour le support. Quand tu travailles des années avec 
une marque, tu connais les gens, tu connais les supports, tu sais 
comment interagir avec les gens pour avoir la bonne personne qui te 
répond sans que ça dure des mois.


Après y'a les marques plus exotiques, on sait que ça fonctionne quand ça 
fonctionne et que c'est susceptible de faire de la merde quand on part 
sur du complexe. C'est comme ça.


Quand on prend une marque répandue (enfin plutôt un produit répandu en 
fait, la nuance compte), on a plus de chances d'avoir des gens et des 
expériences qui ont essuyé les plâtres et peuvent aider, quand on prend 
un truc jeune (même de grande marque), on prend des gros risques et 
parfois même le support est un peu vierge sur les problèmes.


Le point reste : tu es un gros client ou un client de longue date, tu es 
mieux considéré que le petit mec dans son coin...



My 2 cents,

Frédéric


Le 06/01/2014 20:22, Raphael Maunier a écrit :


Sent from my iPhone


On 06 Jan 2014, at 20:05, Matthieu Michaud matth...@nxdomain.fr wrote:

Tu parles de quelles gamme et quelle OS ?


Houla c'était en 2009 et des châssis procurve. J'avais eu des reboots des re

Il y avait un pdf jadis qui tournait faisant etat precisemment de l'interop 
cisco/procurve et il y'en avait bien.


C'était des bug assez étrange ou le châssis partait en vrille .
Genre ça marchait et paf le chien ça cessait de switcher.


Il etait ecrit par un ccie et relevait des mauvais comportements des deux 
côtés. Il faut pas croire que c'est tout le temps la faute de !(cisco)...


Bah les 2960 avec plus de 20 vlans et du mstp et 2 ou 3 boucles ben si ça 
flappe , ton réseau est par terre pendant 10 minutes :)

Concernant l'interop cisco/comware, je n'ai jamais rencontré de pb.


Je ne cherche plus à faire dans l'exotique . J'ai tenté Brocade et ... J'ai 
tenté. Un pote a tenté des extrême ( Fisher price pour les intimes) et les 
switchs partaient aussi en vrille ( conçue en au 6500) lorsque bgp était activé 
.

HP pas mieux. J'ai sous la main un arista, bah pour le moment il fait rien du 
tout sauf un lag de 16 ports 10g qui pousse ... 160g ben ça marche vers un ... 
Juniper :) mais bon c'est pas folichon non plus hein !

Je suis sur Lab en ce moment avec du cluster hadoop avec 250 serveurs et vu les 
trucs de merde que j'ai sur les 5 stacks, je suis content d'avoir un support 
qui sait de quoi je parle et qui sait lire un pcap et faire un vrai debug.
Et ça fait 3 semaines que j'ai des trucs en cascade ( lié principalement à des 
bugs sur la config des linux ) et
Je ne vois même pas en rêve demander à mon client d'acheter autre chose que du 
Juniper ou s'il est allergique du cisco !


On Jan 6, 2014 7:58 PM, Raphael Maunier raph...@maunier.net wrote:




On 06 Jan 2014, at 19:52, Matthieu Michaud matth...@nxdomain.fr wrote:

Pour la maison pourquoi pas :) Mais très franchement , pour ma cave, j’ai
acheté un Cisco2960G au broke pour une bouchée de pain

c'est bien mal connaitre ces produits. l'ex-gamme 3com est pas si mal que
ça en pratique.

Testé et pas validé ! Pb avec du mstp à l'époque et c'était même avec des 
châssis.
Bref, pour un Switch dans une baie pas connecté à une archi spanning-tree




2014/1/6 Raphael Maunier raph...@maunier.net


Fonctions d'administration
IMC - Intelligent Management Center
interface de ligne de commande limitée
navigateur Web
Pour la maison pourquoi pas :) Mais très franchement , pour ma cave, j’ai
acheté un Cisco2960G au broke pour une bouchée de pain

Apres HP pourra se vanter d’être le deuxième équipementier L2, c’est
normal car  lorsque tu as commandé une imprimante tu as un switch en
goodies :)



On 06 Jan 2014, at 14:17, Yohann QUINTON yohann.quin...@awedia.com
wrote:


Hello,

http://www8.hp.com/fr/fr/products/networking-switches/product-detail.html?oid=4177649#!tab=specs

Même combat ?

--
Yohann
Awedia

Le 06/01/2014 15:01, Raphael Maunier a écrit :

On 06 Jan 2014, at 13:56, Frédéric GANDER fgan...@corp.free.fr wrote:


baaa si les équipementiers était de bon vendeurs de ram j'aurais moins

d'erreur ecc sur la ram de mes linecard ;)

de nos jours les switch d'aggregation l2 d'entrée de gamme chez

beaucoup de constructeurs sont basés sur des chipset de société comme
marvell ou broadcom qui font aussi des cartes réseau ;)

et les procédés techniques utilisés pour graver les cpu des pc sont

largement plus avancés que ceux utilisés pour faire les asic / np des
routeurs

Osef du hw au final, ce qui importe c’est le soft. Je ne suis pas

persuadé qu’ils puissent faire un code qui tourne sans 40k bugs et surtout
d’avoir les experts au noc pour te répondre en cas de soucis.

Dire que qu'un pc c'est de la merde c'est un peut facile
un pc 

[FRnOG] [TECH] Configuration L3/L2 sur 3560G

2014-01-01 Par sujet Frederic Dhieux
Bonjour et bonne année à tous,

Je suis en train de configurer des Cisco 3560G pour un besoin
particulier et dont le rôle serait à la fois de gérer une poignée de
sessions BGP vers un backbone (qui envoie uniquement la default route)
et d'agréger le L2 d'un ensemble de switchs de l'autre côté.

J'ai actuellement un point qui m'ennuie dans l'optique d'avoir quelque
chose de bien propre :

- Le 3560G ne gère pas le tagging d'interface L3 aussi loin que je le
connaisse, donc je dois passer mes /31 d'interco L3 en mode switchport
trunk pour passer plusieurs VRF sur un même lien.
 
- J'ai un certain nombre de VLANs à gérer en L2 sur cet équipement. La
logique voudrait que je fasse du MST plutôt que du PVST, mais du coup
voilà, mes interfaces L3 tombent irrémédiablement dans le MST même en
faisant un no spanning-tree vlan  sur mes VLANs utilisés pour les
intercos.

Du coup ça m'irrite pas mal de voir mes interfaces d'interco L3
impliquées dans le spanning tree et potentiellement bloquées. Si des
personnes ici on l'expérience d'une configuration élégante pour faire
cohabiter MST et intercos L3 avec plusieurs VRFs, ça m'intéresserait
d'avoir votre retour sur le sujet. Je n'ai pas pu pour le moment exclure
des vlans ou des interfaces de mon spanning tree MST.

Merci pour votre aide :)

P.S. : Je pose la question par intérêt technique par rapport à cette
situation avec cet équipement. Merci de ne pas me proposer de solution à
base de jette le à la poubelle et prends un
marque/modèle_préféré(e)_de_la_personne ;)

Conf exemple (tourne sur une version 12.2 en mode routeur bien sûr) :

-

spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
 name rtblw
 instance 1 vlan 2000-2999
 instance 2 vlan 3000-3999
!
spanning-tree mst 0-2 priority 20480
no spanning-tree vlan 100-299


interface Port-channel10
 description L3 r2 (Po10)
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,200
 switchport mode trunk

interface Vlan100
 description ic-r1-r2
 ip address xxx.xxx.xxx.xxx 255.255.255.254
 no ip redirects
 no ip proxy-arp

interface Vlan200
 description ic-r1-r2-vrf2
 ip vrf forwarding VRF2
 ip address xxx.xxx.xxx.xxx 255.255.255.254
 no ip redirects
 no ip proxy-arp

-


Frederic


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


Re: [FRnOG] [TECH] IPv6 sur le réseau privé

2013-11-17 Par sujet Frederic Dhieux

Hello,

Plusieurs points pour moi, d'un intérêt très différent :

- Pour la beauté technique : Mettre au placard le NAT autant que 
possible et revenir sur un routage pur sans rustine inélégante (avec 
firewall bien sûr).


- Aspect pratique : Il est plus facile de répartir les subnets et les 
adresses en IPv6 qu'en IPv4, c'est mieux rangé. Egalement savoir qui 
est en cause quand on doit retrouver une IP d'un collaborateur qui a 
fait de la merde sur Internet.


- Pour la mentalité : Si on pense IPv4 et qu'on met IPv6 en façade 
publique juste pour dire de l'avoir, la bascule n'a aucune chance de se 
passer un jour (ce sera déjà bien difficile de le faire). C'est aussi le 
moyen de lever les problèmes et de les traiter. IPv6 existera vraiment 
le jour où à force de changer les petits bouts un par un on aura 
finalement tout qui fonctionnera dessus. Alors là on pourra se poser la 
question de pourquoi garder IPv4 au lieu de se poser la question de 
pourquoi déployer IPv6.



Mais de toute façon les problèmes restent souvent l'historique ne 
supportant pas l'IPv6 (softs, matériel). C'est difficile d'upgrader un 
réseau existant en IPv6, par contre je trouve ça triste de ne pas le 
mettre en parallèle quand on refait celui-ci. Parce que ça coûte pas 
grand chose et que c'est inclus dans un projet valide d'un point de 
vue utile.


Et puis bon si les FAIs faisaient un peu l'effort d'y passer plus vite, 
ça motiverait plus aussi. C'est psychologique, Google et d'autres 
fournisseurs de contenu importants y sont, si les FAIs y passent, de 
suite on verra la part de trafic IPv6 devenir importante et 
inconsciemment pousser les autres à ne plus le négliger. Quand on voit 
la table ronde du FRnOG, ça ne surprend malheureusement pas, mais on 
voit bien que le statu quo n'embête que les gens qui manquent d'IPv4, 
les autres s'en foutent et même semblent en profiter comme d'un avantage 
sur les concurrents en pénurie... Depuis le temps que c'est pour dans 2 
ans, les produits IPv6 sont là, les backbones IPv6 sont là. Ca ne pose 
même pas de problème réel pour les historiques de le déployer vu qu'il y 
a le dual stack.


Bref, si les gens peuvent au moins ajouter une petite brique de temps en 
temps en l'incluant dans leurs projets plus prioritaires et s'ils 
peuvent se mettre à l'aise avec ça, on avancera un peu plus :) Chaque 
occasion est bonne... :) (surtout qu'on n'a pas vraiment envie de ce 
marché de l'IPv4 qui va devenir n'importe quoi avec le temps)


My 2 cents

Frederic

Le 18/11/2013 00:13, Gaël a écrit :

Pour un réseau privé interne d'une entreprise, ou d'un particulier, y a-t-il
une vrai nécessitée de passer à l'IPv6? De mon point de vue, je ne vois
pas... Des idées?

Pouvoir utiliser n'importe quel logiciel qui a besoin d'une ip
publique ? (voix sur IP, transfert direct IRC, etc.)

S'habituer aux outils et spécificités de l'IPv6 ? et prévenir toute
potentielle obsolescence de l'IPv4 ...

My 2 cents


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



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


Re: [FRnOG] Re: [MISC] Soyez sympas, hébergez un Ancre RIPE Atlas

2013-11-12 Par sujet Frederic Dhieux
L'argent c'est pas grave, mais ils pourraient filer des blocs IPs avec,
ça motiverait pas mal :D

Sinon why not, le projet est intéressant.

Frederic

Le 11/12/13 11:14 AM, Pat Meligan a écrit :
 Je sent arriver le avec ce que l'on paye déjà au RIPE...
 Et de fait je ne suis pas loin d'être assez d'accord. Y'a budget pour les 
 sondes mais pas pour les ancres?
 Hum intéressant...

 Le 12 nov. 2013 à 11:01, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 On Tue, Nov 12, 2013 at 09:54:44AM +,
 Patrice Blot - FCNET b...@fcnet.fr wrote 
 a message of 18 lines which said:

 Il faut acheter ou fournir le hardware ? J'ai bien compris ?
 Exactement. Ne vous plaignez pas, le matériel envisagé à l'origine
 (et qui a été acheté par les participants au projet pilote, comme
 l'AFNIC) était bien plus cher que celui finalement choisi.


 ---
 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] Re: [MISC] Soyez sympas, hébergez un Ancre RIPE Atlas

2013-11-12 Par sujet Frederic Dhieux
Le 11/12/13 11:21 AM, Stephane Bortzmeyer a écrit :
 On Tue, Nov 12, 2013 at 11:14:07AM +0100,
  Pat Meligan pat.meli...@gmail.com wrote 
  a message of 24 lines which said:

 Je sent arriver le avec ce que l'on paye déjà au RIPE...
 Ce qu'on paie au RIPE sert aux fonctions de registre. À la dernière
 réunion, à Athènes, la majorité semblait trouver que cet argent ne
 devait pas servir aux mesures. Mais n'hésitez pas à participer au RIPE
 pour donner votre avis.


A raison, ce n'est pas à tous de payer pour ce projet, sinon justement
beaucoup se plaindront que l'argent qu'ils donnent serve à des projets
dont certains se fichent surement.

Frederic


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


Re: [FRnOG] [BIZ] Consultant openbsd

2013-10-30 Par sujet Frederic Dhieux
Le 10/30/13 11:24 AM, Raphael Mazelier a écrit :
 Le 30/10/2013 11:02, Radu-Adrian Feurdean a écrit :
 Avis de barbu rase :
 Pas de BGP + statefull.


 Avis de mal rasé :
 - bgp si tu veux, mais pas de statefull sur un routeur.



+1

J'ajouterais aussi même si ce n'est pas forcément le cas ici : Eviter de
mélanger les rôles entre routeurs eBGP et firewalling.


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


Re: [FRnOG] [TECH] : cisco, juniper, what else ?

2013-10-24 Par sujet Frederic Dhieux
Bonsoir,

Et c'est possible de ne pas avoir d'intervention commerciale pour faire
de la pub sur une mailing tech ?

Je ne juge pas la solution mais ça ne donne pas envie.

Cordialement,
Frederic

Le 10/24/13 6:04 PM, Jean Senechaut a écrit :
 Bonjour,

 Oui cela évolue très rapidement avec 12% des 35 Bn$ investis en RD. Pour en 
 témoigner, nous avons signé plusieurs ISP qui sont satisfaits de la qualité 
 et de la performance de nos solutions, ainsi que de nos prix.
 Cordialement.

 Jean Senechaut
 Directeur Commercial Partenaires  Régions / Regional  Channel Sales Director
 Enterprise Business Group France
 Arcs de Seine - Bâtiment B
 18, quai du Point du Jour
 92659 Boulogne-Billancourt
 Mobile: +33 (0)6 21 58 58 60
 jean.senech...@huawei.com
 www.huawei.com/enterprise

 -Original Message-
 From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of 
 Jérôme Nicolle
 Sent: mercredi 23 octobre 2013 10:59
 To: frnog@frnog.org
 Subject: Re: [FRnOG] [TECH] : cisco, juniper, what else ?

 Le 21/10/2013 19:33, Jean Senechaut a écrit :
 What else? Huawei bien sûr...
 Mouais, il y a plusieurs problème à ce niveau :

 * Gamme très méconnue (site web pourri, pas de doc accessible hors des 
 brochures marketting tout juste bonnes à jouer au bullshit bingo)

 * Positionnement à l'Alcatel (Les NE sont juste hors de prix)

 * Produits pas toujours secs (petits bugs pas grave mais chiants à 
 l'usage), typiquement sur les AR3k (mais qui voudrait encore du soft ou 
 une archi PXF à la 7304/NSE150 ?)

 A moins que ça aie évolué depuis l'année dernière ?



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


Re: [FRnOG] [TECH] : cisco, juniper, what else ?

2013-10-21 Par sujet Frederic Dhieux
Hello,

Le 10/21/13 3:18 PM, William Gacquer a écrit :
 Alcatel fait ça très bien mais il faut être multi-millionaire. Brocade 
 disparait petit à petit et n'a plus de vision sur l'avenir. Reste Huawei. 
 J'ai tout testé dans ma vie en BGP : Nortel, Juniper, Cisco, Alcatel, 
 Brocade, Huawei. 
 Juniper reste pour moi le CLI de référence. Cisco, c'est toujours un CLI tout 
 pourri mais c'est plus simple de trouver un ingénieur réseau qui maîtrise la 
 bête. 
IOS ou IOS XR ou les 2 ? Dans tous les cas la CLI Juniper a toujours de
l'avance mais IOS XR est une bonne évolution (il était temps) côté
Cisco. Brocade ils sont toujours à l'âge de pierre en comparaison mais
tu as le mérite de ne pas être trop dépaysé par rapport à IOS pour un
mec habitué à IOS.

 Pour ton besoin, un CER-RT de Brocade devrait suffire mais que va devenir ce 
 produit?
+1, très bon rapport qualité prix pour cette fonction. Faire attention
par contre de ne pas partir sur des idées exotiques qui pourraient
révéler des bugs =) Au pire comme dit précédemment à voir côté brokers
NL ce qui se fait. Je doute que le CER disparaisse quand même avant son
amortissement s'il est acheté de suite et c'est assez robuste comme produit.

 William Gacquer

 Le 21 oct. 2013 à 14:56, Salim Gasmi sa...@sdv.fr a écrit :

 Bonjour,

 Perso, je resterai sur les standards de fait (aka Cisco,Juniper), pour 
 l'aspect couts le greymarket Hollondais sait faire des miracles.

 Salim

 Le 21/10/2013 14:50, JC PAROLA a écrit :
 Bonjour à tous,

 Parmi la domination de Cisco et Juniper dans le monde du datacenter pour 
 les routeurs de bordure et suite à rachat de foundry par Brocade, j'aurais 
 aimé votre retour d'expérience sur des routeurs pour du BGP full view avec 
 un transit de 100 Mb/s et 250kpps ?

 J'ai lu que 3com (HP) faisait également des routeurs.

 En terme de dimensionnement il faudrait un CISCO 38**.

 Le but étant de réduire le coût pour du PRA entre 2 sites distants.

 Merci

 JCP


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

 -- 
 Salim Gasmi -- Directeur Technique -- SdV Plurimedia


 ---
 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] Solution de mitigation de DDOS pour Operateur

2013-10-14 Par sujet Frederic Dhieux
Les transitaires le proposent de plus en plus en option pour un prix
forfaitaire mensuel fixe (genre 750 Euros / mois)

Ca se voit beaucoup sur les Tier-2, j'en ai vu chez un seul Tier-1 (pour
le moment). C'est clair que pour un petit hébergeur, c'est hors sujet de
penser claquer une fortune dans un Arbor, par contre c'est surement plus
cohérent pour son fournisseur.

Frédéric

Le 10/14/13 10:32 PM, Romain GUICHARD a écrit :
 Dans le thread où Jérémy parlait de son suicide, Philippe Bourcier avait
 brièvement parlé de http://www.packetdam.com/
 Est-ce que quelqu'un a un retour d'expérience sur le produit ?

 Concernant Arbor, celui doit obligatoirement se trouvé sur le réseau de
 l'opérateur ? Dans le cas d'un hébergeur ne disposant que de quelques
 transit IP, est-ce une solution pertinente ou est-ce aux opérateurs de
 transits de la mettre en place ?


 Le 14 octobre 2013 22:21, Jack alexandre.bruyel...@gmail.com a écrit :

 On 14/10/2013 21:00, Raphael Maunier wrote:
 Tss tss , Tu ne fais pas du tout la même chose, soyons sérieux. On ne
 compare pas du bricolage ( qui fonctionne dans une certaine limite ) à des
 solutions pro pour les opérateurs.
 C'est quoi la différence entre bricolage et solution pro ?
 Le commercial et la facture au bout ?
 Des solutions bricolage qui fonctionnent mieux que des solutions
 pro, j'en ai ai la pelle :D

 (Tentative pour détendre l'atmosphère de la mailing-list ..)


 --
 UNIX was not designed to stop its users from doing stupid things, as
 that would also stop them from doing clever things. – Doug Gwyn

 Trouve un travail qui te plaît et plus jamais tu ne travailleras
 Confucius

 Celui qui échange la liberté contre la sécurité ne mérite ni l'une ni
 l'autre et perdra les deux
 Thomas Jefferson






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


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


  1   2   >