Hello,
 
Je viens d'ajouter un switch giga cuivre 4500G sur mon réseau en coeur de réseau.
 
J'ai donc maintenant deux coeurs de réseau redondants, tous mes autres switch sont reliés en boucle à ces deux switch Giga (le protocole spanning tree est en place).
 
Le lien entre ces deux switch et un lien giga également donc, pour augmenter un peu les performances j'amerais faire un agréga de liens entre ces deux switch de backbone. Seulement j'ai lu de ci de là que Trunking et spanning tree pouvait ne pas faire bon ménage...
 
Pouvez vous m'assurer que ca fonctionne bien si l'aggrège 2 ou 3 ports sur mes deux switch de backbone pour avoir 2 à 3 gb/s ?
 
thx

Je ne connais pas 3com mais cela fonctionne bien sur Foundry et Cisco.
 
Chez cisco, une aggrégation de lien doit se faire par la création d'une interface PortChannel, les paramètres spanning tree devront être appliqués sur cette interface Portchannel et s'appliquera donc à tous les ports de l'aggrégation et ca fonctionne sans soucis.
 
Chez foundry, une aggrégation se configure en configurant le premier port de la grappe, les ports suviants repiqueront la config (de toute facon sur un foundry avec un code récent tu peux pas configurer un interface d'uen aggrégation si ce n'est pas l'interface primaire). La aussi la config s'applique sur tous les ports de l'aggrégation et cela fonctionne.
 
Si tu as les moyens de faire un test en lab avant de mettre en prod vazy :-)
 
Si tu veux le faire en live, privilégie une heure ou il n'y a pas beaucoup de monde sur le réseau
 
Au fait, as tu configuré un de tes deux coeurs de réseau comme root spanning tree et le second comme root secondaire ? Et éventuellement mettre un root protect sur les liens qui vont vers les switches de distribution ?

Merci pour ta réponse
 
Oui j'ai un root primary et le second est en root secondaire. Pas de root protect par contre.  
Mais mes switch de distrib ne sont en fait pas tous connectés aux deux coeurs de réseau:
 
Coeur1=======Coeur2
 |  |                    | |
 |  |                    | |
 |  |                    | |
 |  distri1-----distri2 |
 |                          |
 distri3-----------distri4
 
Liens en "block" est le rouge.

Ah oki je vois.
 
Dans ce cas si tu peux mettre des couts (pathcost) sur tes liens, tu devrais mettre un cost plus faible sur ton aggrégat de lien (et tu fais les calculs qui vont bien derriere) pour t'assurer que ce lien la restera up et que l'interco entre tes switches de distrib reste bien en blocking.  
 
Moi j'aurais fait une connexion dans ce style là
(désolé pour la qualité mais c'est un scan vite fait )

 
j'ai ca qui tourne actuellement dans un lab
 
2 coeur et 3 distrib connectés comme ça
interco giga des distrib vers les coeur et n*1gig entre les 2 coeurs.
avec un pathcost bien plsu faible sur l'interco n*1g pour forcer le lien à etre en forwarding
 
ca marche nickel.

En fait avec ma solution, j'économise qq ports sur mes coeurs de réseau. En cas de pb sur un switch de coeur tout fonctionne mais en mode legèrement dégradé. Ca ne gène pas.
 
Et puis j'ai pas mal de fibre et j'ai déjà fait de la redondance physique de fibre et je n'ai plus assez de brin pour connecter mes switch en double sur chaque switch de coeur.
 
De plus la charge est équilibrée entre mes deux coeur de réseau avec ma solution, pas besoin de trifouiller les path cost pour avoir la moitié des liens sur 1 coeur et l'autre sur l'autre
 
Concernant les path cost c'est tout bon.
 
Il me reste plus qu'a faire un trunk de 2Gb/s voir 4Gb/s...
 

 
 
je ne dis pas de trifouiller les pathcost pour partager la charge sur les 2 coeurs mais au contraire pour tout faire passer sur un seul coeur.
Dans le schéma que je montre c'est pas vraiment la peine car comme le root est directement connecté aux switches de distrib sa pate sera forcément en forward et le fait de mettre les bridge id qui vont bien sur le root et le secondaire vont dans ce sens.
 
Mais c'est quand meme bien se setter un pathcost plus faible sur une liaison qui a un débit plus élevé si le 3com ne le fait pas automatiquement.
 
dans ton exemple le cout du chemin de distrib 2 vers coeur 1 est le meme des 2 cotés. le fait de mettre un pathcost plus faible sur l'interco coeur 1-coeur 2 forcera le chemin vers coeur 2 a etre forwarding et donc le chemin vers distrib 1 en blocking

je bosse souvent dans l'optique d'avoir un coeur en prod et un coeur en spare et d'avoir toujours 200% de la capa nécessaire (du genre j'ai besoin de faire passer 2gig depuis un switch de distrib bah je met 2 gig d'uplink vers coeur 1 et 2 gig vers coeur 2). Comme ca le jour ou ya un coeur qui pete bah t'es sur de pouvoir encaisser toute la charge sur l'autre coeur.
 
En faisant du load balancing c'est sympa de pouvoir équilibrer les liens et la charge mais si de chaque coté au bout d'un moment tu utilises un peu plus de 50% de capa, le jour où un coeur pete, bah le coeur restant ne pourra pas encaisser toute la charge.
 
Avec ton schéma, si ta coeur 1 qui pete bah tout l'uplink de distrib1 va passer sur 2 liens avant d'arriver a coeur 2 donc 2 charges a maitriser alors que dans l'autre schéma il a un lien direct.

de toutes facon tu peux faire tes tesst mais essaie dans une fenetre de maintenance car couper un réseau de prod en pleine journée c'est pas une bonne idée
 
Bon courage

Oui tu as raison ce sont deux optiques un peu différentes.  
Par contre dans mon cas les liens coeurs - distri sont TRES TRES loin de saturer un lien giga.  
 
Concernant la modif, une fois qu'une redondance est en place, il est possible de bouger pas mal de choses sans coupure (et ca permet de tester le bon fonctionnement du STP en même temps)