Re: [FRnOG] [TECH] Ports 10 Gbps

2016-04-21 Par sujet Mr Pascal Gay 
les gros clouds providers en sont friands (OVH, IBM SL par exemple)..il faut 
dire que de plus en plus de serveurs ont des cartes 1/10Gbase T natives

Pascal

> Le 21 avr. 2016 à 14:57, Xavier Beaudouin  a écrit :
> 
> Hello,
> 
>> Plusieurs clients m’ont remonté que les ports 10G des serveurs arrivent en 
>> 10G
>> BaseT. Cela est-il un épiphénomène ou cela se généralise-t-il ?
> 
> J'en vois oui. Hélas, le cuivre + RJ45 low life a de l'avenir :D
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] TRILL vs. SPB

2016-04-15 Par sujet Mr Pascal Gay 
encore un point à regarder : l’arrivée des technologies 25/50/100 Gigabits……le 
port 25 Gigabit est au prix du 10 Gigabit, et peut faire du 10 Gigabit 
aussi….idem pour les ports 100 au prix du 40 Gig et qui peuvent faire du 40 Gig 
aussi..ça vaut le cout de regarder pour une plus grande pérennité 
d'investissement

> Le 15 avr. 2016 à 10:41, Raphael Mazelier  a écrit :
> 
> Hello,
> 
> A mon sens tu as deux grandes questions a te poser avant de choisir telle ou 
> telle technologie de "fabric ethernet".
> 
> 1) Est ce que tu veux réellement une architecture de type "fabric ethernet" ? 
> comme l'on dit mes camarades c'est certes (beaucoup ?) plus simple, mais 
> moins fiable et moins scalable qu'une fabric IP.
> 
> 2) Si oui, pose toi la question : avec quelle constructeur de matériel veut 
> tu travailler. Chaque constructeur a implémenté sa solution de fabric 
> ethernet à sa sauce (FabricPath, QFabric/VCF, Trill, SPB), avec c'est à 
> mentionner des constructeur qui utilisent des standards, et d'autres non. Et 
> d'autres ont choisi d'autre approches (comme Arista).
> 
> -- 
> Raphael Mazelier
> 
> Le 15/04/2016 00:19, Jean-Christophe Valiere a écrit :
>> Salut,
>> 
>> C'est dans le cadre d'un Datacenter.
>> Au début, étais plutôt TRILL me semblait plus pertinent mais plus je vois de 
>> doc et plus je penche pour SPB ...
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] TRILL vs. SPB

2016-04-15 Par sujet Mr Pascal Gay 
rebonjour

on peut faire très simple coté mise en oeuvre avec des Fabric IP ou du niveau 2 
(désolé de l’acronyme MLAG au passage, on va dire clustering de 2 switches mais 
avec plans de contrôle séparés pour ne pas confondre avec la technologie VSS de 
Cisco) avec les bons outils logiciels…..
Je suis heureux de voir que Brocade vient aussi à la Fabric IP cela confirme 
donc mon discours que c’est la technologie qui gagne sur le marché :) et grâce 
à cette technologie vous pouvez mixer des Leaf d’une marque et des Spine d’aune 
autre marque, voire mixer des marques coté Leaf et Spine….donc vous n’êtes pas 
enfermé chez un fournisseur 



> Le 15 avr. 2016 à 09:45, David Limery  a écrit :
> 
> Salut,
> 
> Il y a plusieurs types de clients sur le marché. Ceux qui veulent du clé en 
> main et qui ne sont pas encore prêts à se lancer dans le développement ou la 
> gestion d'outils de provisioning ou d'automation; que ces outils soient 
> "maison" ou fournis par un éditeur soft. Et il y a ceux, plus mûrs, qui sont 
> déjà prêts à s'investir dans ce type d'approche souvent parce que l'outil 
> informatique est déjà considéré comme clé pour la génération de nouveaux 
> services pour leurs propres clients et donc de revenus accrus en matière de 
> chiffres d'affaires.
> 
> A liste des supporters des architectures MLAG proposées par mon confrère, 
> j'ajouterai Brocade (je vous renvoie aux motx-clés MCT/Multi-Chassis Trunking 
> ou VLAG/Virtual LAG).
> Pour les Fabric Ethernet, Brocade compte près de 4000 clients VCS (Virtual 
> Cluster Switching) dans le monde depuis la mise à disposition de cette 
> technologie en 2011. Cette technologie adresse le premier type de clients: 
> ceux qui veulent du clé en main, plug and play, propriétaire au sein du 
> cluster mais complètement interopérable en niveau 2 et niveau 3 avec tout 
> type d'environnement multi-constructeurs (réseau, serveurs, hyperviseurs, 
> stockage; ...).
> Pour le second type de clients, là aussi, Brocade propose des architectures 
> Leaf (Fabric IP) avec en guise de control plane:
> - soit un contrôleur externe comme NSX,
> - soit l'utilisation BGP EVPN au niveau des équipements qui constituent la 
> Fabric IP.
> Pour la partie data plane: le protocole qui a le vent en poupe aujourd'hui 
> pour adresser la micro segmentation est VXLAN que la Fabric IP Brocade met en 
> œuvre bien évidemment.
> 
> Pour revenir à la question initiale: Brocade a choisi TRILL (IETF) pour sa 
> Fabric Ethernet VCS pour sa disponibilité précoce par rapport à SPB et sa 
> simplicité de mise en œuvre. Brocade a enrichi le protocole pour y ajouter 
> notamment des fonctions OAM. Le protocole SPB, héritier des protocoles PLSB 
> (poussé par BT et feu Nortel à l'époque, évolution du PBB-TE), est à 
> l'origine orienté plus Service Provider; ce qui explique que des acteurs 
> (plus teintés Opérateurs) comme Avaya (ex-Nortel), Huawei, Alcatel ont opté 
> pour ce protocole de l'IEEE, mais aussi l'approche circuit-based et la 
> disponibilité native de mécanismes OAM.
> 
> Qu'il s'agisse de TRIIL ou SPB, la tendance à moyen et long terme est 
> clairement l'ouverture, l'interopérabilité et le scale. Seul le protocole IP 
> parvient aujourd'hui et de manière éprouvé à proposer ces caractéristiques 
> réseau. Aussi, pour ceux qui sont prêts, Les Fabric IP sont l'avenir. 
> Brocade peut d'ores et déjà vous accompagner dans vos projets de 
> transformation... et ce, quelque que soit l'approche choisie /: D.
> 
> A très bientôt
> /: David LIMERY.
> 
> 
> -Original Message-
> From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of 
> Pascal Gay
> Sent: vendredi 15 avril 2016 07:49
> To: Jean-Christophe Valiere 
> Cc: Fabien Delmotte ; frnog-t...@frnog.org
> Subject: Re: [FRnOG] [TECH] TRILL vs. SPB
> 
> Tout cela c'est de la Fabric ethernet et c'est une technologie qui ne prend 
> pas sur le marché..car elle est difficilement interopérable les constructeurs 
> ayant pris un malin plaisir à faire des choses propriétaires  ...ce qui se 
> fait la plupart du temps est une architecture Spine Leaf côté physique et 
> soit une Fabric IP (avec du VXLAN pour le transport de niveau 2) soit une 
> architecture niveau 2  type MLAG côté logique c'est ce que font Cisco, 
> Arista, Juniper..les leaders sur ce marché ...entre autres... .c'est 
> complètement interopérable (on peut mélanger sans soucis 2 marques dans le 
> Datacenter ) et évolutif jusqu'à des centaines de milliers de serveurs et de 
> VMs si Virtualisation 
> 
> Pascal Gay
> 
> 
> 
>> Le 15 avr. 2016 à 00:19, Jean-Christophe Valiere  a écrit :
>> 
>> Salut,
>> 
>> C'est dans le cadre d'un Datacenter.
>> Au début, étais plutôt TRILL me semblait plus pertinent mais plus je vois de 
>> doc et plus je penche pour SPB ...
>> 
>> Cordialement,
>> Jean-Christophe
>> 
>> 
>>> On Apr 14, 2016, at 5:55 PM, Fabien Delmotte wrote:
>>> 
>>> Bonjour,
>>>

Re: [FRnOG] [MISC] switch OS open source ?

2015-11-06 Par sujet Mr Pascal Gay 
bonjour

notre EOS est basé sur un Linux (Fedora) entièrement accessible et non 
modifié…le switch est pilotable comme un switch (CLI) et comme un serveur….très 
utilisé par les géants du web

www.arista.com

Cordialement


> Le 6 nov. 2015 à 09:27, Nicolas Parpandet  a écrit :
> 
> 
> Hello,
> 
> Existe t'il une plateforme de switch, basée sur de l'open source (bsd ou 
> linux) ?
> On trouve des routeurs, des pare-feux, pour la partie switch cela ne semble 
> pas évident.
> 
> A+
> 
> Nicolas
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] SDN chez Google

2015-06-25 Par sujet Mr Pascal Gay 
bonjour

quand on veut faire bouger des VMs d’un serveur à un autre par exemple qui 
n’est pas dans le même domaine de Broadcast…VXLAN permet de faire un tunnel de 
niveau 2 dans un réseau de niveau 3 compatible avec VMWare et donc on peut le 
faire en software dans l’hyperviseur ou NSX et/ou en hardware dans les switches 
supportant le VTEP…on peut ainsi monter un DC tout niveau 3 (Fabric IP)  entre 
les TOR et le backbone (ou Leafs et Spine) interoperable entre plusieurs 
marques tout en préservant la possibilité de bouger les VMs…
On peut même l’utiliser pour de l’inter Datacenter et utiliser un backbone 
classique IPv4 (c’est de l’UDP)  (pas besoin de MPLS/VPLS)  et faire transiter 
des VMs d’un site à un autre comme cela…nous avons plusieurs clients qui font 
cela pour info

C’est donc utile et devenu un « standard » de fait car supporté par VMWare, 
Alcatel, Arista, A10, Brocade, Cisco, Fortinet, F5, HP, Juniper, Palo Alto 
(ordre alphabétique)  …et j’en passe surement (pardon pour les oubliés)... dans 
leurs switches de Datacenter, ADC et firewalls récents avec un excellente 
intéroperabilité

En espérant être utile à la discussion



 Le 25 juin 2015 à 11:15, Louis luigi.1...@gmail.com a écrit :
 
 VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche
 supplémentaire pour maintenir l'existence de domaines de broadcast Ethernet
 entre serveurs ?
 
 je dirais que parmi les intérêts, il y a :
 - possibilité d'avoir plus de zones de broadcast. On est plus limité à 4096
 - ne plus faire dépendre une zone de broadcast d'un site géographique
 
 
 Le 25 juin 2015 06:59, Romain De Rasse rom...@de-rasse.fr a écrit :
 
 Bonjour,
 
 Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau devops
 réseau par exemple :
 https://github.com/spotify/napalm/blob/master/README.md qui vient avec un
 plugin ansible.
 
 RDR
 
 Le 25 juin 2015 06:33:31 GMT+10:00, Olivier Cochard-Labbé 
 oliv...@cochard.me a écrit :
 
 2015-06-24 21:01 GMT+02:00 Thomas Barandon t.baran...@gmail.com:
 
 Hi,
 
 
 Bref, le SDN c'est bon. Mangez en. De toute façon il faudra composer avec.
 
 
 
 ​Juste un «détail» qui me chiffonne avec les solutions SDN du moment: Ou
 est passé le principe KISS ?
 Prenons l'exemple de Juniper Contrail (je prends cet exemple uniquement car
 la solution fonctionne pas mal et la doc bien foutue):
 
 cf le white paper CONTRAIL ARCHITECTURE, Figure 1 Contrail system
 overview:
 http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf
 
 Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à un
 seul bloc, j'appelle cela de la simplification) je
 découvre un joli mélange
 de:
 - XMPP, pour que routeur fasse des échanges multimédias ou du chat entre
 eux et le contrôleur ? :-)
 - BGP, normal c'est du réseau
 - Netconf, tiens… enfin!
 - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle connerie
 d'avoir prévus 65535 ports pour TCP, alors qu'il en suffisait de trois: 53,
 80 et 443.
 - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN…
  - Pourquoi absolument du MPLS over quelques chose et pas le faire
 nativement ?
  - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche
 supplémentaire pour maintenir l'existence de domaines de broadcast Ethernet
 entre serveurs ?
 - hyperviseur
  - Comment garantir le jitter minimum lorsque l'on doit traverser
 plusieurs hyperviseurs ? (chainage de VMs)
 
 Et le pire: C'est que ça fonctionne.
 Par contre le jour il y aura un problème: Qui est capabl
 e de
 maitriser et
 comprendre l'ensemble des technos mis en œuvre dans une telle solution ?
 ​
 
 Cela me donne l'impression que la révolution SDN va vraiment trop vite.
 J'aurai aimé une étape intermédiaire plus simple avant, comme par exemple
 juste trouver une solution de déploiement automatisée de configuration d'un
 réseau hétérogène. Netconf, après des années de réflexions et je ne sais
 plus combien de RFC n'est toujours pas utilisable à grande échelle dans un
 environnement vraiment multi-constructeurs.
 Le monde de l'IT n'ont pas perdus leur temps en discussion: Ils disposent
 désormais de plusieurs solutions éprouvées qui leur permet de gérer leur
 énormes parc de serveurs (ansible, puppet, chef, salt, etc...). Et pendant
 ce temps là, nous au réseau: Que dalle! Pourtant un serveur est autrement
 plus complexe à gérer qu'un simple switch/routeur.
 Cela nous aurai permis de commencer
 tranquillement notre migration en mode
 devops au lieu de nous prendre la grosse claque SDN d'un coup.
 
 My two cents,
 
 Olivier
 
 ---
 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/