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.
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.
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
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.
