it-swarm-ja.com

dhclientリースの更新により、DNS解決が中断されることがあります

特別なdhcp設定を行ったことがないec2インスタンスのセット(ubuntu trusty 14.04)があります。これは、デフォルトのdhcpオプションを備えたVPC上にあります。

なんらかの理由で、およそ25分ごとに、これがログに表示されます

(IPとxidはスクラブされます)

DHCPREQUEST of 172.16.1.111 on eth0 to 172.16.0.1 port 67 (xid=0x0000000c)
DHCPACK of 172.16.1.111 from 172.16.0.1
bound to 172.16.1.111 -- renewal in 1693 seconds.

(正確な秒数は1300から1700の間で変化します。)

場合によっては、10日に1回のように、この更新によってDNSが破損し、実行中のアプリケーションでgetaddrinfo: Name or service not known.のようなエラーが発生し始めます。更新が約25分後に再度実行されると、問題は解決します。障害を待ち、dhclientリースを手動で更新して(Sudo dhclient -v -r eth0、次にSudo dhclient -v eth0)、問題がすぐに修正されることを確認して、これをテストしました。

2つの質問があります:

  1. なぜ更新時間がこの奇妙な〜25分の数字なのですか? confファイルでこれを設定できることは知っていますが、これは奇妙なデフォルトのようです。

  2. なぜDNS解決が壊れることがあるのですか?これがここでの主な問題です。私の他のec2インスタンスのセットにもこの短いDHCP更新時間がありますが、DHCPの更新時にDNSが壊れることがあるという問題があるのは、この1セットのインスタンスだけです。

1
swagrov

私の推測では、DNSサーバーIPが不正なDHCP更新を受信して​​います-停止中に/etc/resolv.confの内容を確認し、動作中の内容と比較しましたか?

しかし、何が起こっているのかを正確に確認するためにもう少しデータを収集できる場合は、まったく推測しない方がよいでしょう。次の方法でDHCPトラフィックをキャプチャしてみてください。

tcpdump -c 10000 -w /var/tmp/dhcpdump.tcp -i INTERFACE port bootpc or port bootps

「INTERFACE」はeth0、またはプライマリインターフェイスの名前です。これにより、サーバー上のDHCPトラフィックがキャプチャされます(実行中のタスクを忘れてもディスクがいっぱいにならないように、10kパケット後に自動的に終了します)。問題が再度発生した後、「tcpdump -v-rFILE」またはWiresharkを使用してスニフファイルを確認してください。これで、問題の原因となっているDHCPの更新の違いがわかります。

問題の原因となるDHCP更新の明確なパターンが見られる場合は、Amazonサポートに連絡して、更新の良し悪しを示すスニフファイルまたはデコードされた出力を送信してください。

リース期間については、特に異常はありません。 DHCPサービスを管理している人々は、ショートリースが必要だと判断しました。おそらく、他の顧客が15分ごとにインスタンスを作成および破棄しているため、使用されなくなった別の顧客のIPを回復したいと考えています。

2
Velo Traveler