複数の(3)NICと関連するネットワークインターフェイスを備えたLinuxサーバーがたくさんあります。デフォルトのルートを使用する必要があるトラフィックがそうではなく、結果としてルーティングされないという、奇妙なルーティングの問題を回避しています。ルーティングテーブルは次のようになります。
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.31.96.1 0.0.0.0 UG 0 0 0 em3
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 em1
10.31.96.0 0.0.0.0 255.255.252.0 U 0 0 0 em3
10.31.96.0 0.0.0.0 255.255.252.0 U 0 0 0 em4
# ip route list
default via 10.31.96.1 dev em3 proto static
10.0.0.0/8 dev em1 proto kernel scope link src 10.0.0.100
10.31.96.0/22 dev em3 proto kernel scope link src 10.31.97.100
10.31.96.0/22 dev em4 proto kernel scope link src 10.31.96.61
10.31.96.1は、すべてのトラフィックが使用する必要がある私のデフォルトルートです(そのem#はFedoraのものです。「em」が表示されている場所ならどこでも「eth」を安全に精神的に置き換えることができます)。 ifconfigの出力は次のとおりです。
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.100 netmask 255.0.0.0 broadcast 10.255.255.255
inet6 fe80::b6b5:2fff:fe5b:9e7c prefixlen 64 scopeid 0x20<link>
ether b4:b5:2f:5b:9e:7c txqueuelen 1000 (Ethernet)
RX packets 283922868 bytes 44297545348 (41.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 538064680 bytes 108980632740 (101.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfeb60000-feb80000
em3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.31.97.100 netmask 255.255.252.0 broadcast 10.31.99.255
inet6 fe80::b6b5:2fff:fe5b:9e7e prefixlen 64 scopeid 0x20<link>
ether b4:b5:2f:5b:9e:7e txqueuelen 1000 (Ethernet)
RX packets 3733210 bytes 1042607750 (994.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1401537 bytes 114335537 (109.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfea60000-fea80000
em4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.31.96.61 netmask 255.255.252.0 broadcast 10.31.99.255
inet6 fe80::b6b5:2fff:fe5b:9e7f prefixlen 64 scopeid 0x20<link>
ether b4:b5:2f:5b:9e:7f txqueuelen 1000 (Ethernet)
RX packets 2416588 bytes 196633917 (187.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 205038 bytes 19363499 (18.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfeae0000-feb00000
em1/10.0.0.100は、同じラック内のサーバーに接続されたスイッチonlyに移動します。そのラック内のサーバー間でのみ通信するために使用されます。 em3とem4はどちらも同じサブネットにルーティングします。それらの間の唯一の違いは、em3が常に稼働しているわけではないことです(これは、現在「マスター」の役割にあるサーバーに基づくフローティングIPアドレスに関連付けられています)。基本的にすべてのトラフィックは、ローカル10.0.0.1/8サブネット上の他の何かを宛先としない限り、em3を介して送信される必要があります。その場合、em1を介して送信される必要があります。しかし、それは起こっていることではありません。 10.31.96.1/16、10.31.97.1/16、10.31.99.1/16のトラフィックはem3を通過しますが、10.31.45.1/16宛てのトラフィックはem1を通過しようとしていますが、ルーティングする方法がないためタイムアウトします効果的にトラフィック。
これは、次のコマンドでも示されています。 H 3006.619 ms!H
ただし、上記のボックスと同じネットワーク上のシステムから実行し、ネットワークインターフェイスが1つだけの場合は機能します。#tcptraceroute cuda-linux traceroute to cuda-linux(10.31.45.106)、最大30ホップ、40バイトのパケット1 10.31 .96.2(10.31.96.2)0.345 ms 0.403 ms 0.474 ms 2 cuda-linux(10.31.45.106)0.209 ms 0.208 ms 0.201 ms
Em3の10.31.45.1へのルートを追加することでこれを修正できると思いましたが、失敗しました。
# route add default gw 10.31.45.1 em3
SIOCADDRT: Network is unreachable
この時点で、他に何を試すべきか迷っています。助けて?
ルートは、最も具体的なルートから最も具体的でないルート(別名デフォルト)まで処理されます。
default via 10.31.96.1 dev em3 proto static
10.0.0.0/8 dev em1 proto kernel scope link src 10.0.0.100
10.31.96.0/22 dev em3 proto kernel scope link src 10.31.97.100
10.31.96.0/22 dev em4 proto kernel scope link src 10.31.96.61
should be going out through em3 unless its destined for something else on the local 10.0.0.1/8 subnet
が欲しいと言いました。これはまさに起こっていることです。 IPアドレス10.31.45.1
は10.0.0.0/8
内にあるため、em1を介して残されます。 10.0.0.0/8
ルートはそのアドレスに一致し、デフォルトルートよりも具体的です。アドレスが10.31.96.0/22
ルートと一致しません。したがって、em1ルートが選択されます。
あなたの本当の問題は、そのem1インターフェイスに、必要なものに対して大きすぎるサブネットマスクがあり、他のネットワークと競合していることです。 10.0.0.1-10.255.255.254の範囲のIPアドレスを宛先とするものはすべて、ローカルであるかのようにem1を使用しようとしますが、10.31.96.0/22のアドレスの例外は、em3/em4を経由して残ります。
他のネットワークと競合しないようにem1サブネット/ネットワークを修正するか、多数のルートを追加することで、解決策が得られます。
ip route add 10.31.45.0/24 via 10.31.96.1
のようなものが、あなたが望むことをするかもしれません。