Hallo, ich hänge gerade an einen VLAN Problem unter Linux. Eventuell hat ja jemand eine Lösung. Es gibt ein untagged Netzt und 4 VLAN (1-5). Es kommen also bei eth1 packet mit TAG und welche ohne TAG an. (sie ist es zumindest aktuell) Ich habe eth1.1, eth1.2, eth1.3 .. und eth1 eingerichtet - jeweils ein anderes netzt. So jetzt das Problem, alle packet mit einen TAG kommen auch in eth1 an und dort wo sie eigentlich hingehören. Das sieht dann in dhcpd so aus: DHCPREQUEST for 192.168.2.178 from 00:01:38:34:c7:8a (WR-6640Sg) via eth1.2 DHCPREQUEST for 192.168.2.178 from 00:01:38:34:c7:8a (WR-6640Sg) via eth1 was dann natürlich ein Problem ist. gib es eine Möglichkeit packet mit einen TAG in eth1 zu filtern?
Kenn das Problem. DHCP-Broadcasts gehen an alle tagged vlans, schließlich soll der DHCP-Server ja die richtige VLAN-ID bereitstellen können, oder so lautet die Theorie. Ein "bischen" besser gehts z.B. mit dnsmask statt dhcpd, der kann wenigstens pro Interface, an das er bindet, unterschiedliche Addresspools konfiguriert haben. Hilft dir aber nicht für "eth0" ohne tag. Notbehelf (ungetestet): für jedes vlan eine Bridge anlegen, dhcp-Server an den bridges lauschen lassen. Aber auch dnsmask hat seine Probleme: er hat nur einen leases-cache, den er für alle seine Interfaces nutzt. d.H. Client connected an Interface 1 und kriegt Adresse aus Pool 1, disconnect, connect an interface 2: dnsmask findet die hwaddress im cache, und gibt fröhlich nochmal die IP aus Pool 1 heraus, die auf diesem Interface garnicht geroutet wird... Hab dann Kapituliert. Meine Lösung: zwei dhcp-server an zwei ungetaggten switch-ports. Kosten: <20 € für billigst-Netzwerkkarte + Kabel. Wesentlich billiger als die Arbeitszeit die nötig wäre, um den isc-dhcp-Server oder dnsmask umzupatchen...
DHCPinator schrieb: > DHCP-Broadcasts gehen an alle tagged vlans, schließlich soll der > DHCP-Server ja die richtige VLAN-ID bereitstellen können, oder so lautet > die Theorie. nein, so das schein nicht wirklich das Problem zu sein. Auch ICMMP (Ping) von VLAN 2 kommt an eth1 und eth1.2 an. Es wird also jedes Packet (mit oder ohne Tag) an eth1 ausgeliefert. Ich sehe nur die Lösung den Switch umzustellen, das er jedes Packet mit Tag sendet und dann eth1 ohne IP lasse. Und dann eth0.1 verwende.
Du solltest nicht tagged und untagged auf einem Interface mischen, so ist das eigentlich nicht gedacht, auch wenn einige Switche und Betriebssysteme nicht gleich explodieren wenn man das macht. Netfilter (wozu iptables gehört) kann anscheinend auch auf Ebene 2 filtern. Vielleicht findest Du da was http://de.wikipedia.org/wiki/Netfilter > Ich sehe nur die Lösung den Switch umzustellen, das er jedes Packet mit > Tag sendet und dann eth1 ohne IP lasse. Und dann eth0.1 verwende. Ja, so muss das sein.
:
Bearbeitet durch User
Christian Berger schrieb: > Du solltest nicht tagged und untagged auf einem Interface mischen, so > ist das eigentlich nicht gedacht, auch wenn einige Switche und > Betriebssysteme nicht gleich explodieren wenn man das macht. einfacher gesagt als getan. Der Cisco Switch SLM224G lässt leider nicht zu das ich VLAN1 (Default) getaggt über eine Port rausgehen lassen. Bei allen anderen VLANs geht es.
Peter II schrieb: > Der Cisco Switch SLM224G lässt leider nicht zu das ich VLAN1 (Default) > getaggt über eine Port rausgehen lassen. Bei allen anderen VLANs geht > es. Never use VLAN 1
DHCPinator schrieb: > Ein "bischen" besser gehts z.B. mit dnsmask statt dhcpd, der kann > wenigstens pro Interface, an das er bindet, unterschiedliche > Addresspools konfiguriert haben. Falsch.
Peter II schrieb: > Es gibt ein untagged Netzt und 4 VLAN (1-5). Keine gute Idee. Also tagged VLAN 1 und untagged VLAN zu verwenden. Christian Berger schrieb: > Du solltest nicht tagged und untagged auf einem Interface mischen, Bei Cisco ist das nicht weiter ungewöhnlich. So ist das der Regelbetrieb, wenn am gleichen Interface sowohl ein IP-Telefon als auch ein PC hängt.
Stell doch einfach das Native VLAN auf ein unbenutztes VLAN um, dann tagt der Switch auch VLAN1. Das ist jedoch nicht das Problem. VLANs benutzt man um Broadcast Domänen zu verkleinern. Wenn ein Broadcast eines Clients in mehreren VLANs ankommt, dann stimmt am Client bzw. dessen Portkonfiguration nicht oder irgendwie ist da eine Schleife drin. Welche IP der Client bekommt, bestimmt der DHCP anhand der IP auf dessen Interface ankommt bzw. der IP Helper Adresse. Poste doch mal den Aufbau und die Konfiguration...
Condi schrieb: > Stell doch einfach das Native VLAN auf ein unbenutztes VLAN um Yep. > Stell doch einfach das Native VLAN auf ein unbenutztes VLAN um, dann > tagt der Switch auch VLAN1. Tagged VLAN 1 würde ich aber nicht verwenden. Gibt bloss Ärger.
:
Bearbeitet durch User
A. K. schrieb: > Tagged VLAN 1 würde ich aber nicht verwenden. Gibt bloss Ärger. Das musste ich auch schon mal bei einem TP-Link-Switch feststellen. Ist diese Sonderrolle von VLAN 1 eigentlich irgendwo festgeschrieben, oder hat sich das einfach nur eingebürgert?
Peter II schrieb: > > Auch ICMMP (Ping) von VLAN 2 kommt an eth1 und eth1.2 an. Es wird also > jedes Packet (mit oder ohne Tag) an eth1 ausgeliefert. > > Ich sehe nur die Lösung den Switch umzustellen, das er jedes Packet mit > Tag sendet und dann eth1 ohne IP lasse. Und dann eth0.1 verwende. Das DARF nicht sein. Zeig mal deine Config vom Switch und von der Linuxbox Bist du sicher das dein TCP-Dump nicht einfach das Paket zweimal anzeigt? Schreibe den Dump in ein File und analysiere es mit Wireshark. Dann siehst du auch den VLAN-Tag u.s.w.
Alain S. schrieb: > Das DARF nicht sein. Zeig mal deine Config vom Switch und von der > Linuxbox > > Bist du sicher das dein TCP-Dump nicht einfach das Paket zweimal > anzeigt? Schreibe den Dump in ein File und analysiere es mit Wireshark. > Dann siehst du auch den VLAN-Tag u.s.w. ja ich bin sicher. ping 192.168.2.178 tcpdump -e -i eth1 -p -n 08:28:17.836150 74:d4:35:14:b3:b2 > 00:01:38:34:c7:8a, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4, 192.168.2.1 > 192.168.2.178: ICMP echo request, id 7129, seq 1, length 64 08:28:17.837265 00:01:38:34:c7:8a > 74:d4:35:14:b3:b2, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4, 192.168.2.178 > 192.168.2.1: ICMP echo reply, id 7129, seq 1, length 64 08:28:18.837636 74:d4:35:14:b3:b2 > 00:01:38:34:c7:8a, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4, 192.168.2.1 > 192.168.2.178: ICMP echo request, id 7129, seq 2, length 64 tcpdump -e -i eth1.2 -p -n 08:29:33.431189 74:d4:35:14:b3:b2 > 00:01:38:34:c7:8a, ethertype IPv4 (0x0800), length 98: 192.168.2.1 > 192.168.2.178: ICMP echo request, id 7289, seq 1, length 64 08:29:33.432323 00:01:38:34:c7:8a > 74:d4:35:14:b3:b2, ethertype IPv4 (0x0800), length 98: 192.168.2.178 > 192.168.2.1: ICMP echo reply, id 7289, seq 1, length 64 08:29:34.432646 74:d4:35:14:b3:b2 > 00:01:38:34:c7:8a, ethertype IPv4 (0x0800), length 98: 192.168.2.1 > 192.168.2.178: ICMP echo request, id 7289, seq 2, length 64 Packet mit einem Tag werden auch von eth1 verarbeitet. Ich habe bis jetzt keine Möglichkeit gefunden um getagged packet zu filtern. Hier noch die Konfig: 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 74:d4:35:14:b3:b2 brd ff:ff:ff:ff:ff:ff 4: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 74:d4:35:14:b3:b2 brd ff:ff:ff:ff:ff:ff 5: eth1.3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 74:d4:35:14:b3:b2 brd ff:ff:ff:ff:ff:ff cat /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD eth1.2 | 2 | eth1 eth1.3 | 3 | eth1
Jörg Wunsch schrieb: > Ist diese Sonderrolle von VLAN 1 eigentlich irgendwo festgeschrieben, > oder hat sich das einfach nur eingebürgert? IEEE 802.1Q definiert 1 als jene VLAN ID, auf die eingehende Frames ohne VLAN ID gemappt werden, wenn keine anderslautende Port-Konfiguration vorliegt. Weshalb das VLAN 1 in Switches das Default VLAN ist. Da innerhalb vom Switch keine untagged Frames vorliegen kann man ausgehende Frames einer bestimmten ID je nach Konfiguration nur entweder tagged oder untagged versenden, aber nicht beides. Prinzipiell sollte es zwar möglich sein, VLAN 1 tagged zu verwenden, indem man das Default VLAN sämtlicher Ports auf eine nicht explizit verwendete ID legt, aber ich würde das lieber lassen - damit fischt man nur nach Problemen. Für epische Details zu Bridging mit VLANs siehe http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
:
Bearbeitet durch User
A. K. schrieb: > IEEE 802.1Q definiert 1 als jene VLAN ID, auf die eingehende Frames ohne > VLAN ID gemappt werden, wenn keine anderslautende Port-Konfiguration > vorliegt. Danke, das erklärt es natürlich.
Im tcpdump des physikalischen Interface (eth1) werden die VLAN Pakete natürlich immer angezeigt, schliesslich kommen sie ja auf dem physikalischen Interface an bzw. werden über dieses versendet, wie man jedoch im tcpdump oben schön sieht mit dem VLAN Tag versehen und werden somit nicht an die höheren Netzwerk-Schichten (von eth1) weitergeleitet. Beim tcpdump des VLAN Interfaces fehlt dann der entsprechende VLAN Tag und auch nur dort wird die ICMP-Reply ohne VLAN Tag vom Kernel generiert, der dann logischerweise mit VLAN Tag versehen auf eth1 auftaucht. Also alles so wie es sein soll. Thorsten
Thorsten schrieb: > Also alles so wie es sein soll. leider nicht, denn sonst würde ja dhcpd sie nicht sehen: DHCPREQUEST for 192.168.2.178 from 00:01:38:34:c7:8a (WR-6640Sg) via eth1.2 DHCPREQUEST for 192.168.2.178 from 00:01:38:34:c7:8a (WR-6640Sg) via eth1
@Peter II: Jein. Der dhcpd benutzt - wie auch tcpdump - sogenannte RAW Sockets und diese hängen sich auf tiefster Ebene im Netzwerkstack quasi direkt an die Netzwerkkarte. Selbst wenn Du alle Pakete mit der lokalen Linux-Firewall/iptables blockiern würdest, würde sie der dhcpd immer noch sehen. Thorsten
Thorsten schrieb: > Jein. Der dhcpd benutzt - wie auch tcpdump - sogenannte RAW Sockets und > diese hängen sich auf tiefster Ebene im Netzwerkstack quasi direkt an > die Netzwerkkarte. Selbst wenn Du alle Pakete mit der lokalen > Linux-Firewall/iptables blockiern würdest, würde sie der dhcpd immer > noch sehen. dann würde mir ja im dhcpd eine Option reichen, wo alles ignoriert wird was ein VLAN-Tag hat - das habe ich jetzt auch nicht gefunden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.