Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Hello, Le 3 janvier 2011 21:32, Raphael Mazelier r...@futomaki.net a écrit : Quel est le besoin ? tu as tellement de vlan clients à gérer ? tu ne peux pas segmenter un peu avec diffèrent vswitch / différentes classes de vlan ? D'ailleurs le rajout d'interface à chaud ca fonctionne (au moins sous linux), et cela me semble gérable jusqu'à 4 interfaces par serveurs. Après si tu as plus de quatre vlans par serveurs je penses que tu as un problème d'architecture. (enfin déjà je comprends mal plus de deux). Je virtualise des pare-feux et des load-balancers, et le client, c'est moi :). C'est un choix architectural qui peut plaire ou pas. Je comprends pas le besoin d'être en promiscuous pour faire du HA. Ni le besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas en quoi c'est sale. D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a plus foutu la zone qu'autre chose. Il y a doit y avoir un point que je ne saisis pas la. Déjà répondu par Thomas. C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une @mac virtuelle sous Linux (à moins que ça n'ait changé depuis la dernière fois que j'ai regardé). Le concept d'un couple VIP + VMAC me semble plus propre qu'un flood ARP. C'est au niveau des tables des équipements L2 que le changement se voit et non dans les tables ARP de tous les équipements/serveurs L3 présents sur les mêmes segments. Ca me semble moins sale, mais on peut avoir des visions différentes. Teste la version d'essai 60 jours je suis intéressé par le retour :) C'est au programme ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Hello, Le 3 janvier 2011 23:47, Vincent Duvernet (Nolmë Informatique) vincent.duver...@nolme.com a écrit : (C'est super lourd, cela fait la 3ème fois que je ne fais pas gaffe mais le Répondre sur la liste ne fait pas de Reply sur la liste mais à l'expéditeur :/) Concernant ton problème, peux-tu donner quelques compléments d'infos : - Combien de ports physiques a ton serveur ESX ? (Est ce une pizza avec 2x1000 ou bien 2 cartes PCI 4x1000 ?) - Combien de VM tournent sur chaque serveur ? [...] (En tout cas, ça a comme un air d'usine à gaz ton installation j'adore :)) J'ai déjà traité ces problématiques (comment répartir les liens physiques de l'ESX à travers les vSwitchs, nombre de VMS par ESX, etc), et qui sont, dans la limite de ce que permettent les vSwitch, pas trop mal documentés. J'ai déjà échangé avec le support VMWare, qui à part me citer le Nexus sans savoir me dire à ce moment-là ce que c'est, ne m'a pas été très utile. D'ailleurs, il ne m'avait pas parlé du Dvswitch. Sinon, non, ce n'est pas une usine à gaz, au contraire on esssaye de faire des choses qui restent simple. Pas de SAN, de VMotion, etc. On virtualise pour éviter de gacher des ressources CPU, RAM, I/O, électricité, U dans les baies ... dont l'exploitation par machine est faible la plupart du temps. Mais la virtualisation ne permet pas toujours de faire tout ce qu'on fait en dur. Et je dois reconnaitre qu'un vServer pour administrer le tout, c'est assez appréciable, même si c'est la seule vraie raison pour laquelle j'ai un poste sous Windows au bureau :D (la console d'un serveur dans vSphere Client dans une VM Windows dans un Linux ou un Mac, des fois, ça se combien pas très bien ...) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Le 04/01/2011 10:00, Baptiste Malguy a écrit : Je virtualise des pare-feux et des load-balancers, et le client, c'est moi :). C'est un choix architectural qui peut plaire ou pas. Testé (enfin en prod quand je suis arrivé) et retour arrière :^p. (par exemple des lvs + heartbeat virtualisé sur vmware = échec complet, du notamment au fait qu'en virtualisé tu as une clock matérielle nettement moins fiable). D'une manière générale j'eviterais de virtualiser tout ce qui a besoin d'IO. Bon mais je ne suis pas complétement objectif car je suis contre la virtualisation logicielle en production pour un tas de raisons. Déjà répondu par Thomas. Non thomas a dit qu'il ne comprenais pas non plus. Explique. C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une @mac virtuelle sous Linux (à moins que ça n'ait changé depuis la dernière fois que j'ai regardé). Le concept d'un couple VIP + VMAC me semble plus propre qu'un flood ARP. C'est au niveau des tables des équipements L2 que le changement se voit et non dans les tables ARP de tous les équipements/serveurs L3 présents sur les mêmes segments. Ca me semble moins sale, mais on peut avoir des visions différentes. Je connais pas de solution d'@Mac virtuelle sous linux. Tu fais comment ? après que ce soit plus propre ou pas je ne sais pas. C'est juste choisir la technologie qui va poser le moins de problème, et converger le plus rapidement. En l'occurence effectivement avec une @Mac virtuelle c'est théoriquement plus rapide. En pratique... C'est au programme ;-) Merci. -- Raphael Mazelier
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Déjà répondu par Thomas. Non thomas a dit qu'il ne comprenais pas non plus. Explique. Pardon, quelle question ?? C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une @mac virtuelle sous Linux (à moins que ça n'ait changé depuis la dernière fois que j'ai regardé). Le concept d'un couple VIP + VMAC me semble plus propre qu'un flood ARP. C'est au niveau des tables des équipements L2 que le changement se voit et non dans les tables ARP de tous les équipements/serveurs L3 présents sur les mêmes segments. Ca me semble moins sale, mais on peut avoir des visions différentes. Je connais pas de solution d'@Mac virtuelle sous linux. Tu fais comment ? après que ce soit plus propre ou pas je ne sais pas. C'est juste choisir la technologie qui va poser le moins de problème, et converger le plus rapidement. En l'occurence effectivement avec une @Mac virtuelle c'est théoriquement plus rapide. En pratique... Avec deux machines sur le même switch, si l'IP change de machine et garde la même MAC, la machine de failover doit seulement forcer une mise a jour de la table MAC (relation MAC/Port). L'avantage est de ne pas a avoir a' changer l'association ARP (relation MAC/IP) qui a autrement un timeout autrement plus long. Les valeurs par défaut sont entre 4 et 6 heures (selon les vendeurs) pour ARP et 5 minutes pour MAC. Donc c'est plus propre De plus la table MAC est dynamique donc des que le serveur commence a envoyer des frames avec la MAC de l'IP de service, le switch va se mettre a jour, avec au pire 5 minutes de downtime. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
2011/1/4 Thomas Mangin thomas.man...@exa-networks.co.uk: Avec deux machines sur le même switch, si l'IP change de machine et garde la même MAC, la machine de failover doit seulement forcer une mise a jour de la table MAC (relation MAC/Port). L'avantage est de ne pas a avoir a' changer l'association ARP (relation MAC/IP) qui a autrement un timeout autrement plus long. Les valeurs par défaut sont entre 4 et 6 heures (selon les vendeurs) pour ARP et 5 minutes pour MAC. Donc c'est plus propre De plus la table MAC est dynamique donc des que le serveur commence a envoyer des frames avec la MAC de l'IP de service, le switch va se mettre a jour, avec au pire 5 minutes de downtime. Bonjour, si au moment du failover, tu balances de l'ARP gratuitious, tu devrais pas avoir de downtime :) a+ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
2011/1/4 Bedis 9 bed...@gmail.com: 2011/1/4 Thomas Mangin thomas.man...@exa-networks.co.uk: Avec deux machines sur le même switch, si l'IP change de machine et garde la même MAC, la machine de failover doit seulement forcer une mise a jour de la table MAC (relation MAC/Port). L'avantage est de ne pas a avoir a' changer l'association ARP (relation MAC/IP) qui a autrement un timeout autrement plus long. Les valeurs par défaut sont entre 4 et 6 heures (selon les vendeurs) pour ARP et 5 minutes pour MAC. Donc c'est plus propre De plus la table MAC est dynamique donc des que le serveur commence a envoyer des frames avec la MAC de l'IP de service, le switch va se mettre a jour, avec au pire 5 minutes de downtime. Bonjour, si au moment du failover, tu balances de l'ARP gratuitious, tu devrais pas avoir de downtime :) C'est d'ailleurs ce que fait keepalived. -- Pierre-François HUGUES --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
On 4 Jan 2011, at 13:45, Bedis 9 wrote: 2011/1/4 Thomas Mangin thomas.man...@exa-networks.co.uk: Avec deux machines sur le même switch, si l'IP change de machine et garde la même MAC, la machine de failover doit seulement forcer une mise a jour de la table MAC (relation MAC/Port). L'avantage est de ne pas a avoir a' changer l'association ARP (relation MAC/IP) qui a autrement un timeout autrement plus long. Les valeurs par défaut sont entre 4 et 6 heures (selon les vendeurs) pour ARP et 5 minutes pour MAC. Donc c'est plus propre De plus la table MAC est dynamique donc des que le serveur commence a envoyer des frames avec la MAC de l'IP de service, le switch va se mettre a jour, avec au pire 5 minutes de downtime. si au moment du failover, tu balances de l'ARP gratuitious, tu devrais pas avoir de downtime :) En effet mais le mot est bien si :p Il faut faire attention car si tu ne controle pas le routeur/switch, tu peux avoir des surprises :) Juniper, par exemple, n'accepte pas les gratuitious ARP par défaut [1], c'est une configuration par interface (et pas par VLAN - du moins sur le matériel que je possède). Comme j'ai des clients sur les mêmes interfaces trunkées, pour moi c'est un no-go car sinon mes clients pourraient me faire des attaques de man in the middle. Tout dépend donc de la topologie du réseau. Thomas [1] http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-network-interfaces/topic-25627.html --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Bonjour Baptiste, Tout d'abord bonne Année 2011 à tous . Notre solution VMReady sur nos switchs BLADE Network technologies (now IBM) est concurrentielle au Nexus 100V. Elle devrait répondre à vos attentes. Nous pouvons en discuter en off et vous proposer de tester ce qui vous permettrait en toute clarté de valider ou non la solution en fonction de vos besoins. Cdt, Igor Igor Marty, SE Team Leader, EMEA igor.ma...@fr.ibm.com mailto:igor.ma...@fr.ibm.com | +33 620 739 269 | www.bladenetwork.net http://www.bladenetwork.net From: owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] On Behalf Of Baptiste Malguy Sent: lundi 3 janvier 2011 11:58 To: frnog@frnog.org Subject: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous Bonjour, Bon aller, j'amorce (je crois) la première discussion technique de l'année. La version courte pour les pressés : j'aime bien la virtualisation avec VMWare mais je rencontre quelques limitations côté réseau. le Nexus V1000 semble être une partie de la solution et je suis à la recherche de retours d'expérience. La version un peu plus longue à présent. J'ai deux problèmes à ce jour. 1. J'ai des vSwitch avec le numéro de vlan 4095 (tous les VLANs, taggués, arrivent jusqu'aux guests connecté à ces vSwitchs). En revanche, je ne peux pas restreinte les vlans vus par les guests connectés à ces vSwitch, il n'y a pas d'équivalent à un switchport trunk allowed vlan . Avoir une interface par vlan sur mes guests n'est pas une option envisageable (besoin de rebooter pour ajouter une interface, nombre limité, c'est chiant, etc). Du côté du switch physique auquel est connecté l'ESX, j'ai bien évidemment déjà mis un switchport trunk allowed vlan ..., mais j'ai besoin d'être granulaire par guest. 2. J'ai deux serveurs ESX esx1 et esx2. Sur un esx1 j'ai un guest vm1, sur esx2 un guest vm2. Ils partagent des VIPs, que ça soit par HSRP, VRRP, CARP, ... Ce qui implique une adresse MAC virtuelle (ok, ok, sous Linux, les implémentations VRRP font autrement, plus sale d'ailleurs, selon moi). Ceci m'oblige à autoriser le mode promiscuous pour les interfaces concernés sur ces guests. Ceci a un effet de bord pas du tout désiré : les interfaces de ces guests reçoivent tout le traffic des vSwitchs concernés. Deux fonctionnalités en une, moi ça m'arrange vraiment pas. Par conséquent, j'ai : - un double problème de sécurité ne pouvant pas restreinte les vlans par guest et les serveurs en promiscuous recevant plein de trafic qu'ils ne devraient pas ; - un problème de charge des guests qui reçoivent du trafic qui leur ait inutile qui remonte jusqu'au noyau de l'OS qui doit dropper les paquets dont il n'a que faire. Nexus V1000 semble apporter une réponse à mon premier problème. Je ne sais pas s'il en apporte aussi une à mon second problème. Je suis donc très intéressé par un retour sur le Nexus V1000, et si certains ont trouvé comment résoudre ces problèmes (j'imagine ne pas être le premier à les avoir). PS : je ne suis pas certain d'avoir été très clair, reformulation possible sur demande ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 Confidentiality Notice: This message and any attachments may contain privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message. image001.gif
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Ce n'est pas ma question et je n'ai pas l'intention de jouer avec des blades. Je découvre votre solution et de ce que j'en ai compris, ça n'a rien à voir avec VMWare = à priori sans rapport avec ma question. Youhou, les commerciaux sont chauds bouillants en ce début d'année ! PS : merci pour ton retour Alexis. Le 3 janvier 2011 13:49, Igor Marty igor.ma...@bladenetwork.net a écrit : Notre solution VMReady sur nos switchs BLADE Network technologies (now IBM) est concurrentielle au Nexus 100V. Elle devrait répondre à vos attentes. Nous pouvons en discuter en off et vous proposer de tester ce qui vous permettrait en toute clarté de valider ou non la solution en fonction de vos besoins. -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Le 03/01/2011 11:57, Baptiste Malguy a écrit : Bonjour, Bon aller, j'amorce (je crois) la première discussion technique de l'année. La version courte pour les pressés : j'aime bien la virtualisation avec VMWare mais je rencontre quelques limitations côté réseau. le Nexus V1000 semble être une partie de la solution et je suis à la recherche de retours d'expérience. La version un peu plus longue à présent. J'ai deux problèmes à ce jour. 1. J'ai des vSwitch avec le numéro de vlan 4095 (tous les VLANs, taggués, arrivent jusqu'aux guests connecté à ces vSwitchs). En revanche, je ne peux pas restreinte les vlans vus par les guests connectés à ces vSwitch, il n'y a pas d'équivalent à un switchport trunk allowed vlan . Avoir une interface par vlan sur mes guests n'est pas une option envisageable (besoin de rebooter pour ajouter une interface, nombre limité, c'est chiant, etc). Du côté du switch physique auquel est connecté l'ESX, j'ai bien évidemment déjà mis un switchport trunk allowed vlan ..., mais j'ai besoin d'être granulaire par guest. Quel est le besoin ? tu as tellement de vlan clients à gérer ? tu ne peux pas segmenter un peu avec diffèrent vswitch / différentes classes de vlan ? D'ailleurs le rajout d'interface à chaud ca fonctionne (au moins sous linux), et cela me semble gérable jusqu'à 4 interfaces par serveurs. Après si tu as plus de quatre vlans par serveurs je penses que tu as un problème d'architecture. (enfin déjà je comprends mal plus de deux). 2. J'ai deux serveurs ESX esx1 et esx2. Sur un esx1 j'ai un guest vm1, sur esx2 un guest vm2. Ils partagent des VIPs, que ça soit par HSRP, VRRP, CARP, ... Ce qui implique une adresse MAC virtuelle (ok, ok, sous Linux, les implémentations VRRP font autrement, plus sale d'ailleurs, selon moi). Ceci m'oblige à autoriser le mode promiscuous pour les interfaces concernés sur ces guests. Ceci a un effet de bord pas du tout désiré : les interfaces de ces guests reçoivent tout le traffic des vSwitchs concernés. Deux fonctionnalités en une, moi ça m'arrange vraiment pas. Je comprends pas le besoin d'être en promiscuous pour faire du HA. Ni le besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas en quoi c'est sale. D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a plus foutu la zone qu'autre chose. Il y a doit y avoir un point que je ne saisis pas la. Par conséquent, j'ai : - un double problème de sécurité ne pouvant pas restreinte les vlans par guest et les serveurs en promiscuous recevant plein de trafic qu'ils ne devraient pas ; - un problème de charge des guests qui reçoivent du trafic qui leur ait inutile qui remonte jusqu'au noyau de l'OS qui doit dropper les paquets dont il n'a que faire. Nexus V1000 semble apporter une réponse à mon premier problème. Je ne sais pas s'il en apporte aussi une à mon second problème. Les présentations que j'en ai eu ont effectivement de régler le point numéro un. En gros tu as un vrai switch manageable sur ton esx ce qui peut être un vrai plus. Sinon apparemment tu peux aussi le faire avec le dvswitch (pas testé) = http://www.vi-tips.com/2009/07/vlan-trunking-grouping-in-distributed.html Je suis donc très intéressé par un retour sur le Nexus V1000, et si certains ont trouvé comment résoudre ces problèmes (j'imagine ne pas être le premier à les avoir). Teste la version d'essai 60 jours je suis intéressé par le retour :) PS : je ne suis pas certain d'avoir été très clair, reformulation possible sur demande ;-) -- Baptiste MALGUY - www.malguy.net http://www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 -- Raphaël Mazelier
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
(C'est super lourd, cela fait la 3ème fois que je ne fais pas gaffe mais le Répondre sur la liste ne fait pas de Reply sur la liste mais à l'expéditeur :/) Concernant ton problème, peux-tu donner quelques compléments d'infos : - Combien de ports physiques a ton serveur ESX ? (Est ce une pizza avec 2x1000 ou bien 2 cartes PCI 4x1000 ?) - Combien de VM tournent sur chaque serveur ? Entre ESXi1 et ESXi2, est ce que tu comptes rajouter un équilibrage de charges par la suite ou bien est-ce 2 serveurs totalement distincts ? (Ce qui est dommage puisque tu perds des fonctionnalités de consolidation importantes surtout lorsque le matos est à dispo). D'après tes infos je dirais que tu utilises le mode VGT pour tes VLANs ? Je suppose que tu as déjà appris par coeur le PDF : http://www.vmware.com/pdf/esx3_vlan_wp.pdf Après, on peut toujours voir pour te faire ouvrir un case chez Cisco gratuitement (pas un commercial super excité moi, simplement quelques accès bien pratiques chez Cisco ;p) et ensuite, on peut publier la soluce sur la liste. (En tout cas, ça a comme un air d'usine à gaz ton installation j'adore :)) ++ Vincent -- *Logo* *Vincent DUVERNET* /Directeur Technique / Certifications: Kaspersky Lab, Netgear VMWare VSP/VTSP, Cisco Select SMB *Nolmë Informatique* Lieudit La Fontaine 61170 LALEU FRANCE Tel : (+33)2 33 27 30 96 E-mail :/vincent.duver...@nolme.com/ Web : http://www.nolme.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Je comprends pas le besoin d'être en promiscuous pour faire du HA. Pareil ici .. Ni le besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas en quoi c'est sale. IMHO, ce n'est pas sale dans un environnement contrôlé c'est une solution valable ... HSRP, VRRP, CARP etc. c'est concu pour que l'IP de passerelle puisse changer, de manière transparente. Mais si le client contrôle les machines, accepter les ARP flood/spoof c'est s'ouvrir a des problèmes de sécurité. Gérer des listes d'ACL MAC, c'est du boulot. Quitte a avoir le problème, je pense que c'est bien plus simple de gérer les IP de services avec OSPF/BGP avec des /32 et avoir les services d'IP en loopback, en enlevant le test d'URPF sur le serveur, et d'avoir les ACL au L3 - ou/et sur les filtres d'import BGP, que de debuger des magouilles MAC. D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a plus foutu la zone qu'autre chose. Il y a toujours des kits en vente avec des problèmes de filtrage d' ACL MAC, etc. Les IX qui filtrent les MAC ont des résultats variables. Le problème classique des fonctionnalités pas très utilisées et donc buggées. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
