hello
je suis entrain de reprendre toute la sécurité de notre réseau (note de l'ANSSI, instruction DGOS)
 
Je reprends donc depuis le début dans ce qu'il est faisable.
J'en suis à la page sur le Vlan Natif
 
bref, j'aimerais comprendre le fonctionnement de ce vlan. Si vous avez le temps de m'expliquer ou de m'orienter vers une doc en francais.  
Par contre une doc qui parle du protocole normé et pas à la sauce Cisco. C'est épuisant de devoir comprendre un protocole si en plus 80% de la doc parle du spécif Cisco avec des lignes de commande Cisco.
 
Même l'ANSSI ne fait pas d'effort la dessus.
 
Cas concret :
aujourd'hui le Vlan Natif est le vlan default (vlan 1). Oui je sais. Si je reprends tout c'est parce qu'il y a un historique réseau qui remonte à 1993 et pas d'admin réseau jusqu'à moi.
Le vlan default va mourir progressivement mais j'ai encore du matos dessus. Mon management est sur Vlan 2.
 
Il faut que je crée un vlan 3 qui servira de vlan natif à tous mes switch ? ensuite je propage ce vlan sur tous mes ports trunks puis je change switch par switch la notion de vlan natif ?
Sur le parc j'ai du Procurve, du Comware et du batard (H3C de base en interface web), tout le monde va s'entendre ou c'est pas si standard que ça ?
 
Je peux le faire à chaud ?
 
Enfin vous avez compris le concept. Je pars d'un réseau à plat sans VLAN et sans ACL et mon boulot est de se rapprocher des best practices d'aujourd'hui tout en faisant les modfis en prod (24h/24h)

c'est pour faire passer quel type de trafic ton vlan natif ? tu demandes comment faire mais tu ne dis pas pourquoi tu veux le faire.

si je lis bien ta réponse, tu ne dois pas savoir plus que moi à quoi sert le vlan natif.  (édit : sans être méchant hein )
 
Selon la doc de l'ANSSI :  
le VLAN natif est utilisé par les commutateurs pour s’échanger des informations nécessaires
au fonctionnement de certains services qu’ils offrent dont STP, CDP et VTP. Ce VLAN a pour
particularité de circuler non marqué (au sens 802.1Q) sur les liens trunk. Ainsi, toute trame
Ethernet entrante non marquée sur un port trunk du commutateur sera automatiquement
associée par celui-ci au VLAN natif.

ben laisse ça sur le vlan 1, quel est le problème ?

selon les best practices que je trouve ce vlan natif doit être tagged et uniquement sur les ports trunk des switch.
sinon tous les équipements sur ce vlan vont recevoir les trames STP. Et un équipement mal configuré qui reçoit ce genre de trame pourrait la transmettre sur un autre vlan.
 
c'est pour ça que je cherche plus d'info ou ce que font les autres.  
Parfois l'ANSSI envoi des guide méthodo un peu trop costaud et trop high level pour notre dimensionnement  
 
Un exemple :
Il faudrait mettre tous les ports sensés non utilisés sur un VLAN de quarantaine
Je te sors même la recommandation tellement je comprends pas où ils veulent en venir
 
Tous les ports qui sont censés être inutilisés doivent être associés au VLAN de
quarantaine. Les ports placés dans ce VLAN ne doivent donner accès à aucune ressource
du système d’information et doivent interdire les communications avec toute autre
machine, y compris les machines placées dans ce VLAN. Ces ports doivent aussi être
désactivés, de même que le VLAN de quarantaine et l’interface associée.

 
Dans ce cas précis, le problème c'est l'équipement mal configuré. Et il faut qu'il soit sacrément mal configuré pour arriver à un tel résultat, déjà parce que les trames stp ne sont pas retransmises.
Ca ne pose pas de problème que tous les équipements reçoivent les trames STP, la question est de savoir ce qu'ils en font. Et sur les ports faisant face à des serveurs ou des postes, il y a un certain nombre de sécurités que tu peux mettre en place (par exemple root-protection) pour éviter les ennuis si une machine venait à se comporter de manière anormale.
 

 
c'est effectivement une bonne pratique, mais ce n'est pas spécialement lié à la notion de vlan natif (ça concerne aussi les ports non taggés).

Hello,
 
Le but d'utiliser des VLAN est d'isoler les domaines de broadcast dans ton réseau. Donc, un prefix IP = un domaine de broadcast.
 
Ensuite, pour répondre à ta question de VLAN natif. Il est nécessaire de le configurer sur les ports d'un Switch sur lequel, la machine connectée, (PC ou autre) ne précise pas le VLAN sur lequel elle alors que ce port lui même à plusieurs VLAN.
 
Ex sur Cisco :
(VLAN 1 data; VLAN 2 voice, VLAN 3 MGMT)
 
Int Gix/x
Desc PC secrétaire  
Switchport mode trunk
Switchport trunk allowed Vlan 1,2,3
Switchport trunk native vlan 1
 
Ensuite pour la propagation de ton VLAN, le trunking est nécessaire sur les ports qui connectent les différents switch entre eux dans ce même domaine. Pas de notion IP, seulement "layer2"
Au niveau IP, il te faudra un routeur ou un FW pour servir de passerelle à tous ces VLAN.
 
Pour ta migration, il faut créer ton VLAN sur tous les switch. Le nom n'a pas d'importance mais son identifiant : OUI.
Ensuite tu dois l'ajouter sur tous les ports Trunk entre les switch pour que ce traffic layer 2 fonctionne bien.
Ensuite, il faut simplement qu'il y a une Gateway(passerelle) router ou FW sur lequel tous ces VLAN se connectent.

merci Charon_ mais je parle du Vlan natif. On a déjà quelques vlan sur le réseau. Ici l'ANSSI parle du vlan natif. C'est sur ce vlan que communique les switch pour le spanning-tree entre autres.
Comme nous avons déjà eu le pb d'un switch mal configuré (pas à nous) et connecté sur le vlan default, je m’intéresse à ces best practice pour l'avenir.

Hello Fourbe2,
 
En fait pour ce VLAN, si le souhait est d’éviter sa propagation, il faut simplement tagger les liens trunk avec les VLAN autorises. Je préfère présenter ici, la façon Cisco (J'ai plus l'habitude..).
 
Int gix/x
switchport mode trunk
switchport trunk allowed vlan (add) 2,3,4,5,10-20,etc...
 
Ensuite, pour éviter son utilisation, il suffit de créer sur les switch, une interface virtuelle du VLAN 1 (Switch Virtual Interface : SVI)
 
Interface Vlan1
shutdown
 
 Pour les suite, a partir du moment ou les ports du switch sont configures correctement avec marquage des VLAN; le VLAN 1 ne peut pas se propager a travers différents ports.

Et c'est là qu'intervient la déformation Cisco Charon.

Il y a 2 concepts ANSSI :

Vlan par défaut : Que l'on peut affecter aux ports sur lequel on branche un équipement qui ne marque pas ces trames. chez Cisco du coup ils appellent ça le native VLAN

Vlan Natif : Est un Vlan plus "System" qui ne servirait qu'à véhiculer les protocoles réseaux inter switchs (CDP par exemple)

Je n'ai cependant JAMAIS vue d'implémentation d'un VLAN Natif, les protocoles STP,CDP et autre étant véhiculé sur le VLAN par défaut. Je suis également très formaté CISCO donc ...

Par contre, si je peux te donner un conseil, si vraiment ton Réseau est vieillissant et peu sécurisé, je pense que bien d'autres actions pourraient être menées. Celle-ci étant à mon humble avis plutôt orientées COORPORATE avec une armée mexicaine dans l'équipe réseau. Je n'ai même pas vue ça dans des entreprise de plus de 30K personnes.

Travaillant dans la fonction publique, nous risquons de devoir répondre de notre configuration par un audit.
Pour le moment, nous sommes bien mieux loti que bon nombre de structure mais comme toujours avec les hautes instances, quand ca va tomber il faudra tout faire en 3mois.

C'est tout à fait le genre de cas particulier. Malheureusement je ne peux pas t'en dire plus ne l'ayant jamais implémenté  

La sécurisation des switches Cisco est assez bien expliquée sur le blog d'Orange Business:
http://www.orange-business.com/fr/ [...] al_Bonnard
Il ne s'agit pas de théorie, mais au contraire d'une pratique très concrète.
Les risques sont assez bien exposés, afin que les gens comprennent les failles.
Je pense que certains posts te feront sourire (rire, qui sait ?).
 
Lire un résumé de la  question ici :
http://www.orange-business.com/fr/ [...] tches-1010
 
Commencer par cconfigurer "switchport protected" sur  toutes les interfaces de PC, et d' imprimantes.
Ne pas le faire sur les interfaces trunk ou routeurs.
On peut faire cela sans interrompre le service.
 
A propos de sécurité, je te conseilles de NE PAS UTILISER "spanning tree", car un jour ou l'autre, tu aura une tempête de broadcast.
Lire à ce sujet http://www.orange-business.com/fr/ [...] s-dun-cafe
Revoir la topologie et utiliser "flex links" comme recommandé ici  
http://www.orange-business.com/fr/ [...] penser-610
 
Bonne chance

 
Mauvais conseil. Le principal argument du blog d'orange c'est que le spanning tree quand il est mal configuré peut poser des problèmes. Ben la solution c'est de bien le configurer, pas de le supprimer. On peut bien le remplacer par n'importe quoi d'autre, si ce n'importe quoi d'autre est mal configuré, ça posera des problèmes aussi.  
Spanning tree a l'intérêt de bloquer les boucles réseau, ce que ne fait pas le storm control (qui rend juste le port défectueux au lieu de le couper, ce qui est bien plus difficile à diagnostiquer qu'un port bloqué).

Je confirme, le spanning-tree c'est pas toujours fun, mais c'est quand même une fausse bonne idée de pouvoir le désactiver.

J'ai écris qu'il est préférable de ne pas utiliser le spanning tree.
c'est une très mauvaise idée que de le laisser tourner quand il n'est pas nécessaire.
Ce protocole n'est pas sécurisé, c'est une cible d'attaque facile.
Ce protocole peut générer des pannes catastrophiques.
 
J'ai toujours vu des soucis avec des réseaux qui utilisaient spanning tree.
Un jour ou l'autre, il y a une tempête de broadcast, quoi qu'on fasse.
Même avec un spanning tree configuré soigneusement,
même avec des procédures d'exploitation bien documentées et bien encadrées.
 
C'est une situation catastrophique, qui entraine une interruption de service notable.
Il est alors long et pénible de redémarrer le réseau et les services.
Il faut resynchroniser les serveurs ce qui entraîne la plupart du temps des pertes de données.
 
Voir à ce sujet la panne historique (il y a 15 ans, quand même) :
http://www.orange-business.com/fr/ [...] -utilisera
Mais là, c'était très mal configuré.
Il y a d'autres cas où spanning tree ne fait pas le travail, par exemple si jamais il y a un lien unidirectionnel.
Spanning tree ne marche plus bien sur les liens saturés durablement.
Il y a aussi des tempêtes dont on ne sait même pas ce qui les a provoqué.
Il est très facile de saturer la puissance de calcul d'un switch, auquel cas spanning tree ne marche plus.
Une simple défaillance logicielle ou marérielle peut provoquer cela.
 
J'ai déjà vu un réseau se scrratcher en pleine nuit : la synchronisation des serveurs avait saturé un des liens.
Spanning tree  avait créé une boucle, parce que les BPDU ne passaient plus sur ce lien.
Les équipes IT ont passé deux jour pour remettre les bases de données d'équerre.  
Les conséquences sur l'activité ont été très importantes.
 
En conclusion, pour assurer une disponibilité professionnelle, je fais en sorte de ne jamais utiliser spanning tree.
Personne n'est obligé de créer des réseaux avec des boucles.  
Pour ma part, j'obtient une excellente redondance en utilisant "flex links",  
qui de plus réagit beaucoup plus rapidement que spanning tree.
 

Hello,
 
Je pense que ton idée est très bonne et qu'elle vaut la peine d'être creusée.
En revanche, je ne suis pas réellement d'accord sur le fait que STP soit dangereux..
Je l'utilise dans Mon entreprise, et je peux assurée qu'il y en a beaucoup du traffic ici...
J'évolue sur des réseaux "Datacenter" 3-tier, spine and leaf, spanning-tree est toujours là et ne pose aucun problème.
Ton expérience est la tienne, la mienne m'appartient aussi.
Quoi qu'il en soit, spanning tree a fait ses preuves et n'est pas parfait malgré tout. Il a subi beaucoup d'évolutions. Quoi qu'il en soit, il est et sera encore utilisé pendant un bon moment.
Encore une fois, tes idées sont bonnes et elles valent la peine de s'y intéresser, Mais dans tous les cas, éviter spanning-tree, je le déconseille.

 
Salut Charon
 
petit hs mais je rebondis sur ton post, quels parcours pour se former/préparer à un environnement réseau en datacenter ?
J'ai de bonnes connaissances en réseaux cisco (Configuration coeur de réseau/switch, ACL, VLAN, BGP etc..)  dans des environnements de taille moyenne (plusieurs sites distants, un gros site avec beaucoup de vlan et route).
Je me doute qu'un environnement en datacenter doit être bien différent même si les bases sont les mêmes.
 
Est-il possible de se former en autodidacte ? Quelles sont les technologies utilisés ? quoi approfondir ?
 
Tu peux me répondre en mp si tu veux pour éviter de polluer le topic, quoi que c'est toujours intéressant pour tout le monde.
 
merci de ton retour  

Pardon, mais je ne vois strictement aucun rapport entre Spanning tree et Flex links ... Mais alors strictement AUCUN.
 
Ca fais des années que plus personne n'utilise le spanning tree pour les uplinks des switchs. Hors mis si tu as une contrainte au niveau de l'environnement, si tu place 2 switchs évolués face à face tu vas utiliser LACP. Si plus de deux switchs tu vas utiliser du Flex links ou du BGP (en le bricolant un peu) si ton switch ne supporte pas flex links. Et sur les ports "PC" du switch ?  
 
Et puis Flex Links, si je ne dis pas de bêtise, c'est du pur Cisco non ? Là l'op a de multiples constructeur. Et puis en fait je sais même pas pourquoi on parle de spanning tree.

Merci ChaTTon2
C'est bien compliqué de coller aux Best Practice quand on n'a pas du Cisco et c'est encore pire quand c'est multi-constructeur est avec un historique réseau aussi vieux que soi.

Hello schmosy,  
 
MP ;-)

Hello Chatton2,
 
Je m'excuse mais je ne suis pas vraiment sûr de bien te suivre.
Le spanning-tree à ta connaissance n'est plus utilisé sur les réseaux. À ma connaissance, il l'est encore beaucoup et à toujours son intérêt et cela même dans des réseaux larges, donc jusqu'à environ 4090 VLAN utilisables par switch avec "extended Id".
Comme je l'ai dit précédemment, il y a des alternatives à STP Mais dans la plupart des cas STP est utilisé et ça fonctionne très bien.
Dans cette histoire, LACP n'a rien à voir et BGP encore moins car on parle de switching ici.
 
Bref si je peux me permettre Fourbe2, pour sécuriser ou appliquer des best practice, il n'y a pas de méthode particulière. Chaques cas est différent. Pour les VLAN, le numéro 1, 1002-1005 sont des VLAN par défaut et ne peuvent pas être supprimé. On peut simplement les mettre hors service si cela est nécessaire.

===================================================
Flex-lonks, c'est biien du CISCO, tu as raison.  
Mais ce n'est pas un protocole, juste un comportement local du switch : quand l'interface active passe hors service, le switch bascule sur l'interface alternative. C'est donc très rapide.
Cette fonctionnalité existe chez d'autres constructeurs.
 
On peut faire marcher une topologie "spine and leaf" avec du Flex-links ou son équivalent, avec l'avantage que le temps de réaction est bien meilleur (inférieur à la seconde, disons 600ms), bien meilleur que Spanning-Tree.
 
On peut par exemple déménager (changement de salle) sans interruption de trafic au niveau 2.

dans tous les cas du leaf-spine ça n'utilise pas STP pour la redondance, c'est soit trill, spb ou autre techno proprio équivalente (fabricpath), soit MCLAG, soit fabric N3 (donc BGP, OSPF ou IS-IS en général).

Il faut bien lire la phrase en entier : "Ca fais des années que plus personne n'utilise le spanning tree pour les uplinks des switchs." Car je cite la mise en concurence de flex link et spanning tree. Qui pour moi (même si dans le passé on utilisait spanning tree pour faire des uplinks vers d'autres switchs) n'est plus pertinente.

Le spanning tree sur les ports utilisateurs pour se prémunir de boucles locales .... Ca oui ca a toujours un intérêt, et oui aussi ca peut être source à ennuis quand le spanning tree part en vrille. Risque à calculer.

Et le switching, aujourd'hui les switch font du BGP, du RIP. LACP est même présent sur des switch layer 2. C'est donc tout à fais à propos (enfin pas dans la question originelle )

Hello Chatton,
 
Effectivement vu sous cet angle, je comprends mieux :-)
Je pense que le topic a doucement dérivé, mais au moins le débat est très intéressant!
 
merci encore

De mon point de vue, ces pratiques ont un gros inconvénient :
Elles consomment de la ressource processeur, il faut donc prévoir des machines suffisamment puissantes.
Elles sont plus coûteuses (CAPEX +)
La factture d'énergie s'en ressent (OPEX +)
 
Que se passe-t-il en cas de pénurie de ressource processeur ?  
Le temps de réaction est-il compatible avec les exigences des services ?

 
les switchs qui supportent ces protocoles ont évidemment des CPUs assez puissants pour les faire tourner. Le temps de réaction est sous la seconde et la dépense en énergie, sauf si tu as des chiffres précis qui montrent le contraire je pense que c'est complètement négligeable vis a vis de la consommation générale du switch (et du datacenter d'une façon plus générale).
Enfin bon on parle de solutions déjà massivement utilisées là, on peut discuter des avantages et inconvénients de chacune mais parler de surconsommation d'énergie ou de pénurie de ressource processeur c'est un peu anachronique à mon avis.

 
Tout bon.  
 
Après une autre solution pour éviter les boucles, est de stacker les switchs...

bonjour Fourbe2
Tu ne serais pas en train de travailler sur cela ?
 
http://circulaire.legifrance.gouv. [...] =1&r=41533
phase 18mois
3 Mesures de priorité 3 à mettre en place
dans les 18 mois
Gestion des réseaux [RES]
− Cloisonnement du réseau de la structure par grandes familles d’usage
(administration, paie, plateau technique…) et par niveaux de sécurité homogènes
 
Il te reste beaucoup de chose à faire ?
Pour ma part, j'ai deja un cloisonement, mais ce n'est pas parfait.
Sans temps donné par ma direction, je ne peux le faire.

exact, j'ai commencé mais trop d'autres trucs à voir au quotidien pour m'y remettre.
Comme toi, il me faudrait des mois à ne faire que ça pour être dans les clous