このレートでの新しいフローの開始まで残り数日です オータスから。 この点に関して、このトピックに関する有用な資料の翻訳を共有したいと思います。
IPv6 ping 問題 (ICMPv6 エコー要求/エコー応答) のトラブルシューティングに関するヒントとテクニックに関する一連のブログ投稿
私は Linux (特に Fedora 31) を使用していますが、他のオペレーティング システムの ping コマンド構文もよく似ているはずであることに注意してください。
チャネル上のすべての IPv6 ノードに ping を実行する
最初の最も簡単なヒントは、リンク上のすべての IPv6 ノードに ping を実行することです。
IPv6 は、あらゆる種類の 6 対多通信にマルチキャスト アドレスを使用します。 ブロードキャスト (またはブロードキャスト) IPv6 アドレスはありません。 これは、IPv4 を IPv255.255.255.255 と区別します。IPv1122 には、「限定ブロードキャスト」アドレス XNUMX [RFCXNUMX] など、いくつかの種類のブロードキャスト アドレスがあります。
ただし、「全ノード マルチキャスト」IPv6 アドレスがあるため、それを使用してリンク上のすべての IPv6 ノードに ping を送信します。 (「ブロードキャスト」アドレスは、実際には特別に名前が付けられたマルチキャスト アドレスであり、すべてのノードを含むマルチキャスト グループです。たとえば、リンク層のイーサネット ブロードキャスト アドレスでは、「グループ」またはマルチキャスト アドレス ビットがオンになることに注意してください。 ）。
チャネルの全ノード マルチキャスト IPv6 アドレス: ff02::1. ff マルチキャストIPv6アドレスを表します。 次の 0 は、ビットが設定されていないフラグの部分です。
次へ 2 マルチキャストグループのエリアを定義します。 マルチキャスト IPv4 アドレスとは異なり、マルチキャスト IPv6 アドレスにはスコープがあります。 スコープ値は、マルチキャスト パケットの転送が許可されるネットワークの部分を示します。 パケットが指定されたスコープの境界に到達すると、ホップ カウント フィールドがゼロ以外であるかどうかに関係なく、パケットをドロップする必要があります。 もちろん、指定されたマルチキャスト グループの境界に到達する前にホップ カウントが 6 に達した場合も、即座にリセットされます。 以下は、IPvXNUMX マルチキャスト スコープの完全なリストです。
最後に、 ::1 全ノードのマルチキャスト グループを指定します。
住所について ff02::1 曖昧であることに注意してください。 ルーターやマルチホーム ホストなど、複数のインターフェイスを持つ IPv6 ホストでは、アドレス ff02::1 ICMPv6 エコー要求の送信先インターフェイスを指定したり、到着時に ICMPv6 エコー応答を受信することを期待したりできるものは何もありません。 ff02::1 は有効であり、マルチインターフェイス ノードに接続されているインターフェイスおよびチャネルのいずれでも使用できます。
したがって、リンク上のすべての IPv6 ノードに ping を実行するときは、何らかの方法でユーティリティにも通知する必要があります。 ping IPv6 の場合、使用するインターフェイス。
インターフェイスの定義 - コマンドライン オプション
すでに見たように、使用したい全ノードのマルチキャストアドレスは- ff02::1 - ICMPv6 エコー要求およびエコー応答パケットを送受信するインターフェイスに関する情報は提供されません。
では、マルチキャスト アドレス空間またはユニキャスト リンクローカル アドレス空間に使用するインターフェイスを指定するにはどうすればよいでしょうか?
最初の最も明白な方法は、使用しているアプリケーションにパラメータとしてそれを提供することです。
ユーティリティ用 ping オプションで提供します -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$この全ノード マルチキャスト ping を使用して、6 つの IPv6 ノードから応答を受信しました。 応答は、プレフィックスで始まるリンクローカル IPv6 ノード アドレスから送信されました。 fe80::/10.
その ping は、中断するまで ICMPv6 エコー要求を無期限に送信し続けることはありません。通常、送信するパケット数は -c オプションで指定します。 ただし、これにより、マルチキャスト ICMPv6 エコー要求を送信するときに、ping が複数の ICMPv6 エコー応答を受け入れて表示することもできなくなります。 代わりに、-w オプションを使用して、ICMPv1 エコー要求またはエコー応答が送受信された回数に関係なく、ping が 6 秒後に完了するように指定しました。
もう XNUMX つ注意すべき点は (DUP!) 6 番目以降の回答に出力されます。 これらのパケットは、最初に送信された個々の ICMPv6 エコー要求と同じ ICMP シーケンス値を持つため、重複応答として識別されます。 これらは、ICMPvXNUMX マルチキャスト エコー要求によって複数の個別のユニキャスト応答が返されるために表示されます。 重複の数も統計概要に示されます。
インターフェイスの定義 - ゾーン ID
インターフェイスを公開して使用するもう 6 つの方法は、IPvXNUMX アドレス パラメーターの一部として使用することです。
この例は ping 出力で確認できます。応答する IPv6 ホストのアドレスにはサフィックスも付いています。 %enp3s2たとえば、次のようになります。
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msこのインターフェースを指定する方法は、[RFC4007]「IPv6 Defined Address Architecture」で正式に説明されています。 これらは通常、オペレーティング システム インターフェイスと呼ばれますが、実際には、より一般的なもの、つまり「ゾーン」または「スコープ」を定義します。
より一般的なゾーンまたはスコープ ゾーンを持つ理由は、[RFC4007] で述べられているように、IPv6 ノードが同じチャネルに接続された複数の異なる IPv6 インターフェイスを持つことができるためです。 これらのインターフェイスは同じゾーンのメンバーです。
オペレーティング システムのゾーン内で複数のインターフェイスをグループ化できる必要があります。 現時点では、これが Linux で可能かどうか、またその方法はわかりません。
サフィックスの使用 %<zone_id>、コマンドラインオプションを削除できます -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$リンクローカルアドレス応答
この全ノードのマルチキャスト ping から、合計 6 つの一意の応答を受け取りました。
これらの応答は、ユニキャスト リンクローカル IPv6 ホスト アドレスから送信されました。 たとえば、最初の答えは次のとおりです。
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msユニキャスト リンクローカル IPv6 アドレスは、すべての IPv6 対応インターフェイス [RFC4291]、「IP バージョン 6 アドレッシング アーキテクチャ」で必要です。 その理由は、IPv6 ノードは常に自動的にユニキャスト IPv6 アドレスを持ち、少なくとも直接接続されたリンク上の他のノードと通信するために使用できるためです。 これには、リンクローカル ホスト アドレスを介した他のホスト上のアプリケーションとの通信が含まれます。
これにより、IPv6 近隣探索や OSPFv3 などのプロトコルの設計と実装が簡素化されます。 また、ホスト上のエンドユーザー アプリケーションは、チャネル上に他のサポートする IPv6 インフラストラクチャを必要とせずにチャネル経由で通信できるようになります。 接続された IPv6 ホスト間の直接通信には、接続上に IPv6 ルーターや DHCPv6 サーバーは必要ありません。
リンクローカル アドレスは 10 ビットのプレフィックスで始まります fe80、その後に 54 個のゼロ ビット、そして 64 ビットのインターフェイス識別子 (IID) が続きます。 上記の最初の回答では 2392:6213:a15b:66ff は 64 ビット IID です。
ループマルチキャスト
デフォルトでは、マルチキャスト パケットは、それを送信したノードに内部的に返されます。 これは、IPv6 と IPv4 の両方のアドレス指定で発生します。
このデフォルト動作の理由は、マルチキャスト パケットが送信されるときに、ネットワーク上のどこかだけでなく、送信ホスト自体でも実行されているリスニング ローカル マルチキャスト アプリケーションが存在する可能性があるためです。 このローカル アプリケーションはマルチキャスト パケットも受信する必要があります。
このマルチキャスト ローカル ループは ping 出力で確認できます。
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...最初の最速の応答 (0,106 ミリ秒と比較して 0,453 ミリ秒) は、インターフェイス自体に設定されたリンクローカル アドレスからのものです。 enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$ユーティリティ ping パラメータを使用してローカル マルチキャスト フィードバックを抑制する方法を提供します -L。 このフラグを使用して全ノードのマルチキャスト ping を送信すると、応答はリモート ノードに限定されます。 送信インターフェイスのリンクローカル アドレスから応答を受け取りません。
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping リンクローカル アドレス
ご想像のとおり、ユニキャスト リンクローカル アドレス自体も、アドレスに到達するためにどのインターフェイスを使用するかを示すのに十分な情報を提供しません。 全ノードのマルチキャスト ping と同様に、インターフェイスをコマンド ライン パラメーターとして指定する必要もあります。 ping リンクローカル アドレスに ping を実行する場合は、ゾーン ID とアドレスを組み合わせます。
今回使えるのは -c送受信されるパケットと応答の数を制限する ping, ユニキャスト ping を実行しているためです。
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$他の (すべての) IPv6 アドレスに ping を実行しますか?
この記事では、全ノード マルチキャスト IPv6 アドレスを使用してチャネル上のすべての IPv6 ノードに ping を実行する方法について説明しました。 ff02::1。 また、アドレス自体はこの情報を提供できないため、全ノード マルチキャスト IPv6 アドレスで使用するインターフェイスを指定する方法についても説明しました。 コマンドラインオプションのいずれかを使用しました ping、またはサフィックスを使用してインターフェイスを指定します %<zone_id>.
次に、ユニキャスト リンクローカル アドレスについて学びました。これは、全ノードのマルチキャスト ICMPv6 エコー要求に応答するために使用されるアドレスです。
また、デフォルトでマルチキャスト パケットが送信ノードに返される方法と、ユーティリティでこれを無効にする方法についても説明しました。 ping.
最後に、サフィックスを使用して単一のリンクローカル アドレスに ping を実行しました。 %<zone_id>リンクローカル アドレス自体も送信インターフェイスに関する情報を提供しないためです。
では、他のすべてのノードに ping を実行して、グローバル ユニキャスト アドレス (GUA) (つまり、インターネット上のパブリック アドレス) または固有のローカル ユニキャスト アドレス (ULA) を取得してみるのはどうでしょうか? これについては次のブログ投稿で見ていきます。
それだけです。
私たちのコースの詳細については、次の URL でご覧いただけます。.
出所： habr.com
