> Raphael Mazelier a écrit :
> Cisco et les autres poussent leurs propres technologies/protocoles plus dans
> une logique de locking
> des utilisateurs que dans une vraie réflexion de fond sur les besoins du
> réseau de nos jours.
C'est moins pire que dans le passé, je pense. Par exemple, ils o
T'as pas saisi le point, Michel.
Le point c'est :
Si tu utilises un protocole pour propager les définitions de vlans et
associations automagiques sur les trunks ; propriétaire ou pas [VTP, GVRP,
MVRP] ;
alors quand ça va t'exploser entre les mains pour une raison ou une autre, ce
sera triste m
On 09/07/2017 02:54, Guillaume Barrot wrote:
Ouais enfin n'oublions pas que SpanningTree, ISIS ... tout ça c'est DEC.
Le FC, Brocade. Etc.
On a dit la même chose je crois. Mon point était de dire qu'on a souvent
copier des protocoles propriétaires Cisco (ou autres) pour les
normaliser, pl
Le sam. 8 juil. 2017 à 11:54, Raphael Mazelier a écrit :
>
> Dans bien des cas on a normalisé un protocole
> propriétaire cisco quasi à l'identique. Bien ou pas ?
>
Ouais enfin n'oublions pas que SpanningTree, ISIS ... tout ça c'est DEC.
Le FC, Brocade. Etc.
Pas forcément besoin de Cisco pour in
On 08/07/2017 05:42, Michel Py wrote:
Ben justement je suis "enterprise" maintenant et sur le réseau de prod
principal (on en a plusieurs petits ou c'est physiquement séparé pas, dans la même salle,
et toussa) qui est à ce jour 100% Catalyst çà me fait bien chier de devoir mettre encore
une
>> Raphael Mazelier a écrit :
>> VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser
>> cela en prod; cela c'est toujours terminé en désastre par chez moi.
> Frédéric GANDER a écrit :
> +
> c'est une aberration d'activer ca par défaut en dehors du context entreprise
> voir pme
> VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser
> cela
> en prod; cela c'est toujours terminé en désastre par chez moi.
>
+
c'est une aberration d'activer ca par défaut en dehors du context entreprise
voir pme et encore...
sur un catalyst c'est la première chose à déact
Le jeu. 6 juil. 2017 à 22:49, Michel Py
a écrit :
> mais j'ai pas le choix, impossible de changer le réseau de prod.
>
Mets y le feu et touche l'assurance, ca sera plus rentable !
--
Cordialement,
Guillaume BARROT
---
Liste de diffusion du FRnOG
http://www.frnog.org/
> Raphael Mazelier a écrit :
> VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser
> cela en prod; cela c'est toujours terminé en désastre par chez moi.
Jamais eu d'emmerdes à part les débuts de CatOS les bons vieux jours du 5500.
Bon faut être 100% Cisco mais c'est mon cas.
> Non
bonsoir
qq'un aurait un retour d'expérience sur les tests de perf sflow sur ces
N3k?
erik
2017-07-06 21:03 GMT+04:00 Guillaume Barrot :
> Pour ton probleme de vtp : Ansible.
> Pour l'autocommand : Ansible
>
> Pour le 40G sur cartes Intel : XL710 à la place de X710, ça devrait mieux
> marcher.
>
On 06/07/2017 21:23, Michel Py wrote:
C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui
marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon
d'implémenter en NXOS ?
VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser cela
en pr
> Guillaume Barrot a écrit :
> Pour ton probleme de vtp : Ansible.
> Pour l'autocommand : Ansible
C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui
marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon
d'implémenter en NXOS ?
> Pour le 40G sur cartes
Pour ton probleme de vtp : Ansible.
Pour l'autocommand : Ansible
Pour le 40G sur cartes Intel : XL710 à la place de X710, ça devrait mieux
marcher.
Sinon, Mellanox, très bien aussi.
Attention aux optiques en 40G, c'est chatouilleux.
Pour du short range, le twinax, attention aux compatibilités act
13 matches
Mail list logo