Messages

traceroute to ssl0.ovh.net (193.70.18.144), 30 hops max, 60 byte packets

Vraiment pas un bon test. D'une part, 193.70.18.144 drop les paquets vers les ports inutilisés (y compris les paquets UDP envoyés par votre traceroute), d'autre part la plupart des routeurs d'OVH ne répondent pas aux paquets venant de l'extérieur (ou les paquets ICMP sortants contenant des IP de la RFC1918 sont droppés en bordure).

Vous pouvez par exemple utiliser https://mtr.sh/ pour comparer la différence entre d'une part un traceroute (UDP par défaut) et un mtr (ICMP echo-request par défaut), et d'autre part entre quand vous les lancez depuis des machines chez OVH et depuis l'extérieur.

sinon pour vous l'atténuation est bonne ?

Oui, -20dBm est correct en GPON. -25db commence à être limite.

Pour la jarretière, c'est aussi OK.

IL (insertion loss) doit être le plus bas possible, pour une jarretière typiquement >0dB et < 0.5dB. C'est en gros "l'atténuation". Ça augmente en fonction de la distance, du type de fibre et à chaque passage par un "obstacle" (soudures, connecteurs, ...).
RL (return loss) doit être le plus élevé possible. C'est la puissance du signal réfléchi, qui revient à la source. Ça augmente à chaque fois qu'il y a un changement de réflectance.

Le RL est moindre avec des connecteurs APC que des connecteurs PC / UPC (note: vous devez toujours connecter des connecteurs de même type ensemble, ne branchez jamais un connecteur vert sur un bleu ou inversement).

IL doit être inférieur à 1550nm qu'à 1310nm. Si ce n'est pas le cas, il y a une contrainte : sur un lien, il faudrait sortir le réflectomètre pour trouver où est la contrainte.

Si Si: on ajoute un onduleur

Note : je n'ai pas les détails pour cet incident, je ne parle qu'en général.

Je doute que K-Net ait des serveurs dans ses propres locaux, ils sont probablement en datacenter, qui doit fournir au moins une voie ondulée. Brancher des onduleurs en cascade n'est vraiment pas recommandé (et est même interdit dans certains DC) donc K-Net ne pourra probablement pas mettre son propre onduleur directement dans sa baie.

Par contre, ça implique que l'entreprise gérant le DC planifie correctement la taille des onduleurs / batteries (pour pouvoir laisser assez de temps à une personne habilitée pour arriver sur place réarmer un disjoncteur si nécessaire / appeler enedis / prévenir les clients), fasse les {maintenances, des tests réguliers, remplacement} des {onduleurs, batteries} régulièrement, ... Ça n'est pas forcément le cas des petits POP.

À noter aussi que ce n'est pas d'une très grande aide quand c'est la baie elle-même qui disjoncte (et quand ça arrive, les deux voies sautent régulièrement en même temps).

Il existe aussi des prises connectées au réseau, donc télécommandable par internet pour redémarrer un Minux complètement aux fraises.

Quasiment tous les serveurs embarquent déjà un contrôleur et un mini-OS dans leur carte mère (BMC, Baseboard Management Controller), avec une prise ethernet dédiée, pour pouvoir redémarrer / éteindre / prendre le contrôle à distance de l'OS principal du serveur (chercher IPMI / iDRAC / ILO).

La prise télécommandable peut par contre être utile pour les équipements réseaux, même si je dois avouer ne jamais avoir eu besoin d'en faire usage en prod.

[complète]

Le problème avec Bouygues, SFR, et tous les opérateurs alternatifs, c'est que quelque soit leur backbone ou leur peering, ils passent passent tous par des équipements actifs de Covage.

Euh non, tu te trompes. BT et SFR utilisent, sur certains RIP, une collecte de l'OI mais en passif: ce sont leur propres équipements actifs dans tous les cas. C'est d'ailleurs ce qui les différencie des FAI activés.

Attention, en passif l'OC pose certe son propre matériel activé dans les NRO (OLT ou switchs). Mais ça ne l'empêche pas d'acheter à l'OI un service de collecte inter-POP/départemental/national s'il le souhaite/n'a pas la capillarité nécessaire sur son propre réseau de collecte, pour acheminer le traffic de l'équipement actif jusqu'à son backbone.

Je dirais même qu'à part Orange (qui a déjà un bon réseau de collecte pour ses NRA), aucun autre opérateur n'a cette capacité sur la France métropolitaine complète en propre.

[certains]

- si ça semble dépendre d'une fonction de hachage ou pas. C'est utilisé pour la répartition entre plusieurs liens d'un agrégat de liens (LAG), pour la répartition de trames/paquets entre plusieurs files (queues) des routeurs/switchs, ...

C'est une bonne piste.

J'ai rien compris 🤣🤣🤣🤣

Imaginons qu'il faille 80Gbps pour collecter une plaque, et que les routeurs ne supportent au maximum que des SFP+ 10Gbps. Dans ce cas, il y aura physiquement 8 liens de 10Gbps connectés entre les routeurs, et les routeurs de chaque côté seront configurés pour traiter ces 8 liens comme si c'était un seul. Le problème est que les routeurs ne répartissent pas le trafic de façon équitable entre les 8 liens. Il pourrait donc y avoir 7 liens à utilisés à 50 % (5 Gbps), et 1 lien à 90%. Pour des liens L3, c'est généralement l'IP source et l'IP de destination que les routeurs sont configurés pour utiliser pour faire le choix.

Un exemple de ce que ça peut donner :

IP source	IP destination	Lien choisi par le routeur
192.0.2.1	198.51.100.1	lien 1
192.0.2.1	198.51.100.2	lien 2
192.0.2.1	198.51.100.3	lien 3
192.0.2.1	198.51.100.4	lien 4
192.0.2.1	198.51.100.5	lien 5
192.0.2.1	198.51.100.6	lien 6
192.0.2.1	198.51.100.7	lien 7
192.0.2.1	198.51.100.8	lien 8
192.0.2.1	198.51.100.9	lien 1
192.0.2.1	198.51.100.10	lien 2
192.0.2.1	...	...
192.0.2.2	198.51.100.1	lien 2
192.0.2.2	198.51.100.2	lien 3
192.0.2.2	198.51.100.3	lien 4
192.0.2.2	...	...
192.0.2.3	198.51.100.1	lien 3
192.0.2.4	198.51.100.1	lien 4
192.0.2.5	198.51.100.1	lien 5

Si c'est une saturation d'un lien dans le sens remontant/upload (vu de la personne qui fait le traceroute), tous les sauts (hops) dans le traceroute après la saturation seront impactés.
Si c'est une saturation d'un lien dans le sens descendant/download (vu de la personne qui fait le traceroute), certains des sauts (hops) seront impactés, mais pas tous.

Maintenant, regardons le traceroute de votre message d'hier à 21:29:25 :

  1     1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms     1 ms  10.2.0.220
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    72 ms    74 ms    75 ms  122.138.24.109.rev.sfr.net [109.24.138.122]
  5     *        *        *     Délai d'attente de la demande dépassé.
  6     3 ms     3 ms     3 ms  10.2.0.5
  7    56 ms    55 ms    53 ms  178.250.208.14
  8     4 ms     3 ms     3 ms  108.170.244.193
  9    54 ms    53 ms    49 ms  142.251.64.125
10    45 ms    47 ms    49 ms  dns.google [8.8.8.8]

Ça alterne entre OK et KO. Et le routeur 109.24.138.122, qui est chez Covage, a déjà une latence élevée.

Note : il faut faire attention en lisant les traceroutes, il faut normalement obligatoirement la route du retour avant de pouvoir déduire quoi que ce soit, le routage pouvant être asymétrique (c'est un des raisons pour laquelle il faut aussi un traceroute dans l'autre sens, même si ça ne suffit pas toujours) et un routeur peut avoir son CPU occupé à autre chose sans que ça n'ait le moindre impact pour le trafic normal traversant le routeur (et c'est une des raisons pour laquelle il faut aussi un traceroute vers une IP qui n'est pas impactée).
Quant aux questions de tester sur des IP successives, je pense que le tableau plus haut vous donne une idée de pourquoi. Pas forcément besoin de smokepings, juste quelques traceroutes. Sous Windows, un truc moche comme

Code Sélectionner Étendre

for /L %i IN (1,1,32) DO tracert -d -w 150 178.250.209.%i dans une invite de commande DOS suffira largement à se faire une idée.

le smokeping de The Dark et le PRTG de Steph, ont montré la mémé chose, voir pièce jointe du smokeping+ traceroute...

Pour diagnostiquer ce genre de problème, il faut toujours :
- un traceroute depuis chez vous vers une IP qui a le problème et sur laquelle vous pourrez faire un traceroute dans l'autre sens
- un traceroute dans l'autre sens (depuis l'IP de destination du point précédant, vers votre IP K-Net)
- un traceroute ne montrant pas le problème
- vu que c'est seulement vers certaines destinations, il faudra aussi :

• essayer de vérifier la latence de plusieurs IP consécutives, par exemple de 178.250.208.1 à 178.250.208.32
• vérifier si toutes les personnes impactées ont le problème vers les mêmes IP, ou si ça dépend

Cela permettra :
- de voir s'il y a du routage asymétrique
- vers quel hop le problème semble être
- si ça semble dépendre d'une fonction de hachage ou pas. C'est utilisé pour la répartition entre plusieurs liens d'un agrégat de liens (LAG), pour la répartition de trames/paquets entre plusieurs files (queues) des routeurs/switchs, ...

Juste un exemple ....pour prouver le contraire 

on ne parle pas de changer l'adresse mas d'une carte reseau sous windows 10 ou linux ou mac os  qui sont des adresses que l'on peut changer dans les propriétés du périphérique , mais de changer l'adresse mac d'un routeur qui est physiquement dans une rom - aucun logiciel ne fait cela - ou alors donnez moi son nom , je vous dirai bravo .

La capture d'écran de Xynor ne vient pas de son OS, mais de l'interface d'administration de son routeur (c'est clairement une interface d'Ubiquiti).

Pour vous donner quelques exemples venant d'autres constructeurs (les premiers résultats que me retourne Google) :

• https://www.tp-link.com/fr/support/faq/68/
  https://kb.netgear.com/1086/No-Internet-with-new-router-MAC-spoofing
• https://www.cisco.com/c/en/us/support/docs/smb/routers/cisco-rv-series-small-business-routers/1571-Clone-MAC-address-for-an-RV160-or-RV260.html

utilisez de vrais arguments techniques expliquant en quoi une interface web est mieux qu'une interface web ET une interface Locale.

Il y a habituellement deux façons de gérer la configuration à distance d'équipements :
- soit la configuration est locale à l'équipement, et peut être accessible en local ou à distance
- soit la configuration est stockée à distance

Chaque mode de fonctionnement a ses avantages et inconvénients.

Dans le premier cas, les avantages sont que l'utilisateur final à la main sur l'interface même si la connexion internet est indisponible, et que c'est rapide.
Dans le deuxième cas, les avantages sont :
- en cas de réinitialisation usine ou d'échange de routeur (que ce soit vers le même modèle, mais aussi entre des modèles différents, comme entre le Netgear et les Icotera), le plus gros de la configuration est gardé et réappliqué immédiatement, sans aucune intervention. Peu de personnes pensent à télécharger et sauvegarder la configuration de leur routeur sur le PC à chaque modification.
- dans le cas où l'OI a activé votre connexion avant que vous n'ayez reçu votre routeur (c'est le cas opposé au votre), vous pouvez déjà configurer votre routeur à distance. Vous aurez un avertissement que le routeur n'est pas joignable sur le tab principal, mais les autres tab Wifi / ... sont bien configurable lorsque le routeur est injoignable. Lorsque vous branchez le routeur pour la première fois, il prendra sa configuration que vous aviez préparé avant même de le recevoir.
- le support technique de l'opérateur peut voir tout l'historique des modifications de configuration (y compris si votre connexion ne fonctionne pas), et si une modification a été faite par un employé, il a le nom de l'employé associé à la modification
- l'opérateur n'a pas besoin de demander au fabriquant de personnaliser l'interface (et de bloquer certaines options au passage, parce qu'à peu près aucun opérateur ne va vous laisser toucher à la configuration WAN en général)

Il est par contre extrêmement difficile de mélanger les 2 modes : il serait très facile de créer des conflits entre les configurations locales et distantes, au mieux une des modifications étant écrasée par l'autre, au pire des options non compatibles pourraient être activées.

À noter que certains fabricants de matériel réseau pro ont tendance à pousser vers des offres de gestion cloud (Cisco Meraki par exemple)

[Pour que ce soit faisable il faudrait deux appareils 100 % identiques]

Cloner veut dire remplacer l'adresse mac d'un périphérique par l'adresse mac d'un autre . Pour que ce soit faisable il faudrait deux appareils 100 % identiques

Non. L'adresse MAC n'est qu'un identifiant, sa valeur ne change rien au comportement de l'équipement, ni au comportement des autres équipements sur le même réseau, ni aux protocoles utilisés pour parler entre eux, tant que l'adresse est unique sur un même réseau L2. Aucunement besoin qu'ils soit identiques.

Quand vous avez changé de routeur, avez-vous bien aussi changé d'alim ?

Impossible de joindre K-net ce matin, leur numéro ne répond pas.

Panne chez OVH http://travaux.ovh.net/?do=details&id=52283&

[sortant]

Pas de blocage entrant. Par contre, je ne sais pas d'où vous faites vos tests, mais beaucoup de FAI (pas K-Net) bloquent le port 25 sortant.

Code Sélectionner Étendre

tracert labalme.covage
Détermination de l'itinéraire vers labalme.covage [10.2.0.178]
avec un maximum de 30 sauts :
  1     1 ms    <1 ms    <1 ms  k-box.home [192.168.1.1]
  2     1 ms     1 ms     1 ms  labalme.covage [10.2.0.178]
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    76 ms    10 ms    10 ms  k-net.covage [10.2.0.5]
  5    10 ms     9 ms    10 ms  collecte.covage [10.2.0.4]
  6    10 ms    10 ms    10 ms  labalme.covage [10.2.0.178]
Itinéraire déterminé.


Amusant, ça ne fait pas ça sur un accès K-Net dans la Somme :

Code Sélectionner Étendre


$ mtr -nrwc 1 10.2.0.181
Start: 2021-07-04T21:46:36+0200
                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1   0.0%     1    0.3   0.3   0.3   0.3   0.0
  2.|-- 10.2.0.181    0.0%     1    1.7   1.7   1.7   1.7   0.0


Cette IP ne correspond à rien.

Mon routeur pFsense aurait inventé une adresse IP distribuée par le serveur DHCP de K-Net comme passerelle par défaut ?

C'est bien l'adresse distribuée par le serveur DHCP de K-Net, qui précisément est une IP réservée, n'étant portée et allouée par aucun équipement ou client, ni chez K-Net, ni chez Covage. Tout le trafic de l'OLT est forwardé vers le BNG (un routeur chez Covage sur votre RIP, qui vérifie les droits et agit comme passerelle). Quelque soit la requête ARP que vous fassiez, c'est toujours la MAC du BNG qui sera retournée ; donc quelque soit l'IP de passerelle configurée sur votre routeur, c'est lui qui fera passerelle. Pour des raisons techniques, il est préférable en IPv4 que l'IP de passerelle soit dans votre subnet, donc une IP par subnet est réservée dans ce but par les OC (à noter, ce n'est pas le cas en IPv6 où les OI utilisent des IP link local pour leurs passerelles, distribuées par des RA).

Le BNG étant configuré pour forwarder tout le trafic vers la porte de collecte opérateur, et l'IP de "passerelle" donnée par le DHCP n'étant pas configurée dessus, si vous tentez de la pinger il va juste forwarder le paquet ICMP vers la porte de collecte, et l'IP n'étant pas attribuée le paquet sera droppé.  Ça se voit d'ailleurs sur le traceroute que Steph vient de donner : le traceroute vers l'IP de "passerelle" passe par 10.2.0.178 puis se perd ensuite.

[la passerelle par défaut que me transmet K-Net via le DCHP]

la passerelle par défaut que me transmet K-Net via le DCHP.

Cette IP ne correspond à rien.