RE: [FRnOG] [TECH] Conseil switches
Pour les utiliser en cœur ( même petit ... ) , les Juniper EX2200 sont pas trop adapté pour pas mal de raison ( stack max de 4 , pas de ports 10g, licence routage avancé) ... Il faut au minimum prendre des EX3300 ( VC-stack de 10 et 4 ports 10g ) mais licences L3 à ajouter si besoin -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Mathieu Poussin Envoyé : lundi 5 janvier 2015 10:12 À : Simon Morvan; Liste FRnoG Objet : RE: [FRnOG] [TECH] Conseil switches Hello, Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Chez Juniper tu a les EX2200 qui semblent correspondre à ce que tu cherches. Chez HP, tu as les (plus tant) nouvelles gammes suite au rachat de H3C, regarde du côté des 5120 (Et honnêtement le nouvel OS Comware est bien plus puissant que l'OS Procurve, c'est comparable à un IOS) Pour avoir utilisé les deux, Juniper est plus intéressant, mais la CLI est complètement différente de Cisco/HP (mais bien plus puissante/flexible) A+ -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Simon Morvan Envoyé : dimanche 4 janvier 2015 15:19 À : Liste FRnoG Objet : [FRnOG] [TECH] Conseil switches Hello à tous, Je vais devoir remplacer une paire de switchs HP 2510G-24 qui composent un coeur de tout petit réseau. Les deux switchs sont reliés par 2x1G et pour la redondance les machines sont raccordées sur le pair ou l'impair en fonction de leur propre parité. Un cluster de deux firewalls à une patte s'occupe de gérer le routage et les ACLs entre les VLANs portés par ces deux switchs. C'est du HP, ça devait finir par arriver, l'un deux à des comportements suspects : trois ports shutdown simultanément, sans raison (un 1er janvier, oui). Bon, c'est en prod depuis ~5-6 ans, c'est peut être logique aussi ? Je commence à regarder par quoi remplacer ces équipements. Je pensais passer sur du cisco, genre de simple 2960 qui feront fort bien l'affaire, mais est-ce vraiment un gage de meilleure durabilité ? Qu'est-ce qu'on peut trouver d'aussi bien dans le même genres chez les autres références (Brocade ? Juniper ?). Pour l'architecture en elle-même, un point me tente (et me chiffonne aussi) : passer sur du stacking, au lieu du double lien ethernet entre les deux switchs. Évidemment, c'est plus agréable et peut etre un poil plus performant (pour mon usage), mais est-ce que la stack ne va pas devenir rapidement un SPOF en elle même ? Si quelqu'un à une suggestion, ou a déjà défriché cette question, je serais fort intéressé ! Merci d'avance et bonne année à tous. -- Simon --- 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] Conseil switches
Hello, Le 05/01/15 10:11, Mathieu Poussin a écrit : Hello, Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Je pense qu'il parle du cas où un stack bug ou part en vrille et je trouve la question légitime, j'ai déjà vu des stacks partir en vrille et crasher l'ensemble de ses éléments par le passé et là ta redondance elle fait un peu une sale tête. Pour de l'agrégation je trouve que c'est bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne trouve pas que ce soit une bonne idée même si avec du Juniper tu as une meilleure gestion de la capacité réseau (mais aussi du coup un mode dégradé quand l'un tombe) Chez Juniper tu a les EX2200 qui semblent correspondre à ce que tu cherches. Chez HP, tu as les (plus tant) nouvelles gammes suite au rachat de H3C, regarde du côté des 5120 (Et honnêtement le nouvel OS Comware est bien plus puissant que l'OS Procurve, c'est comparable à un IOS) Pour avoir utilisé les deux, Juniper est plus intéressant, mais la CLI est complètement différente de Cisco/HP (mais bien plus puissante/flexible) De mon côté je trouve l'idée de prendre des bons vieux Cisco 2960G plutôt bonne. C'est un bon produit plus très cher, robuste et éprouvé (sans licences ajoutées) depuis des années et qui ne souffre pour moi que d'un réel défaut : être mono-alimenté. Avec du budget sinon monter sur une génération plus moderne et double alimentée. Après à la question est-ce que ça sera plus robuste qu'avant ?, je dirais que ça a des chances, mais que 5 ans sans panne c'est quand même pas mal aussi non ? Cordialement, Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Mon HP-2620 est stackable aussi jusqu’à 16 membres sur une seule virtual IP, mais pas avec un câble propriétaire. Dispo en 24/48 ports 10/100, avec 2 ports 1G et deux ports SFP. Le 5 janvier 2015 11:27, Guillaume Tournat guilla...@ironie.org a écrit : Le 05/01/2015 11:10, Simon Morvan a écrit : On 05/01/2015 10:38, Frederic Dhieux wrote: Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Je pense qu'il parle du cas où un stack bug ou part en vrille et je trouve la question légitime, j'ai déjà vu des stacks partir en vrille et crasher l'ensemble de ses éléments par le passé et là ta redondance elle fait un peu une sale tête. Pour de l'agrégation je trouve que c'est bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne trouve pas que ce soit une bonne idée même si avec du Juniper tu as une meilleure gestion de la capacité réseau (mais aussi du coup un mode dégradé quand l'un tombe) Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Les HP2920 sont stackables. Ils existent en 24 et 48 ports giga. dont 4 ports combo, et 2 modules optionnels 10G. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Chenaud maxime spyk...@gmail.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Conseil switches
On 05/01/2015 11:47, Simon Morvan wrote: On 05/01/2015 11:45, Christophe wrote: Remplacer HP par Cisco, c'est changer la marque de la backdoor... Oui, bon d'accord, une masterkey SSH. Mais bon, faut qu'ils puisse s'y connecter, au switch, non ? Et puis... passe en MISC, c'est plus le meme sujet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
On 05/01/2015 11:45, Christophe wrote: Remplacer HP par Cisco, c'est changer la marque de la backdoor... Oui, bon d'accord, une masterkey SSH. Mais bon, faut qu'ils puisse s'y connecter, au switch, non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Stages DUT RT Normandie
Bonjour, Les DUT Réseaux Télécoms de lIUT de Rouen sont actuellement à la recherche dun stage professionnel de fin détudes : 3 mois, du lundi 30 mars au vendredi 19 juin 2015. Je me place à votre disposition pour discuter de possibles missions ou déléments pragmatiques. Heureuse année à tous, Grégory Chaudemanche. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] EU: Arrêt (temporaire?) des ventes de licence Observium
C'est open source. T'es pas content tu forkes. Tiens tu n'aimes pas Adam, bah tu vas sur https://github.com/librenms/librenms. En tant qu'utilisateur et hackeur d'Observium je vais me permettre de donner mon avis. Le code est simpliste, naïf même un peu. Le bon coté c'est que c'est relativement facile à hacker, le point négatif c'est qu'il y a très peu de factorisation, d'optimisation. Le point qui même gêne le plus c'est la non séparation du rendu de la logique, voir des appels en base. Il y a juste milieu entre utiliser une usine à gaz mvc style Zend, et ne pas séparer du tout (au moins utiliser un moteur de rendu, style smarty ou Twig). C'est un choix de design a priori. Admettons. Le point le plus problématique reste que le développeur principal est relativement hostile à tout patch externe, et tout modification qui ne l’intéresse pas. Forkons on va me réponde. Bah non justement on peu plus, grâce au changement de licence. A part à repartir sur librenms qui a 2 ans de retard... Now on vas rire, est-ce que cacti est bien codé ? Est-ce nagios est bien codé ? Connaissant bien cacti, je vais aussi donner mon avis. Le code de cacti est pour le coup beaucoup plus complexe, beaucoup plus dur à hacker. Mais comparons ce qui est comparable. Cacti fait des choses beaucoup plus poussé et optimisé qu'Observium, et surtout beaucoup plus générique. Ce ne sont pas deux softs qui font la même chose. Ceci étant dit : Observium reste un bon soft, auquel j'ai souscrit, et qui permet la mise en place rapide d'un dashboard réseau. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] EU: Arrêt (temporaire?) des ventes de licence Observium
Bonjour bonjour, Bonne année ! J'voudrais pas ajouter de l'huile sur le feu mais pourquoi vous êtes encore sur des outils du passé ? Sensu dans tout ça ? Bonne journée /Troll Le 5 janvier 2015 12:02, Raphael Mazelier r...@futomaki.net a écrit : C'est open source. T'es pas content tu forkes. Tiens tu n'aimes pas Adam, bah tu vas sur https://github.com/librenms/librenms. En tant qu'utilisateur et hackeur d'Observium je vais me permettre de donner mon avis. Le code est simpliste, naïf même un peu. Le bon coté c'est que c'est relativement facile à hacker, le point négatif c'est qu'il y a très peu de factorisation, d'optimisation. Le point qui même gêne le plus c'est la non séparation du rendu de la logique, voir des appels en base. Il y a juste milieu entre utiliser une usine à gaz mvc style Zend, et ne pas séparer du tout (au moins utiliser un moteur de rendu, style smarty ou Twig). C'est un choix de design a priori. Admettons. Le point le plus problématique reste que le développeur principal est relativement hostile à tout patch externe, et tout modification qui ne l’intéresse pas. Forkons on va me réponde. Bah non justement on peu plus, grâce au changement de licence. A part à repartir sur librenms qui a 2 ans de retard... Now on vas rire, est-ce que cacti est bien codé ? Est-ce nagios est bien codé ? Connaissant bien cacti, je vais aussi donner mon avis. Le code de cacti est pour le coup beaucoup plus complexe, beaucoup plus dur à hacker. Mais comparons ce qui est comparable. Cacti fait des choses beaucoup plus poussé et optimisé qu'Observium, et surtout beaucoup plus générique. Ce ne sont pas deux softs qui font la même chose. Ceci étant dit : Observium reste un bon soft, auquel j'ai souscrit, et qui permet la mise en place rapide d'un dashboard réseau. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
On 05/01/2015 10:38, Frederic Dhieux wrote: Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Je pense qu'il parle du cas où un stack bug ou part en vrille et je trouve la question légitime, j'ai déjà vu des stacks partir en vrille et crasher l'ensemble de ses éléments par le passé et là ta redondance elle fait un peu une sale tête. Pour de l'agrégation je trouve que c'est bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne trouve pas que ce soit une bonne idée même si avec du Juniper tu as une meilleure gestion de la capacité réseau (mais aussi du coup un mode dégradé quand l'un tombe) Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? -- Simon. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/15 11:10, Simon Morvan a écrit : Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Tu veux faire de la redondance active/backup ou utiliser les 2 lien en actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher sur le stacking. Si c'est de la redondance active/backup, il faut juste gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge entre les 2 interfaces du serveur. Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/15 11:10, Simon Morvan a écrit : Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Tu veux faire de la redondance active/backup ou utiliser les 2 lien en actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher sur le stacking. Si c'est de la redondance active/backup, il faut juste gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge entre les 2 interfaces du serveur. Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
On 05/01/2015 11:14, Frederic Dhieux wrote: Le 05/01/15 11:10, Simon Morvan a écrit : Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Tu veux faire de la redondance active/backup ou utiliser les 2 lien en actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher sur le stacking. Si c'est de la redondance active/backup, il faut juste gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge entre les 2 interfaces du serveur. Frédéric Je pense que si le budget le permet, je préfère maximiser l'usage des liens. C'est pour ça que je pensais aux derniers modèles de la gamme 2960 qui sont stackables, justement. Avec un truc type RPS2300, le problème de la double alimentation est réglé. Le seul souci, c'est que c'est une nouvelle gamme, peut-être pas exempte de bug, surtout sur la partie stacking. Peut-être qu'une paire de 3750 en refurb vaut plus le coup pour stacker, finalement. -- Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
le stacking n'est nécessaire que pour faire de l'etherchannel certains softs de teaming savent gérer de l'actif/actif sur 2 liens en egress en utilisant 2 mac address différentes en envoi pour la même IP source cdlt, Le Lundi 5 janvier 2015 11h15, Frederic Dhieux frede...@syn.fr a écrit : Le 05/01/15 11:10, Simon Morvan a écrit : Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Tu veux faire de la redondance active/backup ou utiliser les 2 lien en actif ? Si ce sont 2 liens en actif, effectivement il faut se pencher sur le stacking. Si c'est de la redondance active/backup, il faut juste gérer ce mode de bonding sur le serveur pour qu'il annonce pas la MAC des 2 côtés en même temps. Pas de spanning tree s'il n'y a pas de bridge entre les 2 interfaces du serveur. Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/2015 11:10, Simon Morvan a écrit : On 05/01/2015 10:38, Frederic Dhieux wrote: Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Je pense qu'il parle du cas où un stack bug ou part en vrille et je trouve la question légitime, j'ai déjà vu des stacks partir en vrille et crasher l'ensemble de ses éléments par le passé et là ta redondance elle fait un peu une sale tête. Pour de l'agrégation je trouve que c'est bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne trouve pas que ce soit une bonne idée même si avec du Juniper tu as une meilleure gestion de la capacité réseau (mais aussi du coup un mode dégradé quand l'un tombe) Disons que le stacking me permettrait aussi à terme de double attacher mes prochains serveurs. Je ne pense pas que je puisse faire ça sur une simple paire de 2960 à part en faisant du spanning-tree jusqu'au serveur, non ? Les HP2920 sont stackables. Ils existent en 24 et 48 ports giga. dont 4 ports combo, et 2 modules optionnels 10G. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/15 11:20, Simon Morvan a écrit : Je pense que si le budget le permet, je préfère maximiser l'usage des liens. C'est pour ça que je pensais aux derniers modèles de la gamme 2960 qui sont stackables, justement. Avec un truc type RPS2300, le problème de la double alimentation est réglé. Le seul souci, c'est que c'est une nouvelle gamme, peut-être pas exempte de bug, surtout sur la partie stacking. Peut-être qu'une paire de 3750 en refurb vaut plus le coup pour stacker, finalement. Je ne sais pas pour les dernier 2960 en stack, des 3750 le feraient a priori bien de leur côté effectivement. Pour les RPS, quand j'avais testé, je constatait que la bascule du power actif au backup entrainait un reload du switch (le switching électrique n'était pas transparent) et vu le temps que ça met à booter, j'étais pas ravi de la solution. C'est différent selon les modèles ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/15 10:38, Frederic Dhieux a écrit : Je pense qu'il parle du cas où un stack bug ou part en vrille et je trouve la question légitime, j'ai déjà vu des stacks partir en vrille et crasher l'ensemble de ses éléments par le passé et là ta redondance elle fait un peu une sale tête. Pour de l'agrégation je trouve que c'est bien, si vraiment ce sont 2 switchs centraux d'une redondance, je ne trouve pas que ce soit une bonne idée même si avec du Juniper tu as une meilleure gestion de la capacité réseau (mais aussi du coup un mode dégradé quand l'un tombe) J'ai la même expérience que Frédéric. Le stacking (ou virtual chassis chez Juniper) apporte : - une facilité/simplicité d'administration (une seule configuration pour X switch) - la possibilité de faire du LACP multi-switch (et donc de la redondance + scaling). - la possibilité de faire des configurations spanning tree less. Le point négatif : un SPOF applicatif. Cela arrive rarement mais cela arrive. De mon côté je trouve l'idée de prendre des bons vieux Cisco 2960G plutôt bonne. C'est un bon produit plus très cher, robuste et éprouvé (sans licences ajoutées) depuis des années et qui ne souffre pour moi que d'un réel défaut : être mono-alimenté. Avec du budget sinon monter sur une génération plus moderne et double alimentée. J'ai un bon retour d'expérience avec les 2960G avec flex-stack. (j'ai en depuis 4 ans en production dans taff -1) J'ai aussi un non retour d'expérience avec des EX2200 en virtual chassis aussi (en production depuis 3ans). Niveau obsolescence on sera, je pense, dans les même durées que les anciennes génération de switch. Concernant le double attachement, la question reste : as tu besoin de plus de 1G in/out vers tes serveurs ? - si oui tu es obligé de faire du stacking avec du lacp, - si non tu peux faire des agrégats statiques, ce qui élimine le besoin du stacking. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Bonjour, Remplacer HP par Cisco, c'est changer la marque de la backdoor... http://www.dsfc.net/infrastructure/reseau/switch-ethernet-mcdo-nouilles-chinoises-pour-andouilles-francaises/ Cordialement, Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Conseil switches
Hello, Pour ta question sur le stacking, si tu as bien deux liens redondants, il ne devrait pas y avoir de soucis par rapport à du trunk comme tu fais. Chez Juniper tu a les EX2200 qui semblent correspondre à ce que tu cherches. Chez HP, tu as les (plus tant) nouvelles gammes suite au rachat de H3C, regarde du côté des 5120 (Et honnêtement le nouvel OS Comware est bien plus puissant que l'OS Procurve, c'est comparable à un IOS) Pour avoir utilisé les deux, Juniper est plus intéressant, mais la CLI est complètement différente de Cisco/HP (mais bien plus puissante/flexible) A+ -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Simon Morvan Envoyé : dimanche 4 janvier 2015 15:19 À : Liste FRnoG Objet : [FRnOG] [TECH] Conseil switches Hello à tous, Je vais devoir remplacer une paire de switchs HP 2510G-24 qui composent un coeur de tout petit réseau. Les deux switchs sont reliés par 2x1G et pour la redondance les machines sont raccordées sur le pair ou l'impair en fonction de leur propre parité. Un cluster de deux firewalls à une patte s'occupe de gérer le routage et les ACLs entre les VLANs portés par ces deux switchs. C'est du HP, ça devait finir par arriver, l'un deux à des comportements suspects : trois ports shutdown simultanément, sans raison (un 1er janvier, oui). Bon, c'est en prod depuis ~5-6 ans, c'est peut être logique aussi ? Je commence à regarder par quoi remplacer ces équipements. Je pensais passer sur du cisco, genre de simple 2960 qui feront fort bien l'affaire, mais est-ce vraiment un gage de meilleure durabilité ? Qu'est-ce qu'on peut trouver d'aussi bien dans le même genres chez les autres références (Brocade ? Juniper ?). Pour l'architecture en elle-même, un point me tente (et me chiffonne aussi) : passer sur du stacking, au lieu du double lien ethernet entre les deux switchs. Évidemment, c'est plus agréable et peut etre un poil plus performant (pour mon usage), mais est-ce que la stack ne va pas devenir rapidement un SPOF en elle même ? Si quelqu'un à une suggestion, ou a déjà défriché cette question, je serais fort intéressé ! Merci d'avance et bonne année à tous. -- Simon --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/2015 11:47, Simon Morvan a écrit : Oui, bon d'accord, une masterkey SSH. Mais bon, faut qu'ils puisse s'y connecter, au switch, non ? En général, un switch, c'est branché au réseau ;-) Plus sérieusement, combien de réseau n'ont pas au moins un zombie quelque part ? L'idée d'un réseau protégé est utopique. Cordialement, Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/2015 11:38, Raphael Mazelier a écrit : Le stacking (ou virtual chassis chez Juniper) apporte : - une facilité/simplicité d'administration (une seule configuration pour X switch) - la possibilité de faire du LACP multi-switch (et donc de la redondance + scaling). - la possibilité de faire des configurations spanning tree less. Le point négatif : un SPOF applicatif. Cela arrive rarement mais cela arrive. Bonjour, Pour avoir des dizaines de stack Cisco en prod depuis des années, je confirme les points positifs mis en avant. Je n'imagine pas faire autrement . Quelques infos côté matos : - les 2960S sont limités à quatre éléments par pile mais surtout à 6 Etherchannel par stack ! Autre point, leur coût de maintenance est assez élevé (du fait d'une soudaine augmentation de tarif cette année...) - les 2960X passent à huit éléments par pile et à 24 Etherchannel par stack. Côté matos, vu un switch HS au bout de quelques mois mais ça peut arriver... La version XR propose une double alim et 48 Etherchannel par stack. - les 3750G sont ultra fiables, proposent neuf éléments par pile, 48 Etherchannel par stack mais sont en fin de vie commerciale (en théorie) : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eos-eol-notice-c51-731425.html - les 3750X sont leurs remplaçants théoriques sous IOS-XE like. Rien à dire côté matériel mais quelques bugs relevés sur des features access avec un suivi aléatoire côté TAC... - A prix équivalent, autant regarder côté 3850 maintenant je pense car ceux-ci peuvent être acquis si besoin avec quatre SFP+ 10G par switch et proposent 128 Etherchannels par stack : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3850-series-switches/qa_c67-722110.html Ce pointeur compare ces gammes : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-x-series-switches/white_paper_c11-728327.html Les 3750X / 3850 sont bien devant en terme de perf de la stack mais bon... Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Déporter son NOC.
Merci à tous pour vos réponses (publiques et privées). On va avancer la dessus ! Et on n'hésitera pas à faire un retour d'expérience quand on l'aura mis en place... From: technopoli...@hotmail.com To: frnog@frnog.org Date: Fri, 2 Jan 2015 14:33:45 + Subject: [FRnOG] [TECH] Déporter son NOC. Bonjour, On opère un petit NOC pour lequel de véritables opérations 24/7 ne se justifient pas encore. Mais mine de rien, on commence à avoir beaucoup d'appels client ce qui n'est pas agréable pour les gens d'astreinte d'autant que plus de 80% des incidents se résolvent en utilisant la procédure de première intention (en gros le tech cherche dans une DB l'identifiant du service et applique bétement une procédure qui dans 80% des cas résoud le problème si ca ne marche pas il escalade. Y a t'il des entreprises chez qui on pourrait externaliser cette partie ? En gros, le tech qui prendrait les appels (téléphone et /ou email) a besoin : - De prendre les coordonnées du client et un identifiant de service puis de clicker sur un bouton dans une interface web pour lancer une procédure. - De vérifier sérieusement avec le client que son problème est résolu. - De lancer une escalade si le problème n'est pas résolu ou d'envoyer un petit rapport d'incident si résolu. (Le client (ou le monitoring ou les deux) a signalé l'incident à XXhXX sur le service XX, il a été résolu a XXhXX par application de la procédure de première intention). - Optionellement, de savoir se logguer en ssh sur des machines et appliquer une procédure donnée (souhaitée). On lui fournira une clef. (Mais j'hésites avec celle ci pour d'évidentes raisons de sécurité ca nous fait moins de boulot vu que l'interface web n'est pas à créer, il peut y avoir un peu plus de flexibilité, mais un risque). - De comprendre un mail CRITICAL envoyé par Nagios ;) Niveau connaissance, je dirai que je suis preneur de deux options : - Option 1 : Le mec ne panne pas grand chose mais applique betement la procédure et n'en sort pas. A la fin il copie / colle les éventuelles erreurs s'il doit escalader l'incident. - Option 2 : Le mec à un niveau technicien il peut débrousailler un peu (mais je préfères qu'il n'agisse pas). Attention : Pas de trucs crevards ou le mec au phone ne parles pas français, on ne peut vraiment pas se permettre cela. Langues d'intervention : Français et Anglais. Voila, preneur de tout retour d'expérience pour des gens qui ont tenté cela. A la fois sur les presta fiables et/ou à éviter mais aussi sur les méthodologies à mettre en place pour que cela fonctionne bien. A noter que l'on a pas mal d'équipements qui ne sont pas strictement du réseau mais bon dans l'idée c'est identique (on se loggue et on applique une procédure). Merci d'avance et bonne année ! --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Re: [TECH] DNS Free Down ?
Le 04 janv. - 22:17, Stephane Bortzmeyer a écrit : Ces résolveurs ouverts sont une très mauvaise idée, Tout comme ceux de Google je suppose ? Non, cela ne s'applique pas aux rares résolveurs ouverts qui sont gérés, rate-limités, supervisés (ce qui est le cas de Google Public DNS, je peux en témoigner). Une bonne partie des résolveurs cités dans la page à laquelle tu faisais référence suivent les préconisations de rigueur (supervision, rate-limit, etc), préconisations que tu fais toi-meme par ailleurs, par exemple ici : https://groupes.renater.fr/sympa/arc/dns-fr/2014-09/msg0.html tout en désapprouvant la mise en place de ce type de service, ce que je comprends tout à fait. Mon avis, c'est que plutôt que d'avoir le choix entre Google et rien, je préfère avoir le choix entre Google et un service fourni par mon fournisseur d'accès associatif. Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] DNS Free Down ?
Le 03/01/2015 20:41, Stephane Bortzmeyer a écrit : Ces résolveurs ouverts sont une très mauvaise idée, ils servent souvent de réflecteurs pour des attaques DoS Ces récursifs ouverts gérés et supervisés de la moins mauvaise manière sont un compromis entre plusieurs notions dont liberté et sécurité. Ils sont un moindre mal, un point d'équilibre. Je ne reviendrai pas sur les avantages (et limites) de tels récursifs, j'ai déjà présenté mes arguments dans le billet cité par Julien dans ce même thread. Soyons clair : ici, on ne parle *PAS* de récursifs ouverts par méconnaissance/négligence et oubliés. Je pense que j'enfonce des portes ouvertes. Ce qui me dérange dans cet obscurantisme ou, au minimum, cette absence de documentation émanant de ceux (DNS OARC, par exemple) qui savent, de par leur expérience, configurer des récursifs ouverts gérés et supervisés sains, c'est que ça va à l'encontre de l'objectif que ces personnes/organisations souhaitent atteindre : en plus des récursifs ouverts par méconnaissance/négligence, on doit lutter contre les récursifs gérés ouverts par pure volonté mais mal configurés à cause justement de l'absence de documentation how-to. Des personnes ont envie de mettre en place des récursifs ouverts mais ne trouvent pas de documentation complète et potable d'où des récursifs ouverts chaotiques voire dangereux. Cela se voit particulièrement à chaque épisode de censure administrative/judiciaire. On ne peut pas arrêter les personnes déterminées à agir, d'autant plus que la cause est noble, donc pourquoi ne pas proposer une documentation complète qui fait consensus sur « comment configurer un récursif ouvert sain » ? La configuration par défaut des principaux logiciels serveurs DNS sont sécurisées (fermées) depuis longtemps dans les principales familles de systèmes (GNU/Linux, *BSD, ...), de la prévention pour les récursifs ouverts négligemment et de la documentation pour les demandeurs de récursifs ouverts délibérément, ça ne peut pas être pire et ça permet d'agir sur l'ensemble de la typologie des récursifs ouverts. Juste mon avis. comme celle dont vient d'être victime OVH Les tweets m'évoquent un pot-pourri donc si je devais réagir de la sorte, je dirais : interdisons les serveurs DNS qui font autorité sans RRL, les pools NTP gérés et supervisés, le matos Juniper et, pourquoi pas tout serveur web ouvert. :) Dit autrement : en l'absence de statistiques publiques plus détaillées, difficile de se faire un avis sur la partie de l'attaque imputable à des récursifs DNS ouverts, sujet de la présente causerie. Le RFC 5358 dit bien qu'il faut les éviter (mon résumé en http://www.bortzmeyer.org/5358.html) Mais pas les interdire complètement sinon on empêche de faire des choses bien, utiles et avec un risque limité. D'autre part, rien ne garantit l'intégrité des réponses : même si on a confiance dans les gérants du résolveur, le trajet est long, et les paquets UDP pas signés... Récursif local (réseau ou machine) validant qui forward à un récursif mutualisé comme ceux indiqués ci-dessus. Ainsi on a morale/éthique/transparence et intégrité avec un impact minimal sur les serveurs DNS qui font autorité. En attendant qu'un plus grand nombre de zones soient signées, les récursifs présentés ci-dessus ne sont pas pire que ceux des grands FAI commerciaux (niveau morale/éthique/transparence) ou que Google Public DNS/OpenDNS/autre_prestataire (point de vue morale/éthique/transparence fluctuante par le passé et intégrité). Ces récursifs ouverts de confiance (ça dépend de l'observateur, comme d'habitude) sont aussi utiles pour mutualiser un cache quand on parle d'avoir un récursif (fermé) à la maison : http://www.bortzmeyer.org/son-propre-resolveur-dns.html. ;) Et je ne parle même pas de confidentialité https://tools.ietf.org/html/draft-ietf-dprive-problem-statement Certes, les récursifs ouverts gérés et supervisés ne vont pas rendre les poils plus soyeux, résoudre la faim dans le monde ou bien encore enlargir les pénis. :) Une bonne partie des résolveurs cités dans la page à laquelle tu faisais référence suivent les préconisations de rigueur (supervision, rate-limit, etc) En effet : - FDN : rate-limiting des requêtes portant sur le QTYPE ANY et une adresse mail de contact valide. Le reste n'est pas porté à ma connaissance. - ARN/LDN : rate-limiting strict (1 r/s, 2r/s burst) des requêtes portant sur le QTYPE ANY, rate-limiting global 10r/s, 20r/s, limitation de la taille max des réponses fournies sur UDP, adresse mail de contact valide, supervision. - Le reste n'est pas porté à ma connaissance mais une piste est donnée ici : https://lists.ffdn.org/wws/arc/diy-isp/2014-08/msg6.html --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
2015-01-04 15:19 GMT+01:00 Simon Morvan gar...@zone84.net: Je commence à regarder par quoi remplacer ces équipements. Je pensais passer sur du cisco, genre de simple 2960 qui feront fort bien l'affaire, mais est-ce vraiment un gage de meilleure durabilité ? Qu'est-ce qu'on peut trouver d'aussi bien dans le même genres chez les autres références (Brocade ? Juniper ?). Pour l'architecture en elle-même, un point me tente (et me chiffonne aussi) : passer sur du stacking, au lieu du double lien ethernet entre les deux switchs. Évidemment, c'est plus agréable et peut etre un poil plus performant (pour mon usage), mais est-ce que la stack ne va pas devenir rapidement un SPOF en elle même ? Bonjour, J'ai en prod depuis plusieurs années et pour des besoins similaires (coeur de réseau, stack de distribution, etc.) de nombreux stacks HP (gamme anciennement 3Com/H3C) : - Des stacks de 5500 EI dans leur première version stackable (via les liens CX4) composés de 2 à 5 éléments : en 5 ans, j'ai perdu un switch suite à une coupure de courant. - Des stacks de 5800 de 2 éléments. Idem, j'ai perdu un switch en 4 ans. Côté alim, j'ai des modules RPS sur ces modèles. C'est moins pratique que les nouvelles gammes avec les alims intégrées. - Plus récemment des stacks de 5820 de 2 éléments. Les deux alims sont intégrées. RAS pour le moment. Quelque soit la version, ça fait très bien le boulot si on ne demande pas l'impossible. J'ai un peu de mal avec la CLI de cette gamme par rapport aux ProCurve ou autres Cisco-like, mais c'est question d'habitude. Tous les équipements connectés à ces stacks sont au minimum double attachés sur différents éléments, ce qui permet de tenir quelques jours avant de remplacer un switch en cas de problème : je me repose sur la garantie à vie HP (jamais eu de problème avec ça, bonne réactivité). Evidemment, ça n'adresse pas la rare éventualité d'un plantage du stack complet... mais tout est question du risque que tu acceptes de prendre. Pour les stacks de 5820, je me suis récemment posé la question de changer de constructeur (Cisco ou Juniper) mais vu les tarifs de ceux-ci, et le fait que je suis satisfait des modèles HP, je suis reparti pour HP. ++ -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can. --- Liste de diffusion du FRnOG http://www.frnog.org/
