Discussion :

[francky23012301]

Bonjour à tous,

Je me permets de vous contacter pour une confirmation de votre part :

Il y a quelques mois, j'ai sollicité un prestataire pour mettre en place un MPLS afin de relier plusieurs sites que nous avons sur un même coeur de réseau.
L'infra est constituée d'un MPLS Sfr avec une passerelle SIP et Data sur laquelle est montée de l'openscape business S de chez Unify.
Dans chaque entité nous avons une fibre dédiée 10 mo et une fibre mutualisée à 100 mo. Elles arrivent toutes les deux sur deux box reliés à des routeurs mikrotik (on rigole pas svp ) relieux tous les deux à un switch data et un switch voix.

Nous avons depuis la mise en place de ce réseau constamment des problèmes : datacenter qui tombe (plus de téléphonie et d'internet), site dont les fibres mutualisée et primaires tombent, des microcoupures un peu partout, des appels qui n'aboutissent pas .... Bref la joie .

Quelques temps après, j'ai constaté que nos routeurs-switchs-machines à affranchir ne pingaient plus. Et cela n'étant pas suffisant, plus aucune interface web de ces appareils n'étaient accessible. Nous avons aussi parfois des pages web qui mettent plusieurs minutes pour s'ouvrir (teams, teamvierwer, CRM etc etc).

Comme notre prestataire ne supervise pas notre réseau (sauf par les routeurs Mikrotik par un autre prestataire), je n'ai pas eu le choix que de pinger nos routeurs à chaque incidents qui a lieu pour au moins vérifier ou se situe le problème. Réponse du prestataire pour tous ces problèmes : je ferais trop ping se qui provoqueraient des collisions ce qui serait à l'origine de tous les incidents que l'on rencontre.

J'ai répondu que normalement FULL DUPLEX pas de collisions possibles, et si HALF DUPLEX (chose que je n'espère pas) CSMA/CD limite la casse.

A votre avis est ce que des pings de quelques minutes sur le réseau à partir d'un seul poste (informations nous avons 10 entités) peuvent créer des collisions suffisantes pour dégrader le réseau et bloquer l'accès aux interfaces web pendant plusieurs semaines ? (je me doute de la réponse mais bon ).

En parallèle ce dernier m'indique qu'il est hors de question que je met en place un outil de supervision (Centreon) car la supervision impacte les réseaux. Etant en train de travailler sur le sujet (je pense que le problème rencontré résulte plus de snmpwal que j'ai lancé sur 2 routeurs et switchs que de pings effectués : votre avis) et étant totalement novice sur le sujet, pouvez-vous me confirmer que le snmp n'impacte pas un réseau quand il est bon configuré ?

Merci pour votre avis

[fredoche]

Bah vu l'archi, je vois pas bien où tu pourrais avoir de collisions, qui depuis l'avènement des switchs, n'ont aucune raison d'être puisque chaque port d'un switch isole son domaine de collision.

Ce qui est désagréable, c'est de sentir à quel point ces gens se foutent de toi en te sortant des arguments aussi bidons. Ca sent l'arnaque à plein nez. M'est avis que vous payez cher des prestations que vous n'avez pas

Bon courage

[francky23012301]

Bonjour Fredoche et merci pour ton retour

[Invité]

Merci pour votre avis

Ce genre de retour clients, ça hérisse le poil
Bon, après, il faut voir ce qui a été vendu et acheté en termes de SLA...
Et s'il n'y a pas de convention de services officielle, formalisée et contractuelle, ce serait bien d'amorcer les choses. Cette situation n'est pas tenable pour n'importe quelle société, d'autant plus dans une infra qui converge voix/data...

la supervision impacte les réseaux

Ça, c'est géant comme argument

pouvez-vous me confirmer que le snmp n'impacte pas un réseau quand il est bon configuré ?

J'ai déjà vu des cas de figure où le traffic de supervision et de collecte de logs peut devenir volumineux...

Mais dans les grosses infras, la recommandation est de déployer du "out-of-band".

Grosso modo, tu déploies des switches pour collecter les interfaces de management des switches, routeurs, interfaces ILO des serveurs, etc. Puis tu fais remonter ces flux par des chemins physiques distincts des flux utilisateurs. Si tu as un problème de prod/perf, les stations d'admin peuvent donc toujours accéder aux IP de management. Et c'est par là que tu transportes tes flux SNMP...

Mais à en juger par la réponse de ton presta, je ne suis même pas sûr qu'il sache ce que c'est qu'un réseau d'admin out-of-band
C'est pourtant un minimum de la part d'un prestataire qui vend des services managés dans une infra hébergée en datacenter...
Ahurissante cette situation...

-VX

[francky23012301]

Bonjour,

Merci pour votre retour vxlan.is.top.

Mon prestataire est assez secret sur ce qu'il a monté, mais le peu d'information que j'ai me font dire que nous avons un MPLS de la sorte.
-2 routeurs physiques locaux avec chacun 2 VLAN voix et data pointant chacun vers un routeur virtuel qui pointe directement vers un routeur PE Cisco.
-Nous avons ainsi 3 routeurs PE dédiés à cela pour 12 entités.

Nous avons deux PABX virtuels liés par un switch (je suppose) qui pointent vers un PE.
Nous avons un routeur PE pour aller sur une passerelle SIP qui semble être notre porte d'entrée/sortie sur internet.

Notre coeur de réseau semble constitué de 3 routeurs PE.

Je précise que pour aller sur internet, nos datas passent par le coeur de réseau.

Quel est votre avis sur cette architecture ?

[Invité]

Mon prestataire est assez secret sur ce qu'il a monté

C'est justement ça le problème. Il faudrait lui demander d'ouvrir un peu le capot

Maintenant, sans rentrer dans le détail, de ce que je comprends, ton prestataire s'appuie sur un réseau MPLS opéré par SFR.

Donc déjà, ce que tu appelles "PE" n'est probablement pas un PE au sens IP MPLS parce que la fonction d'un PE n'est pas de fournir les fonctionnalités d'un coeur de réseau d'entreprise... Dans la terminologie MPLS, un PE se situe au bord du nuage MPLS et est connecté à un "CE" (Customer Equipement). Le PE collecte les préfixes IP du client connecté au travers du CE (chez Cisco, ce sont des address-families ipv4), puis les propage dans le nuage MPLS vers les autres PE de ton infra privé sous forme d'adress-families vpvnv4 (les opérateurs font ça avec des sessions MP-BGP entre les PE).

Ton prestataire n'a certainement pas accès aux PE MPLS de SFR (c'est dans le périmètre de responsabilité de l'opérateur).
Ton prestataire doit avoir accès à partir des CE qui sont en frontal des PE SFR.

A ce titre, toi le client, et ça relève d'une droit juridique, tu es en droit d'exiger la description complète (on appelle ça la cartographie L2/L3) de ce qui est installé à partir du CE jusque dans ton infra, ou au moins le minimum suivant:

- la nature des liens physique et le nom des interfaces connectées depuis le CE vers son PE correspondant,
- les VLAN Id qui collectent tes flux voix/data,
- les adresses IP réelles utilisées et les adresses HSRP/VRRP pour la résilience L3,
- ainsi qu'une description de la façon dont est conçue votre évasion vers l'Internet

ceci pour chacun de tes sites qui sont connectés sur le réseau MPLS.

Encore une fois, tout ce qui se trouve "après" le PE est la partie privée, et doit être explicitement précisée et clarifiée !

D'autre part, quand on déploie ce type d'infrastructure, la moindre des choses pour un prestataire est de fournir a minima un Cahier de Recettes avec des tests fonctionnels de résilience effectués en coordination avec ton service IT, ça ne se fait certainement pas à l'arrache !

Là, il faut taper du poing sur la table...
Encore une fois, en tant que client, vous avez des droits ! Tout ça me semble bien opaque pour une boîte qui fait du Service Managé (je sais de quoi je parle, j'ai managé l'Engineering d'un gros Cloud Privé pendant plusieurs années).

-VX

[francky23012301]

Bonjour à tous,

Petit résumé de notre réunion avec les prestataires :
1)C'est moi (support IT de la société) qui mettrait le bordel en faisant trop de pings (environ 3 pings par semaine d'une durée de 30 sec ).
2)Les pings provoqueraient des rétrécissements dans le réseau qui provoqueraient des collisions .

Bref l'échange a été tendu. En plus de ces mots, :
-Notre prestataire nous refuse la communication des mots de passe du matériel chez nous, la cartographie L2/L3 avant les routeurs PE et nous n'avons pas à savoir comment fonctionne notre réseau.
-L'évasion vers internet passe par le coeur du réseau. Je ne vois pas trop l'intérêt mais bon .....
-Nos deux routeurs locaux Mikrotik iraient directement sur le MPLS ou dedans un routeur virtuel Mikrotik jouerai le rôle de passerelle et assurer le fail-over entre les deux routeurs locaux.
J'ai rien dit mais j'ai fait un bon de 3m dans ma tête (Je vois pas l'intérêt de faire ça alors que du VRRP entre les 2 routeurs locaux m'aurait semblé mieux mais bon ....)
-Pour le cahier de recette, les tests de charges et de pannes : ils ne savent pas si cela a été fait. Le PDG prestataire a vu tout rouge (Il m'a demandé ce que je cherchais .... en sous entendant "la merde").
-Ils ne savent pas ce qu'est un routeur P ou PE, et pour eux, le backbone est en dehors du du MPLS.
-Le matériel chez nous ne nous appartient pas (location) selon notre prestataire : c'est à eux, on a pas le droit d'y toucher ni de le superviser.

Je vous dis pas tout mais l'échange a été un peu chaud patate . De mon côté, je m'en moque : la responsabilité est maintenant du côté de ma direction.
Perso, j'aurais pas cherché et aurais annulé le contrat avec ce presta.

Cependant ma direction a bien compris qu'il y avait quand même un petit soucis et que les pings n'étaient qu'une excuse.

[Invité]

Bon, les "échanges" sont amorcés, c'est déjà ça

Perso, je partirais du contrat officiel qui a été signé par tes boss (parce qu'il doit nécessairement exister)...
Puis je commencerais à lister les manquements...

Bon courage

-VX

[chrtophe]

Vu que tu soit disant "fous le bordel" en effectuant des pings pour essayer d'avancer sur le problème, n'en fais plus, ne fais plus de tests de ce type, et vu que le matériel est sous la responsabilité du presta, demandes-lui de régler le problème. Les salades SFR MPLS, c'est pas ton problème. Prends des copies d'écrans du problème, ceci permettra de démontrer le problème.

C'est un peut-être un peu simpliste mais c’est vers cela qu'il faut à mon avis que tu tendes, vu que c'est hors de tes compétences.

cf la dernière remarque de vxlan.is.top, mais essayes de rester dans une démarche "on essaye d'avancer", histoire d'éviter de se mettre les gens à dos, l'idée étant d'essayer qu'ils collaborent. des fois avec de la bonne volonté, on règle des problèmes qui semblaient insurmontables. Ce n'est pas non plus dans leur intérêt de ne pas régler le problème.
Voir comme déjà évoqué les liens qui t'unissent au prestataire (contrat de maintenance, prestations au coup par coup), demandes-leur conseil sur ce qu'il faut faire pour pallier à la situation, cela permettra d'une part d'avoir peut-être des infos historiques que tu n'as pas, d'avoir leur position officielle et de les mettre face à leur responsabilité si malgré leurs recommandations, les dysfonctionnements perdurent.