web-dev-qa-db-fra.com

Quelles sont les autres raisons de la faible connectivité réseau?

À l'exclusion de cela, car j'ai essayé toutes les méthodes répertoriées sur ce site. Et à l'exclusion de this et this , elles se trouvent dans le site susmentionné. Quelles sont les causes possibles d'un ralentissement logiciel d'Internet.

Symptômes:

  • Le démarrage sous Windows ou un autre disque de démarrage en direct fait fonctionner Internet, envoie une requête 0% de perte.
  • Le routeur peut être cinglé par le PC en question, tout en exécutant Ubuntu, avec une perte de 0% ainsi que n'importe quoi dans le même réseau, une perte de 0%.
  • Pinging ou mtr, par le PC en question à tout ce qui se trouve en dehors du réseau (de l'autre côté du routeur) entraîne une perte de 100%.
  • Si le routeur ou d'autres périphériques sur le réseau tentent d'envoyer une requête ping à l'ordinateur en question, ils ont une perte de 80% à 95%.

Quelle pourrait être la cause de ce type de panne de réseau sur Ubuntu?

Les ordinateurs Ubuntu avec ce problème ont des réponses à lspci -knn | grep Eth -A2:

02:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8131 Gigabit Ethernet [1969:1063] (rev c0)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7599]
    Kernel driver in use: atl1c

Celui-ci a moins de 80% de perte ~ 50% en utilisant un port réseau USB vers Cat5

00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Kernel driver in use: ehci-pci
networkinginternetnetwork-managerethernet
2
Luke Burgess

C'est et sera toujours une supposition sans être sur place, mais voici quelques raisons qui pourraient empêcher Ethernet de fonctionner correctement. Le pilote Windows pour la carte peut être en mesure de faire de l'automagique pour dégrader les paramètres de votre carte. Ou la carte a besoin de piquer pour faire la négociation automatique.

  1. Le plus évident pourrait être l'adresse MAC en double. Répertoriez les adresses MAC sur le PC concerné, puis arrêtez-le puis essayez arping les adresses MAC d'une autre machine.

  2. Votre routeur peut être une vraie affaire et bloquer certains paramètres IP par défaut. Si vous pouvez essayer d'utiliser un autre routeur générique sur le réseau, faites-le pour exclure cette possibilité.

  3. Câblage tordu ou ancien qui empêche la carte de fonctionner à des vitesses plus élevées. Vous pouvez essayer de définir le mode de liaison sur 10M ou 100M manuellement à l'aide de mii-tool ou d'ethtool.

  4. Similaire avec les paramètres duplex intégral ou semi-duplex sur la carte.

Voici un article sur mii-tool/ethtool qui y va plus en détail.

Une autre idée sur la façon de déboguer le problème:

  • Vous pouvez essayer de renifler l'interface réseau à l'aide de tcpdump ou de wirehark et observer les différences entre les pings lancés sur le PC en question et les pings lancés ailleurs.
  • La même chose peut être faite sur le routeur si c'est f.e. sous Linux embarqué, ou vous pouvez brancher un "renifleur" composé de deux cartes réseau reliées entre le routeur et le réseau intérieur.
2
oerdnj

Iperf est un autre outil que vous pourriez vouloir utiliser. Vous pouvez l'utiliser pour déterminer si le réseau local tue votre débit. Une référence se trouve à: https://iperf.fr/ . Vous pouvez simplement générer des charges de bande passante élevées, puis vérifier le débit réel signalé. Si vous avez deux nœuds, vous pouvez effectuer la vérification suivante. Première exécution

Sudo lshw -c network

sur les deux machines. Trouvez votre interface et notez la vitesse de liaison signalée, devrait être quelque chose de la forme:

size: 100Mbit/s
capacity: 100Mbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation

Cette interface rapporte 100Mbit/s, vérifiez cela sur les deux appareils et déterminez le minimum que vous attendez. Utilisez ensuite iperf pour pousser une grande quantité de trafic afin de déterminer quel est le débit réel.

Sur le nœud 1, exécutez:

iperf -s -i 2

Sur le nœud 2, exécutez:

iperf -n 1000M -i 2 -c <SERVER IP>

Cela générera un rapport sur le côté client du formulaire:

------------------------------------------------------------
Client connecting to <SERVER IP>, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local <CLIENT IP> port 36114 connected with <SERVER IP> port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 2.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  2.0- 4.0 sec  22.2 MBytes  93.3 Mbits/sec
[  3]  4.0- 6.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  6.0- 8.0 sec  22.4 MBytes  93.8 Mbits/sec

et quelque chose de similaire côté serveur (le nœud -s). Vous remarquerez que dans ce cas, le débit est assez proche de l'idéal signalé. Vous devez vous attendre à perdre quelques Mbits/s à TCP surcharge, mais si cette valeur est loin, vous pouvez blâmer quelque chose à l'intérieur de votre réseau. Si ce nombre est dans une certaine tolérance (disons 5 -7% des signalés), votre problème se situe au-delà de votre passerelle.

À ce stade, on peut se demander si votre fournisseur de services procède à une procuration, ou fait une certaine forme de mise en forme du trafic qui accorde un traitement préférentiel à certains types de trafic?

2
James S.