背景
14.04で現在最新のUbuntuサーバーを実行しています。ネットワークデバイスが1つしか接続されていません。イーサネットコードを使用して壁からラップトップ(Windows 7を実行)に接続すると、DHCPは問題なく解決します。
問題
イーサネットコードを壁からサーバー(Ubuntuを実行中)に接続してサーバーの電源を入れると、DHCPサーバーはサーバーにIPアドレスを割り当てません。ただし、Wifi接続を介して接続するラップトップのイーサネットを使用してサーバーからラップトップにコードを接続すると、サーバーはラップトップ経由でDHCPからIPアドレスを取得します。最後に、ラップトップ接続からIPを取得した後、次のコマンドを使用し、コードが壁からサーバーに接続されているときにDHCPが機能します。
Sudo dhclient -r
Sudo dhclient -v eth0
次回Sudo shutdown -r now
経由でサーバーを再起動すると、サーバーは壁からサーバーへのコードを使用してDHCPからIPを再度取得できなくなります。
/etc/network/interfaces
ファイルで静的アドレスを割り当てると、ネットワークはIPを割り当てず、インターフェースがダウンすることに注意してください。
質問
サーバーの電源を入れたときにネットワークでDHCPサーバーを検出できないという問題を解決する方法はありますか?
さらに情報が必要な場合はお知らせください。
追加情報
ラップトップに接続する前のdhclient
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
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)
ラップトップのDHCPとコードを壁からサーバーに再接続した後のdhclient
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)
ネットワークインターフェース(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
更新:
私の/etc/network/interfaces
ファイルはそのようなものです
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
動作するように見える一時的な修正を見つけましたが、この問題を解決できる場合、それが私の解決策になりたくありません。 interfacesファイルを次のように変更しました
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
pre-up ifconfig $IFACE up
pre-up mii-tool -R
それは(私は信じている)インターフェイスにリセットするように指示し、何らかの理由でDHCPが本来のように解決することを許可しました。私が言ったように、これ以外にも実際の修正が必要です。
解決策:
Fabbysの答えの助けを借りて、私は一緒に暮らせるより実行可能なソリューションを思いつくことができました。
/ etc/network/interfacesを開き、次のいずれかの方法でイーサネットインターフェースを設定します。
DHCP
auto eth0
iface eth0 inet dhcp
pre-up ifconfig $IFACE up
pre-up ethtool -s $IFACE speed 100 duplex full autoneg off
Static
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
これが将来他の誰かに役立つことを願っています。
チャットでの議論に従って、サーバーで自動ネゴシエーションをオフにするに設定し、ネットワーク速度をネットワークインターフェイスカード(NIC)が維持できる最高レベルに修正します。
10Mbps、半二重から始めて、問題が始まるまで、10Mbps FD、100Mbps HDに上向きに働きます。次に、1ノッチ下げて、その速度のままにします。
まず、ethtool
をインストールします(既にインストールされている場合は、最新バージョンが既にインストールされているという警告が表示されます)
Sudo apt-get install ethtool
今:
次のコマンドを入力します(1つずつテストします)
Sudo ethtool --change eth0 speed xxx duplex yyy autoneg off
ここで、xxx = 10
、100
または1000
およびyyy = half
またはfull
。
10 half
、10 full
、100 half
、...から始めます.
ifconfig
を実行して、IPアドレスを取得したかどうかを確認します。
動作が停止するまで1に戻り、まだ動作していた以前の値を使用します:
変更を永続的にするには、次のコマンドを実行します。
Sudo nano /etc/network/interfaces
pre-up
セクションに入力します:
pre-up /usr/sbin/ethtool --change eth0 speed xxx duplex yyy autoneg off
OH MAN FACEPALM(最初にではなく、この2番目のことを考えていたので、自分自身にフェイスパームを使用する必要があります。テクノロジーを使って輪になっていくための最も簡単なことですよね?)
(これが問題である可能性が高いため、上に移動しましたが、参照用に以下の他のコンテンツを残しました)。
あなたがあなたのサーバーを壁に接続しているのと同じワイヤーを使用してサーバーをラップトップに接続している場合、それはおそらく問題です!!(これもこれを最初に見逃し、2番目に考えただけで自分自身に乗り込むことができます。
ここで使用しているワイヤには2種類あります...
参照: https://www.computercablestore.com/straight-through-crossover-and-rollover-wiring
最初は、クライアントコンピューターへのスイッチとルーターに使用されるストレートイーサネットケーブルです。
2つ目はクロスオーバーケーブルです。これらはマシン間接続に使用され、物理的に異なる方法で配線されています。
そのため、2の間にスイッチまたはルーターがなくてもサーバーとラップトップ間でケーブルが機能する場合(WiFi接続は何も考慮されません)、そのケーブルはクロスオーバーする必要があります。
標準のストレートケーブルを入手し、ルーターからサーバーに接続して、何が起こるかを確認します。
私の経験では、コンピューターの問題は、最も単純な見過ごされている問題に要約されます。一部のルーターとスイッチは「スマート」であり、間違ったケーブル(クロスオーバー)を使用すると内部調整を試みることがあるため、それを使用してマシンを接続できますが、これは信頼できるものではなく、問題。
実際、これはルーターの問題のように聞こえます。たとえば、私はFiOSを持っているので、ルーターでネットワーク設定を調べて、WiFiサーバーと有線セグメントを別々にDHCPサーバーにブリッジする場所を確認します。そのため、その設定で何かが起こった場合、ここでは、DHCPサーバーを実行している「ホーム」ネットワークに接続されていないため、ワイヤーを介してIPを取得できませんが、ルーター内の「ホーム」ネットワークに接続されているため、WiFiを介して接続できます。ルーターの高度な設定を確認するか、ペーパークリップがあり、リセットピンのプッシュボタンがある場合、工場出荷時のリセット方法を調べることができます(通常、ペーパークリップをリセットボタンに30秒間押し続ける) )。
また、ラップトップにはWiFiのみでIPが割り当てられます。あなたがマシンを持っていて、それが有線とwifiアダプタの両方を持っていて、WiFiが接続されていて、それが失敗してもワイヤを差し込むと、マシンはまだインターネットをうまくサーフィンし、原因はWiFi経由ですべての要求をルーティングし、無視することです有線ポート全体。
最終的にラップトップWifiアダプターを介してIPを要求しているため、「修正」が機能します。
ここをもっと読むと、ルータで有効にしたMACセキュリティ機能もあることに気づきます...これは、NICのMACアドレスがクライアントの許可リストにない限り、ルータが与えることを拒否することを意味しますそれは住所です。 「最初にリストにあるラップトップを経由して修正し、壁に接続して別のリクエストを投げるときにその方法でアドレスを取得すると、すでにアドレスを与えられていることがわかるため、MACチェックをスキップすることができますまた、少なくともサーバーが信頼できるクライアントであると一時的に見なし、ルーター内で有効にしたMACセキュリティもチェックします。
ルーターのDHCPサーバーで奇妙な問題が発生することは不可能ではないと言っているわけではありませんが、これは非常にまれなことです。