ip route replace default scope global
nexthop via 11.22.33.1 dev eth0 weight 1
nexthop via 55.66.77.1 dev eth1 weight 1
（ ここにサンプル命令）
問題はこれです。接続が定期的に切断され、システムがありません。 それは数時間立つことができます、5-10分で落ちるかもしれません。 httpやtorrent'amはこれを妨害しません。 最初の場合、セッションは通常非常に短く、2番目の場合、再接続は気付かれず、結果なしになります。 しかし、sshを使用する場合はどうでしょうか？
そのようなルーティングスキームがどのように機能するかを知らない人のための説明。
デフォルトゲートウェイを通過する各接続について、使用可能なチャネルの1つが選択され、確率は重みパラメータに対応します。
次に、この接続のルートレコードがキャッシュに入力され、これらのIPアドレス間のすべてのパケットがこのルートに沿ってさらに進みます。 しばらくの間、このルートにパケットがない場合、キャッシュエントリは削除されます。 デフォルトでは、これには約5分かかります。 これには少なくとも1つの問題があります。接続が長時間データを送信しない場合、ルートキャッシュからのレコードは消去されますが、まだ接続キャッシュからではない場合があります。 デフォルトでは、nf_conntrackモジュールはtcp接続の非常に長い有効期間を公開します。 どうなるの？ 次回もパケットがこの接続を通過すると、まだ切断されていないと見なされ、新しいルートが再確立されたかのように選択されます。 運がよければ-同じです。 その後、すべてが機能し続けます。 しかし、他の場合-何も行きません。
しかし、実際には、これは小さな問題です。接続が長い間アイドル状態になっている状況がかなりあります。たとえば、sshセッションであっても、キープアライブパケットを有効にできます。 他のほとんどの実際の場合と同様。 理論的には、このような状況はftpでも可能ですが、長い間使用していません。お勧めしません。 また、ほとんどのftpクライアントはキープアライブも可能です。
さらに悪いことに、このようなスキームでは、データの連続的な流れを伴うセッションでさえも落ちました。 そして、これは理解できないことが判明しました。
急いで盲目にされた問題の単純なバイパスは、最も必要なリモートホストへの静的ルートの確立であることが判明したため、それらへのルートは厳密に1つのインターフェイスを経由しました。 しかし、それはいです。 普遍的ではなく、接続フェイルオーバーのアイデアを壊します。
これが助けになり、問題がルーティングのどこかにあると思うようになったという事実。 3時間の発掘で次のことが明らかになりました： 2.6.35までのカーネル （およびそれらに多くのシステムがあります）のルーティング設定にはパラメーターnet.ipv4.route.secret_intervalがあり、秒単位で、デフォルトは600です。それを回避するために強制的にルートキャッシュをフラッシュするオーバーフロー。 将来的には、それを放棄することが決定されました-https ://github.com/torvalds/linux/commit/3ee943728fff536edaf8f59faa58aaa1aa7366e3
したがって、10分ごとに1回、キャッシュがリセットされ、ルートが再度選択されます。 そして、私たちが望むように常にではありません。
したがって、複数のアップリンクを持つシステムでポリシールーティングを安定して動作させるには、このパラメーターを0に設定することをお勧めします。
sysctl -w net.ipv4.route.secret_interval=0
もちろん、この動作全体を排除するカーネルパッチを置くこともできますが、これは誰にとっても解決策ではありません。
後のカーネルではルートキャッシュのオーバーフローに対する追加の保護メカニズムが導入されていないため、このリセットを無効にすることは非常に安全です;既存のものは非常に信頼できると考えられていました。