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?
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?
Ein Default-Gateway ist für beide NICs eingetragen...
+ Antworten
Ergebnis 1 bis 17 von 17
- 23.01.12, 11:05 #1
Ein Server, zwei Subnetze - aber irgendwie klappt es nicht, wie es soll...
Grüße, FlintX
- 24.01.12, 00:33 #2
- 24.01.12, 00:39 #3Gefreiter
- Registriert seit
- 16.01.2010
- Beiträge
- 34
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.
- 24.01.12, 00:58 #4Oberbootsmann
- Registriert seit
- 19.01.2010
- Beiträge
- 773
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?
- 24.01.12, 01:18 #5
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...
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...Geändert von FLiNTx (24.01.12 um 01:21 Uhr)
Grüße, FlintX
- 24.01.12, 03:43 #6Gefreiter
- Registriert seit
- 16.01.2010
- Beiträge
- 34
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)
- 24.01.12, 08:36 #7Oberbootsmann
- Registriert seit
- 19.01.2010
- Beiträge
- 773
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?
- 24.01.12, 11:43 #8
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.jpgGeändert von FLiNTx (24.01.12 um 11:51 Uhr)
Grüße, FlintX
- 24.01.12, 12:40 #9Gefreiter
- Registriert seit
- 16.01.2010
- Beiträge
- 34
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
- 24.01.12, 13:03 #10
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... :-)Grüße, FlintX
- 24.01.12, 17:56 #11
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-TabelleGrüße, FlintX
- 06.02.12, 15:26 #12
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?Mini
Intel Core i3-540 Dual-Core, Intel Media Series DH57JG, 4GB G.Skill DDR3 ECO Ram, Lian Li PC-Q07B
2600K
Intel Core i7-2600K, Asus P8Z68 Deluxe, 2x8GB-Kit GEIL PC3-12800 DDR3-1600 CL9, Powercolor HD6970 2048MB
Photography
- 06.02.12, 16:18 #13
Das hatte ich auch so erwartet - aber wie gesagt, da passiert garnichts - und ich hab noch keine Erklärung gefunden, warum das so ist...:-(
Tippfehler... die Router sitzen im 172.20.0.0/24...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?Grüße, FlintX
- 06.02.12, 21:12 #14
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 ?Geändert von winbLa (06.02.12 um 21:16 Uhr)
"No reason at all to play it quiet. No reason to play it any way but my way."
- 07.02.12, 10:01 #15
Mach ich heute Abend... :-)
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.../edit : arbeitest du tatsächlich mit vlans auf dem switch ? hast du trunk-ports konfiguriert ?Grüße, FlintX
- 07.02.12, 23:56 #16
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.
- 09.02.12, 21:47 #17
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 . . . . . . . : Aktiviertgepingt wird auf den Server mit diesen EinstellungenIPv4-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
================================================== =========================
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.1DEVICE="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.194Grüße, FlintX

LinkBack URL
About LinkBacks
Zitieren

