Ein Server, zwei Subnetze - aber irgendwie klappt es nicht, wie es soll...

FLiNTx

Enthusiast
Thread Starter
Mitglied seit
18.06.2001
Beiträge
1.456
Ort
Hessen
Moin,

kurz zum Aufbau: Ich habe zwei Subnetze, verbunden über einen 0815 Router...
Ein Linux-Server (CentOS 6) hat in beide Subnetze einen Netzwerkanschluss...

Subnetz A: 172.20.0.x/24
Subnetz B: 172.20.20.x/24

Ausgangspunkt:
NIC A am Server ist abgeschaltet... Ich kann sowohl aus Subnetz A als auch aus Subnetz B die NIC B des Servers erreichen...
Schalte ich NIC A ein und B aus, ist NIC B ebenfalls aus beiden Subnetzen erreichbar...

Sobald ich aber beide NICs aktiviere, ist NIC A nur noch aus Netz A erreichbar und NIC B nur noch aus Netz B... Für die Funktion ist das so auch i.O. aber ich verstehe im Moment noch nicht ganz, warum das so ist...

Die Routing-Tabelle des Servers sieht für meinen Geschmack auch i.O. aus - Subnetz A über NIC A, Subnetz B über NIC B und die default-Route über NIC A...

Was passiert jetzt mit einem Ping aus Subnetz A auf NIC B, dass der eben nicht zurück kommt? Wo ist mein Denkfehler? :coolblue:
Brauche ich eine dedizierte Route, die sagt, dass Subnetz A über das Gateway von Subnetz B erreichbar ist? Würde dann nicht aller Traffic für Subnet A über Subnet B laufen? :stupid:
Ein Default-Gateway ist für beide NICs eingetragen...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was passiert jetzt mit einem Ping aus Subnetz A auf NIC B, dass der eben nicht zurück kommt? Wo ist mein Denkfehler? :coolblue:
Brauche ich eine dedizierte Route, die sagt, dass Subnetz A über das Gateway von Subnetz B erreichbar ist? Würde dann nicht aller Traffic für Subnet A über Subnet B laufen? :stupid:
Die zusätzlichen Routen sollten eine höhere Metrik besitzen, so dass sie nur benutzt werden, falls die jeweilige Default-Route ausfällt.
(Kennt der 0815 Router an dem A hängt die Route zum Server über B?)

Der Ping aus Subnetz A trifft auf NIC B ein -> keine Route von NIC A - Subnetz A (Wie lange braucht es um die Default-Route zu entfernen und die Alternative zu nehmen?) -> Die Route über B,Router 0815 zu Subnetz A (mit höherer Metrik) fehlt.
 
hat dein Router überhaupt ein Interface, bzw eine IP in jedem der beiden Subnetze? Wenn nicht kann er ja auch nix routen. Und hat das einen näheren Sinn dass du öffentliche IPs für dein wohl privates Netz verwendest?
 
Die zusätzlichen Routen sollten eine höhere Metrik besitzen, so dass sie nur benutzt werden, falls die jeweilige Default-Route ausfällt.
(Kennt der 0815 Router an dem A hängt die Route zum Server über B?)

Der Ping aus Subnetz A trifft auf NIC B ein -> keine Route von NIC A - Subnetz A (Wie lange braucht es um die Default-Route zu entfernen und die Alternative zu nehmen?) -> Die Route über B,Router 0815 zu Subnetz A (mit höherer Metrik) fehlt.

Hab ich probiert, bringt nichts... Es geht ja auch darum, dass es nicht sauber klappt, wenn beide NICs aktiv sind - da steht das Gateway ja zur Verfügung und eine zweite, schlechtere Route wäre quasi nutzlos...

hat dein Router überhaupt ein Interface, bzw eine IP in jedem der beiden Subnetze? Wenn nicht kann er ja auch nix routen. Und hat das einen näheren Sinn dass du öffentliche IPs für dein wohl privates Netz verwendest?

Ja, logisch hat der Router in jedem Subnetz ein Interface... Das Routing dort funktioniert auch...
Hatte ja oben auch schon geschrieben, dass der Server aus beiden Netzen erreichbar ist, solange er nur mit einer Netzwerkkarte läuft... Irgendwas macht die Linux-Kiste aber anscheinend nicht wie es sein soll (oder wie ich es brauche) wenn beide NICs aktiv sind...
Und: 172.20.x.x liegt auch in einem privaten Bereich ;-)


Ich glaube ich muss morgen mal sniffern, ob der Ping am Server überhaupt ankommt (sollte aber eigentlich) und ob und wo eine eventuelle Antwort aus dem Server rauskrabbelt...
 
Zuletzt bearbeitet:
Es sollte eigentlich Funktionieren, denn bei Multihoming wird doch eigentlich genau das gleiche gemacht afaik. (Andererseits wird doch Schleifenfreiheit bei Ethernet via STP Spanning tree protocol gefordert und es gibt Sachen wie OSPF die auch schleifenfrei sind)
 
achja stimmt, ist ja 172.16.0.0 – 172.31.255.255 .
Kannst du mal deine Verkabelung skizzieren? Hängt der Server direkt mit der jeweiligen NIC im passenden Subnetz?
 
Verkabelungstechnisch ist das ziemlich simpel - da läuft ein Kabel vom ESX-Server in den Switch - Sowohl der Router als auch der betreffende Server sind virtuelle Maschinen :-)
Das Subnetz 172.20.0.0/24 ist im VLAN 1 zu Hause, 172.20.20.0/24 im VLAN 20 - Logisch sieht das ganze dann etwa so wie im Anhang beschrieben aus...

netzwerk.jpg

Mit "realen" Komponenten würde das etwa so aussehen:

netzwerk2.jpg
 
Zuletzt bearbeitet:
Liegt es an den Ethernet Broadcast Domains ?
Auf den Broadcast "Welche MAC nimmt Pakete an IP-Adresse (Subnet A)" reagieren die Rechner im Subnet B nicht.

google fand zB über proxyarp, arping im network guide
Mit tcpdump/wireshark und ping mit quelladresse und quellinterface sollte sich die Sache doch schnell herausfinden lassen
 
Liegt es an den Ethernet Broadcast Domains ?
Auf den Broadcast "Welche MAC nimmt Pakete an IP-Adresse (Subnet A)" reagieren die Rechner im Subnet B nicht.

Nee, das sollte eigentlich i.O. sein. Der Client in Subnetz a macht ja für Clients im Subnetz B garkeinen ARP Request... der Schickt das Paket direkt ans Gateway (Weil das Ziel eben in nem andren Subnetz liegt) und der macht dann wenn nötig den ARP...

Wie gesagt - sniffern steht aufm Plan, weis aber noch nicht, wann ich dazu komme... :-)
 
So, hab mal nen TCPdump auf dem Server gemacht...

Server-Interface in Subnet A ist abgeschaltet...
Dauerping vom Client in Subnetz A auf das Server-Interface in Subnet B...

Ping funktioniert und TCPdump spuckt die erwareten Pakete aus...

Aktiviere ich jetzt das Server-Interface in Subnet A, sehe ich die Pings weiterhin am Server-Interface in Subnet B ankommen - aber es gibt keine ECHO replys mehr - weder auf interface A noch auf interface B - EINE default-route (0.0.0.0 über subnetz B) ist in der Routing-Tabelle
 
Aktiviere ich jetzt das Server-Interface in Subnet A, sehe ich die Pings weiterhin am Server-Interface in Subnet B ankommen - aber es gibt keine ECHO replys mehr - weder auf interface A noch auf interface B - EINE default-route (0.0.0.0 über subnetz B) ist in der Routing-Tabelle


Ich würde erwarten, das der Server die Pakete (echo replies) für das subnet A über das interface A zurückschickt. Eine default route hat da keinen Einfluss drauf. Wobei was mich jetzt an deiner ersten Skizze irritiert ist, dass der der server im netz 172.20.0.0/24 hängt während die Router im Netz 172.20.10.0/24? hängen?
 
Ich würde erwarten, das der Server die Pakete (echo replies) für das subnet A über das interface A zurückschickt. Eine default route hat da keinen Einfluss drauf.
Das hatte ich auch so erwartet - aber wie gesagt, da passiert garnichts - und ich hab noch keine Erklärung gefunden, warum das so ist...:-(

Wobei was mich jetzt an deiner ersten Skizze irritiert ist, dass der der server im netz 172.20.0.0/24 hängt während die Router im Netz 172.20.10.0/24? hängen?

Tippfehler... die Router sitzen im 172.20.0.0/24...
 
zeig doch mal die ifconfigs und routing-tabellen der hosts

/edit : arbeitest du tatsächlich mit vlans auf dem switch ? hast du trunk-ports konfiguriert ?
 
Zuletzt bearbeitet:
zeig doch mal die ifconfigs und routing-tabellen der hosts
Mach ich heute Abend... :-)

/edit : arbeitest du tatsächlich mit vlans auf dem switch ? hast du trunk-ports konfiguriert ?
Ja und nein... Wie gesagt ist einiges von der Spielwiese virtuell - auf dem Switch gibt es zwei VLANs, trunks brauch ich allerdings nicht, da der ESX (mittlerweile) zwei NICs hat und so prima beide VLANs bedienen kann...
 
Kannst du von dem Server, welcher die beiden Interface hat, denn Hosts in beiden Netzen pingen?

Ein Ping aus Netz a an Nic b sollte aufjedenfall über Nic a wieder rausgehen, da der Server hierfür praktisch eine most specifc route hat.

Mach doch einfach mal IP Forward auf dem virtuellen Server an. Der Server muss hier ja ein wenig Routen. Das tut Linux ohne IP Forward in Standardkonfig aber nicht.

Trag zum testen mal folgendes in die Datei /etc/sysctl.conf ein:

net.ipv4.ip_forward = 1

Danach einfach sysctl -p /etc/sysctl.conf eintippen und es sollte aktiv sein.
 
Hier exemplarisch die Config eines Hosts im Netz - nichts besonderes eben:

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:

Verbindungsspezifisches DNS-Suffix: springfield
Beschreibung. . . . . . . . . . . : Broadcom 802.11g Network Adapter
Physikalische Adresse . . . . . . : 00-26-82-3F-53-AE
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::c853:cc47:7d7a:2551%10(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 172.20.0.13(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 9. Februar 2012 19:30:01
Lease läuft ab. . . . . . . . . . : Donnerstag, 9. Februar 2012 22:29:59
Standardgateway . . . . . . . . . : 172.20.0.1
DHCP-Server . . . . . . . . . . . : 172.20.0.194
DHCPv6-IAID . . . . . . . . . . . : 167782018
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-9D-E4-FE-00-26-9E-A1-1F-BA

DNS-Server . . . . . . . . . . . : 172.20.0.194
172.20.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 172.20.0.1 172.20.0.13 25
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
172.20.0.0 255.255.255.0 Auf Verbindung 172.20.0.13 281
172.20.0.13 255.255.255.255 Auf Verbindung 172.20.0.13 281
172.20.0.255 255.255.255.255 Auf Verbindung 172.20.0.13 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 172.20.0.13 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 172.20.0.13 281
===========================================================================

gepingt wird auf den Server mit diesen Einstellungen
DEVICE="eth0"
HWADDR=""
NM_CONTROLLED="yes"
ONBOOT="yes"
IPADDR=172.20.0.194
GATEWAY=172.20.0.1
NETMASK=255.255.255.0
DNS1=172.20.0.194
DNS2=172.20.0.1
DEVICE="eth1"
HWADDR="00:0C:29:E9:39:35"
NM_CONTROLLED="yes"
ONBOOT="yes"
IPADDR=172.20.20.194
NETMASK=255.255.255.0
DNS1=172.20.0.194
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh