我有一个基于Linux的路由器具有四个接口（每个接口都有自己的私有子网）。
当我直接连接设备时直接地（即没有交换机，只有一根跳线）到一个接口和另一个设备直接地更改为另一个，如下所示，则路由器可以完美运行。
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 层，交换机 1（Dell PowerConnect 3548P）通过光纤连接到交换机 2（Dell PowerConnect 6224F），后者是我们的核心交换机，负责处理大多数 VLAN 之间的路由。它通过光纤连接到交换机 3（Dell PowerConnect 6224）。
核心交换机上的路由未启用两个 VLAN（192.168.8.11 或 10.58.129.254）。原因是我们的核心交换机不支持基于策略的路由，因此 Linux 机器在这些 VLAN 上执行路由。
通过交换机连接路由器后，从 Device1，我可以 ping Linux 路由器上的接口 192.168.8.254，但无法 ping 另一个接口（10.58.129.254）。
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
设备 1 诊断
(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).
因此，从设备 1 运行ping 10.58.129.254，并tcpdump在 Linux 路由器的 192.168.8.254 接口上运行，我可以看到 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
但答复从未返回到设备1。
有人知道问题可能出在哪里吗？eth2、3 和 4 上的 tcpdump 也显示了以下输出（我没有在 eth0 上看到它，eth0 是上述由核心交换机路由的一个 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 的硬件地址。
答案1
在第二个拓扑中，您似乎有一个分割子网。192.168.8.0/24 跨越多个交换机，您声明这些交换机是第 3 层。在 switch2 的输出中，您有一个指向单个接口的此 /24 的静态路由：
S 192.168.8.0/24 [1/0] via 10.58.3.254, vlan 3
这意味着到达交换机 2 的流量（目的地为 192.168.8.254 或 192.168.8.11）将被转发到相同的下一跳。至少其中一个目的地
为了使它按您的预期工作，您有以下几种选择：
- 将交换机[123]配置为第 2 层交换机，这样 192.168.8.0/24 再次成为单个广播域。
- 在每个链路上配置单独的网络：{设备 1 -> 交换机 1、交换机 1 -> 交换机 2 等}
答案2
由于无法解决这个问题，现在正在使用一种不同的方法，这将大大简化配置。我现在不再通过核心交换机路由一些 VLAN，而通过 Linux 设备路由其他 VLAN，而是允许核心交换机执行 VLAN 之间的所有路由，使用 ACL 执行两个路由器提供的隔离。
我将把 Linux 机箱移至整个网络通向外界的默认网关，在 iproute2 的帮助下，执行基于源 IP 的路由，以便正确的系统使用正确的网关。