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

2016-04-15 Par sujet Jean-Christophe Valiere
Hello,

Oui c'est notre reseau DANS un Datacenter, pas le backbone d'un DC :-)


Cordialement,
Jean-Christophe Valiere
On 15.04.2016 11:39:17, Michel Hostettler 
 wrote:
Bonjour,

Voulez-vous parler de réseau DANS un datacenter, au sein d'un site client 
terminal (client dans le sens de client d'opérateurs de services de transport) ?

Cordialement,
Michel

- Mail original -
De: "Raphael Mazelier"
À: "Michel Hostettler"
Cc: frnog@frnog.org
Envoyé: Vendredi 15 Avril 2016 11:23:11
Objet: Re: [FRnOG] [TECH] TRILL vs. SPB



>
> L'Ethernet opérateur est une technologie L2VPN, plus évolutive et moins 
> dispendieuse que MPLS ou PPPoE.
> IP est soit une technologie L3VPN (assez peu utilisée avec L2TP) ou une 
> technologie non VPN, multipoint à multipoint.
>

Quelle est le rapport avec le sujet ? on parle de réseau "datacenter",
on ne parle pas du tout de mpls, pppoe ou l2tp ?!

L'objectif d'un réseau "datacenter" est de fournir une connectivité à
ses serveurs (quel que soit la technologie sous-jacente utilisée).

--
Raphael Mazelier


---
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] [BIZ] Commercial

2016-04-15 Par sujet Jean-Pierre Roussanidès

Bonjour,

Nous sommes à la recherche d'un commercial PME Grand Ouest pour 
développer notre activité dans les Télécoms.


Pour cela nous aimerions nous faire accompagner par un cabinet de 
recrutement spécialisé dans notre domaine.


Quelqu'un peut il nous conseiller un cabinet sérieux ?

Merci de votre aide.

JP Roussanidès



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


Re: [FRnOG] [TECH]: correlation MTU et time-out SMTP ?

2016-04-15 Par sujet neo futur
 il se passe quelque chose avec la MTU. je n ai pas eu le probleme en
SMTP mais je l ai eu sur du ssh et sur des formulaires web, heberges
sur des serveurs chez online , et les symptomes sont proches.

 plus de problemes apres avoir baisse la mtu a 1400. il semble que je
ne sois pas le seul, voir ma reponse complete sur :

 
http://serverfault.com/questions/210408/ssh-access-problem-debug1-expecting-ssh2-msg-kex-dh-gex-reply/676026#676026

 Je n ai jamais eu ce probleme depuis plus de 10 ans que je gere des
serveurs, seulement ces derniers mois.
 Certains suggerent que ca pourrait etre lie a des option de DPI des
routeurs cisco . . . dans tous les cas il serait interessant que des
experts se penchent sur le sujet.

  desole si ca n a rien a voir avec ton probleme, mais au cas ou . . .
je signale mon experience, vu que les symptomes sont proches.


2016-04-15 7:32 GMT-05:00 JC PAROLA :
> On Fri, 15 Apr 2016 09:30:01 +0200
> Pierre DOLIDON  wrote:
>
>> Le 14/04/2016 15:17, JC PAROLA a écrit :
>> > Bonjour à tous,
>> >
>> > Des clients m'ont remontés l'erreur suivante sur les serveurs SMTP:
>> >
>> > Apr 14 09:30:12  postfix/error[25452]: 7D3191BF0488: 
>> > to=, relay=none, delay=4.8, delays=4.8/0/0/0.07, 
>> > dsn=4.4.2,
>> > status=deferred (delivery temporarily suspended: conversation with 
>> > ah16.wadax.ne.jp[203.183.218.26] timed out while sending end of data -- 
>> > message
>> > may be sent more than once)
>> >
>> >
>> > PS: le serveur SMTP distant est au japon, il y a donc de la latence. Dans 
>> > l'exemple ci-dessus le delay est de 4.8s mais dans certains cas il est
>> > plus important.
>>
>> Comme manifestement, j'ai été le seul choqué par cela, je voudrais dire
>> que non, le delay de 4,8sec n'est pas la latence vers le japon.
>> Depuis postfix 2.3.13 :
>>
>> Better insight into the nature of performance bottle necks, with
>> detailed logging of delays in various stages of message delivery.
>> Postfix logs additional delay information as "delays=a/b/c/d" where
>> a=time before queue manager, including message transmission; b=time in
>> queue manager; c=connection setup time including DNS, HELO and TLS;
>> d=message transmission time.
>>
>> Les 4,8 sec sont donc "perdues" dans ton pipe local (antispam antivirus,
>> etc.).
>> Il n'y a que 70ms de transmission de data a proprement parler.
>>
>> Pierre.
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
> Je viens de supprimer toutes les policy et le mail est correctement envoyé.
>
> indépendemment de cela, j'avais observé un temps de traitement en file 
> d'attente important dans postfix.
>
> Je pense que tout était lié.
>
> Merci à tous, Merci Pierre. tu avais bien vu.
>
> bonne fin de journée
>
> --
> Jean-christophe PAROLA
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



-- 
Cordialement
   ---
 William Waisse
  http://waisse.org | http://neoskills.com | http://ww7.pe |
https://careers.stackoverflow.com/neofutur
"Computers are like air conditionners. They work better when you close windows."
"You have enemies? Good. That means you've stood up for something in your life."
"First they ignore you, then they laugh at you, then they fight you,
then you win"


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


Re: [FRnOG] [TECH]: correlation MTU et time-out SMTP ?

2016-04-15 Par sujet JC PAROLA
On Fri, 15 Apr 2016 09:30:01 +0200
Pierre DOLIDON  wrote:

> Le 14/04/2016 15:17, JC PAROLA a écrit :
> > Bonjour à tous,
> >
> > Des clients m'ont remontés l'erreur suivante sur les serveurs SMTP:
> >
> > Apr 14 09:30:12  postfix/error[25452]: 7D3191BF0488: 
> > to=, relay=none, delay=4.8, delays=4.8/0/0/0.07, 
> > dsn=4.4.2,
> > status=deferred (delivery temporarily suspended: conversation with 
> > ah16.wadax.ne.jp[203.183.218.26] timed out while sending end of data -- 
> > message
> > may be sent more than once)
> >
> >
> > PS: le serveur SMTP distant est au japon, il y a donc de la latence. Dans 
> > l'exemple ci-dessus le delay est de 4.8s mais dans certains cas il est
> > plus important.
> 
> Comme manifestement, j'ai été le seul choqué par cela, je voudrais dire 
> que non, le delay de 4,8sec n'est pas la latence vers le japon.
> Depuis postfix 2.3.13 :
> 
> Better insight into the nature of performance bottle necks, with 
> detailed logging of delays in various stages of message delivery. 
> Postfix logs additional delay information as "delays=a/b/c/d" where 
> a=time before queue manager, including message transmission; b=time in 
> queue manager; c=connection setup time including DNS, HELO and TLS; 
> d=message transmission time.
> 
> Les 4,8 sec sont donc "perdues" dans ton pipe local (antispam antivirus, 
> etc.).
> Il n'y a que 70ms de transmission de data a proprement parler.
> 
> Pierre.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Je viens de supprimer toutes les policy et le mail est correctement envoyé.

indépendemment de cela, j'avais observé un temps de traitement en file 
d'attente important dans postfix.

Je pense que tout était lié.

Merci à tous, Merci Pierre. tu avais bien vu.

bonne fin de journée

-- 
Jean-christophe PAROLA
  


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


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

2016-04-15 Par sujet Youssef Bengelloun-Zahr
Hello,

Tout dépends de ton business case et des facteurs d'échelles que tu souhaites 
atteindre.

Personnellement, je pense que les deux méthodes / Technos répondent à des 
besoins différents. Et bien évidement, PROs and CONs.

My 2 cents.

RDV cette aprèm.



> 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 Michel Hostettler
Bonjour,

Voulez-vous parler de réseau DANS un datacenter, au sein d'un site client 
terminal (client dans le sens de client d'opérateurs de services de transport) ?

Cordialement,
Michel 

- Mail original -
De: "Raphael Mazelier" 
À: "Michel Hostettler" 
Cc: frnog@frnog.org
Envoyé: Vendredi 15 Avril 2016 11:23:11
Objet: Re: [FRnOG] [TECH] TRILL vs. SPB



>
> L'Ethernet opérateur est une technologie L2VPN, plus évolutive et moins 
> dispendieuse que MPLS ou PPPoE.
> IP est soit une technologie L3VPN (assez peu utilisée avec L2TP) ou une 
> technologie non VPN, multipoint à multipoint.
>

Quelle est le rapport avec le sujet ? on parle de réseau "datacenter", 
on ne parle pas du tout de mpls, pppoe ou l2tp ?!

L'objectif d'un réseau "datacenter" est de fournir une connectivité à 
ses serveurs (quel que soit la technologie sous-jacente utilisée).

-- 
Raphael Mazelier


---
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 Raphael Mazelier





L'Ethernet opérateur est une technologie L2VPN, plus évolutive et moins 
dispendieuse que MPLS ou PPPoE.
IP est soit une technologie L3VPN (assez peu utilisée avec L2TP) ou une 
technologie non VPN, multipoint à multipoint.



Quelle est le rapport avec le sujet ? on parle de réseau "datacenter", 
on ne parle pas du tout de mpls, pppoe ou l2tp ?!


L'objectif d'un réseau "datacenter" est de fournir une connectivité à 
ses serveurs (quel que soit la technologie sous-jacente utilisée).


--
Raphael Mazelier


---
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 Michel Hostettler
Bonjour,

Cela me semble assez étrange de mélanger des carottes avec des poireaux, sauf 
pour faire une soupe.

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

L'Ethernet opérateur est une technologie L2VPN, plus évolutive et moins 
dispendieuse que MPLS ou PPPoE.
IP est soit une technologie L3VPN (assez peu utilisée avec L2TP) ou une 
technologie non VPN, multipoint à multipoint.

Les objectifs sont un peu différents.
Cordialement,
Michel Hostettler


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


[FRnOG] [JOBS] Administrateur réseaux

2016-04-15 Par sujet Victor B
Bonjour,



iBrowse est un FAI spécialisé dans les réseaux privés et les services à
valeur ajoutée (MPLS, Wifi, VoIP etc.) sur un créneau porteur. L’entreprise
est basée dans le centre de Paris et la clientèle est internationale.



Nous sommes à la recherche de compétences en réseau MPLS, en VoIP et en
administration Systèmes (VM). Le développement (Python ...) fait partie de
notre environnement. Nous privilégions les candidats avec une expérience
validée (5 ans) dans une ou plusieurs des compétences recherchées.
Néanmoins les candidats débutants, à fort potentiel et qui montrent le goût
et la volonté d'apprendre et d'évoluer sont les bienvenus.



iBrowse est une petite entreprise dynamique évoluant dans un environnement
international. L'anglais est obligatoire. Nous cherchons à mettre en valeur
et à développer les compétences de chacun. Nous travaillons en équipe et
nous intégrons les dernières avancées technologiques afin d’apporter des
solutions toujours plus performantes à nos clients qui sont de grands
groupes européens.



Rejoignez une équipe motivée et sympathique !



Demander des informations directement à Jonathan Angel, Blake Willis ou
Victor Boglea présents au FRnOG aujourd'hui.

Plus de détails sur : http://www.ibrowse.com/careers/; pour nous joindre :
01 70 61 83 13 ; pour postuler sans réfléchir J :  recr...@ibrowse.com
-- 
*Victor Boglea*

My PGP public signature


---
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] [TECH] TRILL vs. SPB

2016-04-15 Par sujet Raphael Mazelier

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/


Re: [FRnOG] [TECH]: correlation MTU et time-out SMTP ?

2016-04-15 Par sujet JC PAROLA
On Fri, 15 Apr 2016 09:30:01 +0200
Pierre DOLIDON  wrote:

> Le 14/04/2016 15:17, JC PAROLA a écrit :
> > Bonjour à tous,
> >
> > Des clients m'ont remontés l'erreur suivante sur les serveurs SMTP:
> >
> > Apr 14 09:30:12  postfix/error[25452]: 7D3191BF0488: 
> > to=, relay=none, delay=4.8, delays=4.8/0/0/0.07, 
> > dsn=4.4.2,
> > status=deferred (delivery temporarily suspended: conversation with 
> > ah16.wadax.ne.jp[203.183.218.26] timed out while sending end of data -- 
> > message
> > may be sent more than once)
> >
> >
> > PS: le serveur SMTP distant est au japon, il y a donc de la latence. Dans 
> > l'exemple ci-dessus le delay est de 4.8s mais dans certains cas il est
> > plus important.
> 
> Comme manifestement, j'ai été le seul choqué par cela, je voudrais dire 
> que non, le delay de 4,8sec n'est pas la latence vers le japon.
> Depuis postfix 2.3.13 :
> 
> Better insight into the nature of performance bottle necks, with 
> detailed logging of delays in various stages of message delivery. 
> Postfix logs additional delay information as "delays=a/b/c/d" where 
> a=time before queue manager, including message transmission; b=time in 
> queue manager; c=connection setup time including DNS, HELO and TLS; 
> d=message transmission time.
> 
> Les 4,8 sec sont donc "perdues" dans ton pipe local (antispam antivirus, 
> etc.).
> Il n'y a que 70ms de transmission de data a proprement parler.
> 
> Pierre.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Merci beaucoup pour cette précision. Ma version de postfix 2.11 est donc 
concernée.

Ton explication nous permet de comprendre pourquoi le mail ne part pas avec 
Postfix mais peut être émis avec telnet quelque soit la valeur du champ
DATA par rapport au MTU.

Je vais donc analyser cela en fonction de mes policy.

Je ferais un retour sur la liste pour que cela puisse servir à d'autres.

merci encore

-- 
Jean-christophe PAROLA


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


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

2016-04-15 Par sujet David Limery
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,
>> 
>> Dans le cadre de DataCenter ou de Campus ?
>> Je pense que les problématiques sont différentes (entre DataCenter et 
>> Campus). Quoi qu’il en soit, Trill que je trouve sympathique 
>> intellectuellement a été « enrichi » par les constructeurs et cela est 
>> devenu un « machin » non interopérable.
>> 
>> Cordialement
>> 
>> Fabien
>> 
>>> Le 14 avr. 2016 à 17:37, Jean-Christophe Valiere  a écrit :
>>> 
>>> Salut,
>>> 
>>> Est-ce que des gens ont des input sur le choix entre TRILL & SPB ?
>>> 
>>> Si vous avez des questions n'hesitez pas :-)
>>> 
>>> Cordialement,
>>> Jean-Christophe Valiere
>>> ---
>>> Liste de diffusion du FRnOG
>>> 

Re: [FRnOG] [MISC] FRNOG 26.0

2016-04-15 Par sujet Philippe Bourcier


Bonjour,

Vendredi c'est trolldi (ou ravioli) pour certains et réunion FRNOG pour 
les autres !


Vous êtes cordialement attendus à partir de 14h00 à l'Hôtel 
Intercontinental et cette fois-ci *il y aura du WiFi pour tout le monde* 
!!!


Donc même en astreinte, chers netops/devops, vous n'avez plus d'excuses 
pour ne pas venir :)


Le programme :
http://www.frnog.org/?page=frnog26


Cordialement,
Philippe Bourcier

On 2016-04-11 21:47, Philippe Bourcier wrote:

Bonsoir,

Eh oui, on y est déjà !

Le programme est désormais complet et vous pouvez toujours vous
inscrire pour la réunion de vendredi.
C'est par ici : http://www.frnog.org/?page=frnog26


Les inscriptions sont ouvertes pour la réunion FRNOG 26.0 :
http://www.frnog.org/?page=frnog26


La prochaine réunion FRNOG aura lieu le 15 Avril prochain.



Cordialement,


--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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


Re: [FRnOG] [TECH]: correlation MTU et time-out SMTP ?

2016-04-15 Par sujet Pierre DOLIDON

Le 14/04/2016 15:17, JC PAROLA a écrit :

Bonjour à tous,

Des clients m'ont remontés l'erreur suivante sur les serveurs SMTP:

Apr 14 09:30:12  postfix/error[25452]: 7D3191BF0488: to=, 
relay=none, delay=4.8, delays=4.8/0/0/0.07, dsn=4.4.2,
status=deferred (delivery temporarily suspended: conversation with 
ah16.wadax.ne.jp[203.183.218.26] timed out while sending end of data -- message
may be sent more than once)


PS: le serveur SMTP distant est au japon, il y a donc de la latence. Dans 
l'exemple ci-dessus le delay est de 4.8s mais dans certains cas il est plus
important.


Comme manifestement, j'ai été le seul choqué par cela, je voudrais dire 
que non, le delay de 4,8sec n'est pas la latence vers le japon.

Depuis postfix 2.3.13 :

Better insight into the nature of performance bottle necks, with 
detailed logging of delays in various stages of message delivery. 
Postfix logs additional delay information as "delays=a/b/c/d" where 
a=time before queue manager, including message transmission; b=time in 
queue manager; c=connection setup time including DNS, HELO and TLS; 
d=message transmission time.


Les 4,8 sec sont donc "perdues" dans ton pipe local (antispam antivirus, 
etc.).

Il n'y a que 70ms de transmission de data a proprement parler.

Pierre.


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