On 25/06/2015 11:47, David Ponzone wrote:
Je me pose des questions sur la stabilité long-terme d’un réseau géré par du
code « intelligent » .
Faut pas voir ça comme du code intelligent, ou de l'IA ou je ne sais
quoi. Le but n'est pas forcément que le réseau prennent des décisions à
la place de
Le 25/06/15 13:17, Olivier MELWIG a écrit :
Le tout est de bien conserver à l'esprit l'importance du réseau
sous-jacent qui interconnecte tout cela et de pouvoir garder la
visibilité des flux, voir des paquets qui y transitent pour être capable
de troubleshooter tout incident qui se passe
Bonjour,
Le tout est de bien conserver à l'esprit l'importance du réseau sous-jacent
qui interconnecte tout cela et de pouvoir garder la visibilité des flux,
voir des paquets qui y transitent pour être capable de troubleshooter tout
incident qui se passe au-dessus, peu importe l'overlay utilisé.
Par « intelligent » , je ne pensais pas au provisionning standard, mais plutôt
à un réseau où un event va déclencher une action.
La configuration d’un port de switch, je n’appelle pas ça un algorithme.
Le 25 juin 2015 à 13:18, Simon Morvan gar...@zone84.net a écrit :
On 25/06/2015 11:47,
25 juin 2015 11:30
À : Romain De Rasse
Cc : Olivier Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG
Objet : Re: [FRnOG] [TECH] SDN chez Google
Bonjour,
ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres sur
lesquels on peut se baser aujourd'hui.
la CLI
De Rasse
Cc : Olivier Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG
Objet : Re: [FRnOG] [TECH] SDN chez Google
Bonjour,
ce n'est qu'une question de s'y mettre, il y a énormément d'outils
libres sur lesquels on peut se baser aujourd'hui.
la CLI est un dinosaure qu'il
Le 25/06/15 11:42, Julien Schafer a écrit :
C'est bien cela qui me fait peur.
Je n'irai pas jusqu'à dire qu'il n'y a jamais de bugs sur du matériel réseau,
mais franchement ce que j'ai pu vivre et voir chez mes différents clients est
de la rigolade au regard des problèmes que génèrent les
On 25/06/2015 11:15, Louis wrote:
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 ?
Faire comme du L2VPN sans MPLS:
- tu as une fabric L3 globale
- tu montes des réseaux L2 de tes
Salut Radu,
J'ai eu la même réflexion que toi et j'ai posé la question directement aux
principaux intéressés.
Rassure-toi, les deux méthodes cohabitent ensemble. Tout le monde s'accorde à
dire que garder la CLI en backup peut s'avérer utile en cas de gros coups
durs. Le but, c'est de s'en
On Thu, Jun 25, 2015, at 11:30, Michel Moriniaux wrote:
la CLI est un dinosaure qu'il faut laisser s’éteindre mais
J'espere quand-meme que la CLI restera toujours disponible, au moins en
tant que porte arriere.
Le tout automatise et programme sans une entree de secours, moi ca ne
me plait pas du
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
Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG
Objet : Re: [FRnOG] [TECH] SDN chez Google
Bonjour,
ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres sur
lesquels on peut se baser aujourd'hui.
la CLI est un dinosaure qu'il faut laisser s’éteindre mais
Salut,
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
-
Bonjour,
ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres
sur lesquels on peut se baser aujourd'hui.
la CLI est un dinosaure qu'il faut laisser s’éteindre mais malheureusement
c'est la seule API universellement disponible. (bon, peut-être pas vu que
beaucoup d'APIs
: Mercredi 24 Juin 2015 15:34:24
Objet: RE: [FRnOG] [TECH] SDN chez Google
Mis à part pour les très gros et les hébergeurs, SDN ça peut avoir un
quelconque intérêt pour un client final classique...?
-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
: [FRnOG] [TECH] SDN chez Google
un article plutôt intéressant
http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter
Il y a aussi une keynote que je regarderai
Objet : Re: [FRnOG] [TECH] SDN chez Google
Bonjour,
Celui de commander le réseau opérateur pour programmer une bande passante sur
une période donnée.
Nous sommes à l'ère du VPN agile, à la demande.
Cordialement,
Michel
- Mail original -
De: Julien Schafer j.scha...@actilogie.com
À: frnog
Le 24/06/2015 15:57, Michel Hostettler a écrit :
Celui de commander le réseau opérateur pour programmer une bande passante sur
une période donnée.
À quoi bon brider à la base ? Si on veux simplifier l'opérationnel
commençons donc par simplifier l'offre…
Nous sommes à l'ère du VPN agile, à
un article plutôt intéressant
http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter
Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps
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 :
20 matches
Mail list logo
