Linuxルーターの問題

Question

私は Linuxベースのルーター 4つのインターフェース（それぞれが独自のプライベートサブネットを持つ）を持っています。

デバイスを直接（つまり、スイッチなし、パッチケーブルのみ）を1つのインターフェイスに接続し、別のデバイスを別のインターフェイスに直接接続する場合、以下のように、ルーターは完全に機能します。

 DEVICE1 192.168.8.11 ------- 192.168.8.254 ROUTER 10.58.129.254 ------- DEVICE2 10.58.129.1

以下のように、スイッチを挟んでルーターを接続すると、ルーターが機能しなくなります。

 DEVICE1 192.168.8.11 ----------- switch1 | switch2 | switch3 | 192.168.8.254 ROUTER 10.58.129.254 -------- switch3 | DEVICE2 10.58.129.1

すべてのスイッチはレイヤー3であり、Switch1（Dell PowerConnect 3548P）は、ほとんどのVLAN間のルーティングを処理するコアスイッチであるSwitch2（Dell PowerConnect 6224F）へのファイバー接続を備えています。これは、ファイバーを介してSwitch3（Dell PowerConnect 6224）に接続されます。

コアスイッチでのルーティングは、2つのVLAN（192.168.8.11または10.58.129.254）のいずれでも有効になっていません。これは、コアスイッチがポリシーベースのルーティングをサポートしていないためです。したがって、このLinuxボックスの背後にある理由はこれらのVLANでルーティングを実行するためです。

ルーターがスイッチを介して接続されている場合、Device1から、Linuxルーターのインターフェイス192.168.8.254にpingを実行できますが、他のインターフェイス（10.58.129.254）にpingを実行できません。

Switch2構成/診断

switch2#show ip route Route Codes: R - RIP Derived, O - OSPF Derived, C - Connected, S - Static B - BGP Derived, IA - OSPF Inter Area E1 - OSPF External Type 1, E2 - OSPF External Type 2 N1 - OSPF NSSA External Type 1, N2 - OSPF NSSA External Type 2 S 0.0.0.0/0 [50/0] via 10.58.3.16, vlan 3 C 10.58.3.0/24 [0/0] directly connected, vlan 3 C 10.58.4.0/24 [0/0] directly connected, vlan 4 C 10.58.5.0/24 [0/0] directly connected, vlan 5 C 10.58.9.0/24 [0/0] directly connected, vlan 9 C 10.58.10.0/24 [0/0] directly connected, vlan 10 C 10.58.11.0/24 [0/0] directly connected, vlan 11 C 10.58.12.0/24 [0/0] directly connected, vlan 12 S 10.58.64.0/24 [40/0] via 10.58.3.17, vlan 3 S 10.58.128.0/24 [40/0] via 10.58.3.254, vlan 3 S 10.58.129.0/24 [1/0] via 10.58.3.254, vlan 3 S 192.168.8.0/24 [1/0] via 10.58.3.254, vlan 3 switch2#ping 10.58.129.254 Pinging 10.58.129.254 with 64 bytes of data: ----10.58.129.254 PING Statistics---- 4 packets transmitted,0 packets received,100% packet loss round-trip (ms) min/avg/max = 0/NaN/0 switch2#ping 192.168.8.254 Pinging 192.168.8.254 with 64 bytes of data: ----192.168.8.254 PING Statistics---- 4 packets transmitted,0 packets received,100% packet loss round-trip (ms) min/avg/max = 0/NaN/0

ルーター診断

router# traceroute -d 192.168.8.11 traceroute to 192.168.8.11 (192.168.8.11), 30 Hops max, 60 byte packets 1 192.168.8.11 (192.168.8.11) 0.237 ms 0.222 ms 0.211 ms router# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.58.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.58.128.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 10.58.129.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4 router# ping 192.168.8.11 PING 192.168.8.11 (192.168.8.11) 56(84) bytes of data. 64 bytes from 192.168.8.11: icmp_seq=1 ttl=128 time=2.23 ms 64 bytes from 192.168.8.11: icmp_seq=2 ttl=128 time=0.237 ms

Device1診断

(device1)c:\>route print =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...bc 30 5b d8 41 c3 ...... Broadcom NetXtreme 57xx Gigabit Controller - Pac ket Scheduler Miniport =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.8.254 192.168.8.11 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.8.0 255.255.255.0 192.168.8.11 192.168.8.11 20 192.168.8.11 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.8.255 255.255.255.255 192.168.8.11 192.168.8.11 20 224.0.0.0 240.0.0.0 192.168.8.11 192.168.8.11 20 255.255.255.255 255.255.255.255 192.168.8.11 192.168.8.11 1 Default Gateway: 192.168.8.254 =========================================================================== Persistent Routes: None (device1)c:\>tracert -d 10.58.129.254 Tracing route to 10.58.129.254 over a maximum of 30 Hops 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. (etc. until 30 Hops).

したがって、device1からping 10.58.129.254を実行し、Linuxルーターの192.168.8.254インターフェイスでtcpdumpを実行すると、ICMPエコー要求と応答を確認できます。

router# tcpdump -i eth4 17:08:08.326221 IP 192.168.8.11 > 10.58.129.254: ICMP echo request, id 512, seq 63746, length 40 17:08:08.326240 IP 10.58.129.254 > 192.168.8.11: ICMP echo reply, id 512, seq 63746, length 40

ただし、応答がdevice1に戻ることはありません。

誰かが問題が何であるか知っていますか？ eth2、3、および4のtcpdumpは、次の出力も示します（eth0では見ていません。これはコアスイッチによってルーティングされる上記の1つVLAN）です）：

19:49:16.246286 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8000.a4:ba:db:69:74:91.8014, length 43 19:49:18.257007 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 8000.a4:ba:db:69:74:91.8014, length 43

これがスパニングツリーであることは理解していますが、これが悪いことかどうかはわかりません。これは何か手がかりを提供しますか？参考までに、上記のSTPメッセージのハードウェアアドレスは、switch3のアドレスです。

Murali Suriar · Accepted Answer

2番目のトポロジでは、サブネットが分割されているように見えます。 192.168.8.0/24は、レイヤー3であると指定する複数のスイッチにまたがっています。switch2からの出力には、単一のインターフェイスを指すこの/ 24の静的ルートがあります。

S 192.168.8.0/24 [1/0] via 10.58.3.254, vlan 3

これは、192.168.8.254または192.168.8.11のいずれかを宛先とするswitch2にヒットするトラフィックが、同じネクストホップに転送されることを意味します。それらの目的地の少なくとも1つ

これが意図したとおりに機能するためには、いくつかのオプションがあります。

Switch [123]をレイヤー2スイッチとして構成し、192.168.8.0/24が再び単一のブロードキャストドメインになるようにします。
リンクごとに個別のネットワークを構成します：{device1-> switch1、switch1-> switch2など}

Bryan · Answer

この問題を解決できないため、現在、構成を大幅に簡素化する別のアプローチが利用されています。一部のVLANをコアスイッチでルーティングし、他のVLANをLinuxボックスでルーティングする代わりに、コアスイッチがVLAN間のすべてのルーティングを実行できるようにし、ACLが2つのルーターが提供する分離を実行できるようにしました。

Linuxボックスを、iproute2を使用して、ネットワーク全体の外界へのデフォルトゲートウェイに移動し、ソースIPベースのルーティングを実行して、正しいシステムが正しいゲートウェイを使用するようにします。