長い間、ネットワークに関して解決困難な問題を抱えていました。
パフォーマンスを低下させる原因を探して、ルーター、アクセス ポイントを変更し、ワイヤレス接続を有線化しましたが、設定の何が問題なのかはよくわかりませんでした。
問題は「ネットワークが遅いように感じる」という漠然としたものであり、問題の特定の症状が持続していないため、根本的な原因を見つけることができません。
現在のインフラストラクチャは次のもので構成されています。
esxi で実行されている pfsense 仮想マシン。現在、ホスト (Proliant ML110、Core 2 Duo) で実行されている唯一の仮想マシンで、パフォーマンスを低下させる他の仮想マシンを排除します。サーバーには 2 つの NIC があり、1 つは WAN 用、もう 1 つは LAN 用です。
3 台の Procurve 1800/1810 8 ポートおよび 24 ポート スイッチ。2 つの VLAN (1 つは LAN 用、もう 1 つは WAN 用)。
Ubiquiti Unifi UAP-AC 1 台。
このネットワークは、20 以上のユニットに接続機能を提供します。
昨日はNetflixで映画を観始めることができないというより根深い問題がありました。少しグーグルで調べたところここNetflix サポートに問い合わせたところ、問題は Netflix ではなく ISP にあるとのことでした。
そこの説明は私が抱えている問題とよく一致しており、アプリの起動が非常に遅く、再生が常に機能するとは限りません。
Apple-TV を取り外し、同じケーブルを使用して Macbook を接続してみました。コンピューターでは Netflix が問題なく動作しました。そのケーブルでスピードテストを実行すると、帯域幅が双方向 100 メガビットであることが確認されました。Apple-TV を再接続しても Netflix は動作しませんでした。
Apple TV が接続されているポートの VLAN を LAN から WAN に変更すると、パブリック IP を使用してインターネットに直接接続できるようになり、問題なく映画をストリーミングできるようになりました。
LAN に戻しても再生は再び失敗しました。Apple-TV とスイッチからのスイッチ アップリンク以外のすべてを切断しました。インターネット入力のあるスイッチに移動し、2 つの pfsense ポート、ファイバー コンバータへの接続、および Apple-TV のあるスイッチへのアップリンク以外のすべてを切断しました。その後、再生を開始できました。
その結果、すべてを再接続してどのケーブルが再生を妨げているかを確認すれば、問題の原因を正確に特定できるはずだと考えました。問題は解決しませんでした。すべてを再接続すると、すべて正常に動作しました。
接続のパフォーマンスが悪い理由を突き止めようとするたびに、このような経験をしてきました。双方向 100 メガビットならかなり速いはずですが、4G の方が速いので、携帯電話の Wi-Fi を何度かオフにしました。スピードテストでは常に 100 メガビットが表示されます。
ストリーミングは特に扱いにくいようで、AirPlay を使用して画面をミラーリングしてもほとんど役に立ちません。同じテクノロジーを使用して音楽を再生することはできますが、再生が中断されることがよくあります。
昨日はファイアウォールをバイパスしたことで、これがすべて犯罪者の手柄であるように見えましたが、今日は結果が逆転しました。
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
また、ネットワークの MTU を確認するために (Apple フォーラムの理論に従って)、WAN からさまざまなパッケージ サイズで ping を実行してみましたが、テストの結果、大きなパッケージはネットワークをうまく通過できないことがわかりました。
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
いくつかの実験により、WAN 上の MTU が実際に 1500 であることが確認されたようです。
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
LAN では、ブレークポイントは同じパケット サイズにありますが、パケットが分割されるために断片化を許可しないように手動で指定する必要があります。
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
ネットワークの何が問題なのかわかりません。さらにトラブルシューティングする方法もわかりません。ネットワークからゴーストを完全に排除できるように、トラブルシューティングを再構築するのを手伝ってください。
編集、DNS 設定について:
私の理解が正しければ、Google のリゾルバは、ISP から DHCP で割り当てられたネーム サーバーが利用できない場合にのみフォールバックとして使用されるということです。これで正しいでしょうか。それとも、遠く離れたネーム サーバーにランダムにアドレスを要求しているのでしょうか。
以下に示すように、pfsense は最初に名前解決を独自に処理しようとし、2 番目と 3 番目に ISP に問い合わせ、4 番目と 5 番目のオプションとしてのみ Google に頼りますが、これは私にとってはかなり合理的に思えます。
Apple TV には DHCP によって割り当てられたネットワーク設定があり、ゲートウェイをネーム サーバーとして使用します。DHCP サーバーには専用の DNS 設定はありませんが、上記のネーム サーバー リストを継承します。
編集、for ループに関して:
100 パケットで 1 回ではなく 100 回 ping を実行する理由は、手動で実行したときに ping が「開始」されるまでにかなり異なる時間がかかるように思われたため、その動作を 100 倍にすることでその感覚をより明確にすることができるかもしれないと考えたため、毎回名前解決を実行するためです。
Ubuntu には次の構成があるとします。
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
その考えはちょっとばかげているかもしれませんが...
編集、Apple TV に関して:
Apple TV を工場出荷時の状態にリセットしました。デバイスのプラグを何度も抜きました (時にはかなりの激怒を伴って)。
編集、pfSense:
先日、pfSense を工場出荷時の状態に戻し、より重要な部分 (DNS、DHCP、NAT、静的 DHCP リース、いくつかのポート転送) のみを再度有効にしましたが、昨日も Netflix はストリーミングの途中で再生を停止しました。問題は再び解消されたので、映画を再開するとうまくいきました。
Netflix はストリーミング中に DNS を必要とするのだろうか、その時点ですでに対処されているはずだと感じる。
そして、サーバーは最新のpfsenseバージョン（2.2.2）を実行しているため、縛られないデフォルトでは。
リゾルバが解決を正常にキャッシュしているかどうかは、診断ツールを使用して 2 回連続して検索を実行することで確認できます。
しかし、答えが異なっているので混乱します。
編集、MTU:
MTU は自動に設定されています。
編集、ATV 速度テスト:
Apple TV で速度テストを実行すると、pfsense に次のグラフが生成されます。
その後、Apple TV に「テストが正常に終了しました」というメッセージが一瞬表示され、その後次のように変わります。
エラーが発生しているにもかかわらず、Netflix は使用できます。
答え1
遠く離れた DNS サービスではなく、必ずローカル ISP の DNS サーバーを使用してください。
Apple TV にダウンロードまたはストリーミングできるコンテンツのほとんどは、Akamai CDN 経由で提供されます (Apple は長年 Akamai の最大の顧客の 1 つです)。Akamai は、DNS ルックアップの取得元に基づいて、最も近い CDN エッジ ノード (サーバー) を見つけます。DNS ルックアップは通常、クライアント デバイスで使用するように設定したローカルの再帰/解決 DNS サーバーから取得されます。
Apple TV が、Google DNS (8.8.8.8 および 8.8.4.4) や Level 3 (4.2.2.x)、OpenDNS などの遠く離れたサーバーではなく、ローカル ISP の DNS サーバーを使用するように設定されていることを確認してください。Apple TV は DHCP 経由で DNS 設定を取得している可能性があり、DHCP サーバーはルーター/ゲートウェイ上のプロセスである可能性があります。DHCP サーバーが Apple TV に NAT ゲートウェイ (または他のローカル ファイアウォールやルーター) のプライベート IP アドレスを DNS アドレスとして使用するように指示している場合は、NAT ゲートウェイが DNS プロキシとして動作していることを意味します。これを継続したい場合は、その NAT ゲートウェイがローカル ISP の DNS サーバーを DNS として使用していることを確認してください。そのDNS サーバー。
ローカル DNS サーバーを使用することで、Akamai はクライアントに対し、Google の 8.8.8.8 DNS サーバーが配置されている米国の Google データセンター付近のサーバーではなく、スウェーデンにある最も近い Akamai サーバーからダウンロード/ストリーム要求を行うように指示します。
[これがあなたにとって正しい答えでなかったとしても、この質問を見つけた他の人にとっては正しい答えかもしれないので、とにかくここに残しておきます。]