у меня есть Маршрутизатор на базе 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, Switch1 (Dell PowerConnect 3548P) имеет оптоволоконное соединение с Switch2 (Dell PowerConnect 6224F), который является нашим основным коммутатором, который обрабатывает маршрутизацию между большинством VLAN. Он подключен через оптоволокно к Switch3 (Dell PowerConnect 6224).
Маршрутизация на основном коммутаторе не включена ни в одной из двух сетей VLAN (192.168.8.11 или 10.58.129.254). Причина этого в том, что наш базовый коммутатор не поддерживает маршрутизацию на основе политик, отсюда и причина, по которой этот модуль Linux выполняет маршрутизацию в этих VLAN.
Когда маршрутизатор подключен через коммутаторы с устройства Device1, я могу проверить связь с интерфейсом 192.168.8.254 на маршрутизаторе Linux, но не могу проверить связь с другим интерфейсом (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
Диагностика 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).
Итак, с устройства1 запускается ping 10.58.129.254, и с tcpdump работает на интерфейсе 192.168.8.254 маршрутизатора Linux, я вижу эхо-запросы и ответы 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 не возвращается.
Кто-нибудь знает, в чем может быть проблема? tcpdump на eth2,3 и 4 также показывает следующий вывод (я не видел его на 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.
Во второй топологии у вас есть разделенная подсеть. 192.168.8.0/24 охватывает несколько коммутаторов, которые вы указываете как уровень 3. В выходных данных switch2 у вас есть статический маршрут для this / 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, будет перенаправлен на тот же следующий переход. По крайней мере, одно из этих направлений
Чтобы это работало так, как вы предполагаете, у вас есть несколько вариантов:
Из-за невозможности решить эту проблему теперь используется другой подход, который значительно упростит настройку. Вместо того, чтобы маршрутизировать одни VLAN с помощью основного коммутатора, а другие - с помощью Linux, я теперь разрешаю базовому коммутатору выполнять всю маршрутизацию между VLAN, а списки контроля доступа выполняют разделение, которое обеспечивали бы два маршрутизатора.
Я собираюсь сделать Linux-сервер шлюзом по умолчанию для внешнего мира для всей сети с помощью iproute2 для выполнения маршрутизации на основе IP-адреса источника, чтобы правильные системы использовали правильные шлюзы.