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

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

Re: [FRnOG] [TECH] Changement Cisco ?

[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é ?

[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

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

[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

[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

[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

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

[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

[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

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

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

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

[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

[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

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

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




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 m

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

[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&D", 
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

[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

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

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

[Frederic Dhieux]

Hello,

Je suis à la recherche d'hébergement un peu all around the world par un
même fournisseur. Les contraintes :

- Pouvoir hoster aux US (vers NY, pourquoi pas aussi un point sur la
cote ouest), en Asie (genre HK), en Europe de l'Est (genre Bucarest ou
Vienne), en Amérique du Sud (au pire en Floride, sinon Brésil c'est pas
mal), en Middle East ce serait pas mal.
- Fournir un serveur standard (ou l'emplacement ou au pire de la VM pas
moisie) avec une IP d'interco et possibilité de fournir du BGP monté
dessus pour annoncer une ou deux /24 nous appartenant.


L'idée étant de fournir du service léger depuis des PoP locaux sur des
points clés du globe et de pouvoir activer/désactiver facilement
l'anycast sur chaque point.

Le point bonus serait que le fournisseur passe par Level3 ou Tinet ou
Tata pour un de ses transits et permette de pousser des communautés BGP
pour forcer l'annonce uniquement via ce transitaire si on le souhaite à
un moment.

Merci de votre aide :)

Frédéric


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

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

[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

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

[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] OVH down ?

[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] Banques CIC et CM HS ?

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

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

[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  a
>>> écrit :
>>>
>>>
>>>
>>> - Mail original -
 De: "Jeremy" 
 À: "frnog-tech" 
 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] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

[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] [TECH] Open-Source Web-based IPAM

[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

[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

[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

[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

[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

[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

[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

[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] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

[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] [ALERT] Problème chez level3 ? avec Free

[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

[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  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] [TECH] DDoS / analyse de traffic

[Frederic Dhieux]

Bonjour,

On retombe toujours sur les mêmes problèmes. Dans tous les cas quand on
prend un bon DDoS, à moins d'avoir de gros moyens ou de souscrire à un
service anti-DDoS chez ton transitaire (beaucoup le proposent et c'est
bien parce qu'ils ont la capa pour le gérer correctement), il n'y a pas
beaucoup de solutions.

Pour ma part j'ai pris le parti de prendre un transit poubelle et d'y
coller un serveur machine à laver à qui un outil d'analyse applique des
ACLs en fonction des attaques. Après le jeu est d'appliquer des
communautés BGP et des annonces pour faire converger le trafic DDoS sur
ce transit poubelle et garder le reste sur les liens propres. Sinon de
préserver les peerings sensibles et opérateurs clés de mon activité et
basculer tout le reste sur le transit poubelle.

Si le transit poubelle sature, au moins je préserve une partie du
trafic. Sachant aussi qu'en cas d'attaque ciblée sur une IP, le /24 le
contenant est annoncé indépendamment pour que le traitement ne concerne
que cette /24 et pas tout le reste.

C'est un compromis que je trouve plus acceptable chez nous que de
dépenser des 100aines de milliers d'Euros dans une solution à la mode
dont la capacité de traitement est plafonnée de toute manière par la
taille du tuyau quand les attaques augmentent de mois en mois.

Sinon quand on a pas de temps à perdre pour mettre ça en place, prendre
un transit avec service anti-DDoS et tout basculer dessus en cas de
problème. Ou faire les 2 quand on veut s'amuser et se backuper.

Je pense qu'il faut vraiment avoir une taille critique et des moyens
pour utiliser des solutions Anti-DDoS commerciales en propre.

Frédéric

Le 27/02/15 14:14, Youssef Bengelloun-Zahr a écrit :
> Sans compter que tout le monde n'a peut-être pas suffisement de TCAMs sur
> ses routeurs de coeur (qui a dit firewalls ;-) pour blackholer autant d'IP
> sources.
>
> My 2 cents.
>
> @++
>
>
>
> Le 27 février 2015 14:04, Raphael Maunier  a écrit :
>
>>> On 27 Feb 2015, at 05:02, David CHANIAL  wrote:
>>>
>>> Bonjour Raphael,
>>>
 Le 27 févr. 2015 à 13:51, Raphael Maunier  a
>> écrit :
 Si tu dois faire un blackhole sur ton ip, l’attaquant a gagné.
>>> N’y a t’il pas « 50 nuances » de victoire de part et d’autre ?
>> :)
>>> Filtrer/Mitigier l’attaque uniquement, sans affecter tout le reste de
>> l’infra reste un objectif louable.
>>
>> Sauf comme indiqué dans une de mes réponses tu as 20G qui rentre, le nulle
>> route des ip en in ( et il faut que ca ne soit pas genre 80 000 ip ) ou une
>> autre attaque qui forge les ip ton routeur tes routages ne te seront pas
>> d’une grande utilité
>>
>>> Mais si le budget ne le permet pas, ne vaut-il pas mieux envisager des
>> solutions intermédiaires, dont certaines te permettent de bloquer
>> uniquement la cible, et pas le reste de ton infra ?
>>> Cordialement,
>>> --
>>> David CHANIAL
>>>
>>
>> ---
>> 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

[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" 
>> À: "Romain MAZET - BSO Network Solutions" 
>> Cc: "" 
>> 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
>>>  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

[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

[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 
   enforce-first-as


Frédéric


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

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

[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] [ALERT] Pertes de paquets sur franceix

[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

[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] [TECH] Conseil switches

[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

[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

[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] [MISC] C'est nous qu'on est les meilleurs

[Frederic Dhieux]

Le 26/11/14 14:54, Manu a écrit :
>
>
> La plupart de nous vivent déjà dans une grotte non ? ou dans un
> datacenter.. ou dans un local au sous sol.
>

Ou au dessus d'un bar, c'est bien aussi :) Mais bon on n'est pas numéro
2 d'un grand opérateur non plus, on n'a pas les mêmes contraintes (ni
les mêmes avantages :D ).

Frédéric


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

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

[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

[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

[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"  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] Lien optique qui clignote.

[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 Lesimple  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 Ponzone  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 Colombier  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] PRA et ISO

[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] Quel mode de bonding pour du multi-switch ?

[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 
> 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  wrote:
>
> From: Inulogic - Free-H  
> To: 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  
>  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 p

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

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

[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

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

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

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

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

[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] [ALERT] Saturation Level / Orange ?

[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] [ALERT] Saturation Level / Orange ?

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

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

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

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

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

[Frederic Dhieux]

Le 29/08/14 15:11, David Ponzone a écrit :
> Le 29 août 2014 à 14:39, aymeric marchand  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

[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

[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] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Frederic Dhieux]

Le 28/08/14 18:56, David Ponzone a écrit :
> Le 28 août 2014 à 18:47, Pierre-Yves Maunier  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

[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] [MISC] Philippe Bourcier, la fibre au bureau

[Frederic Dhieux]

Bonsoir,

Pourquoi une telle agressivité ? Pourquoi votre expérience serait plus
crédible que celle de Philippe ?

Je  ne suis pas intervenu sur le sujet mais les questions du coût
m'intéressent aussi. La question que j'aurais posé est la suivante :
Dans quel contexte et à partir de combien de postes celà devient
rentable (parce qu'effectivement le problème c'est le coût du port plus
que du lien à faible volume).

Je pense que l'expérience est intéressante pour une grosse boîte avec de
nombreux postes. Le passage de câbles en masse est pénible avec du
cuivre là où la fibre est beaucoup plus simple. En coût d'installation
je veux bien croire que sur des centaines de postes ça fait une belle
économie en JH.

A voir également la solution de téléphonie adoptée au sein de
l'entreprise, certains ont des téléphones software sur le PC en
dématérialisé plutôt que des postes fixes ou du skype.

Bref, ce serait plus intéressant de demander plus de détails sur la
solution ou d'avoir une présentation au prochain FRnOG que de dire
unilatéralement que quelqu'un raconte n'importe quoi.

Je pense que s'il a mené ce projet dans sa boîte, c'est qu'il y a un
minimum réfléchi quand même, concéder cela est le minimum de respect
qu'on peut avoir ici.

C'est un peu dommage de penser de manière binaire sans prendre en compte
le contexte. Et cette solution sera de plus en plus intéressante à
l'avenir car le coût de l'optique baissera encore et celui du cuivre
grimpera inexorablement.

Cordialement,
Frédéric Dhieux


Le 18/08/14 20:55, Thierry Martin (Europe) a écrit :
> Bonjour,
>
> déjà fait dans le passé, mais uniquement pour des besoins spécifiques.
>
> Rentable plus que le cuivre : VRAIMENT  NON
> - la fibre optique coutait plus cher à l'époque
>
> et maintenant:
> - toujours plus chère, si on fais le VRAI calcul (connectique + tests en plus 
> )
> - les précâblages optiques sont-ils réexploitables ?? NON , ils sont en OM1 
> et limité à 10/100Mb
> - on est loin de l'OM3 ou OM4  vs OS2 pour la monomode
>
>
> et :
> - comme le disent certains : le POE
> - un téléphone IP avec un port FO ?? NON
>
>
> Monsieur Philippe Bourcier
> => trouvez-vous sur le commerce des PCs (et pas des serveurs) avec un port FO 
> ou un slot pour un GBIC type SFP (nouvelle génération) ??
> => alors, réfléchissez avant d'écrire vos articles.
>
> A+
>
>
>
>
> Thierry Martin
> Senior Engineer Expert
> Dimension Data France
> Tel: +33 1 4975 8852
> Mob: +33 6 6023 6611
> Fax: +33 1 4975 8629
> thierry.mar...@dimensiondata.com
>
> Zone Orlytech - 20 avenue Louis Blériot
> (adresse postale 91781 Wissous Cedex), Paray Vieille Poste, 91550, France.
>
> Dimension Data is an NTT Group company. For further information about 
> Dimension Data, please go to 
> www.dimensiondata.com
> Follow us on Social Media Blog 
> Facebook 
> LinkedIn 
> Twitter
>
> P please consider the environment before printing this email
>
> [cid:c386cb.png@e66017e1.4992e583]
>
> 
> De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Laurent 
> CARON [lca...@unix-scripts.info]
> Envoyé : lundi 18 août 2014 18:32
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau
>
>
>
> On 18/08/2014 15:34, Pascal Rullier wrote:
>> Bonjour,
>>
>> Certains n'ont peut être pas vu l'article dans le monde :
>>
>> http://www.lemonde.fr/pixels/article/2014/08/12/philippe-bourcier-la-fibre-au-bureau_4470193_4408996.html
> Bonjour Philippe,
>
> As-tu déployé des postes téléphoniques IP disposant d'un port fibre ? ;)
> Quid du POE ?
>
> Ces questions peuvent sembler 'trollesques', mais sont importantes à mon
> sens.
>
> Merci
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> itevomcid
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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

[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 »  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] [TECH] Switch brocade fcx

[Frederic Dhieux]

Salut,

show module ?
show version ?

(tant qu'à faire du support Brocade, autant avoir les infos)

Frederic

Le 30/07/14 22:18, Jeremy a écrit :
> Salut Olivier,
>
> Merci pour ta réponse. Cependant, sur le FCX 624, il n'y a pas de SFP
> 1G. Il n'y a qu'une carte 4x10G que j'ai rajouté. Du coup, ça élude
> aussi le problème de licence qu'on m'a remonté, ça n'existe pas sur le
> FCX.
>
> C'est ça qui est dingue, on a l'impression que la carte est reconnue
> comme une carte 10G mais que les ports sont reconnu comme des ports 1G.
>
> Je creuse depuis 2 jours, mais je n'avance pas pour l'instant. Comme
> d'hab, le support Brocade fait la carpe.
>
>
> Le 30/07/2014 22:13, Olivier Benghozi a écrit :
>> Les ports de stack sur les 4x10G par défaut sont les 1 et 2. Donc
>> x/2/1 et x/2/2.
>>
>> Ceci dit, on lit ici que tu as inséré tes optiques sur le bandeau de
>> 4x1GE du haut au lieu des 4x10GE juste en dessous.
>>
>> Le 30 juil. 2014 à 21:53, Jeremy  a écrit :
>>
>>> Salut les barbus,
>>>
>>> Je cherche un coup de main pour configurer des saloperie de switch
>>> brocade FCX qui me bouffent la vie depuis quelques jours.
>>> Le concept de stacking qui pourrait être séduisant sur le papier est
>>> incompréhensible. J'ai une carte 4x10G qui semble reconnu comme des
>>> ports 1G comme le suggère cette réponse du cli :
>>>
>>> equinix-val59-10G#sh media ethernet 1/1/1
>>> Port  1/1/1: Type  : 1G M-LX(SFP)
>>>  Vendor: BrocadeVersion: 1.0
>>>  Part# : 10G-SFPP-LR+-SOSerial#: SOP131L2340
>>>
>>> equinix-val59-10G#sh media ethernet 1/1/4
>>> Port  1/1/4: Type  : 1G M-LX(SFP)
>>>  Vendor: BrocadeVersion: 1.0
>>>  Part# : 10G-SFPP-LR+-SOSerial#: SOP131L2339
>>>
>>> D'ailleurs, mes optiques sont sur 1/2/1 et 1/2/4, je ne comprend pas
>>> pourquoi il les voit sur 1/1/1 et 1/1/4. Encore un coup du stack
>>> unit 1 ?
>>>
>>> Bref, si quelqu'un a déjà eu à faire à ces bêtes là, ou qui veux une
>>> bonne bière la semaine prochaine lorsque je vais repasser à paris,
>>> ça serais très sympa.
>>
>> ---
>> 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] Recrutement

[Frederic Dhieux]

Bonjour,

Donner un salaire plancher pourquoi pas, une fourchette... 
Personnellement il y a des propositions d'entretien que je n'aurais 
jamais acceptées si une fourchette de salaire avait été annoncée avant.


Quand on rencontre un candidat (pour connaitre les 2 côtés de la 
barrière), on rencontre d'abord un profil qui peut matcher à un poste à 
pourvoir, mais on rencontre aussi une personne qui peut correspondre à 
la société, un profil pour lequel on peut adapter des choses, qui peut 
correspondre à un autre poste. Et pourquoi pas même changer une 
organisation pour créer un poste où ce profil puisse s'épanouir et 
apporter à la boîte, ça s'est déjà vu.


Un entretien ne devrait pas une corvée (même si des sociétés de merde il 
y en a pas mal), c'est toujours l'occasion de découvrir des gens, des 
sociétés, d'échanger et même d'apprendre. Se borner à un profil ultra 
cadré ne mène qu'à donner un poste ultra fermé. Personnellement une 
société qui donne une fiche fermée avec un rôle trop défini et réduit et 
un salaire fixé, ça me fait penser que je vais rentrer dans une grosse 
structure où évoluer sera difficile et où je ferai toujours la même 
chose sans pouvoir acquérir d'autres compétences.


On parle d'humain, pas de formatage binaire. Il y a ce qu'on veut mettre 
pour un profil au départ et ce qu'on est prêt à faire ou à ne pas faire 
une fois qu'on connait la valeur de la personne en face.


My 2cents,
Frederic


Le 24/07/2014 15:10, Xavier ROCA a écrit :

Bonjour,

Nouveau fil plus approprié comme le suggère Alexis

Parlé salaire dans une offre d'emploi est-ce évident ?
Nous allons prochainement lancer des recrutements de DEV et la question se pose 
et est bien plus complexe qu'on ne le pense en essayant d'en faire l'inventaire.

Cas perso : Petite PME pas de DRH pas forcément doué pour l'exercice de 
l'annonce
On va lever des fonds de R&D donc des moyens pour les salaires.
Doit on se fixer sur un candidat tellement type que la on connait le salaire ?
Donc si je mets avec 4 ans expériences et x,y,z en compétence sur tel secteur 
géographique je m'y tiens.

Dans une PME faut accorder une place à des gens qui sont à cheval sur un deux 
ou trois profil.
Moi je n'ai pas des besoins aussi formaté qu'une boîte du CAC40

Un gros Geek autodidacte n'a pas sa chance face à un gars avec 4 ans 
d'expérience selon vous ?
Moi je ne veux fermer la porte à personne ?

J'ai trois postes à offrir, si je trouve deux qui remplissent bien l'objectif 
pour un même budget c'est une solution à ne pas retenir ?

Bref, j'ai trouvé, pour certains d'entre vous, trop de sectarisme dans un sens 
ou dans un autre.
Les plus cool ne sont pas forcément les mieux payé apparemment. Mais des 
passionnés...

Et tiens ca compte dans le salaire la passion ? Oui ! Pour l'employeur qui va 
profiter de cela et pour l'employé qui acceptera par passion un truc de ouf aux 
yeux des autres.

Pourquoi obliger à donner un salaire ou pas ?
Liberté de s'exprimer, non ?

Et pour parler de chiffre précisement sans ressenti disproportionné faudrait-il 
pas avoir une base de référence parfaite et exhaustive.
Emploi dans le Larzac ou Paris ce n'est pas pareil. Et selon si on veut faire 
venir ou recruter sur place aussi ...

Si je veux débaucher dans la ML, j'ai tout intérêt à mettre un beau salaire 
dans l'annonce. Cela veut-il dire que ceux qui veulent voir le salaire sont les 
plus vénales? Et donc faire un tri sur les annonces avant de se découvrir 
(c'est un petit monde tout ce sait très vite ici)
Est-ce bien un candidat comme celui-ci ? Serra-t-il fidèle ou purement vénale ?
Vous ne trouvez pas que c'est facile de rendre un avis très arbitrairement 
négatif ou positif ?

Est-ce que ma réflexion tiens compte d'élément complètement extérieur : non
Je peux avoir envies de me sortir de la ou je suis car ambiance nulle, j'ai 
deux ou trois schtroumfs à faire vivre et ma femme ... (la je vais me faire 
sortir donc je vous laisse compléter).
J'ai contracté des prêts donc j'ai un besoin à minima de tant. Il y a tant de 
paramètres !

Moi avec cette réflexion, voila comment je pense que j'exprimerais mon 
recrutement :
Je donnerai une fourchette qui ne veut rien dire 1500-4000 € et donnerai une 
préférence à celui qui préfère un bon petit salaire en base avec une indexation 
sur la performance et objectif. Et un passionné !
Si autodidacte, pourquoi pas...
Comme on a le beau temps souvent ici on négociera le confort de vie et l'envie 
de bosser avec des gens biens (pas moi, mes collègues)


A vos réflexions et tachons d'être constructif avec une ouverture d'esprit.

Mes 4 cts et mes 20K fautes de Français

Xavier





-Message d'origine-
De : Alexis Lameire [mailto:alexis.lame...@gmail.com]
Envoyé : jeudi 24 juillet 2014 13:17
À : frnog@frnog.org
Objet : Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work


Bonjour,

Je ne me suis pas encore exprimé sur cette ML, néanmoins je souhaiterais 
apporter un argument à la discussion.

I

Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work

[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

[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

[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

[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

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

[Frederic Dhieux]

Le 3/5/14 5:13 PM, Thomas Mangin a écrit :
> On 5 Mar 2014, at 15:56, Xavier Beaudouin  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

[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  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] [MISC] FRNOG 22.0 - RC1

[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  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] [TECH] Routeurs cisco

[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

[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

[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

[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  a écrit :


On Mon, Feb 17, 2014 at 10:40:47AM +0100,
Alarig Le Lay  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/

Re: [FRnOG] [TECH] Reroutages et problèmes sur Internet

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

[FRnOG] [TECH] Reroutages et problèmes sur Internet

[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] [MISC] Amplifications NTP

[Frederic Dhieux]

Le 2/1/14 10:15 PM, Raphael Maunier a écrit :
> On 01 Feb 2014, at 22:02, Radu-Adrian Feurdean 
>  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] Amplifications NTP

[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] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

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

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

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

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

Re: [FRnOG] [MISC] Les procédures d'accès aux datacenters: Une punition à chaque fois ?

[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

[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  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"  wrote:




On 06 Jan 2014, at 19:52, Matthieu Michaud  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 


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 
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  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 peut router et manipuler (tunneler/ encapsuler / filtrer etc)

60gbit/s de trafic sans broncher.

certain routeur je

Re: [FRnOG] [TECH] Configuration L3/L2 sur 3560G

[Frederic Dhieux]

Bonjour,

Merci pour les réponses données et les bonnes pistes :

@Olivier : Merci, très bêtement j'en étais resté à portfast sans
l'argument "trunk" en complètement qui est donc totalement inefficace,
c'est beaucoup mieux comme ça (avec le filtrage bien sûr). Pour
l'instance dédié, c'est plus propre effectivement que de laisser dans la
0 de défaut, même si en pratique ça ne change pas vraiment le
comportement de ce que j'ai vu.

@Jérôme et Olivier : Pour le no spanning-tree, c'est effectivement non
fonctionnel en MST on est d'accord, je l'ai laissé pour bien clarifier
ce point et qu'on ne me le propose pas

@Mohamed : L'idée est effectivement intéressante et c'est ce que
j'aurais préféré, avoir un interco qui gère l'ensemble des VRF comme sur
un routeur MPLS, sauf que là il me faut garder l'étanchéïté entre les
VRF des 2 côtés. Je reçois une default route mais j'envoie aussi des
networks locaux dans l'autre sens spécifiques à chaque VRF. Clairement
ne pas se taper X intercos L3 pour X VRF ce serait bien mieux :)

Frédéric


Le 1/2/14 11:15 AM, Mohamed Touré a écrit :
> Bon,jour et Bonne année
>
> Si les sessions BGP sont maintenues entre les deux memes equipements (3560
> <-> BB), je suggèrerai de monter une seule session BGP dans la Globale ou
> dans une VRF créée à cet effet et par un jeu d'import/export (route
> leaking) et progager la default route dans chaque VRF.
>
> On mutualiserait le port L3 (no switchport). Ce qui réduit le nombre de
> SVI, de sessions BGP et de configuration. Par conséquent pas de
> spanning-tree sur le port L3.
>
> BR
>
> Mohamed
>
>
>
> 2014/1/2 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
>> " ;)
>>
>> 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/
>>
>
>


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

[FRnOG] [TECH] Configuration L3/L2 sur 3560G

[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
" ;)

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/