maze13
Goto Top

Switches blocken Kommunikation innerhalb eines Subnetzes?

... oder "wie verteilen Switches ihre ARP-Broadcasts?"

Hallo zusammen,

bräuchte mal nen "virtuellen Klaps-auf-den-Hinterkopf". Ich habe auf unserer Firewall/Router eine der Netzwerkkarten mit ner IP eines neuen Subnetzes ausgestattet (Vorbereitung für ne DMZ). Wenn ich nun von einem Rechner eines anderen Subnetzes einen Ping auf diese IP mache, antwortet diese einwandfrei. Dabei muss ich erwähnen, dass der Rechner am gleichen Switch hing, der selbst keine IP-Adresse hat, also ausschließlich auf Layer 2 agiert. Der Client sendet dann wahrscheinlich über sein Standardgateway (interne IP des Standard-Netzes auf der Firewall und diese routet dann weiter ins andere Subnetz).

Wenn ich nun einen weiteren Rechner in das neue Subnetz hänge und dann einen Ping auf die IP-Adresse des Routers/Firewall im gleichen Subnetz mache, bekomme ich keine Antwort. Als Standardgateway ist auf dem Clientrechner dieselbe IP der Firewall eingetragen. Allerdings versuche ich den Ping von einem Rechner der an einem anderen Switch hängt als die Firewall (dieser ist aber physikalisch per LWL über unseren Kernswitch wiederum mit dem Switch der Firewall verbunden) und der Switch hat außerdem selbst einen IP aus dem Standardsubnetz bekommen.

Sollte der Switch nicht unabhängig von der eigenen IP-Adresse die Kommunikation zwischen unterschiedlichen Subnetzen erlauben (mit Zwischenstation Router - siehe erstes Beispiel) mindestens aber innerhalb eines Subnetzes (siehe zweites Beispiel)? Also nach dem Motto: ich möchte mich innerhalb meines Subnetzes unterhalten - lieber Switch mach mal nen ARP-Broadcast (also auf Layer 2 eigentlich unabhängig von Subnetzen, so dass die eigene IP des Switches nicht stören dürfte) auch über die anderen Switches hinweg und suche mir die MAC-Adresse von meinem Gateway? Irgendwie habe ich da glaube ich nen Denkfehler drin (grübel). Oder laufen ARP-Broadcast auch immer nur innerhalb eines IP-Subnetzes?

Wie machen das denn eigentlich außerdem Switches, wenn Rechner aus unterschiedlichen IP-Subnetzen an ihnen hängen? Oder geht das dann nicht mehr wenn ich den Switch selbst in ein bestimmtes Subnetz hänge zwecks Administration per Web-GUI? Wenn ich bspw. bestimmte VLANs definiere, muss ich die Rechner aus den unterschiedlichen VLANs doch auch in verschiedene IP-Subnetze hängen, damit Sie zumindest über den Router noch miteinander kommunizieren können.

Also, zusammengefasst: warum blocken meine Switches (alles HP 2524) anscheinend die Kommunikation zwischen 2 Karten im gleichen Subnetz? Es gibt nur das Standard-VLAN (alle Ports untagged) und die auch sonst sind die Switches laum angefasst worden wegen irgendwelchen Sonderkonfigurationen oder so.

Vielen Dank schon mal im voraus für Eure Hilfe!

Euer Maze

Content-ID: 87193

Url: https://administrator.de/forum/switches-blocken-kommunikation-innerhalb-eines-subnetzes-87193.html

Ausgedruckt am: 23.12.2024 um 14:12 Uhr

spacyfreak
spacyfreak 07.05.2008 um 22:49:31 Uhr
Goto Top
Puh das ist ja ein halber Lebenslauf!

Also die IP die der Switch selber hat ist erstmal völlig unrelevant, die dient nur zum Management des Switches. Der Switch ist ansonsten ein reines Layer2 Gerät und lernt MAC-Adressen an seinen Ports und bietet den Clients die Möglichkeit in versch.logischen Netzen zu sein per VLANs.

Da würd ich mal ganz klassisch Fehlersuche machen.
Schritt für Schritt.

Wie sieht die MAC-Adress-Table des Switches aus? Lernt er die MAC Adressen der PCs die dran hängen? Der Switch macht kein Filtering, das passiert auf Routerebene (ACLs oder Firewall-Regeln, also Layer 3). Ausnahme wäre eine transparente Firewall (Layer2), das kann man in dem Fall wohl ausschliessen. Mal andere Switchports probiert?
Ist die VLAN Config zw. Switch und Router ok?
ARP Broadcasts gehen auch nicht über Routergrenzen hinweg, es geht ja nur drum im lokalen Subnetz Mac-Adressen auf IPs mappen bzw. herauszufinden welcher Rechner oder Interface die MAC-Adresse zu einer bestimmten IP hat.
aqui
aqui 08.05.2008 um 09:44:10 Uhr
Goto Top
Dein Problem sind mit an Sicherheit grenzender Wahrscheinlichkeit inkonsistende VLANs auf den Switches !!

Dein VLAN mit dem neuen Subnetze der Firewall MUSS zwingend konsistent über einen 802.1q tagged Uplink übertragen werden.
Hier siehst du mal ein Beispiel von 2 HP Switches mit 3 VLANs wie sowas auszusehen hat mit einem tagged Uplink auf Port 24 der die Switches verbindet und damit sowas funktioniert:

vlan 1
name "DEFAULT_VLAN"
untagged 11-22
ip address 172.16.1.254 255.255.255.0
exit
vlan 10
name "Firewall"
untagged 1-8
tagged 24
exit
vlan 20
name "DMZ"
untagged 9-10
tagged 24

Wenn du das analog auch 2 Switches konfiguriertst (der 2te hat natürlich eine andere Management IP .253 z.B. !) dann sind alle 3 VLANs transparent über den Uplink verbunden.
D.h. die Ports 1 bis 8 ist ein VLAN, die Ports 9 bis 10 und die Ports von 11 bis 22. 23 und 24 sind die tagged Uplink Ports zwischen den Switches, sei es Glas oder Kupfer.

Die IP Adresse des Switches spielt keinerlei Rolle, denn sie dient ja ausschliesslich nur zum Mangement des Switches sonst nichts !!! An der IP Kommunikation hat sie keinerlei Anteil !

In jedem VLAN residiert natürlich ein unterschiedliches IP Netz das ist klar ! VLANs untereinander haben KEINE Verbindung ohne einen Layer 3 Switch ! Das macht ja dann auch deine Firewall.
Schematisch betrachtet sähe dein Netz mit den 2 Switches und VLANs dann so aus:

1a0ed6d492073acf7b0e10c540e5e115-vlan4fw

Falls du etwas Nachholbedarf in Bezug auf VLANs hast sei dir dieser Artikel empfohlen:

http://www.heise.de/netze/Fiktive-Netzwerke--/artikel/77832
Maze13
Maze13 08.05.2008 um 11:41:51 Uhr
Goto Top
Hi, vielen Dank! Das hat mir schon mal für mein Verständnis geholfen.

Der Etagenswitch, an dem der Clientrechner mit der IP des neuen Subnetzes (nennen wir es der Einfachheit halber mal 70er Netz) hängt, kennt die MAC-Adresse des Clientrechners und die MAC-Adresse der Netzwerkkarte der Firewall aus dem Standard-Subnetz (nennen wir es der Einfachheit halber mal 80er Netz). Die Netzwerkkarte/MAC-Adresse der Firewall aus dem 70er Netz kennt er an seinem Uplink-port leider nicht.

Das bedeutet also: die Kommunikation auf Layer-2-Ebene zwischen den Switches ist gestört. Ich habe unterschlagen, dass der Switch an dem die Firewall hängt KEIN HP ist, sondern ein Netgear. Den haben wir provisorisch reingehangen, weil ein HP-Switch kaputtgegangen ist. Daher wurde er bisher noch nicht gemanaged und hat auch keine IP-Adresse. Was ich als nächstes tun werde, ist diesem Switch ebenfalls eine IP zu verpassen und mir die MAC-Tabelle und VLANs darauf mal anzuschauen. Vielleicht hat es ja auch wirklich etwas mit inkonsisten VLANs zu tun, wie von aqui unten beschrieben ... Interessant ist dabei natürlich das ein Ping auf die Karte der Firewall innerhalb des 80er IP-Subnetzes reibungslos funktioniert. Deshalb haben wir uns auch nicht veranlasst gesehen, den Switch noch irgendwie weiter durchzukonfigurieren.

@aqui: warum muss denn das "default-vlan" in deinem Beispiel nicht ebenfalls über port 24 getaggt werden? eigentlich wollten wir bei uns (zunächst) überhaupt keine vlans, sondern nur neue subnetze einrichten. deshalb kann es sich eigentlich nur um einen konflikt bei den jeweiligen default-vlans auf den Switches handeln, oder? aber wie bereit oben gesagt: es ist schon komisch, dass ein ping innerhalb des standard-subnetzes funktioniert und nur nicht innerhalb des neuen ...


Gruß, Maze


edit: so, traue mich gar nicht zu sagen, was es war ... face-wink Die Netzwerkkarte auf der Firewall für das neue Subnetz hatte einen Defekt. Habe es mit einer anderen probiert und schon gings. Deshalb hat es auch geklappt, als ich das neue Netz aus dem alten Subnetz angesprochen habe: er ist dann erst über die Karte des Standardsubnetzes (80er) rein und hat dann gesagt, "klar habe ich auch ne Karte für das andere Subnetz (70er)" und alles schien okay zu sein - nur das er eben in diesem Fall nicht über das neue Subnetz direkt auf die Firewall gegangen ist.

Trotzdem vielen vielen Dank für Eure Hilfsbereitschaft. Habe wieder was gelernt!

Gruß,

Euer Maze
spacyfreak
spacyfreak 08.05.2008 um 19:09:28 Uhr
Goto Top

edit: so, traue mich gar nicht zu sagen, was
es war ... face-wink Die Netzwerkkarte auf der
Firewall für das neue Subnetz hatte
einen Defekt. Habe es mit einer anderen
probiert und schon gings.

"Ferft ten Purschen tu Poten!".
Hehe. Tja, Shit happens!
Darum heissts ja - Schritt für Schritt den OSI Layer hochschlafen beim TRoubleshooting!
aqui
aqui 10.05.2008 um 10:11:54 Uhr
Goto Top
@Maze13
Kleine Ursache große Wirkung wie so oft bei solchen Problemen...
Nochmal zu deiner Frage: ...warum muss denn das "default-vlan" in deinem Beispiel nicht ebenfalls über port 24 getaggt werden?

Gut erkannt in der Konfig und zeigt das du das Prinzip verstanden hast... face-wink
Antwort: Das ist vom Hersteller abhängig. Der IEEE 802.1q Standard sagt das das default VLAN immer untagged also OHNE die VLAN ID auf einem tagged Link übertragen wird. HP hält sich daran, so das du das default VLAN 1 nicht mit einem Tag versehen muss (es geht bei HP auch gar nicht das zu konfigurieren). D.h. das default VLAN wird auf tagged Links also immer untagged übertragen parallel zu den getaggten VLANs bei einem 802.1q Link bei HP.

Bei anderen Herstellern ist dort ggf. auch ein tagging erforderlich...Eine Regel welcher Hersteller macht was.. gibt es leider nicht, es ist wie bereits gesagt Hersteller abhängig und ein Blick ins Handbuch kann da oft nicht schaden und Frust vermeiden, wenn man verschiedene Hersteller im Netz hat...


Wenns das war bitte dann
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Maze13
Maze13 10.05.2008 um 21:04:25 Uhr
Goto Top
@aqui:

Hi, find ich super, dass Du mir das mit dem Default-VLAN noch erklärt hast. Ist gut zu wissen, dass die Hersteller den Standard unterschiedlich umsetzen. Der Netgear ist bei uns die einzige Ausnahme, sonst haben wir nur HP im Einsatz. Wahrscheinlich werde ich das so halten, dass ich den Netgear ausschließlich für das DMZ-Subnetz verwende - so habe ich auch eine physikalische Trennung von DMZ und den "normalen" internen IPs.

Gruß, Maze