Linux Router Problem

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.254wird und tcpdumpauf 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.

— Bryan
quelle

Wie weit kommt die Ablaufverfolgung, wenn Sie Traceroute von beiden Enden aus ausführen?

— Rory Alsop

+1 für die Traceroute. Möchten Sie auch die Routing-Tabelle von DEVICE1, ROUTER und DEVICE2 hinzufügen? Auch Ihr Problem, die Remote-Schnittstelle eines Multi-Homed-Gateways zu pingen, erinnert mich an ein bestimmtes Problem mit Linux. Ich werde es überprüfen.

— Renik

Das Gleiche gilt für die Traceroute, aber auch aus der umgekehrten Richtung. Was / wo sind Ihre Referenzen für Ihre aktuellen Ping-Ergebnisse? Haben Sie auch verschiedene Referenzpunkte in Ihrem Netzwerk in der Reihenfolge Null in ausprobiert?

— Benutzer48838

Danke für die Kommentare. Ich habe das Büro vor einigen Stunden verlassen und kann nur von hier aus auf den Router zugreifen. (Ich habe die Frage mit dem Wenigen aktualisiert, das ich im Moment hinzufügen kann). Wenn ich morgens zur Arbeit zurückkehre, füge ich der Frage den Rest der angeforderten Informationen hinzu.

— Bryan

Ich bin bereit zu wetten, dass die icmp-Anfragen und -Antworten von verschiedenen Schnittstellen kommen und gehen. Überprüfen Sie mit einem tcpdump auf jeder Schnittstelle separat.

— JimB

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:

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

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:

Konfigurieren Sie switch [123] als Layer-2-Switches, sodass 192.168.8.0/24 wieder eine einzelne Broadcast-Domäne ist.
Konfigurieren Sie separate Netzwerke für jede der Verbindungen: {Gerät1 -> Switch1, Switch1 -> Switch2 usw.}

— Murali Suriar
quelle

+1: Danke Murali. Ich kann das jetzt nicht testen, da ich letztendlich eine andere Lösung verwendet habe (gemäß meiner eigenen Antwort), aber ich werde Ihre Antwort trotzdem akzeptieren, da es so aussieht, als wäre diese statische Rouge-Route gewesen die Ursache des Problems.

— Bryan

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.

— Bryan
quelle