Kann ich Netzwerkredundanz nur mit statischen Routingtabellen implementieren?

Kann ich Netzwerkredundanz nur mit statischen Routingtabellen implementieren?

Ich habe einen Windows 2003-Server, der über 192.168.15.10 mit einem Router bei 192.168.15.1 verbunden ist. Außerdem habe ich einen Linux-Server, der über 192.168.15.90 mit demselben Router verbunden ist. Und ich habe eine direkte Verbindung zwischen diesen beiden Maschinen über 192.168.15.11 bzw. 192.168.15.91.

Ich versuche, die Netzwerkkonfiguration so einzurichten, dass bevorzugt die direkte Verbindung verwendet wird. Wenn das aber nicht funktioniert, wird stattdessen automatisch die Verbindung über den Router verwendet.

Ich habe statische Routen mit unterschiedlichen Metriken für die Verbindungen eingerichtet, aber es scheint nicht zu funktionieren, wenn die direkte Verbindung unterbrochen ist.

Ist das, was ich erreichen möchte, tatsächlich nur mit statischem Routing möglich oder muss ich dynamisches/Rip-Routing verwenden?

=======

Ich habe die direkte Verbindung auf ein anderes Subnetz, 192.168.18.0/24, geändert, nur für den Fall, dass es dort zu Konflikten kommen sollte.

Da kein statisches Routing vorhanden war, folgte PINg dem Pfad über den Router, daher habe ich auf W2003 die folgenden persistenten Routen hinzugefügt:

C:\Documents and Settings\Administrator>route print

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 04 5a 7c 39 06 ...... Linksys LNE100TX Fast Ethernet Adapter(LNE100TX
v4) - Deterministic Network Enhancer Miniport
0x30003 ...00 13 20 5c ca 9b ...... Broadcom NetXtreme 5751 Gigabit Controller -
 Deterministic Network Enhancer Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.15.1    192.168.15.10     20
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
     192.168.15.0    255.255.255.0    192.168.15.10    192.168.15.10     20
    192.168.15.10  255.255.255.255        127.0.0.1        127.0.0.1     20
    192.168.15.90  255.255.255.255    192.168.18.91    192.168.18.11      1
   192.168.15.255  255.255.255.255    192.168.15.10    192.168.15.10     20
     192.168.18.0    255.255.255.0    192.168.18.11    192.168.18.11     20
    192.168.18.11  255.255.255.255        127.0.0.1        127.0.0.1     20
    192.168.18.91  255.255.255.255    192.168.18.11    192.168.18.11      1
   192.168.18.255  255.255.255.255    192.168.18.11    192.168.18.11     20
        224.0.0.0        240.0.0.0    192.168.15.10    192.168.15.10     20
        224.0.0.0        240.0.0.0    192.168.18.11    192.168.18.11     20
  255.255.255.255  255.255.255.255    192.168.15.10    192.168.15.10      1
  255.255.255.255  255.255.255.255    192.168.18.11    192.168.18.11      1
Default Gateway:      192.168.15.1
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
    192.168.18.91  255.255.255.255    192.168.18.11       1
    192.168.15.90  255.255.255.255    192.168.18.91       1

Und Folgendes unter Linux:

192.168.15.11/32 via 192.168.18.91 metric 1 dev eth1
192.168.15.10/32 via 192.168.18.11 metric 1 dev eth1

Wenn die direkte Verbindung aktiv ist, ist alles in Ordnung, der Verkehr fließt wie gewünscht. Wenn ich die Verbindung jedoch trenne, werden die persistenten Routen aus der aktiven Tabelle entfernt, sodass ich Folgendes habe:

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 04 5a 7c 39 06 ...... Linksys LNE100TX Fast Ethernet Adapter(LNE100TX
v4) - Deterministic Network Enhancer Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.15.1    192.168.15.10     20
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
     192.168.15.0    255.255.255.0    192.168.15.10    192.168.15.10     20
    192.168.15.10  255.255.255.255        127.0.0.1        127.0.0.1     20
   192.168.15.255  255.255.255.255    192.168.15.10    192.168.15.10     20
        224.0.0.0        240.0.0.0    192.168.15.10    192.168.15.10     20
  255.255.255.255  255.255.255.255    192.168.15.10    192.168.15.10      1
Default Gateway:      192.168.15.1
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
    192.168.18.91  255.255.255.255    192.168.18.11       1
    192.168.15.90  255.255.255.255    192.168.18.91       1

PINGs von 15.10 bis 15.90 schlagen fehl (ich sehe ARP-Nachrichten, wer 15.90 hat, sagt es 15.10) und PINGs von 15.90 bis 15.10 schlagen ebenfalls mit der Antwort „von 18.91: Host nicht verfügbar“ fehl.

Antwort1

Wo soll ich anfangen ...

Sie haben uns die Netzmaske nicht mitgeteilt – ich nehme an, diese sind alle im selben /24? Wenn ja, hat das Routing absolut nichts damit zu tun. Diese Maschinen sind alle im selben Subnetz, also wird es kein Routing geben.

Ich nehme an, Sie haben zwei Netzwerkkarten in jedem Server? Und ich nehme auch an, Sie versuchen, eine Verbindung per IP herzustellen? Wenn ja, ist die IP, die mit der unterbrochenen Verbindung verknüpft ist, unterbrochen und Sie können sie nie kontaktieren. Wenn Sie das Kabel trennen, das die Schnittstellen .11 und .91 verbindet, sind diese IP-Adressen jetzt nicht mehr erreichbar.

Wenn Sie versuchen, eine Verbindung über DNS-Namen herzustellen, erfolgt die Auflösung ordnungsgemäß?

Um diese Probleme richtig zu beheben, müssen Sie besser erklären, was Sie eigentlich tun. Außerdem wäre es sehr hilfreich, das ISO-Modell zu verstehen und die Probleme der Reihe nach zu beheben, damit Sie sich auf die Problemstelle konzentrieren können.

/edit - OK, ich sehe Ihre Bearbeitung, bei der Sie die zweiten Schnittstellen in ein anderes Subnetz gesetzt haben. Der Punkt bleibt bestehen - wenn eine Schnittstelle (mit einer IP) ausfällt, ist diese IP nicht erreichbar.

Wovor möchten Sie sich schützen? Klingt nach „einzelner NIC-Ausfall“. Nun, es gibt eine Standardmaßnahme, um sich davor zu schützen – NIC-Bonding. Stellen Sie sicher, dass Ihre NIC-Treiber eine Form davon unterstützen, gruppieren Sie die NICs und weisen Sie dem Team (auf jedem Server) eine einzelne IP zu.

verwandte Informationen