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 af
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 pa
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
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 au-d
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 a écrit :
> On 25/06/2015 11:47, David Ponzone wrote:
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
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é.
D
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 OS
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la
> part de Michel Moriniaux
> > Envoyé : jeudi 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
equ...@frnog.org] De la part de
> Michel Moriniaux
> Envoyé : jeudi 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 quest
5 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'
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 ha
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 const
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é à 409
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
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é"
a écrit :
>2015-06-24 21:01 GMT+02
Hi,
Il s'agit plus d'avoir "une base" ou "une offre" mais d'avoir ce dont j'ai
besoin et donc au prix juste (oui, je sais, théorie =/= pratique).
Faut pas perdre de vue que derrière l'agilité technique que le SDN apporte
il y aussi toute une notion d'automatisation / industrialisation maximum
des
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,
juin 2015 15:58
À : Julien Schafer
Cc : frnog-tech
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 origi
n 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
rnog-tech
Objet : [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=mail&utm_medium=email&utm_campaign=Newsletter
Il y a aussi une ke
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=mail&utm_medium=email&utm_campaign=Newsletter
Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps
htt
22 matches
Mail list logo
