さて、これが私の状況です。
これはインターネット上にあります。6224 はこの図のルーターであり、物理的には Kanata に存在します。
VLAN 1697 と 3994 は両方ともインターネット サービス プロバイダーによって提供されます。これらの VLAN は単一の 1Gb イーサネット ワイヤを通じて提供されます。
Kanata ホストは 6224 に直接接続されていますが、他の 2 つのサイトはリモートです。
VLAN 3994 は単一の IP アドレス空間であるため、理論的にはそのサブネット上のホストが物理的にどこにあるかは問題になりません。
ここに問題があります。
さらにインターネットに接続された監視システムがあるため、モニターからのプローブは 1697 VLAN 上のこの図に入力されます。
インターネットから Albert または Bells Corners のホストに ping すると、損失は 0 です。接続は完璧に見えます。
Kanata のホストに ping すると、ping の 10 ~ 40% が失われます。失われる量は予測できませんが、失われる場合は、少なくとも 3 回、通常は 4 回、まれにそれ以上の ping が一度に失われます。
3994のKanataの6224にモニターを直接接続しました。
モニターが 6224 ルーティング インターフェイスを ping すると、まったく同じ損失パターンが表示されますが、リモート システムからの損失と同時には発生しません。ping 時間は約 1 ミリ秒です。
モニターが 6224 に直接接続された別のシステムに ping を実行すると、損失は 0 になります。ping 時間は約 0.1 ミリ秒で、ルーターに ping を実行する時間の 10 分の 1 です。
ここで何が起こっているのか知っている人はいますか?
アップデートにより、物事がわかりにくくなるかもしれない
起こっていることは、ISP の接続に出入りするトラフィックは正常であるということです。ルーター ブレインからスイッチング ブレイン (またはその逆) に送信されるトラフィックに問題があります。
2 つのリモート サイト間のインターネット アクセスは安定しているので、ISP を責めることはできません。問題が発生しているのは、6224 に直接接続されているホストだけです。
アップデート2
さて、痕跡をじっと見つめて長い時間を過ごした後、より具体的な症状がわかりました。
リモート サイトに送信されるブロードキャスト トラフィックだけが表示されるはずだという理論に基づいて、ISP アップリンクの VLAN 3994 で tcpdump を実行し、自分のアドレスを探しました。しかし、実際には、この VLAN の TLS を通過するシステムのインターフェイスで表示されるはずのパケットが表示されました。
それで:
何らかの理由で、6224 はシステムが TLS の遠端にあると頻繁に認識します。
正常に動作しているときにスイッチング テーブルを検査すると、エントリは次のようになります。
3994 0007.E924.F714 2/g16 Dynamic
…ポート 16 に接続されているので、これは当然です。ただし、壊れている場合は、次のようになります。
3994 0007.E924.F714 2/g22 Dynamic
誤って送信されたパケットのストリームは、私のシステムからのブロードキャストによって導かれているようです。ただし、私のシステムから 1 つのブロードキャストが送信され、3994 VLAN から TLS へのブロードキャストが 2 つ送信されています。通常は IGMP V2 メンバーシップ レポート / グループ 224.0.0.251 への参加ですが、システム上の管理チップが自分自身に対して arp を送信している場合もあります (これは、理由が不明ですが、約 2 秒ごとに実行されます)。
これは、ベルズ コーナーズまたはアルバートに私のブロードキャストを聞いて、何らかの理由でそれをエコーバックしているシステムがあることを意味します。そのため、6224 は、この Mac は実際には TLS リンクがダウンしているに違いないと判断し、それに応じてスイッチング テーブルを調整します。
この問題の説明は何か思い当たるところがありますか?
答え1
わかりました。私はこれを理解したので、ここに書きます。この特定の解決策は、エッジケースであるため、誰の役にも立たない可能性があります。
このプロバイダーとのリンクの古い歴史を遡ると、私たちはプライマリVLANに2番目のVLANを追加しました。当時、プロバイダーはこのVLANをタグ付きVLANとして接続していました。そして接続の相手側ではタグなしです。スイッチは、タグ付きとタグなしを別々の接続として扱います。
それで何が起こるかというと、Dell に接続された私のシステムが ARP ブロードキャストを送信し (このコンピュータの管理インターフェイスは、愚かな理由で 0.5 秒ごとに ARP パケットを送信します)、スイッチがリンクを介してリモート サイトに転送します。プロバイダーのスイッチは、タグなしインターフェイスでブロードキャストを受信します。そしてタグ付けされたインターフェースで私に送り返しますスイッチはこれを聞き、ブロードキャストの発信元の MAC アドレスがプロバイダーのリンク経由で実際に到達可能であると結論付けます。そのため、後続のパケットは誤った方向に送られます。
解決策は、プロバイダに構成を変更してもらい、Dell の構成と一致させることでした。一般的な接続の問題はすべて解消されました。