Ich habe einen Linux-basierten Router mit vier Schnittstellen (jede mit einem eigenen privaten Subnetz).
Wenn ich ein Gerät direkt (dh keinen Switch, nur ein Patchkabel) direkt an eine Schnittstelle und ein anderes Gerät direkt an eine andere anschließe (siehe unten), funktioniert der Router einwandfrei.
DEVICE1
192.168.8.11 ------- 192.168.8.254
ROUTER
10.58.129.254 ------- DEVICE2
10.58.129.1
Wenn ich den Router wie unten mit unseren Switches dazwischen verbinde, funktioniert der Router nicht.
DEVICE1
192.168.8.11 ----------- switch1
|
switch2
|
switch3
|
192.168.8.254
ROUTER
10.58.129.254 -------- switch3
|
DEVICE2
10.58.129.1
Alle Switches sind Layer 3, Switch1 (Dell PowerConnect 3548P) verfügt über eine Glasfaserverbindung zu Switch2 (Dell PowerConnect 6224F), unserem Kern-Switch, der das Routing zwischen den meisten VLANs übernimmt. Dies ist über Glasfaser mit Switch3 (Dell PowerConnect 6224) verbunden.
Das Routing auf dem Core-Switch ist in keinem der beiden VLANs (192.168.8.11 oder 10.58.129.254) aktiviert. Der Grund dafür ist, dass unser Core-Switch kein richtlinienbasiertes Routing unterstützt, daher der Grund für diese Linux-Box, das Routing in diesen VLANs durchzuführen.
Wenn der Router über die Switches von Gerät1 aus verbunden ist, kann ich die Schnittstelle 192.168.8.254 auf dem Linux-Router anpingen, aber nicht an die andere Schnittstelle (10.58.129.254).
Switch2 Konfiguration / Diagnose
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-Diagnose
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
Geräte1-Diagnose
(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).
Auf Gerät1, das ausgeführt ping 10.58.129.254
wird und tcpdump
auf der 192.168.8.254-Schnittstelle des Linux-Routers ausgeführt wird, kann ich ICMP-Echoanforderungen und -Antworten sehen
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
Die Antwort kehrt jedoch niemals zu device1 zurück.
Weiß jemand, was das Problem sein könnte? tcpdump auf eth2,3 & 4 zeigt auch die folgende Ausgabe an (ich habe sie auf eth0 nicht gesehen, dem einen VLAN des oben genannten, das vom Core-Switch geroutet wird):
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
Ich verstehe, dass dies ein Spanning Tree ist, aber ich weiß nicht, ob dies eine schlechte Sache ist oder nicht. Bietet dies Hinweise? Zur Information: Die Hardwareadresse in der obigen STP-Nachricht ist die von switch3.
Antworten:
In Ihrer zweiten Topologie scheint es ein geteiltes Subnetz zu geben. 192.168.8.0/24 umfasst mehrere Switches, von denen Sie angeben, dass sie Schicht 3 sind. In Ihrer Ausgabe von Switch2 haben Sie eine statische Route für diese / 24, die auf eine einzelne Schnittstelle zeigt:
Dies bedeutet, dass Datenverkehr, der auf switch2 trifft, der entweder für 192.168.8.254 oder 192.168.8.11 bestimmt ist, an denselben nächsten Hop weitergeleitet wird. Mindestens eines dieser Ziele
Damit dies so funktioniert, wie Sie es beabsichtigen, haben Sie mehrere Möglichkeiten:
quelle
Da dieses Problem nicht gelöst werden kann, wird jetzt ein anderer Ansatz verwendet, der die Konfiguration erheblich vereinfacht. Anstatt einige VLANs über den Core-Switch und andere über eine Linux-Box zu routen, erlaube ich dem Core-Switch jetzt, das gesamte Routing zwischen VLANs durchzuführen, wobei ACLs die von zwei Routern bereitgestellte Trennung durchführen.
Ich werde die Linux-Box mithilfe von iproute2 als Standard-Gateway zur Außenwelt für das gesamte Netzwerk verschieben, um Quell-IP-basiertes Routing durchzuführen, damit die richtigen Systeme die richtigen Gateways verwenden.
quelle