web-dev-qa-db-fra.com

Réseau eth0 DHCP, IP statique et problèmes de négociation automatique

Contexte

J'utilise un serveur Ubuntu le 14.04, qui est actuellement à jour. Je n'ai qu'un seul périphérique réseau connecté. Lorsque j'utilise mon câble Ethernet et que je le connecte du mur à mon ordinateur portable (sous Windows 7), le protocole DHCP est résolu sans problème.

Problème

Lorsque je connecte mon câble Ethernet du mur à mon serveur (sous Ubuntu) et que je mets mon serveur sous tension, le serveur DHCP n'attribue pas d'adresse IP à mon serveur. Cependant, lorsque je connecte le cordon de mon serveur à mon ordinateur portable à l'aide de la connexion Ethernet des ordinateurs portables pour se connecter via ma connexion Wifi, le serveur obtiendra une adresse IP de DHCP via l'ordinateur portable. Enfin, après avoir reçu une adresse IP de la connexion d’un ordinateur portable, j’utilise les commandes suivantes, puis DHCP fonctionne lorsque le cordon est connecté du mur au serveur:

Sudo dhclient -r
Sudo dhclient -v eth0

La prochaine fois que je redémarrerai le serveur via Sudo shutdown -r now, le serveur ne pourra plus obtenir d’adresse IP de DHCP avec le cordon du mur vers le serveur.

Notez que lorsque j'attribue une adresse statique dans le fichier /etc/network/interfaces, le réseau ne lui attribuera pas l'adresse IP et l'interface sera hors service.

Question

Existe-t-il un moyen de résoudre le problème rencontré avec mon réseau, qui ne parvient pas à détecter le serveur DHCP lorsque je le met sous tension?

Si vous avez besoin de plus d'informations s'il vous plaît faites le moi savoir.

Informations complémentaires

dhclient avant de se connecter à un ordinateur portable

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x********)
...
No DHCPOFFERS received
No working leases in persistent database - sleeping.

dhclient avec serveur connecté à un ordinateur portable

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x*********)
DHCPREQUEST of 192.168.137.233 on eth0 to 255.255.255.255 port 67 (xid=0x*********)
DHCPOFFER of 192.168.137.233 from 192.168.137.1
DHCPACK of 192.168.137.233 from 192.168.137.1
bound to 192.168.137.233 -- renewal in 275 seconds.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.137.233  Bcast:192.168.137.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2781 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4655957 (4.6 MB)  TX bytes:415144 (415.1 KB)

dhclient après que le DHCP et le cordon du portable soient reconnectés du mur au serveur

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x********)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x********)
DHCPREQUEST of 192.168.1.126 on eth0 to 255.255.255.255 port 67 (xid=0x*******)
DHCPOFFER of 192.168.1.126 from 192.168.1.254
DHCPACK of 192.168.1.126 from 192.168.1.154
bound to 192.168.1.126 -- renewal in 41950 second.

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:22:64:23:7c:da  
          inet addr:192.168.1.126  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33438 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5245215 (5.2 MB)  TX bytes:550462 (550.4 KB)

interface réseau (lshw)

Sudo lshw -class network

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: eth0
       version: 02
       serial: 00:22:64:23:7c:da
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.82 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:42 ioport:e800(size=256) memory:febff000-febfffff memory:fdff0000-fdffffff memory:febc0000-febdffff

Mise à jour:

Mon fichier /etc/network/interfaces est en tant que tel

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

J'ai trouvé une solution temporaire qui semble fonctionner, mais je ne voudrais pas que ce soit ma solution si nous pouvons résoudre ce problème. J'ai changé le fichier d'interface comme si

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up mii-tool -R

Cela (je crois) indiquerait à l'interface de se réinitialiser et pour une raison quelconque, cela permettrait au DHCP de résoudre comme il se doit. Comme je l'ai dit, il doit y avoir un correctif réel en dehors de celui-ci.

Solution:

Grâce à la réponse de Fabbys, j'ai pu proposer une solution plus viable avec laquelle je peux vivre.

Ouvrez/etc/network/interfaces et configurez l’interface Ethernet de l’une des manières suivantes:

DHCP

auto eth0
iface eth0 inet dhcp
    pre-up ifconfig $IFACE up
    pre-up ethtool -s $IFACE speed 100 duplex full autoneg off

Statique 

auto eth0
iface eth0 inet static
    post-up ethtool -s $IFACE speed 100 duplex full autoneg off
    address x.x.x.x #Internal IP
    netmask 255.255.255.0
    gateway x.x.x.y #Gateway IP
    dns-nameservers 8.8.8.8 #Google DNS

J'espère que cela aidera quelqu'un d'autre à l'avenir.

14.04networkingethernetdhcp
6
Mic1780

Comme indiqué dans la discussion sur le chat, désactivez la négociation automatique sur le serveur et fixez la vitesse du réseau au niveau le plus élevé que la carte d'interface réseau (NIC) peut gérer.

Commencez avec 10 Mbits/s, en semi-duplex et passez à 10 Mb/s FD, 100 Mb/s HD, ... jusqu'à ce que le problème se pose. Ensuite, descendez d’un cran et laissez-le à cette vitesse.

Commencez par installer ethtool (si vous êtes déjà installé, vous recevrez simplement un avertissement indiquant que la dernière version est déjà installée).

Sudo apt-get install ethtool

À présent:

  1. Tapez la commande suivante (et testez les un par un)

    Sudo ethtool --change eth0 speed xxx duplex yyy autoneg off

    où xxx = 10, 100 ou 1000 et yyy = half ou full.

    Alors commencez par 10 half, 10 full, 100 half, ...

  2. Faites un ifconfig pour vérifier si vous avez une adresse IP.

  3. Revenez à 1 jusqu'à ce qu'il cesse de fonctionner et utilisez les valeurs précédentes qui fonctionnaient toujours pour:

  4. Pour rendre la modification permanente, exécutez la commande suivante:

    Sudo nano /etc/network/interfaces

    et tapez à la section pre-up:

    pre-up /usr/sbin/ethtool --change eth0 speed xxx duplex yyy autoneg off
4
Fabby

OH MAN FACEPALM (facepalm pour moi-même, alors que je pensais à l'origine de cette seconde au lieu de la première comme je l'aurais dû, c'est presque toujours la la plupart des choses simples qui peuvent vous faire tourner en rond avec la technologie, hein?)

(déplacé au sommet car c'est probablement le problème, mais a laissé l'autre contenu ci-dessous pour référence).

Si vous utilisez le même câble pour connecter votre serveur à votre ordinateur portable, vous êtes votre serveur au mur C'EST PROBABLEMENT LE PROBLÈME! (encore une fois, c'est plus moi me reprochant d’avoir manqué cette première et pensant seulement à la seconde.

Vous utilisez 2 types de fils différents ...

Référence: https://www.computercablestore.com/straight-through-crossover-and-rollover-wiring

Le premier est un câble Ethernet droit utilisé pour les commutateurs et les routeurs vers les ordinateurs clients

Le second est un câble croisé: ils sont utilisés pour les connexions entre machines et sont physiquement câblés différemment!

Donc, si ces câbles fonctionnent entre votre serveur et votre ordinateur portable sans commutateur ni routeur entre les 2 (la connexion WiFi ne compte pas du tout ici), ce câble doit être un croisement.

Procurez-vous un câble droit direct et connectez-vous du routeur au serveur pour voir ce qui se passe.

D'après mon expérience, les problèmes informatiques se résument au plus simple des problèmes omis. Certains routeurs et commutateurs sont "intelligents" et peuvent essayer de faire des ajustements internes lorsque vous utilisez un câble incorrect (câble croisé) de sorte que vous puissiez toujours l'utiliser pour connecter la machine, mais vous ne pourrez jamais vous en fier à cela. problème.

Euh en fait cela ressemble à un problème de routeur. Par exemple, j'ai FiOS et dans le routeur, je peux consulter les paramètres réseau et voir où il relie les segments WiFi et Wired séparément au serveur DHCP. Ainsi, si quelque chose devait arriver à ce paramètre, je pourrais me retrouver avec ce que vous avez. Dans ce cas, vous ne pouvez plus obtenir d’adresse IP sur le réseau filaire, car elle n’est pas connectée au réseau "domestique" exécutant le serveur DHCP, mais vous pouvez utiliser le WiFi car elle est toujours connectée au réseau "domestique" du routeur. Vous pouvez soit essayer de parcourir les paramètres avancés de votre routeur, soit le plus souvent si vous avez un trombone et qu'il existe un bouton-poussoir permettant de réinitialiser la broche. Vous pouvez rechercher comment le réinitialiser en usine (généralement maintenir le bouton trombone dans le bouton de réinitialisation pendant environ 30 secondes). ).

De plus, votre ordinateur portable reçoit une adresse IP via WiFi uniquement. Si vous avez une machine et qu’elle a à la fois un adaptateur filaire et une connexion Wi-Fi et que vous avez une connexion Wi-Fi et branchez un fil même si cela ne fonctionne pas, votre machine surfera quand même correctement sur Internet, ce qui ne causera pas le routage de toutes les demandes via port filaire tout à fait.

Votre "solution" fonctionne parce que vous demandez une adresse IP via l’adaptateur Wifi pour ordinateur portable.

En lisant plus ici, je remarque également qu’il s’agit peut-être d’une fonctionnalité de sécurité MAC que vous avez activée sur le routeur ... Cela signifie que si l’adresse MAC de votre NIC se trouve dans la liste des clients autorisés que votre routeur refuserait de communiquer. c'est une adresse. Vous pouvez "résoudre ce problème en passant d'abord par l'ordinateur portable qui est sur la liste et une fois que vous obtenez une adresse de cette manière, lorsque vous vous reconnectez au mur et envoyez une autre demande, le contrôle MAC peut être ignoré puisqu'il vous l'a déjà déjà indiqué. et à moins que votre serveur ne soit temporairement considéré comme un client de confiance, je voudrais également vérifier la sécurité MAC que vous avez activée dans le routeur.

Je ne dis pas qu'il est impossible que votre serveur DHCP de routeurs ait un problème étrange, mais ce serait SOO SUPER RARE. Je ne peux pas vous dire à quel point il est rare.

0
Mike