Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Bonsoir,

Le 21/05/2021 à 18:48, aderum...@odiso.com a écrit :

Le vendredi 21 mai 2021 à 14:02 +0200, Emmanuel DECAEN a écrit :

Sur le principe oui, c'est sympa, mais à moins de changer toute
l'infrastructure, la suppression de l'ARP peut poser problème si elle se
fait par étape, en commençant par le coeur.

Cas concret: Infrastructure avec deux switchs clients A et B (L2)
connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP +
BGP-EVPN)
Ton client décide de basculer son serveur entre ses deux switchs (A->B)
=> le serveur devient injoignable.

Dans un réseau uniquement L2, à la première requête ARP, la réponse du
serveur permet de mettre à jour la table d'adresse MAC sur le chemin de
switchs (y compris le coeur).
Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera
filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne
sera plus joignable.

Il y a plusieurs solutions de contournement : timeout arp, retrait du
suppress-arp
Si quelqu'un a une meilleure solution, je suis preneur.

Mais en attendant, à diagnostiquer la première fois, c'est un peu 
coton ;-)





Je pense que le problème, c'est que tu ne fais pas de l'evpn de bout 
en bout, mais uniquement sur tes coeurs.


Oui, nous sommes d'accord, c'est bien le problème avec le suppress-arp 
dans ce contexte.
Et je ne me vois pas balancer tout le parc de switchs L2 d'extrémité 
parce qu'ils ne savent pas faire du VXLAN.
=> Le compromis du retrait du suppress-arp est acceptable en attendant 
le renouvèlement du parc :-)


Bon Week-End

--
*Emmanuel DECAEN*


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

Re: [FRnOG] [TECH] Best Practice I/O esxi 6.0

[Romain]

Avec une signature comme ça, t’as de la chance qu’on soit vendredi ;)

Le ven. 21 mai 2021 à 23:26, Ludovic LACOSTE  a
écrit :

> de noc à soc en 2 mails
> En même temps, le phénomène DevOps cherche des références,  des piliers,
> afin de justifier leur acceptation dans le monde de l'infrastructure...
>
> Téléchargez Outlook pour Android
>
> 
> From: frnog-requ...@frnog.org  on behalf of
> Guillaume Tournat via frnog 
> Sent: Friday, May 21, 2021 11:08:38 PM
> To: Merwan Zenati ; frnog-tech <
> frnog-t...@frnog.org>
> Subject: Re: [FRnOG] [TECH] Best Practice I/O esxi 6.0
>
> Bonsoir,
>
> Ne le prends pas personnellement, mais le thread précédent parlant de
> Postfix,
>
> et le tien d'ESXi, je me demande s'il ne faudrait pas rappeler la
> signification de
>
> l'acronyme FRnOG...?
>
>
> Pour le précédent thread, un point d'entrée serait plutôt :
> smtp...@groupes.renater.fr
>
> et pour toi :  fr...@frsag.org
>
> ;-)
>
>
> Le 21/05/2021 à 22:58, Merwan Zenati a écrit :
> > Hello la liste, Happy Friday,
> >
> >
> > Je suis confronte a un probleme d'I/O sur l'Esxi d'un client.
> > Ils utilisent un fichier QuickBooks(Hosted sur DC)  via un serveur
> SRV-TS .
> > Les deux servers se trouvent sur le meme Esxi.
> > Avec le temps, et beaucoup de plaintes a propos de lenteur, nous avont
> > remarque que le probleme, est un probleme d'I/O.
> >
> > J'aimerais savoir si certains on des best practices a me proposer pour
> > ameliorer cela (tant au niveau OS/ESXi qu'au niveau Server/iLO) .
> > Sachant que le server est équipé de 4x SSD Samsung 860 2TB en raid 5.
> > C'est ProLiant DL360 Gen10 avec Firmware U32 V2.12.
> > J'ai l'impression que le serveur contient seulement un raid logiciel (oui
> > c'est a ch*er) Embedded RAID HPE Smart Array P408i-a SR Gen10  Version du
> > Firmware 1.99.
> >
> > Auriez vous des reco pour booster les I/O ? J'imagine que plus d'infos
> sont
> > necessaire egalement.
> > En esperant que quelqu'un puisse m'aiguiller.
> > Bon W-E
> >
> > Merwan
> >
> > ---
> > 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] Best Practice I/O esxi 6.0

[Ludovic LACOSTE]

de noc à soc en 2 mails
En même temps, le phénomène DevOps cherche des références,  des piliers, afin 
de justifier leur acceptation dans le monde de l'infrastructure...

Téléchargez Outlook pour Android


From: frnog-requ...@frnog.org  on behalf of Guillaume 
Tournat via frnog 
Sent: Friday, May 21, 2021 11:08:38 PM
To: Merwan Zenati ; frnog-tech 
Subject: Re: [FRnOG] [TECH] Best Practice I/O esxi 6.0

Bonsoir,

Ne le prends pas personnellement, mais le thread précédent parlant de
Postfix,

et le tien d'ESXi, je me demande s'il ne faudrait pas rappeler la
signification de

l'acronyme FRnOG...?


Pour le précédent thread, un point d'entrée serait plutôt :
smtp...@groupes.renater.fr

et pour toi :  fr...@frsag.org

;-)


Le 21/05/2021 à 22:58, Merwan Zenati a écrit :
> Hello la liste, Happy Friday,
>
>
> Je suis confronte a un probleme d'I/O sur l'Esxi d'un client.
> Ils utilisent un fichier QuickBooks(Hosted sur DC)  via un serveur SRV-TS .
> Les deux servers se trouvent sur le meme Esxi.
> Avec le temps, et beaucoup de plaintes a propos de lenteur, nous avont
> remarque que le probleme, est un probleme d'I/O.
>
> J'aimerais savoir si certains on des best practices a me proposer pour
> ameliorer cela (tant au niveau OS/ESXi qu'au niveau Server/iLO) .
> Sachant que le server est équipé de 4x SSD Samsung 860 2TB en raid 5.
> C'est ProLiant DL360 Gen10 avec Firmware U32 V2.12.
> J'ai l'impression que le serveur contient seulement un raid logiciel (oui
> c'est a ch*er) Embedded RAID HPE Smart Array P408i-a SR Gen10  Version du
> Firmware 1.99.
>
> Auriez vous des reco pour booster les I/O ? J'imagine que plus d'infos sont
> necessaire egalement.
> En esperant que quelqu'un puisse m'aiguiller.
> Bon W-E
>
> Merwan
>
> ---
> 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] Best Practice I/O esxi 6.0

[Guillaume Tournat via frnog]

Bonsoir,

Ne le prends pas personnellement, mais le thread précédent parlant de 
Postfix,


et le tien d'ESXi, je me demande s'il ne faudrait pas rappeler la 
signification de


l'acronyme FRnOG...?


Pour le précédent thread, un point d'entrée serait plutôt : 
smtp...@groupes.renater.fr


et pour toi :  fr...@frsag.org

;-)


Le 21/05/2021 à 22:58, Merwan Zenati a écrit :

Hello la liste, Happy Friday,


Je suis confronte a un probleme d'I/O sur l'Esxi d'un client.
Ils utilisent un fichier QuickBooks(Hosted sur DC)  via un serveur SRV-TS .
Les deux servers se trouvent sur le meme Esxi.
Avec le temps, et beaucoup de plaintes a propos de lenteur, nous avont
remarque que le probleme, est un probleme d'I/O.

J'aimerais savoir si certains on des best practices a me proposer pour
ameliorer cela (tant au niveau OS/ESXi qu'au niveau Server/iLO) .
Sachant que le server est équipé de 4x SSD Samsung 860 2TB en raid 5.
C'est ProLiant DL360 Gen10 avec Firmware U32 V2.12.
J'ai l'impression que le serveur contient seulement un raid logiciel (oui
c'est a ch*er) Embedded RAID HPE Smart Array P408i-a SR Gen10  Version du
Firmware 1.99.

Auriez vous des reco pour booster les I/O ? J'imagine que plus d'infos sont
necessaire egalement.
En esperant que quelqu'un puisse m'aiguiller.
Bon W-E

Merwan

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




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

[FRnOG] [TECH] Best Practice I/O esxi 6.0

[Merwan Zenati]

Hello la liste, Happy Friday,


Je suis confronte a un probleme d'I/O sur l'Esxi d'un client.
Ils utilisent un fichier QuickBooks(Hosted sur DC)  via un serveur SRV-TS .
Les deux servers se trouvent sur le meme Esxi.
Avec le temps, et beaucoup de plaintes a propos de lenteur, nous avont
remarque que le probleme, est un probleme d'I/O.

J'aimerais savoir si certains on des best practices a me proposer pour
ameliorer cela (tant au niveau OS/ESXi qu'au niveau Server/iLO) .
Sachant que le server est équipé de 4x SSD Samsung 860 2TB en raid 5.
C'est ProLiant DL360 Gen10 avec Firmware U32 V2.12.
J'ai l'impression que le serveur contient seulement un raid logiciel (oui
c'est a ch*er) Embedded RAID HPE Smart Array P408i-a SR Gen10  Version du
Firmware 1.99.

Auriez vous des reco pour booster les I/O ? J'imagine que plus d'infos sont
necessaire egalement.
En esperant que quelqu'un puisse m'aiguiller.
Bon W-E

Merwan

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

[FRnOG] [JOBS] Recherche d'alternance sur la region parisienne

[perso via frnog]

Bonjour à toute la liste,

Je n'ai jamais eu l'occasion de parler à la liste, alors je me présente : Je 
m'appelle Pierre Sarret, j'ai 20 ans et je suis originaire de Blois.
Pour me présenter en quelques mots, je dirais avant tout que je suis passionné 
d'informatique. Bidouilleur dès mon adolescence, je suis devenu au fur et à 
mesure du temps un vrai passionné des réseaux & systèmes, ce qui guide 
aujourd'hui mon orientation professionnelle.

D'un point de vue études, je suis actuellement en Licence Pro Qualité & 
Sécurité des SI, en alternance chez Orange. Je suis diplômé d'un DUT Réseaux et 
Télécoms à l'IUT de Blois, et d'un baccalauréat STI2D SIN au lycée Augustin 
Thierry à Blois.
Je vais en septembre poursuivre mes études en Master Système, Réseau & Cloud 
Computing sur Paris, je suis donc en recherche d'une entreprise où je pourrais 
effectuer une alternance pendant ce Master.

J'ai pu lors de mes études approfondir mes connaissances des réseaux et 
systèmes. Je possède les certifications Cisco CCNA 1 et 2 (Routing & Switching) 
ainsi que CCNA Security. Je poursuis personnellement cet approfondissement en 
expérimentant chez moi, par le biais d'un homelab, par exemple en système avec 
Proxmox, Docker, Kubernetes, ainsi que réseau avec EVE-NG/GNS3 et DN42, où 
j'explore BGP, OSPF, et d'autres protocoles qui façonnent nos réseaux.

Lors de mon temps libre, je gère avec des amis l'association Loire Esports 
(http://loire-esports.fr), association d'événementiel dans l'Esport, que je 
préside, spécialisée dans l'organisation de LAN Party. Bien que l'activité est 
freinée à cause de la pandémie, nous continuons de réfléchir à l'organisation 
de notre 3ᵉ LAN Party. Nous avons organisé une LAN réunissant plus de 40 
joueurs en février 2020, où j'ai beaucoup appris en organisation 
événementielle, en système, en scénographie ainsi qu'en réseau.

Je recherche donc une entreprise où je pourrais approfondir mes connaissances 
en réseau et/ou en système, avec de vrais projets. J'ai un réel plaisir à 
apprendre de nouvelles choses et à expérimenter, je sais également être 
polyvalent et faire preuve d'autonomie. Je suis ouvert à toutes propositions.

Mon master se déroulera en un cycle d’une semaine école / trois semaines 
entreprise, pour un démarrage début octobre.

N'hésitez pas à me contacter si mon profil vous intéresse, ou que vous 
souhaitez avoir plus d'information sur moi.
Mon CV est disponible sur ce lien : https://pierresarret.fr/cv.pdf 
(https://pierresarret.fr/cv.pdf)

Je suis joignable par mail et par téléphone, aux coordonnées suivantes :
alterna...@pierresarret.fr (mailto:alterna...@pierresarret.fr)
+33 6 58 84 44 40

Je vous remercie par avance.

Cordialement,
Pierre SARRET

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le vendredi 21 mai 2021 à 14:02 +0200, Emmanuel DECAEN a écrit :
> Bonjour,
> 
> Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :
> > Pour argumenter le débat, le SDN a tout a fait sa place dans un 
> > environnement complexe style Datacenter, et comme j'ai pu le voir
> > plus 
> > tôt aussi, en séparant le controlplane du dataplane.
> > Imaginez un monde ou le broadcast ARP disparait, ce serait top non
> > ? 
> > (ne me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à
> > cela, 
> > le contrôleur ayant une connaissance globale du réseau, la requête 
> > peut être répondu localement par le premier saut sans avoir à 
> > traverser le réseau  !
> 
> 
> Sur le principe oui, c'est sympa, mais à moins de changer toute 
> l'infrastructure, la suppression de l'ARP peut poser problème si elle
> se 
> fait par étape, en commençant par le coeur.
> 
> Cas concret: Infrastructure avec deux switchs clients A et B (L2) 
> connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress
> ARP + 
> BGP-EVPN)
> Ton client décide de basculer son serveur entre ses deux switchs (A-
> >B) 
> => le serveur devient injoignable.
> 
> Dans un réseau uniquement L2, à la première requête ARP, la réponse
> du 
> serveur permet de mettre à jour la table d'adresse MAC sur le chemin
> de 
> switchs (y compris le coeur).
> Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP
> sera 
> filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne
> sera plus joignable.
> 
> Il y a plusieurs solutions de contournement : timeout arp, retrait du
> suppress-arp
> Si quelqu'un a une meilleure solution, je suis preneur.
> 
> Mais en attendant, à diagnostiquer la première fois, c'est un peu
> coton ;-)
> 
> 

Je pense que le problème, c'est que tu ne fais pas de l'evpn de bout en
bout, mais uniquement sur tes coeurs.
Au DC (on fait du hosting), on fait directement de l'evpn sur les
leafs/swich racks (et meme sur les hyperviseurs en direct pour les vms)
, et meme pas sur les coeurs.
Du coup, aucun soucis avec la suppression d'arp.



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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

Okay, je pense que j’ai trouvé :

le problème était que j’avais écris ceci :

virtual_mailbox_domains =   pgsql:/usr/local/etc/postfix/domains.cf

au lieu de cela :

virtual_alias_domains =   pgsql:/usr/local/etc/postfix/domains.cf

avec

virtual_alias_maps =pgsql:/usr/local/etc/postfix/virtuals.cf

Donc, en fait, les deux lignes étaient contradictoires, parce que virtual alias 
≠ virtual mailbox.

Je me demande d’ailleurs comment cela pouvait fonctionner malgré cette erreur 
flagrante de configuration.

Merci à tous ceux qui m’ont répondu, et toutes mes excuses pour le bruit.

Vincent


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

Re: [FRnOG] [TECH] Petite question Postfix

[Daniel via frnog]

Le 21/05/2021 à 16:44, Vincent Habchi a écrit :

Si j'ai bien compris:

dans ton virtusertable tu inscris pour chaque domaine après la liste des users

@another.domain error:nouser No such user here - Utilisateur 
inconnu - Blad poczta adresa

Dans le fichier des alias virtuels (virtual_alias_maps), j’ai des entrées du 
genre :

#alias virtuel  # utilisateur

toto@DN machin
tata@DN truc

où ‘machin' et ‘truc’ sont des utilisateurs locaux.


et c'est là ou tu rajoutes

#alias virtuel  # utilisateur

toto@DN machin
tata@DN truc
@DN Erreur - utilisateur inconnu ; ou
@DN /dev/null

et tu fais la même chose pour le second domaine

--
Daniel


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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

Priviet! 

> On 21 May 2021, at 17:01, Pavel Polyakov  wrote:
> 
> Il faudrait un postconf -n.
> 
> T'aurais pas mis tes domaines dans mydestination en plus du
> virtual_mailbox_domains ?

Ben non, justement :

> grep mydestination main.cf

# The mydestination parameter specifies the list of domains that this
#mydestination = $myhostname, localhost.$mydomain, localhost
mydestination = localhost, $myhostname, $mydomain

Spassibo bolchoy!

Vincent


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

Re: [FRnOG] [TECH] Petite question Postfix

[Pavel Polyakov via frnog]

Vincent Habchi  wrote:

> Dans le fichier des alias virtuels (virtual_alias_maps), j’ai des
> entrées du genre :
> 
> #alias virtuel# utilisateur
> 
> toto@DN   machin
> tata@DN   truc
> 
> où ‘machin' et ‘truc’ sont des utilisateurs locaux.
> 
> Le problème, c’est que je m’aperçois que tout se passe comme si ces
> deux lignes :
> 
> machin@DN machin
> truc@DN   truc

Il faudrait un postconf -n.

T'aurais pas mis tes domaines dans mydestination en plus du
virtual_mailbox_domains ?

--
PP


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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

> Si j'ai bien compris:
> 
> dans ton virtusertable tu inscris pour chaque domaine après la liste des users
> 
> @another.domain error:nouser No such user here - Utilisateur 
> inconnu - Blad poczta adresa

Dans le fichier des alias virtuels (virtual_alias_maps), j’ai des entrées du 
genre :

#alias virtuel  # utilisateur

toto@DN machin
tata@DN truc

où ‘machin' et ‘truc’ sont des utilisateurs locaux.

Le problème, c’est que je m’aperçois que tout se passe comme si ces deux lignes 
:

machin@DN   machin
truc@DN truc

étaient automatiquement ajoutées. Ce que je ne veux pas.

Vincent


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

Re: [FRnOG] [TECH] Petite question Postfix

[Daniel via frnog]

Si j'ai bien compris:

dans ton virtusertable tu inscris pour chaque domaine après la liste des 
users


@another.domain     error:nouser No such user here - 
Utilisateur inconnu - Blad poczta adresa


Le 21/05/2021 à 16:22, Vincent Habchi a écrit :

Tu vas finir par la poser ta question ? ;)

Bon, ok, vu les demandes insistantes du public, je cède :)

(couper-coller hein) :

Mon serveur postfix gère, disons, trois domaines : un domain principal (mettons 
root.domain) et deux domaines virtuels (other.domain, yetanother.domain)

J’ai un certain nombre d’utilisateurs, disons deux, foo et baz, qui peuvent 
recevoir du mail soit sur @root.domain directement (foo@root.domain, 
baz@root.domain) soit sur des alias virtuels correspondant aux deux domaines 
virtuels (par exemple : ham@other.domain, yummy@yetanother.domain). Ces alias 
virtuels sont placés dans le fichier virtual_alias_maps.

Ce dont je viens de me rendre compte, c’est que les adresses foo@other.domain, 
baz@other.domain, foo@yetanother.domain et baz@yetanother.domain, même si elles 
ne sont pas présentes dans le fichier des alias virtuels, fonctionnent quand 
même. Autrement dit, quel que soit le contenu des alias virtuels, du moment que 
UN est un nom d’utilisateur local, et que DN est un alias cité dans 
virtual_mailbox_domains, alors l’adresse UN@DN est routée, même si UN@DN 
n’apparaît pas dans virtual_alias_map.

Y aurait-il un moyen d’empêcher ce comportement par défaut, autrement dit de 
retourner les courriers adressés à UN@DN comme utilisateur inexistant si cette 
adresse n’est pas explicitement listée dans virtual_alias_map ?

Merci beaucoup !

Vincent

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


--
Daniel


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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

> Je sais bien qu'on est vendredi après-midi mais ta demande est quand
> même sacrément confuse ...
> 
> Si tu veux une réponse, soit clair et précis. Encore plus sur cette
> liste que sur beaucoup d'autres, ce sera apprécié et tu maximises ta
> chance de réponse pertinente et donc utile.

Euh, j’essayais d’illustrer ça le plus simplement possible. Je vais le faire en 
mode prof de maths :)

Donc le problème est le suivant :

Soit DR le domaine root de mon serveur.
Soit DN un domaine virtuel (qui n’est pas un sous-domaine de DR) listé dans 
virtual_mailbox_domains.

Soit UN le nom d’un utilisateur local (UN@DR existe).

Alors, apparemment UN@DN est routé vers UN@DR, même si aucune ligne UN@DN 
existe dans la base ‘virtual_alias_map’.

Comment faire pour que UN@DN soit retourné en erreur, plutôt que 
silencieusement accepté ?

Merci !
Vincent


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

Re: [FRnOG] [TECH] Petite question Postfix

[Julien Escario]

Je sais bien qu'on est vendredi après-midi mais ta demande est quand
même sacrément confuse ...

Si tu veux une réponse, soit clair et précis. Encore plus sur cette
liste que sur beaucoup d'autres, ce sera apprécié et tu maximises ta
chance de réponse pertinente et donc utile.

En bref, soit tech.

Julien

Le 21/05/2021 à 16:16, Vincent Habchi a écrit :
> Ah, non, ce n’était pas ma question en fait. Petit imbroglio.
>
> Je repends :
>
> Christophe Baegert m’avait répondu par mail perso à mon premier message 
> quelque chose du genre : « dis toujours ce qui te chiffonne ». je lui ai donc 
> envoyé un mail avec mon souci, mail qui m’est revenu en pleine face avec 
> l’erreur de RDNS. Comme je ne pouvais pas lui faire part de cette erreur par 
> mail direct (lol), je l’ai postée sur la liste pour qu’il soit prévenu ! :)
>
> V.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

> Tu vas finir par la poser ta question ? ;)

Bon, ok, vu les demandes insistantes du public, je cède :)

(couper-coller hein) :

Mon serveur postfix gère, disons, trois domaines : un domain principal (mettons 
root.domain) et deux domaines virtuels (other.domain, yetanother.domain)

J’ai un certain nombre d’utilisateurs, disons deux, foo et baz, qui peuvent 
recevoir du mail soit sur @root.domain directement (foo@root.domain, 
baz@root.domain) soit sur des alias virtuels correspondant aux deux domaines 
virtuels (par exemple : ham@other.domain, yummy@yetanother.domain). Ces alias 
virtuels sont placés dans le fichier virtual_alias_maps. 

Ce dont je viens de me rendre compte, c’est que les adresses foo@other.domain, 
baz@other.domain, foo@yetanother.domain et baz@yetanother.domain, même si elles 
ne sont pas présentes dans le fichier des alias virtuels, fonctionnent quand 
même. Autrement dit, quel que soit le contenu des alias virtuels, du moment que 
UN est un nom d’utilisateur local, et que DN est un alias cité dans 
virtual_mailbox_domains, alors l’adresse UN@DN est routée, même si UN@DN 
n’apparaît pas dans virtual_alias_map.

Y aurait-il un moyen d’empêcher ce comportement par défaut, autrement dit de 
retourner les courriers adressés à UN@DN comme utilisateur inexistant si cette 
adresse n’est pas explicitement listée dans virtual_alias_map ?

Merci beaucoup !

Vincent

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

Re: [FRnOG] [TECH] Petite question Postfix

[Romain]

Tu vas finir par la poser ta question ? ;)

Le ven. 21 mai 2021 à 16:16, Vincent Habchi  a écrit :

> Ah, non, ce n’était pas ma question en fait. Petit imbroglio.
>
> Je repends :
>
> Christophe Baegert m’avait répondu par mail perso à mon premier message
> quelque chose du genre : « dis toujours ce qui te chiffonne ». je lui ai
> donc envoyé un mail avec mon souci, mail qui m’est revenu en pleine face
> avec l’erreur de RDNS. Comme je ne pouvais pas lui faire part de cette
> erreur par mail direct (lol), je l’ai postée sur la liste pour qu’il soit
> prévenu ! :)
>
> V.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

Ah, non, ce n’était pas ma question en fait. Petit imbroglio.

Je repends :

Christophe Baegert m’avait répondu par mail perso à mon premier message quelque 
chose du genre : « dis toujours ce qui te chiffonne ». je lui ai donc envoyé un 
mail avec mon souci, mail qui m’est revenu en pleine face avec l’erreur de 
RDNS. Comme je ne pouvais pas lui faire part de cette erreur par mail direct 
(lol), je l’ai postée sur la liste pour qu’il soit prévenu ! :)

V.


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

Re: [FRnOG] [TECH] Petite question Postfix

[neo futur]

> Poses toujours là question ici, on verra après si qqu'un sait répondre ;-)
La question est posee dans son email suivant, Il a un DNS valide et un
reverse DNS valide , mais le MX en face lui repond :

> host mx2.lixium.fr[79.98.96.12] said: 550 5.7.1 Client
>   host rejected: cannot find your reverse hostname, [185.5.111.8] (in reply
>   to RCPT TO command)
>Reporting-MTA: dns; smtp01.srv.celeste.fr

>
> Cdlt,
>
> Le 21/05/2021 à 14:53, Vincent Habchi a écrit :
> > Je ne suis pas certain que ce soit le bon groupe pour ça, mais si quelqu’un 
> > a de bonnes connaissances en postfix, j’aurais une question à lui poser.
> >
> > Merci,
> > Vincent
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> 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] Petite question Postfix

[Jean-Yves LENHOF]

Hello,

Poses toujours là question ici, on verra après si qqu'un sait répondre ;-)

Cdlt,

Le 21/05/2021 à 14:53, Vincent Habchi a écrit :

Je ne suis pas certain que ce soit le bon groupe pour ça, mais si quelqu’un a 
de bonnes connaissances en postfix, j’aurais une question à lui poser.

Merci,
Vincent

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



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

Re: [FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

Christophe,

Oops, désolé de la réponse directe sur le forum mais l’envoi de mail direct ne 
fonctionne pas :

: host mx2.lixium.fr[79.98.96.12] said: 550 5.7.1 Client
   host rejected: cannot find your reverse hostname, [185.5.111.8] (in reply
   to RCPT TO command)
Reporting-MTA: dns; smtp01.srv.celeste.fr
X-Postfix-Queue-ID: 8F2352283B
X-Postfix-Sender: rfc822; vinc...@geomag.fr
Arrival-Date: Fri, 21 May 2021 15:09:25 +0200 (CEST)

Final-Recipient: rfc822; c.baeg...@lixium.fr
Original-Recipient: rfc822;c.baeg...@lixium.fr
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx2.lixium.fr
Diagnostic-Code: smtp; 550 5.7.1 Client host rejected: cannot find your reverse
   hostname, [185.5.111.8]

Et pourtant :

> dig -x 185.5.111.8
[…]
;; ANSWER SECTION:
8.111.5.185.IN-ADDR.ARPA. 3450  IN  PTR smtp01.srv.celeste.fr.


Il doit y avoir un souci de config.

V.


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

[FRnOG] [TECH] Petite question Postfix

[Vincent Habchi]

Je ne suis pas certain que ce soit le bon groupe pour ça, mais si quelqu’un a 
de bonnes connaissances en postfix, j’aurais une question à lui poser.

Merci,
Vincent

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :


Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de 
manière centralisée, et éviter l'auto-apprentissage de celles-ci, et 
pourquoi pas faire du switching intelligent (load balancing, ...) 
comme le permet à peu prêt le PBR que nous connaissons tous, mais au 
niveau 2.=> Adieu le spanning-tree



Oui, c'est un gros gain de supprimer le spanning-tree, on utilise tous 
les liens en même temps, et la bascule en cas de panne se fait en moins 
d'une seconde.
Pour éviter le risque de SPOF avec la centralisation, on a "stocké" les 
MAC + IP/MAC sur deux route-reflector.


Pour revenir à la partie configuration centralisée, pour moi, cela reste 
le point délicat.
Sur le papier c'est sympa, mais dans la réalité les modules ansible 
évoluent parfois avec des modifications critiques, il faut être attentif 
et prudent.
Par exemple la disparition du "switchport mode" dans une évolution : 
https://github.com/ansible/ansible/issues/65032


Je pense que la centralisation de la configuration est indispensable 
pour un réseau significatif en constante évolution, ça simplifie les 
configurations et limite les erreurs, mais il faut être très rigoureux 
dans le suivi du produit.
Si le produit est opensource (comme ansible), cela signifie passer du 
temps à suivre ses évolutions et bugs.
Si le produit est propriétaire, il faut non seulement suivre le produit, 
mais aussi l'évolution de l'éditeur (santé, rachats, etc.) pour 
s'assurer de la pérennité du produit.


--
*Emmanuel DECAEN*

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jérôme Marteaux]

Le 21/05/2021 à 11:46, Xavier Beaudouin a écrit :

Hello Jérôme,



Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
  - de permettre à plus de gens (il n'y a pas tant que ça d'expert
réseau sur le marché de l'emploi) de mettre en prod des services sur
étagère:
 - donc d'accélérer la livraison du service;
 - de standardiser le déploiement, donc moins d'erreur, moins
d'échec de livraison, plus de satisfaction client;
 - plus d'homogénéité du réseau, une documentation à jour ? Donc
plus aisé de faire du troubleshooting dessus;
 - donc de diminuer le coût du service;
 - donc d'augmenter le nombre de service pour qu'il puisse profiter
à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour
activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à
son travail / à la maison.


Oui et non... C'est "pratique" pour mettre en place un service ou le déployer,
là dessus on est d'accord, mais laisser des gens qui ont peu ou pas d'expertise
a déployer des réseaux de prod, on arrive vite fait à un bordel sans nom,
des choix discutables, et aussi des problèmes de sécurité.
Allez demander au sysadmin quand ils se battent avec des devoups qui déploient
des dockers récupérés je ne sais où, avec des mises à jour de sécurité
inexistantes depuis 5 ans...
  


Effectivement le SDN a 2 cibles, autant tu décris un end-user qui va 
assembler des briques pour construire un service où il faut normalement 
des compétences d'architecte d'infrastructure. Je partage ton point de vue.
Mon argumentaire est vu d'un ISP qui livre des services télécom où le 
SDN est la base de l'usine télécom.


C'est vrai que l'usage que l'on peut en faire est bien différent.



   - le but ultime de ce genre de produit c'est d'arriver à standardiser
des pratiques (que contient le service, son déploiement, sa
configuration, son exploitation ...). Par exemple les emails, jusqu'aux
années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop,
le webmail, les anti-spam, anti-virus, les quarantaines et c'était les
admin sys qui géraient le support des utilisateurs. Grâce à l'essor de
gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec
devant des clickodromes permettant de gérer ces boites mails. Depuis, je
ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui
m'intéresse plus !


Et quand gmail ou azure t'as buté ton serveur, tu es aussi dans la merde,
pareil... vu le nombre de gens qui ne comprennent pas l'infra du mail et
qui pensent que ça doit être immédiat...

Je gère encore mon serveur, il y a des solutions qui le permette sans avoir
a se taper tout... ceci dit, ca apprends les protocoles et comment débugger
les choses quand ça part en couille... (aka expliquer aux devoups ce qu'ils
doivent mettre dans un mail pour pas qu'il soit jeté ).



C'est vrai, j'ai également encore mon serveur perso, mais c'est assez 
rare que gmail/azure perdent le serveur, sinon ils ne géreraient pas 
autant de boites mails.



Est-ce encore nécessaire d'être un expert SMTP pour réussir à envoyer un 
mail ?
Hier où la majorité des protocoles étaient encodés en binaire (pratique 
de faire un recv(fd, _structure, sizeof(ma_structure)) et pour parler 
avec ce protocole il fallait en devenir un expert. Où aujourd'hui 99% 
des protocoles sont du JSON/XML sur de l'HTTP où les lib HTTP/REST/SOAP 
(quel gros mot !) sont suffisamment bien faites pour ne pas avoir à 
connaître comment fonctionne HTTP 1.1.
Lorsque je vois toutes les difficultés qu'a HTTP 2 à émerger, seules les 
grosses boîtes de dév arrivent à faire de l'HTTP 2 car personne n'a 
envie de se replonger dans HTTP (en plus pour quel bénéfice ?).


Toutes ces expertises se perdent car elles ne sont plus nécessaires. 
Avant les années 2005 à chaque installation d'un linux je me recompilais 
le kernel pour l'adapter au hardware, combien de fois il fallait avoir 
le module xxx pour la carte raid, pour le chipset réseau ? Maintenant je 
ne sais même pas à quelle version de linux on en est, ma ubuntu boot sur 
n'importe quel serveur / desktop.
Est-ce que ça serait bien que je garde cette connaissance sur un usage 
qui est devenu obsolète ? Je ne pense pas.



Et pour finir, je ne pense pas que ni les gros acteurs ni les petits
utilisent ce genre d'outil marketé par les équipementiers, il y a
largement la place pour développer des solutions home-made.


+1. Mais attention au SSII^H^H^H^HESN qui aiment bien pousser des solutions
chères et privatrices...



Je trouve que les marketeux sont des génies. Comme Sun & IBM qui 
vendaient des serveurs "optimisés" pour faire tourner du Java qu'ils 
enrichissaient. Les ESN préconisaient Java et recommandaient donc ces 
mêmes serveurs.


Si tu veux du Salesforce il faut intégrer un maximum de chose dessus car 
c'est plus sympa, d'où sa marketplace qui prend tout son intérêt.


AWS vient avec son écosystème (S3, route53, EFS, EKS, ...), ils ont crée 
un marché d'infogéreurs qui 

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Emmanuel DECAEN]

Bonjour,

Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :
Pour argumenter le débat, le SDN a tout a fait sa place dans un 
environnement complexe style Datacenter, et comme j'ai pu le voir plus 
tôt aussi, en séparant le controlplane du dataplane.
Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? 
(ne me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, 
le contrôleur ayant une connaissance globale du réseau, la requête 
peut être répondu localement par le premier saut sans avoir à 
traverser le réseau  !



Sur le principe oui, c'est sympa, mais à moins de changer toute 
l'infrastructure, la suppression de l'ARP peut poser problème si elle se 
fait par étape, en commençant par le coeur.


Cas concret: Infrastructure avec deux switchs clients A et B (L2) 
connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP + 
BGP-EVPN)
Ton client décide de basculer son serveur entre ses deux switchs (A->B) 
=> le serveur devient injoignable.


Dans un réseau uniquement L2, à la première requête ARP, la réponse du 
serveur permet de mettre à jour la table d'adresse MAC sur le chemin de 
switchs (y compris le coeur).
Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera 
filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne 
sera plus joignable.


Il y a plusieurs solutions de contournement : timeout arp, retrait du 
suppress-arp

Si quelqu'un a une meilleure solution, je suis preneur.

Mais en attendant, à diagnostiquer la première fois, c'est un peu coton ;-)


--
*Emmanuel DECAEN*


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

J'attends avec impatience le syndrome de la poule et de l'oeuf.

Quand le déploiement automatisé du "software defined" reposera sur 
lui-même, et qu'il faudra reseter l'ensemble parce que la manager s'est 
fait hacker, ça promet d'être un spectacle amusant...




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benjamin CALLAR]

Hello la liste !

Bravo Cécile pour le débat, quel engouement

Pour moi le SDN, c'est une vraie évolution, mais qui malheureusement a 
été complètement pompée par le marketing et qui en a fait n'importe 
quoi. J'aime le comparer à d'autres tendances - et que j'ai eu 
l'occasion de voir plus tôt dans le thread - que sont le "Cloud" alors 
que c'est juste de la VM (ça doit mieux se vendre les termes anglais XD) 
ou encore le "AI" alors qu'il s'agit juste de statistiques sans aucun 
apprentissage (mais encore une fois, ça se vend vachement bien une 
solution qui fait de "l'intelligence artificielle" (=> un calcul de 
moyenne ? ) !).


Autant je suis 1000% pour l'esprit startup, mais il y a des niches qui 
ont été exploitées à en perdre leur sens .. Le SDN, SD-WAN, AI, Cloud, 
Cybersécurité en font partie...


Et je ne parle pas des écoles qui ont encore plus exploité la chose en 
vendant des formations "Ingénieur Cloud", "Ingénieur cybersécurité, 
"Ingénieur AI" ... alors que le programme corresponds à un titre 
d'ingénieur Systèmes et réseaux ou développeur d'il y a quelques années ...
Je ne mets pas tous les oeufs dans le même panier, il y a des écoles qui 
respectent leurs engagements, mais pour la majorité que j'ai eu 
l'occasion de voir ce n'est pas le cas ...


Malheureusement, cela donne une vision erronée du monde du travail aux 
jeunes qui souhaiteraient rejoindre le milieu.


Pour argumenter le débat, le SDN a tout a fait sa place dans un 
environnement complexe style Datacenter, et comme j'ai pu le voir plus 
tôt aussi, en séparant le controlplane du dataplane.
Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? (ne 
me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, le 
contrôleur ayant une connaissance globale du réseau, la requête peut 
être répondu localement par le premier saut sans avoir à traverser le 
réseau  !


Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de 
manière centralisée, et éviter l'auto-apprentissage de celles-ci, et 
pourquoi pas faire du switching intelligent (load balancing, ...) comme 
le permet à peu prêt le PBR que nous connaissons tous, mais au niveau 
2.=> Adieu le spanning-tree


Et il y encore pleins d'autres exemple, les protocoles de NHRP, de LAGP, 
de PBR, peuvent tous être "SDN-isé" pour y ajouter les besoins liés à 
des contextes complexes, et surtout des règles spécifiques à l'entreprise.


Le problème des protocoles que je viens de citer, c'est qu'il faut que 
ça évolue et que ça arrive dans le firmware (qu'il faut mettre à jour), 
avec le SDN, chacun peut y mettre du sien, le contrôleur n'étant qu'un 
"programme" qui peut être mis à jour bien plus souvent qu'un firmware. 
(imaginez la puissance d'un contrôleur opensource combiné avec un bon 
ingénieur)


C'est à ça que j'identifie le SDN, une entité qui a la connaissance 
globale du réseau et qui peut intervenir instantanément sur les flux en 
fonction d'évènements, besoins, etc.


J'ai eu la chance il y a quelques années de suivre une formation 
Coursera à ce sujet, qui est justement dans cette définition du SDN : 
https://www.coursera.org/learn/sdn?#about


En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage 
intelligent, ce n'est pas nouveau, et ça ne se vends pas aussi cher ! Et 
quand je vois à quel point les solutions vendues sont fermées, bridée, 
... ça me déprime ...


J'espère avoir apporté ma pierre au débat,

Vous souhaitant une agréable journée

Benjamin CALLAR


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Beaudouin]

Hello Jérôme,


> Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
>  - de permettre à plus de gens (il n'y a pas tant que ça d'expert
> réseau sur le marché de l'emploi) de mettre en prod des services sur
> étagère:
> - donc d'accélérer la livraison du service;
> - de standardiser le déploiement, donc moins d'erreur, moins
> d'échec de livraison, plus de satisfaction client;
> - plus d'homogénéité du réseau, une documentation à jour ? Donc
> plus aisé de faire du troubleshooting dessus;
> - donc de diminuer le coût du service;
> - donc d'augmenter le nombre de service pour qu'il puisse profiter
> à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour
> activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à
> son travail / à la maison.

Oui et non... C'est "pratique" pour mettre en place un service ou le déployer,
là dessus on est d'accord, mais laisser des gens qui ont peu ou pas d'expertise
a déployer des réseaux de prod, on arrive vite fait à un bordel sans nom,
des choix discutables, et aussi des problèmes de sécurité.
Allez demander au sysadmin quand ils se battent avec des devoups qui déploient
des dockers récupérés je ne sais où, avec des mises à jour de sécurité 
inexistantes depuis 5 ans...
 
>   - en tant qu'expert réseau je préfère travailler sur des sujets
> autrement plus intéressants que de déployer des services basique sans
> intérêt technique et à travailler à la chaîne au déploiement des
> services qui sont toujours les mêmes;

Déployer des services basic peut être automatisés *sans* passer par
un SDN/SD-WAN proprio.

>   - le but ultime de ce genre de produit c'est d'arriver à standardiser
> des pratiques (que contient le service, son déploiement, sa
> configuration, son exploitation ...). Par exemple les emails, jusqu'aux
> années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop,
> le webmail, les anti-spam, anti-virus, les quarantaines et c'était les
> admin sys qui géraient le support des utilisateurs. Grâce à l'essor de
> gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec
> devant des clickodromes permettant de gérer ces boites mails. Depuis, je
> ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui
> m'intéresse plus !

Et quand gmail ou azure t'as buté ton serveur, tu es aussi dans la merde,
pareil... vu le nombre de gens qui ne comprennent pas l'infra du mail et
qui pensent que ça doit être immédiat...

Je gère encore mon serveur, il y a des solutions qui le permette sans avoir
a se taper tout... ceci dit, ca apprends les protocoles et comment débugger
les choses quand ça part en couille... (aka expliquer aux devoups ce qu'ils
doivent mettre dans un mail pour pas qu'il soit jeté ).

> Et pour finir, je ne pense pas que ni les gros acteurs ni les petits
> utilisent ce genre d'outil marketé par les équipementiers, il y a
> largement la place pour développer des solutions home-made.

+1. Mais attention au SSII^H^H^H^HESN qui aiment bien pousser des solutions
chères et privatrices...

> Le véritable sujet derrière tout ça c'est la scalabilité que ces outils
> permettent de gagner. A la base on est un artisan qui façonnons nos
> réseaux, nos outils (bientôt le dernier "dino" des télécom au JT de TF1
> ? :) ). Mais pour passer à la vitesse supérieure, il nous faut une usine
> avec des robots que des humains moins expert peuvent piloter et contrôler.

*SURTOUT* contrôler... mais ça me fait penser aux générateurs de codes
qui ne sont plus trop à la mode... 

/Xavier


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jérôme Marteaux]

Le 21/05/2021 à 10:59, Xavier Beaudouin a écrit :

Hello

Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
"mouais".

En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
fait quand même un peu marrer vu la jeunesse du produit.

En gros le seul et unique problème de ces machins, c'est que ça fait ce qui est 
prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu tu veux 
du Cisco tu prends le produit truc et si tu veux du juniper tu prends le 
produit truc.

D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
(syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a été 
prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une autre 
chose.

Après le jour où le machin se fracasse ou que la license est venue a 
expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
appelle un dino pour réparer le merdier.

Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor locked.
Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui nous 
les brisent.

Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
pas rentrer dans les cases SD-WAN...

Xavier


Je ne suis pas tout à fait d'accord. Ce genre de produit permet:
 - de permettre à plus de gens (il n'y a pas tant que ça d'expert 
réseau sur le marché de l'emploi) de mettre en prod des services sur 
étagère:

- donc d'accélérer la livraison du service;
- de standardiser le déploiement, donc moins d'erreur, moins 
d'échec de livraison, plus de satisfaction client;
- plus d'homogénéité du réseau, une documentation à jour ? Donc 
plus aisé de faire du troubleshooting dessus;

- donc de diminuer le coût du service;
- donc d'augmenter le nombre de service pour qu'il puisse profiter 
à plus de gens. S'il fallait qu'un ingé télécom travaille 2 heures pour 
activer une FTTO/FTTH il n'y aurai pas grand monde qui aurait la fibre à 
son travail / à la maison.


  - en tant qu'expert réseau je préfère travailler sur des sujets 
autrement plus intéressants que de déployer des services basique sans 
intérêt technique et à travailler à la chaîne au déploiement des 
services qui sont toujours les mêmes;


  - le but ultime de ce genre de produit c'est d'arriver à standardiser 
des pratiques (que contient le service, son déploiement, sa 
configuration, son exploitation ...). Par exemple les emails, jusqu'aux 
années 2010 il fallait gérer son serveur mail avec le smtp, l'imap/pop, 
le webmail, les anti-spam, anti-virus, les quarantaines et c'était les 
admin sys qui géraient le support des utilisateurs. Grâce à l'essor de 
gmail, azure, 95% des boîtes mails sont maintenant dans le cloud avec 
devant des clickodromes permettant de gérer ces boites mails. Depuis, je 
ne gère plus cette partie ! Je peux me concentrer sur de l'admin sys qui 
m'intéresse plus !


Et pour finir, je ne pense pas que ni les gros acteurs ni les petits 
utilisent ce genre d'outil marketé par les équipementiers, il y a 
largement la place pour développer des solutions home-made.


Le véritable sujet derrière tout ça c'est la scalabilité que ces outils 
permettent de gagner. A la base on est un artisan qui façonnons nos 
réseaux, nos outils (bientôt le dernier "dino" des télécom au JT de TF1 
? :) ). Mais pour passer à la vitesse supérieure, il nous faut une usine 
avec des robots que des humains moins expert peuvent piloter et contrôler.



Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Marc Abel]

Bonjour,

En un mot c'est pas pour moi (mais ça peut aider certains d'entre vous) 
(j'ai pas dit comme IPv6).


Pardonnez ma méfiance envers la centralisation du control-plane mais 
j'ai déjà subi des déboires à cause de technos censées fiabiliser le 
réseau...
Certains d'entre vous ont-ils eu des serveurs injoignables parce que le 
HA foirait ? ou avec HSRP/VRRP/load ballancer/ etc. quelle que soit la 
cause.


C'est vrai que le plus souvent les pannes viennent d'erreurs humaines 
(on travaille et ça se voit ;-) mais on peut aussi faire des dégâts sur 
du SDN.
J'imagine que si le SDN tient la route (si j'ose dire) il va éviter les 
incohérences/boucles/duplicate mais sera-t-il exempt de toute faille/bug ?


Le cerveau du SDxxx n'est-il pas un SPOF ? il va falloir le redonder et 
assurer le HA (et penser à payer le support/la licence à temps).


N'ayant pas de budget/ de temps libre / de besoin de ce genre je reste 
sur KISS (pas forcément stupide mais simple et lisible).


Il faut prendre ce qui marche simplement et fait avancer le truc de 
façon maîtrisée, exemple stacker plutôt que cascader les switches, ou 
mieux avec les VSS et autres virtual chassis on simplifie 
l'administration et on diminue le nombre de cerveaux mais on réfléchi un 
peu aux intercos quand même...


Car le software ne peut donner que ce qui existe au niveau hard, ok pour 
mixer une fibre FTTH avec un lien Sdsl dans un petit site distant 
(SD-WAN ?), par contre pas ok pour croire qu'un lien qui bagotte ou qui 
est sous-dimensionné fonctionnera mieux (juste je ne le verrai pas).


Coté utilisateurs j'ai aussi une réticence à proposer 
"any-to-any-as-you-want", l'interco L2 n'est pas une option généralisée 
(si besoin réel on monte un VPLS), à priori tout ce qui sort de 
l'étage/bâtiment est routé. Je veux dire que c'est pas parce que ça 
existe, ou que ça peut fonctionner qu'on doit le faire et le généraliser.


Côté serveurs on en gère un bon millier mais les fonctions sont 
regroupées pour limiter les licences par cœur (Oracle et consort) tout 
mettre à plat serait inutilement coûteux.


Je suis trop petit, jusqu'à preuve du contraire SDN c'est pas pour moi, 
parlez-moi plutôt de micro-switches pour FTTO (Cisco s'y met après 
NeXans et Microsens) ça a du sens d'arrêter le câblage cuivre des 
bâtiments de bureau 


Marc ABEL




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nang Bat]

Attention malheureux ! En 5g aussi faut tout racheter, le HLR (HSS en
LTE...) change encore de nom et devient UDM (+AUSF...) et c'est du
REST (avec des def openapi du genre
https://github.com/jdegre/5GC_APIs/blob/master/TS29503_Nudm_MT.yaml)
et la je te raconte pas le merdier quand tes users font 2/3/4/5G c'est
que du bonheur.

Le ven. 21 mai 2021 à 11:17, David Ponzone  a écrit :
>
> > Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> >
> > Après le jour où le machin se fracasse ou que la license est venue a 
> > expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> > appelle un dino pour réparer le merdier.
>
> Oserais-je une comparaison (pas fonctionnelle) avec le HLR d’un réseau mobile 
> ? :)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

> Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.

Oserais-je une comparaison (pas fonctionnelle) avec le HLR d’un réseau mobile ? 
:)


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le jeudi 20 mai 2021 à 12:54 +0200, Cécile MORANGE a écrit :
> Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
> dit que ce serait sympa d'écrire un article sur mon blog 
> (blog.ataxya.net) à propos de ça. Vu que sur internet je trouve
> beaucoup 
> plus de présentations commerciales que d'avis réels sur la solution,
> je 
> me suis dit que j'allais demander à mon groupe d'expert préféré ce
> qu'il 
> pense de cette techno. Mes questions sont donc : - Pourquoi passer au
> SDN ? - Il y a-t-il un réel intérêt de passer au SDN ? (Hormis
> l'aspect 
> commercial) - En avez-vous déjà mis en place ? Comment ça s'est passé
> ? 
> Avez-vous remarqué un réel changement dans la façon de faire vos
> réseaux 
> ? (et du gain de temps ?) - Pensez vous que dans 5,10,20 ans, tous
> les 
> réseaux seront du SDN ? Je suis à l'écoute de tous vos retours, ça me
> permettra de mieux comprendre le SDN et l'intérêt (s'il y en a un) !
> (Je sens que je vais lancer un long thread plein de débats :D)
> Merci d'avance !
> 
> Cordialement,
> 
Personnellement, l'intérêt que je vois,  c'est de pouvoir faire de
l'encapsulation (réseau overlay),
au dessus d'un autre réseau.

Quand tu commence à avoir un gros réseau, avec beaucoup d'hyperviseurs,
et plusieurs datacenters,  faire du layer2 partout (pour pouvoir migrer
les machines virtuelles entre les noeuds/baies/dc),
ca devient vite la merde.
du coup, layer3 bgp partout dans ton réseau underlay,  et au dessus tu
ajoute un réseau "sdn" qui s'occupe de gérer le réseau "virtuel" de tes
vms.  

normalement, dans un sdn, le controlplane (qui a la vu les mac/ips de
tes vms) est séparé du dataplane (les bridge/vswitchs de tes
hyperviseurs).  Le but du controller, c'est de pousser les mac dans la
fdb des bridges/vswitchs  VS un appretissage classique layer2 avec des
BUM.

certains sdn on des controllers centralisés (beurk), openflow, tout cas
 , d'autres décentralisés (openstack dragonflow, bgp-evpn ;).

Ensuite au dessus de ca, y'a pleins de briques de NFV (network virtual
function), en fonction de sdn, généralement ce sont des services qui
viennent se plugger dedans (firewall, loadblaancer,...). Généralement
ce sont des vms, et le sdn se démerde pour router les flux dans les
différents briques.


Perso, j'aime bien les standard et l'interopérabilité, du coup bgp-evpn
pour moi. (et l'intégration dans proxmox est dispo ;)


Alexandre








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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pascal Romano via frnog]

On ne peut être plus clair !


> On 21 May 2021, at 10:59, Xavier Beaudouin  wrote:
> 
> Hello
> 
> Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
> "mouais".
> 
> En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
> les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
> fait quand même un peu marrer vu la jeunesse du produit.
> 
> En gros le seul et unique problème de ces machins, c'est que ça fait ce qui 
> est prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu 
> tu veux du Cisco tu prends le produit truc et si tu veux du juniper tu prends 
> le produit truc.
> 
> D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
> décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
> (syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
> les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a 
> été prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une 
> autre chose.
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.
> 
> Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor 
> locked.
> Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui 
> nous les brisent.
> 
> Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
> où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
> pas rentrer dans les cases SD-WAN...
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Xavier Beaudouin]

Hello

Et pour avoir lu ce fil, je suis plutôt entre "c'est un nouveau truc" et 
"mouais".

En résumé, il y a des gens qui cherchent des personnes ayant 5 ans d'expé sur 
les techno cisco sdn (je ne sais plus quel produit et bon ... osef) et ça me 
fait quand même un peu marrer vu la jeunesse du produit.

En gros le seul et unique problème de ces machins, c'est que ça fait ce qui est 
prévu pour une marque X ou Y... Évidement l'interop n'est pas là. Si tu tu veux 
du Cisco tu prends le produit truc et si tu veux du juniper tu prends le 
produit truc.

D'après l'expérience que j'ai avec des gens qui l'utilise c'est que le soft a 
décidé un certain nombre de choses qui simplifie bcp l'admin du reseau 
(syndrôme du pousse bouton sans savoir ce qui se passe en dessous, chose que 
les dino comme moi n'aime pas), mais... quand ça sort des rails de ce qui a été 
prévu par le cahier de charges des dev du soft de SD-WAN, là c'est une autre 
chose.

Après le jour où le machin se fracasse ou que la license est venue a 
expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
appelle un dino pour réparer le merdier.

Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor locked.
Et on est bon nombre a râler vis a vis de leur pratiques commerciales qui nous 
les brisent.

Pour l'instant je suis dans le wait and see... mais en tous cas dans la boite 
où je bosse, le réseau est suffisamment en dehors de clous habituels pour ne 
pas rentrer dans les cases SD-WAN...

Xavier


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[aderumier]

Le vendredi 21 mai 2021 à 09:16 +0200, Nicolas Vuillermet a écrit :
> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la 
> possibilité de haute dispo) du controlplane.
> 
> Comme l'ont dit certains, la base est Openflow, qui ira faire 
> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight, 
> Onos, OpenSack Neutron :troll:).

Personnelement, bgp-evpn c'est du sdn pour moi, et le control plane est
décentralisé (et pas d'openflow)




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Vincent Habchi]

> On 21 May 2021, at 09:54, Gregory CAUCHIE  wrote:
> 
> Je ne pense pas avoir compris ton point.

Argh, les anglicismes :p

V.


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Erratum, "un nouveau paradigme d’exploitation" et non "un nouveau paradigme 
d’innovation", sorry

> Le 21 mai 2021 à 09:54, Gregory CAUCHIE  a écrit :
> 
> Salut Michel,
> 
>> Le 21 mai 2021 à 07:09, Michel Py  a 
>> écrit :
>> 
>> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
>> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
>> entre "ras-le-bol" et "plein-les-c..."
>> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
>> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. 
>> Et dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.
> 
> Je ne pense pas avoir compris ton point.
> 
> 
>> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du 
>> coté netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que 
>> des technologies qui existaient bien avant que le marketing n'invente le 
>> nouveau buzzword à la mode, bref c'est un ramassis de conneries
> 
> Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
> années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
> sur le fait que ça n’existe pas. 
> Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
> l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
> pousse-paquet des familles.
> Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je 
> ne compte plus le nombre de réseaux d’ETI en routage statique. C’est juste 
> une histoire classique de complexité à opérer, d’impact ou non sur le 
> business et de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
> bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
> raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
> d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
> VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
> (beau challenge), soit prendre le produit packagé sous label SD-WAN. 
> 
> Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
> définition. À partir de quel moment une solution est-elle innovante ? quel 
> seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur 
> l’industrie et pourtant la base du protocole n’est que mélange des 
> caractéristiques de datagramme IP et de circuit ATM/Frame Relay/ Le VLAN 
> a permis d’énormément rationaliser la taille des infra sans pour autant 
> changer la technique de commutation. Les VPN, GRE et autres VxLAN sont tous 
> des techniques de tunnelisation/overlay comme un VLAN au dessus d’une infra 
> mutualisée. Arpanet s’est monté en overlay des réseaux de l’époque, donc pas 
> nouveau et pourtant chaque VPN a eu son propre impact (site distant, 
> extension de LAN entre DC, …) . 
> Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
> (pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à 
> voir où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
> datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
> d’innovation ». 
> 
> —
> Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Gregory CAUCHIE]

Salut Michel,

> Le 21 mai 2021 à 07:09, Michel Py  a 
> écrit :
> 
> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
> entre "ras-le-bol" et "plein-les-c..."
> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. Et 
> dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.

Je ne pense pas avoir compris ton point.


> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du coté 
> netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que des 
> technologies qui existaient bien avant que le marketing n'invente le nouveau 
> buzzword à la mode, bref c'est un ramassis de conneries

Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
sur le fait que ça n’existe pas. 
Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
pousse-paquet des familles.
Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je ne 
compte plus le nombre de réseaux d’ETI en routage statique. C’est juste une 
histoire classique de complexité à opérer, d’impact ou non sur le business et 
de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
(beau challenge), soit prendre le produit packagé sous label SD-WAN. 

Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
définition. À partir de quel moment une solution est-elle innovante ? quel 
seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur l’industrie 
et pourtant la base du protocole n’est que mélange des caractéristiques de 
datagramme IP et de circuit ATM/Frame Relay/ Le VLAN a permis d’énormément 
rationaliser la taille des infra sans pour autant changer la technique de 
commutation. Les VPN, GRE et autres VxLAN sont tous des techniques de 
tunnelisation/overlay comme un VLAN au dessus d’une infra mutualisée. Arpanet 
s’est monté en overlay des réseaux de l’époque, donc pas nouveau et pourtant 
chaque VPN a eu son propre impact (site distant, extension de LAN entre DC, …) 
. 
Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
(pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à voir 
où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
d’innovation ». 

—
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nang Bat]

Pour les ROADM, oui après faut avoir le besoin et puis en plus les
dernières génération de ROADM sont "flexgrid" pour prendre des
channels de largeurs variable. Après de ce que j'ai vu en prod c'est
pour du très gros CSP, peut-être des telco je sais pas.
Sinon les histoire d'API northbound, depuis qu'on a telnet j'ai vu des
gens faire du expect avec du perl ça compte :D
La ou j'admet qu'on peut percevoir un changement dans les équipements
c'est le moment ou tu peux taper la RIB en direct avec des truc genre
openconfig/gribi la on peut commencer à avoir des soft qui font des
trucs sympa. En presque off-topic c'est le genre de logique qu'on
retrouve sur au moins une constellation de satellite pour le
broadband: synthétiser les RIB (avec des LFA etc.) de tout les
satellites au sol (vu que tu connais la topologie du reseau en avance)
et les dispatcher au fil du temps, ca permet de supprimer complètement
la décision locale, ce qui est impossible tant qu'il reste un bout
d'igp/bgp qui tourne sur les équipements.

Le ven. 21 mai 2021 à 09:25, Remi Desgrange
 a écrit :
>
> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)
>
> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
>
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
>
> > SDN, bullshit pour ceux qui ont pas pigé l'idée ?
> >
> > En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
> > possibilité de haute dispo) du controlplane.
> >
> > Comme l'ont dit certains, la base est Openflow, qui ira faire
> > l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
> > Onos, OpenSack Neutron :troll:).
> >
> > Dans le fond, ça va faire plusieurs choses.
> >
> > Déjà pousser les confs (on en a fait que niveau L2) vers une
> > hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
> > Northbound.
> >
> > L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
> > personne n'a rien compris quand la prof en a parlé, et maintenant la
> > moitié de la promo confond routage et commutation.
> > Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
> > dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
> > table ARP, que les switchs du réseau SDN aillent demander au contrôleur
> > où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
> > rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
> > décision. Les paquets suivants respecteront par la suite la décision du
> > contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
> >
> > Pour ce point je trouve un sacré avantage : pour une infra DC, tu
> > automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
> > niveau MAC, c'est sympa je trouve.
> > On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
> > SDN...
> >
> > Bref :) C'est cool, mais pas tout le temps en a la nécessité.
> >
> > 'dredi morning
> >
> > Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
> > >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
> > >>
> > >>
> > >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
> > >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
> > >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> > > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
> > Cloud » et le slogan sera « les spécialistes de l’hébergement ».
> > >
> > > Bon, je sors … … …
> > >
> > > V.
> > >
> > >
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> --
> Cordialement, Rémi Desgrange
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[David Ponzone]

Chouette, une bataille d’acronyme.
Et je crois que j’en ai un qui a été oublié……le vCPE!
Et le uCPE aussi.

Un bel article de 2019 bien bullshit avec des prospectives faites en 2015:
https://blogdigital.beijaflore.com/vcpe-virtualisation-reseaux/ 


> Le 21 mai 2021 à 09:22, Remi Desgrange  a 
> écrit :
> 
> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)
> 
> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
> 
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
> 


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Benoit Chesneau]

On Fri, May 21, 2021 at 09:22, Remi Desgrange  
wrote:

> Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
> géré par un cloud provider") j'attends le "SDN At The Edge" :-)

cela s’appelle azure stack hci…

> Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
> vrais ?
>
> On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
> wrote:
>
>> SDN, bullshit pour ceux qui ont pas pigé l'idée ?
>>
>> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
>> possibilité de haute dispo) du controlplane.
>>
>> Comme l'ont dit certains, la base est Openflow, qui ira faire
>> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
>> Onos, OpenSack Neutron :troll:).
>>
>> Dans le fond, ça va faire plusieurs choses.
>>
>> Déjà pousser les confs (on en a fait que niveau L2) vers une
>> hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
>> Northbound.
>>
>> L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
>> personne n'a rien compris quand la prof en a parlé, et maintenant la
>> moitié de la promo confond routage et commutation.
>> Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
>> dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
>> table ARP, que les switchs du réseau SDN aillent demander au contrôleur
>> où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
>> rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
>> décision. Les paquets suivants respecteront par la suite la décision du
>> contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
>>
>> Pour ce point je trouve un sacré avantage : pour une infra DC, tu
>> automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
>> niveau MAC, c'est sympa je trouve.
>> On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
>> SDN...
>>
>> Bref :) C'est cool, mais pas tout le temps en a la nécessité.
>>
>> 'dredi morning
>>
>> Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
>> >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
>> >>
>> >>
>> >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
>> >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
>> >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
>> > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
>> Cloud » et le slogan sera « les spécialistes de l’hébergement ».
>> >
>> > Bon, je sors … … …
>> >
>> > V.
>> >
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
> --
> Cordialement, Rémi Desgrange
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Remi Desgrange]

Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, mais
géré par un cloud provider") j'attends le "SDN At The Edge" :-)

Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise ça en
vrais ?

On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 
wrote:

> SDN, bullshit pour ceux qui ont pas pigé l'idée ?
>
> En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la
> possibilité de haute dispo) du controlplane.
>
> Comme l'ont dit certains, la base est Openflow, qui ira faire
> l'interface entre un contrôleur (des noms sont sortis, OpenDayLight,
> Onos, OpenSack Neutron :troll:).
>
> Dans le fond, ça va faire plusieurs choses.
>
> Déjà pousser les confs (on en a fait que niveau L2) vers une
> hétéréogénéité d'équipements, bien suivant le contrôleur expose une API
> Northbound.
>
> L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui,
> personne n'a rien compris quand la prof en a parlé, et maintenant la
> moitié de la promo confond routage et commutation.
> Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des
> dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la
> table ARP, que les switchs du réseau SDN aillent demander au contrôleur
> où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui
> rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et
> décision. Les paquets suivants respecteront par la suite la décision du
> contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).
>
> Pour ce point je trouve un sacré avantage : pour une infra DC, tu
> automatises l'emplacement des @MAC sur les switchs, du coup tu filtres
> niveau MAC, c'est sympa je trouve.
> On a vu des choses amusantes du genre couplage 802.1x avec contrôleur
> SDN...
>
> Bref :) C'est cool, mais pas tout le temps en a la nécessité.
>
> 'dredi morning
>
> Le 20/05/2021 à 20:31, Vincent Habchi a écrit :
> >> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
> >>
> >>
> >> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
> >>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?
> >> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> > Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés «
> Cloud » et le slogan sera « les spécialistes de l’hébergement ».
> >
> > Bon, je sors … … …
> >
> > V.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement, Rémi Desgrange

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Nicolas Vuillermet]

SDN, bullshit pour ceux qui ont pas pigé l'idée ?

En cours, ce qu'on voit, c'est vraiment la centralisation (modulo la 
possibilité de haute dispo) du controlplane.


Comme l'ont dit certains, la base est Openflow, qui ira faire 
l'interface entre un contrôleur (des noms sont sortis, OpenDayLight, 
Onos, OpenSack Neutron :troll:).


Dans le fond, ça va faire plusieurs choses.

Déjà pousser les confs (on en a fait que niveau L2) vers une 
hétéréogénéité d'équipements, bien suivant le contrôleur expose une API 
Northbound.


L'autre point qu'on a vu en cours, c'est le routage L2. Oui oui oui oui, 
personne n'a rien compris quand la prof en a parlé, et maintenant la 
moitié de la promo confond routage et commutation.
Mais bon, l'idée sous-jacente est la possibilité de ne plus avoir des 
dumb-switch au niveau ARP, mais qu'à chaque nécessité de remplir la 
table ARP, que les switchs du réseau SDN aillent demander au contrôleur 
où se trouvent l'adresse. Dans certains cas, c'est tout le paquet qui 
rentre dans le réseau SDN qui est envoyé au contrôleur pour analyse et 
décision. Les paquets suivants respecteront par la suite la décision du 
contrôleur (c'est du ARP managé en gros ? c'est ce que j'ai retenu).


Pour ce point je trouve un sacré avantage : pour une infra DC, tu 
automatises l'emplacement des @MAC sur les switchs, du coup tu filtres 
niveau MAC, c'est sympa je trouve.
On a vu des choses amusantes du genre couplage 802.1x avec contrôleur 
SDN...


Bref :) C'est cool, mais pas tout le temps en a la nécessité.

'dredi morning

Le 20/05/2021 à 20:31, Vincent Habchi a écrit :

On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:


Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :

Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ?

J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)

Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés « Cloud » 
et le slogan sera « les spécialistes de l’hébergement ».

Bon, je sors … … …

V.


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



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Jean-Francois Billaud via frnog]

On 21/05/2021 07:09, Michel Py via frnog wrote:

> Question pour Cécile : quand on est une nana, comment on dit "plein les 
> couilles" ?

Les autres aussi peuvent répondre ?

GONADE, subst. fém.
BIOL. Glande génitale qui produit les gamètes et sécrète des hormones 
sexuelles. Gonade femelle (synon. ovaire), gonade mâle (synon. testicule).

Donc gonadoclaste = qui casse les gonades

et gonadoclastophobe = qui n'aime pas les gonadoclastes.


JFB (inclusif gonadoclastophobe ampélidophile xyloglotte)


PS https://www.cledut.net/xylo.htm

-- 
   __  _
   .-.'  `; `-._  __  _
  (_, .-:'  `; `-._
,'o"((_,   )
   (__,-'  ,'o"()>
  (   (__,-')
   `-'._.--._( )
  |||  |||`-'._.--._.-'
 |||  |||
(Bob Allison)


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