web-dev-qa-db-ja.com

遠隔インターネットルーティングの問題をトラブルシューティングするにはどうすればよいですか？

（これはserverfaultでより適切に回答される可能性がありますが、技術的にはサーバーに関するものではないため、提案を歓迎します...）

職場にオフィスを移転しました。私たちはマサチューセッツ州ケンブリッジにいて、Comcastビジネスクラスのケーブルモデムを持っています。数日に1回、ほとんどの場合、Slashdotなど、すべてではありませんが一部のWebサイトにアクセスするのに問題があります。たまたま、私はオフィスから3マイル離れたところに住んでいて、自宅にはComcastビジネスクラスのケーブルモデムもあります。仕事から、自宅のサーバーにSSH接続できます。同じルーターをいくつか通過しますが、同じ一般的なPOPのallすべてを通過します。自宅からこれらの問題を抱えていません。

15年前、私はこれをトラブルシューティングし、NOCに電話して理解する方法を知っていました。今日、ロードバランサーと仮想IPで、私は困惑しています。以下のtracerouteでSavvisに連絡してみたところ、「私たちではありません」と言われました。私はそれらをSlashdotに送信しましたが、もちろん応答はありませんでしたが、それはSavvisの問題だけではなく、Slashdotの問題でもありません。

また、Googleの8.8.8.8にpingを実行すると、10〜30％のパケット損失が発生することがあります。問題が同時に発生するかどうかはわかりません。現時点で失敗したtracerouteはありませんが、正常なtracerouteは111eighthave.ny.ibone.comcast.netを離れ、SavvisにアクセスせずにGoogleに直接アクセスします。

オフィスからのtracerouteの失敗：

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 Hops max, 52 byte packets
 1  * * *
 2  te-7-1-ur01.cambridge.ma.boston.comcast.net (68.87.36.241)  10.628 ms  7.029 ms  14.147 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  10.648 ms  13.714 ms  13.754 ms
 4  pos-2-1-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.95.29)  20.171 ms  18.774 ms  17.866 ms
 5  pos-1-6-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.87.110)  20.177 ms  18.549 ms  18.130 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  20.854 ms  19.490 ms  16.720 ms
 7  cr1-tengig-0-8-3-0.newyork.savvis.net (204.70.198.13)  15.856 ms  20.863 ms  16.717 ms
 8  cr2-tengig-0-0-2-0.chicago.savvis.net (204.70.196.242)  59.632 ms  47.147 ms  52.665 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  40.771 ms  55.918 ms  39.418 ms
10  das4-v3044.ch3.savvis.net (64.37.207.206)  45.907 ms  45.159 ms  46.643 ms
11  64.27.160.198 (64.27.160.198)  42.509 ms  39.425 ms  67.412 ms
12  * * *
13  * * *
14  * * *
15  * * *

自宅からのtracerouteの成功：

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 Hops max, 52 byte packets
 1  73.164.80.1 (73.164.80.1)  10.194 ms  13.718 ms  9.876 ms
 2  te-7-4-ur01.cambridge.ma.boston.comcast.net (68.85.160.17)  9.680 ms  6.937 ms  9.150 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  8.392 ms  7.986 ms  8.621 ms
 4  pos-2-2-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.93.185)  16.350 ms  18.983 ms  19.961 ms
 5  pos-1-4-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.86.194)  17.208 ms  16.946 ms  20.909 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  16.934 ms  18.493 ms  23.790 ms
 7  cr2-tengig-0-15-4-0.newyork.savvis.net (204.70.198.17)  26.530 ms  16.009 ms  14.924 ms
 8  cr2-pos-0-7-3-0.chicago.savvis.net (204.70.192.109)  40.031 ms  39.496 ms  39.807 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  41.065 ms  45.294 ms  41.091 ms
10  das3-v3039.ch3.savvis.net (64.37.207.186)  47.867 ms  40.606 ms  40.157 ms
11  64.27.160.194 (64.27.160.194)  50.774 ms  56.097 ms  51.147 ms
12  slashdot.org (216.34.181.45)  39.788 ms  41.741 ms  39.871 ms
internetroutingtraceroutepacket-loss
6
Jay Levitt
  1. 注意：icmp-tests（traceroute | ping）は常に正確で正確ではありません-エンドポイントとのTCP接続は成功している可能性がありますが、一部のホップ（宛先を含む）からのICMP応答をフィルタリングします。あなたは（簡単に）検出する能力がありません-それはタイムアウトまたは抑制されたエコー応答ですか
  2. 同じ物理ソースの場所は同じネットワークを意味するわけではありません（オフィスのIPは表示されませんが、68.87.3？ネットワークのどこかにある必要があると思いますが、ホームネットは73.164です。 80.）ルーティングのベースである同じAS（自律システム）（最も単純な形式で記述し、NOCの詳細を削除した場合）
  3. トラブルシューティングを行うには、icmp-tcp接続を確認し（以前と同じですが、2つのタイプの方が望ましい）、ターゲットのAS、良いソースのAS、悪いソースのASを知り、support @にチケットを配置します。 smth。 「担当領域のASYからASXへの接続の問題が検出されましたが、ASZは同じタイプの問題を示していません」の近くにあります。良いソースと悪いソースの同じASの場合、ネットワークだけで十分です。
  4. 「それは私たちではありません」NOCへの回答ではありません !!!法律ツールを入手するためにSLA）を読むか、（可能であれば）経営陣またはルート沿いの隣人に「問題のエスカレーション」を要求することができます。

HTH

2
Lazy Badger