私は生の IP ソケットを実行しているアプリケーションを持っています。このソケットの宛先は、「ip route add」コマンドでインストールされたルートによって制御されます。これらのルートは、ソケットの存続期間中に変更される可能性があります (たとえば、ネクストホップが変更されるため)。
簡単に言うと、 という 2 つのインターフェースがあるとします。eth0またeth1、 経由のデフォルト ルートもありますeth0。
たとえば、raw ソケットのエンドポイントは で10.10.10.10、eth1 のアドレスは です100.0.0.1。raw ソケットの有効期間中は、次の操作を実行します。
ip -f inet route delete 10.10.10.10
ip -f inet route add 100.0.0.2 dev eth1
ip -f inet route add 10.10.10.10/32 via 100.0.0.2 dev eth1
今私が見ているのは、この操作の後、トラフィックが数秒間は正常に通過しeth1、その後しばらくの間 (0.5 秒未満) エラーになり (eth0 経由)、その後再び正常になる (私が永続的に確認できる限り) ということです。
私の主な質問は次のとおりです。 - ここで何が問題になるのか説明してくれる人はいますか?ip route flush cache前述のシーケンスの後に追加してみましたが、何も起こりませんでした。現在、トラフィックがドロップされることがある理由がわかりません。ルーティング コマンドのタイミングの問題か、ルートを一瞬無効にするその他のトリガーのどちらかだと思いますが、選択肢がなくなってきています。
私は自分のrawソケットでオプションを使用しようとしましたSO_BINDTODEVICEが、残念ながらこれはあまり役に立ちませんでした。主な違いは、トラフィックがうまくいかないと送信されないことです。まったく間違ったインターフェイスを経由するからです。しかし、私が期待していたのは、errno を E_CANNOTROUTE (これは存在しません) などに設定して、これをキャッチしてパケットの送信を再試行できるようにすることでした。現在はこれが行われていませんが、このような失敗をキャッチする方法はありますか? システムとソケットを実行するアプリケーションを (ほぼ) 完全に制御できます。
私が知っている解決策の 1 つは、L3 生のソケットではなくソケットを使用することですAF_PACKET(また、ARP/ND も自分で実行します)。ただし、現時点ではまだその点については触れません。
アップデート
このルート変更の動作を変更することで、システムの動作が改善されました。ネクストホップを更新する必要がある場合は、すでにインストールされているルートを確認し、それに基づいてアクションを実行します。
- 存在しない場合は、新しいルートをインストールして削除をスキップします。
- 正確なルートがすでに存在する場合 (同じ nh、同じ dev)、何も行いません。
- このルートに別の NH が存在する場合は、この NH のみをより具体的に削除してから追加します。
これにより、ほとんどの問題は安定しましたが、実際の削除 + 追加 (新しいメカニズムの最後のケース) が発生したときに、同じことが発生することがあります (ただし、頻度ははるかに低くなります)。また、これは実際には何が間違っているのかを説明していません (単に回避するだけです)。そのため、ここで何が間違っているのか本当に知りたいので、今のところこの質問は未解決のままにしておきます。
参考までに: Centos で問題が発生しています。私が確認した限りでは、Centos4 から Centos6 (32 ビット) に移行したときに問題が発生しました。
答え1
私の理解が正しければ、パケットは常に eth1 から送信されるはずですが、問題は、eth1 上の新しいネクストホップに更新するときに、パケットが eth0 から送信されることがあるということですか? これは、削除 + 追加がアトミック操作ではないためです。
最初に追加し、その後に削除を実行してみてください。削除は、追加したばかりの新しいルートも削除されないように、具体的に行う必要があります (デバイスとネクストホップを指定する必要があります)。
答え2
eth0 経由のデフォルト ルート (または 10.10.10.10/32 をカバーする他のルート) はありますか? 最初に削除してから追加する場合、削除が発生し、削除と追加の間にパケットがデフォルト ルートから送信され、その後追加が発生してパケットが期待どおりの場所に送信され始めるという競合状態が発生する可能性があります。
これは明らかに何らかの競合状態のように思えますが、これはおそらく、あなたが言及した 2 つのルーティング操作の非アトミックな性質によるものと思われます (Law29 で述べられているように)。