web-dev-qa-db-ja.com

ip routegetはアドレスをエニーキャストとして認識します

# ip route get 1.2.3.4
anycast 1.2.3.4 dev eth0  src 5.6.7.8

問題は、アドレスがエニーキャストであることをどのようにして知るかということです。 （これは明らかに真実です）。

更新：

エニーキャストルートとして存在：

root@hv2 ~ # ip route get 1.2.3.4
anycast 1.2.3.4 dev eth0  src 5.6.7.8 
    cache

ただし、リストには表示されません：

root@hv2 ~ # ip route list|grep 1.2.3.4|wc -l
0

しかし、それを削除して、通常の状態に戻すことは可能です（anycastはもうありません）：

root@hv2 ~ # ip route del anycast 1.2.3.4 dev eth0
root@hv2 ~ # ip route get 1.2.3.4
1.2.3.4 via 5.6.7.8 dev eth0  src 9.10.11.12 
    cache
linuxroutingipanycastiproute
2
pawel7318

iproute2 gitweb を見ると、カーネルルーティング構造に設定されているRTN_ANYCASTビットのステータスが表示されていることがわかります。これを kernel source（rtnetlink.h） と相互参照すると、次のコメントが表示されます。

    RTN_ANYCAST,            /* Accept locally as broadcast,
                               but send as unicast */

マニュアルページを確認すると、アドレスのエニーキャストステータスが構成によって決定されていることがわかります（特に、追加するアドレスを指定するときにanycastキーワードを追加します）。 man 8 ipによると：

   IFADDR := PREFIX | ADDR peer PREFIX [ broadcast ADDR ] [ anycast ADDR ]
           [ label STRING ] [ scope SCOPE-ID ]

   ...
           anycast   -   _not  implemented_  the  destinations are anycast
           addresses assigned to this Host.  They are mainly equivalent to
           local with one difference: such addresses are invalid when used
           as the source address of any packet.

マニュアルの最初の部分から、アドレスを指定すると、それがエニーキャストアドレスであることをスタックに指示できると記載されています。カーネルのソースコードをチェックせずに、エニーキャストアドレスを追加すると、エニーキャストビットは、アドレスが追加されたときに作成される対応するルーティングテーブルエントリに伝播されると思います。

Iproute2が実際にエニーキャストフラグをシステムコールに渡しているように見えるため、「実装されていない」部分が完全に正しいかどうかはわかりません。したがって、エニーキャストがカーネルでサポートされている場合は、機能するはずです。しかし、私はそれをテストしていないので、それについてはわかりません。

4
mpontillo

ip-routeのマニュアルページの「iprouteget」セクションから：

この操作は、ip routeshowと同等ではないことに注意してください。 showは既存のルートを表示します。 getはそれらを解決し、必要に応じて新しいクローンを作成します。基本的に、getはこのパスに沿ってパケットを送信することと同じです

コマンドip route show type anycastを使用して、エニーキャストルートを表示できます。

1
Jed Daniels