Dynamisches VLAN Tagging auf Layer 2

[Thomas Wildgruber]

Hi Group,

ich suche nach einer Möglichkeit, Clients sortiert nach ihrer MAC Adresse,
in ein bestimmtes VLAN zu verfrachten ohne dabei den Port am Switch
festzulegen, an welchem der Client anliegt.

Szenario:
Eine Gebäudeverkabelung sieht für Daten (PC) und Telefonie (IPT/VoIP) am
Client ausschliesslich RJ45 Anschlüsse vor. Diese Anschlüsse sind auf einen
AccessSwitch gepatchet und je nachdem, was der Anwender einsteckt, sollte
der Switch das Device in das dafür vorgesehene VLAN packen und er DHCP
sollte dabei eine IP aus dem zum VLAN gehörigem IP Range vergeben.

Diesbezüglich haben wir erstmal 802.1q in Verbindung mit RADIUS gefunden
aber diverse Dokumentationen gehen davon aus, dass das Paket bereits von
der Client NIC mit einer VLAN ID versehen, gesendet wird. Wir können jetzt
aber nicht sicherstellen, dass sämtliche NICs dieses Feature beherrschen.

Szenario:
Ein Kunde kommt mit seinem Laptop ins Haus und möchte während seiner
Anwesenheit gerne seine E-Mails abrufen können oder sonstige Dienste im
Internet nutzen. Der Plan sieht diesbezüglich vor, jede unserem System
unbekannte MAC Adresse in ein /Quarantäne/ VLAN zu packen, welches über das
Gateway zwar konventionelle Dienste (SMTP; POP3; IMAP; HTTP(S); FTP etc...)
im Internet nutzen kann, sonst aber keinerlei Zugang zum Firmen LAN hat.
Bei solch einem Client kann ich weder sicherstellen, dass die NIC die
Zuweisung einer VLAN ID überhaupt kann, noch möchte ich als Admin dass
immer erstmal einrichten...

So wäre der Wunsch, sowohl IP Adresse (aus dem für das VLAN definierte IP
Range) als auch die VLAN Zugehörigkeit automagisch anhand der MAC Adresse
zu ermitteln und zu konfigurieren.

Möglich? Welche Features sind dafür nötig? Eine kurze stichpunktartige
Vorgehensweise wäre ideal, sie muss nicht ins Detail gehen aber im Moment
habe ich erstmal das Grundprinzip noch nicht gefunden.

In der Testumgebung sind derzeit ein HP ProCurve 2650 Switch und ein
FreeRADIUS Server auf FreeBSD OS vorhanden, sowie diverse XP Laptops die
Client spielen sollen. Der RADIUS sollte im produktiven Umfeld via LDAP auf
ein Microsoft AD zugreifgen oder gleich als Microsoft RADIUS auf einem DC
laufen. Entweder um die Portsecurity über das ganze LAN auszudehnen,
mindestens aber um die WLAN Clients zu authentifzieren. Ähnlich verhält es
sich mit dem DHCP, dieser ist jedoch in der derzeitigen Teststellung noch
nicht involviert...

Bye Tom

[Patrick Cervicek]

Post by Thomas Wildgruber
Hi Group,
ich suche nach einer Möglichkeit, Clients sortiert nach ihrer MAC Adresse,
in ein bestimmtes VLAN zu verfrachten ohne dabei den Port am Switch
festzulegen, an welchem der Client anliegt.

Stichworte:
- "dynamisches Vlan"
- VMPS (Cisco, wie das bei HP heist weis ich nicht)
http://de.wikipedia.org/wiki/VMPS

Post by Thomas Wildgruber
Diesbezüglich haben wir erstmal 802.1q in Verbindung mit RADIUS gefunden
aber diverse Dokumentationen gehen davon aus, dass das Paket bereits von
der Client NIC mit einer VLAN ID versehen, gesendet wird. Wir können jetzt
aber nicht sicherstellen, dass sämtliche NICs dieses Feature beherrschen.

Gedankenfehler: Die NICs müssen kein 802.1q können, da du diesen Port
als "untagged" Vlan einstellst. 802.1q brauchst dunur, wenn du ein
Switch - Telefon - PC in Reihe anschliessen willst. Dann nutzt du nur
für das Telefon 802.1q, und für den PC halt nicht.
802.1q wird auch zum Anschluss zwischen den Switches verwendet.

Post by Thomas Wildgruber
Bei solch einem Client kann ich weder sicherstellen, dass die NIC die
Zuweisung einer VLAN ID überhaupt kann, noch möchte ich als Admin dass
immer erstmal einrichten...

s.o.

Post by Thomas Wildgruber
So wäre der Wunsch, sowohl IP Adresse (aus dem für das VLAN definierte IP
Range) als auch die VLAN Zugehörigkeit automagisch anhand der MAC Adresse
zu ermitteln und zu konfigurieren.
Möglich? Welche Features sind dafür nötig? Eine kurze stichpunktartige
Vorgehensweise wäre ideal, sie muss nicht ins Detail gehen aber im Moment
habe ich erstmal das Grundprinzip noch nicht gefunden.

s. Stichworte

[Thomas Wildgruber]

Post by Patrick Cervicek
Gedankenfehler: Die NICs müssen kein 802.1q können, da du diesen Port
als "untagged" Vlan einstellst. 802.1q brauchst dunur, wenn du ein
Switch - Telefon - PC in Reihe anschliessen willst. Dann nutzt du nur
für das Telefon 802.1q, und für den PC halt nicht.
802.1q wird auch zum Anschluss zwischen den Switches verwendet.

Wir haben das jetzt in unserer Teststellung hinbekommen und zwar nicht mit
802.1q sondern mit simpler MAC-based Authentifizierung. Anfänglich hatten
wir zwar ein Problem damit, weil wir über die FreeRADIUS Sytnax gestolpert
sind aber jetzt scheint das recht zuverlässig zu klappen.

Die MAC-based Authentifizierung hat den Vorteil, dass die ganze Sache auf
Clientseite Zero-Config ist. Hat aber auch den Nachteil, dass MAC-Address
Spoofing weiterhin eine Möglichkeit ist, die Sache zu umgehen. Das stört
uns jetzt aber nicht sonderlich, da wir hier keinen Hochsicherheitstrakt
aufbauen müssen, sondern lediglich eine Struktur in die Topologie bringen
müssen, die es u.a. auch Kunden erlaubt über das Firmen LAN auf das
Internet zuzugreifen, ohne dass der Admin jedes mal antraben muss und dem
Kunden u.U. den Zugang verwehr, weil die ein oder andere Richtlinie
(Virenpatter, Patchlevel) nicht erfüllt sind. Kommt jetzt eine MAC Adresse
daher die dem System unbekannt ist, wird sie in ein unauthorized VLAN
gepackt. Der Rest sind dann Router Policies.

Wo ich auch noch Verständnissprobleme hatte, war welche Ports am Switch
'tagged' und welche 'untagged' sein müssen. Aber nachdem wir jetzt alle
(involvierten) Ports am Switch in jedem verfügbaren VLAN auf 'tagged'
gestellt haben, klappt das wunderbar. Gibt es hierbei evtl. noch etwas, was
man berücksichtigen sollte?

Bye Tom

[Christian Dürrhauer]

On the seventh day, Thomas Wildgruber wrote...

Post by Thomas Wildgruber
Die MAC-based Authentifizierung hat den Vorteil, dass die ganze Sache auf
Clientseite Zero-Config ist. Hat aber auch den Nachteil, dass MAC-Address
Spoofing weiterhin eine Möglichkeit ist, die Sache zu umgehen. Das stört
uns jetzt aber nicht sonderlich, da wir hier keinen Hochsicherheitstrakt
aufbauen müssen, sondern lediglich eine Struktur in die Topologie bringen
müssen, die es u.a. auch Kunden erlaubt über das Firmen LAN auf das
Internet zuzugreifen, ohne dass der Admin jedes mal antraben muss und dem
Kunden u.U. den Zugang verwehr, weil die ein oder andere Richtlinie
(Virenpatter, Patchlevel) nicht erfüllt sind. Kommt jetzt eine MAC Adresse
daher die dem System unbekannt ist, wird sie in ein unauthorized VLAN
gepackt. Der Rest sind dann Router Policies.

Ich hätte obwohl es jetzt geht lieber die Variante gewählt, ein zweites
WLAN (bzw. eine zweite SSID) zu verwenden. Mittels geeigneter AP (die auch
ruhig RADIUS verwenden dürfen) hätte man über 802.1q ganz schnell ein
eigenes, ebenso null Konfig. erforderndes VLAN für Besucher. Das Problem
beim Umgang mit MAC-Adressen sehe ich weniger in dem Spoofing an sich, als
vielmehr in dem trügerischen Gefühl der Sicherheit, das bei den
Mitarbeitern aufgebaut wird. Außerdem ist es eine Fehlerquelle mehr.
--
mit freundlichen Grüßen/with kind regards
Christian Dürrhauer

The essence of all jokes, of all comedy, seems to be an honest or well
intended halfness; a non performance of that which is pretended to be
performed, at the same time that one is giving loud pledges of performance.
The balking of the intellect, is comedy and it announces itself in the
pleasant spasms we call laughter.
Ralph Waldo Emerson

[Thomas Wildgruber]

Post by Christian Dürrhauer
Ich hätte obwohl es jetzt geht lieber die Variante gewählt, ein zweites
WLAN (bzw. eine zweite SSID) zu verwenden. Mittels geeigneter AP (die auch
ruhig RADIUS verwenden dürfen) hätte man über 802.1q ganz schnell ein
eigenes, ebenso null Konfig. erforderndes VLAN für Besucher.

Es geht dabei nicht um WLAN Clients bzw. APs, sondern um eine
Strukturierung der im Gebäude vorhandenen RJ45 Dosen. Hier sollte der
Switch (bzw. der RADIUS) nach der MAC Adresse erkennen, ob es ein
IP-Telefon, ein PC oder ein unbekanntes Gerät ist und der RADIUS Server
(bzw. der Switch) sollte dies dann in das entsprechende VLAN packen.

Bezgl. Kunden WLAN glauben wir ganz pragmatisch vorzugehen, in dem man
einen AP (oder zwei, je nach Grösse der Funkzelle) quasi als HotSpot
einrichtet (WPA Verschlüsselung mit bekannter SSID und bekannter Passphrase
und das ganze dann nur tagsüber aktiv) und diese ausschliesslich über das
Gateway nur ins Internet routet. Genauso wie bei dem unauthorized VLAN
auch... (Für den fall. dass jemand sein Laptop direkt an einer Dose
anstöpselt)

Post by Christian Dürrhauer
Das Problem
beim Umgang mit MAC-Adressen sehe ich weniger in dem Spoofing an sich, als
vielmehr in dem trügerischen Gefühl der Sicherheit, das bei den
Mitarbeitern aufgebaut wird.

Welches Gefühl der Sicherheit? Für die Mitarbeiter ist das ganze
transparent, die bekommen von all dem ja gar nichts mit -> Jeder ist
zufrieden und keiner weis warum ;-)

Post by Christian Dürrhauer
Außerdem ist es eine Fehlerquelle mehr.

Das wird aber bei jeder verwendeten Art von Portsecurity so sein. Egal ob
jetzt MAC-based, WEB-based, 802.1q oder was auch immer zum Einsatz kommt.
Eines davon wird es werden und das ist IMHO eine zusätzliche Fehlerquelle,
isn't it?

Bye Tom

[Andre Beck]

Post by Thomas Wildgruber
ich suche nach einer Möglichkeit, Clients sortiert nach ihrer MAC Adresse,
in ein bestimmtes VLAN zu verfrachten ohne dabei den Port am Switch
festzulegen, an welchem der Client anliegt.

Die generische Antwort darauf ist 802.1X. Leider ist die clientseitig
invasiv, da ein Supplicant benötigt wird, aber irgendwas ist ja immer.

Post by Thomas Wildgruber
Eine Gebäudeverkabelung sieht für Daten (PC) und Telefonie (IPT/VoIP) am
Client ausschliesslich RJ45 Anschlüsse vor. Diese Anschlüsse sind auf einen
AccessSwitch gepatchet und je nachdem, was der Anwender einsteckt, sollte
der Switch das Device in das dafür vorgesehene VLAN packen und er DHCP
sollte dabei eine IP aus dem zum VLAN gehörigem IP Range vergeben.

Für den Sonderfall, dass es nur um Voice vs. Data geht, kommt man auch
um .1X herum, wenn der Hersteller eine Alternative bietet. Cisco etwa
erkennt seine eigenen Phones über CDP und sorgt für das richtige VLAN.
Das ist allerings nicht sicher, nur pragmatisch.

Post by Thomas Wildgruber
Diesbezüglich haben wir erstmal 802.1q in Verbindung mit RADIUS gefunden
aber diverse Dokumentationen gehen davon aus, dass das Paket bereits von
der Client NIC mit einer VLAN ID versehen, gesendet wird. Wir können jetzt
aber nicht sicherstellen, dass sämtliche NICs dieses Feature beherrschen.

RADIUS ergibt nur Sinn, wenn 802.1X mit im Spiel ist. Der Switch wird
dabei zum Authenticator, der nach Anstecken des Clients mit dem darauf
laufenden Supplicant zunächst nur EAPOL spricht. Der Client authentisiert
sich und der RADIUS sagt dem Switch, in welches VLAN der Port geschoben
werden soll, bevor das erste echte Datenframe akzeptiert wird.

Haken: Welches Phone kann .1X? Welches Altgerät? Welcher Drucker?

Post by Thomas Wildgruber
Ein Kunde kommt mit seinem Laptop ins Haus und möchte während seiner
Anwesenheit gerne seine E-Mails abrufen können oder sonstige Dienste im
Internet nutzen. Der Plan sieht diesbezüglich vor, jede unserem System
unbekannte MAC Adresse in ein /Quarantäne/ VLAN zu packen, welches über das
Gateway zwar konventionelle Dienste (SMTP; POP3; IMAP; HTTP(S); FTP etc...)
im Internet nutzen kann, sonst aber keinerlei Zugang zum Firmen LAN hat.
Bei solch einem Client kann ich weder sicherstellen, dass die NIC die
Zuweisung einer VLAN ID überhaupt kann, noch möchte ich als Admin dass
immer erstmal einrichten...

Der Rückfall in ein Quarantäne-VLAN ist durchaus machbar, wenn die .1X-
Anmeldung fehlschlägt. Kommt auf den Switch an, ob er das kann und wie
flexibel er dabei ist.

Post by Thomas Wildgruber
So wäre der Wunsch, sowohl IP Adresse (aus dem für das VLAN definierte IP
Range) als auch die VLAN Zugehörigkeit automagisch anhand der MAC Adresse
zu ermitteln und zu konfigurieren.

MAC wird an den RADIUS geschickt und könnte dort auch als alleiniges
Authentisierkriterium dienen. Würde ich aber nicht wollen, ist lang-
fristig ein Managementalptraum. In reinen Windows-Shops (2000+) ist
.1X relativ leicht auszurollen, da man alles beisammen hat (AD mit
PKI und AD-integrierter RADIUS, Maschinenzertifikate etc), kompliziert
wird es, wenn andere OSe und Gerätschaften im freien Accessbereich
dazukommen.

Post by Thomas Wildgruber
Möglich? Welche Features sind dafür nötig? Eine kurze stichpunktartige
Vorgehensweise wäre ideal, sie muss nicht ins Detail gehen aber im Moment
habe ich erstmal das Grundprinzip noch nicht gefunden.

Siehe 802.1X, EAPOL, Supplicant vs. Authenticator vs. Auth Server. Muss
man mal durchsteigen, lichtet sich dann aber.

Post by Thomas Wildgruber
In der Testumgebung sind derzeit ein HP ProCurve 2650 Switch und ein

Ich weiß zwar, dass der auf dem Papier .1X kann, aber nichts genaues über
die Qualität der Implementation. ProCurve ist leider bisweilen überraschend
unfexibel.

Post by Thomas Wildgruber
FreeRADIUS Server auf FreeBSD OS vorhanden,

Das ist im Prinzip gut für detailliertes Debuggen, weil man genau zu-
sehen kann, was passiert. FreeRADIUS ist aber bei EAP-basierten Ver-
fahren eher wacklig, sei froh wenn Dir PEAP stabil gelingt...

Post by Thomas Wildgruber
sowie diverse XP Laptops die Client spielen sollen.

Klingt gut.

Post by Thomas Wildgruber
Der RADIUS sollte im produktiven Umfeld via LDAP auf
ein Microsoft AD zugreifgen oder gleich als Microsoft RADIUS auf einem DC
laufen.

Denke über letzteres nach, es ist schlicht einfacher und die Software
ist eh dabei. Allerdings würde ich dafür ein 2003er AD und IAS empfehlen,
die cryptohaltigen Dinge (PEAP, EAP-TLS etc) sind dort AFAIR erst komplett.

Post by Thomas Wildgruber
Entweder um die Portsecurity über das ganze LAN auszudehnen,
mindestens aber um die WLAN Clients zu authentifzieren.

WLAN ist dann eigentlich das gleiche. Dort wird 802.1X nur häufiger
verwendet als auf Switches und es geht um SSIDs statt um VLANs (wobei
im Enterprise WLAN die SSIDs auf VLANs mappen). Die Sache ist dort
trotzdem einfacher, weil der Client immer die Entscheidung treffen
muss, mit welcher SSID er assoziiert und der AP nur noch festzulegen
hat, ob er das zulässt.

Post by Thomas Wildgruber
Ähnlich verhält es sich mit dem DHCP, dieser ist jedoch in der
derzeitigen Teststellung noch nicht involviert...

DHCP kommt erst nach EAPOL und ist dann schon in der richtigen
Broadcastdomain, um die erwartungsgemäße Antwort zu erhalten. Jeden-
falls wenn die Implementation was taugt - drangestrickte Supplicants
kommen u.U. zu spät und das Interface dann mit APIPA hoch...

[Thomas Wildgruber]

Post by Andre Beck

Post by Thomas Wildgruber
ich suche nach einer Möglichkeit, Clients sortiert nach ihrer MAC Adresse,
in ein bestimmtes VLAN zu verfrachten ohne dabei den Port am Switch
festzulegen, an welchem der Client anliegt.

Die generische Antwort darauf ist 802.1X. Leider ist die clientseitig
invasiv, da ein Supplicant benötigt wird, aber irgendwas ist ja immer[...]

Wir haben das hier jetzt in der Testumgebung auch ohne 802.1X hinbekommen.
Der Switch übermittelt dabei via ChapRADIUS die MAC Adresse an den
RADIUS-Server, welcher dem Switch das zugehörige VLAN mitteilt. Als
Anmeldeinformationen werden dabei beim RADIUS die MAC Adresse sowohl als
Username als auch als Paswort hinterlegt. Das hat den Vorteil, dass
clientseitig keinerlei Konfiguration nötig ist.

Post by Andre Beck

Post by Thomas Wildgruber
Ein Kunde kommt mit seinem Laptop ins Haus und möchte während seiner
Anwesenheit gerne seine E-Mails abrufen können oder sonstige Dienste im
Internet nutzen. Der Plan sieht diesbezüglich vor, jede unserem System
unbekannte MAC Adresse in ein /Quarantäne/ VLAN zu packen, welches über das
Gateway zwar konventionelle Dienste (SMTP; POP3; IMAP; HTTP(S); FTP etc...)
im Internet nutzen kann, sonst aber keinerlei Zugang zum Firmen LAN hat.
Bei solch einem Client kann ich weder sicherstellen, dass die NIC die
Zuweisung einer VLAN ID überhaupt kann, noch möchte ich als Admin dass
immer erstmal einrichten...

Der Rückfall in ein Quarantäne-VLAN ist durchaus machbar, wenn die .1X-
Anmeldung fehlschlägt. Kommt auf den Switch an, ob er das kann und wie
flexibel er dabei ist.

Der Switch kann nicht authentifizierte Clients in ein Quarantäne VLAN
stecken. Funktioniert zumindest hier in der Testumgebung schon mal.

Post by Andre Beck

Post by Thomas Wildgruber
So wäre der Wunsch, sowohl IP Adresse (aus dem für das VLAN definierte IP
Range) als auch die VLAN Zugehörigkeit automagisch anhand der MAC Adresse
zu ermitteln und zu konfigurieren.

MAC wird an den RADIUS geschickt und könnte dort auch als alleiniges
Authentisierkriterium dienen. Würde ich aber nicht wollen, ist lang-
fristig ein Managementalptraum.

Warum? Wo siehst du Probleme aufkommen?

Post by Andre Beck
In reinen Windows-Shops (2000+) ist
.1X relativ leicht auszurollen, da man alles beisammen hat (AD mit
PKI und AD-integrierter RADIUS, Maschinenzertifikate etc), kompliziert
wird es, wenn andere OSe und Gerätschaften im freien Accessbereich
dazukommen.

Das wird schierig werden, eine native Windows AD Umgebung wird nicht
möglich sein. Wir haben zwar einen Schwerpunkt auf Windows aber es werden
auch noch andere Plattformen (MAC OSX; Linux; Unix; Solaris etc.) zum
Einsatz kommen.

Post by Andre Beck

Post by Thomas Wildgruber
[...]In der Testumgebung sind derzeit ein HP ProCurve 2650 Switch und ein

Ich weiß zwar, dass der auf dem Papier .1X kann, aber nichts genaues über
die Qualität der Implementation. ProCurve ist leider bisweilen überraschend
unfexibel[...]

So wie wir es derzeit am Laufen haben, würde uns es schon reichen. Wir
versuchen jetzt die Testumgebung hier irgendwie in den produktiven bereich
zu integrieren, damit wir eine Aussage über die Stabilität des ganzen
Setups treffen können...

Post by Andre Beck

Post by Thomas Wildgruber
[...]Ähnlich verhält es sich mit dem DHCP, dieser ist jedoch in der
derzeitigen Teststellung noch nicht involviert...

DHCP kommt erst nach EAPOL und ist dann schon in der richtigen
Broadcastdomain, um die erwartungsgemäße Antwort zu erhalten. Jeden-
falls wenn die Implementation was taugt - drangestrickte Supplicants
kommen u.U. zu spät und das Interface dann mit APIPA hoch...

...und da sehe ich meine grösste Sorge. Es muss nicht mal so lange dauern,
dass das Interface mit einer APIPA Adresse hochfährt, mir macht schon das
Anmeldescript Sorgen. Kann der User sich am System schon anmelden, noch
bevor der ganze RADIUS Kram abgeschlossen ist, läuft das Anmeldescripr u.U.
nicht ab. Vor allem XP mit seinem /genialen/[tm] Startupoptimizing ist hier
nicht gerade hilfreich. Vor allem im WLAN Bereich habe ich hier schon so
meine liebe Mühe und Not gehabt... Ich denke das wird bei der RADIUS Sache
ähnlich sein. Wobei es helfen könnte, dass nicht der Username vom RADIUS
ausgewertet wird sondern die MAC Adresse, die könnte möglicherweise schon
früher übetragen werden.

Auch kann ich das ganze jetzt nicht unter Last testen. Mit den paar
Clients, die ich zum testen hzabe, wird wohl der Switch und auch der RADIUS
kein Problem haben aber wenn dann mal 30, 40 Clients am Switch hängen - und
die dann alle auch noch mehr oder weniger gleichzeitig daherkommen....

Bye Tom

[Andre Beck]

Post by Thomas Wildgruber

Post by Andre Beck
Die generische Antwort darauf ist 802.1X. Leider ist die clientseitig
invasiv, da ein Supplicant benötigt wird, aber irgendwas ist ja immer[...]

Wir haben das hier jetzt in der Testumgebung auch ohne 802.1X hinbekommen.
Der Switch übermittelt dabei via ChapRADIUS die MAC Adresse an den
RADIUS-Server, welcher dem Switch das zugehörige VLAN mitteilt. Als
Anmeldeinformationen werden dabei beim RADIUS die MAC Adresse sowohl als
Username als auch als Paswort hinterlegt. Das hat den Vorteil, dass
clientseitig keinerlei Konfiguration nötig ist.

Nettes Feature, sozusagen "supplicant free .1X". Was mich hier am ehesten
beunruhigt ist die Frage, was für Frames den Vorgang auslösen und wie lange
das dann dauert, bis der Port im richtigen VLAN transparent wird. Bei .1X
ist dem Client (theoretisch, bekloppte Implementationen beiseite) klar,
dass er Datenframes nicht zu schicken braucht, bevor EAPOL nicht komplett
durchgelaufen ist. Hier gibt's einfach eine Weile keine Antworten. Gut,
das ist sowieso immer so, RSTP und LACP blockieren den Port auch schon
für einige Sekunden, die Frage ist halt, wo wird es zu viel (STP ohne
Portfast mit seinen 30s ist bekanntlich definitiv zu viel).

Wenn man es nicht sicher braucht vielleicht die beste Kompromisslösung.

Post by Thomas Wildgruber

Post by Andre Beck
MAC wird an den RADIUS geschickt und könnte dort auch als alleiniges
Authentisierkriterium dienen. Würde ich aber nicht wollen, ist lang-
fristig ein Managementalptraum.

Warum? Wo siehst du Probleme aufkommen?

Abgänge müssen gelegentlich aufgeräumt werden, Neuzugänge sind einzu-
pflegen. Auf Dauer nervt das, wird vernachlässigt und genau immer dann,
wenn mal dringend eine Änderung gemacht werden muss, ist derjenige, der
sich damit auskennt, gerade nicht greifbar.

Das Quarantäne-VLAN entspannt die Sache aber.

Post by Thomas Wildgruber

Post by Andre Beck
In reinen Windows-Shops (2000+) ist
.1X relativ leicht auszurollen, da man alles beisammen hat (AD mit
PKI und AD-integrierter RADIUS, Maschinenzertifikate etc), kompliziert
wird es, wenn andere OSe und Gerätschaften im freien Accessbereich
dazukommen.

Das wird schierig werden, eine native Windows AD Umgebung wird nicht
möglich sein. Wir haben zwar einen Schwerpunkt auf Windows aber es werden
auch noch andere Plattformen (MAC OSX; Linux; Unix; Solaris etc.) zum
Einsatz kommen.

Solaris und andere Unices im freien Access? Sowas ist heute selten ;)

MacOS X bringt IIRC einen Supplicant mit, für Linux gibt es welche,
das sollte also noch gehen - wenn die PEAP können, auch gegen IAS.

Post by Thomas Wildgruber

Post by Andre Beck

Post by Thomas Wildgruber
[...]In der Testumgebung sind derzeit ein HP ProCurve 2650 Switch und ein

Ich weiß zwar, dass der auf dem Papier .1X kann, aber nichts genaues über
die Qualität der Implementation. ProCurve ist leider bisweilen überraschend
unfexibel[...]

So wie wir es derzeit am Laufen haben, würde uns es schon reichen. Wir
versuchen jetzt die Testumgebung hier irgendwie in den produktiven bereich
zu integrieren, damit wir eine Aussage über die Stabilität des ganzen
Setups treffen können...

Wenn die Erfahrungen da sind, wäre ich an einem kurzen Feedback hier
in der Gruppe interessiert.

Post by Thomas Wildgruber

Post by Andre Beck
DHCP kommt erst nach EAPOL und ist dann schon in der richtigen
Broadcastdomain, um die erwartungsgemäße Antwort zu erhalten. Jeden-
falls wenn die Implementation was taugt - drangestrickte Supplicants
kommen u.U. zu spät und das Interface dann mit APIPA hoch...

...und da sehe ich meine grösste Sorge. Es muss nicht mal so lange dauern,
dass das Interface mit einer APIPA Adresse hochfährt, mir macht schon das
Anmeldescript Sorgen.

Naja, das Script sollte doch erst laufen, wenn die Domänen-Authentifi-
zierung durch ist, und die wiederum will das Interface IP-mäßig oben
haben. Aber ja, das ist vom Timing her kritisch - siehe oben.

Post by Thomas Wildgruber
Kann der User sich am System schon anmelden, noch
bevor der ganze RADIUS Kram abgeschlossen ist, läuft das Anmeldescripr u.U.
nicht ab. Vor allem XP mit seinem /genialen/[tm] Startupoptimizing ist hier
nicht gerade hilfreich. Vor allem im WLAN Bereich habe ich hier schon so
meine liebe Mühe und Not gehabt...

Da ist WLAN allerdings etwas Besonderes, denn die WLAN-Assoziation läuft
u.U. erst nach der Anmeldung und aktiver Rückfrage beim Nutzer durch und
ist zudem oft sehr träge.

Post by Thomas Wildgruber
Ich denke das wird bei der RADIUS Sache
ähnlich sein. Wobei es helfen könnte, dass nicht der Username vom RADIUS
ausgewertet wird sondern die MAC Adresse, die könnte möglicherweise schon
früher übetragen werden.

Im Prinzip sollte der erste DHCP Discover Broadcast den Vorgang anstoßen,
wenn das einige Sekunden nach Link Up passiert sind RSTP und LACP bis
dahin auch zufrieden und der Switchport reagiert sofort. Die RADIUS-
Interaktion bis zum Verschieben des Switchports in das korrekte Access-
VLAN sollte dann maximal eine Sekunde dauern, ich erwarte eher weniger,
gerade mit CHAP (keine aufwendige Crypto). Das macht Windows eigentlich
unproblematisch mit.

Post by Thomas Wildgruber
Auch kann ich das ganze jetzt nicht unter Last testen. Mit den paar
Clients, die ich zum testen hzabe, wird wohl der Switch und auch der RADIUS
kein Problem haben aber wenn dann mal 30, 40 Clients am Switch hängen - und
die dann alle auch noch mehr oder weniger gleichzeitig daherkommen....

FreeRADIUS habe ich schon wegtreten sehen, wenn zu viele Requests auf
einmal ankamen. 100% CPU und keine Antworten mehr. Aber ich meine, das
ist in aktuellen Versionen gefixt. An sich ist das aber alles kein Akt,
die Sache sollte weniger als eine Sekunde dauern und ziemlich gut
skalieren, wenn nicht irgendwas rattig ist.

[Thomas Wildgruber]

Post by Andre Beck
Nettes Feature, sozusagen "supplicant free .1X". Was mich hier am ehesten
beunruhigt ist die Frage, was für Frames den Vorgang auslösen und wie lange
das dann dauert, bis der Port im richtigen VLAN transparent wird.

Ich habe das jetzt mal versucht heraus zu sniffen aber so richtig kann ich
den Frame jetzt nicht identifizieren, der das ganze auslöst. Ich sniffe den
Traffic mit Wireshark auf einem Notebook mit, während ich es am Switch
anstecke. Das erste was aufschlägt sind meißtens Broadcasts, recht
zuverlässig ist eigentlich immer ein LLDP Paket vom HP ganz vorne mit
dabei[*] aber das initiale Paket, welches den Vorgang auslöst vermag ich
entweder mit meinem Wireshark Setup nicht zu identifizieren oder es ist
wirklich immer etwas anderes.

[*] Hinter deren Sinn ich bis jetzt auch nicht ganz gekommen bin.

Post by Andre Beck
Bei .1X
ist dem Client (theoretisch, bekloppte Implementationen beiseite) klar,
dass er Datenframes nicht zu schicken braucht, bevor EAPOL nicht komplett
durchgelaufen ist. Hier gibt's einfach eine Weile keine Antworten. Gut,
das ist sowieso immer so, RSTP und LACP blockieren den Port auch schon
für einige Sekunden, die Frage ist halt, wo wird es zu viel (STP ohne
Portfast mit seinen 30s ist bekanntlich definitiv zu viel).

RSTP, LACP und STP nutzen wir hier nicht. Wir haben das Switch Setup noch
nicht redundant ausgelegt. Ob wir es überhaupt machen bleibt noch offen.
Das kann die GL dann entscheiden ob sie mit dem Risiko leben wollen. Aber
um ehrlich zu sein, wir haben hier im Altbau bislang auch nur einen Core
Switch (HP 5308XL) und der ist noch nie augefallen. Deshalb hätte ich im
Neubau auch gerne einen HP 5308XL, denn könnten wir uns für beide Häuser
ein Chassie und die wichtigsten Module als Spareparts zulegen aber der 53xx
läuft demnächst aus... Aber stimmt schon, der Core wenn ausfällt wird es
eng ;-)

Post by Andre Beck
Wenn man es nicht sicher braucht vielleicht die beste Kompromisslösung.

Nein im Wired Segment steht Sicherheit nicht im Vordergrund, Strukturierung
ist das Ziel. Wenn es das ein oder andere Security Feature mitbringt ist
das auch okay. Wenn einer im Haus anfängt MAC Adressen zu spoofen, bitte
schön -> Der fliegt früher oder später eh auf und ich wüsste nicht, welche
Veranlassung er dazu überhaupt haben sollte. Geht doch eh alles, was sie
brauchen.

Post by Andre Beck
Solaris und andere Unices im freien Access? Sowas ist heute selten ;)

<seufz> Was Entwickler alles brauchen können, denen fällt jeden zweiten Tag
was Neues ein ;-)

Post by Andre Beck
MacOS X bringt IIRC einen Supplicant mit, für Linux gibt es welche,
das sollte also noch gehen - wenn die PEAP können, auch gegen IAS.

Was bis jetzt aufgefallen ist, dass eine IP Camera nicht mehr funktioniert.
Die haben wir hier auch grad zum Testen rumliegen gehabt und mit in das
Setup aufgenommen. *Warum* die aber nicht mehr funktioniert können wir
jetzt abschliessend noch nicht erklären. Das einzige was uns bislang
aufgefallen ist, dass die Camera 802.1Q nicht versteht. Wir rätseln hier
grade rum, ob das von den Devices unterstützt werden muss, da wir alle im
Test involvierten Switch Ports getagget haben -> untagget konnten wir wir
sonst die Ports nicht mehreren VLANs zuweisen. Die Spec von 802.1Q sagt
aus, dass dem Ethernet Frame vier weitere Bytes mit dem VLAN Identifier
etc. hinzugefügt werden. Wir konnten das mit Wireshark zwar nicht
verifizieren, da sämtliche Versuche das Interface in den Sniffer Mode zu
versetzen fehl geschlagen sind aber die Manuals der Interfaces hatten
mehrere Workaround parat, um diese vier Bytes bis an den Sniffer weiter zu
leiten - funktioniert hat zwar keiner aber alleine die Tatsache, dass diese
Workarounds existieren, beweist wohl schon, dass diese vier Bytes bis zum
Client weitergeleitet werden. Warum der das aber überhaupt wissen will habe
ich bis jetzt noch nicht verstanden. Es reicht doch schon aus, wenn der
Switch den Port in das passende VLAN packt - isn't it?

Post by Andre Beck
[...]Wenn die Erfahrungen da sind, wäre ich an einem kurzen Feedback hier
in der Gruppe interessiert.

Mach ich. Im Moment haben wir hier unser EDV Büro in das Testumfeld mit
aufgenommen, dass wären ein Drucker, unsere sechs PCs (jeder hat zwei;),
drei Laptops (zum /Spielen/) und die besagte IP-Camera. Läuft das diese und
nächste Woche störungsfrei bzw. wir haben bis dahin die letzten Probleme
beiseite geräumt, dann verbauen wir das ganze hier im Haus in einer
Abteilung mit 10 Leuten. Mehr an Last kann ich erstmal nicht erzeugen aber
ich berichte was dabei rauskommt.

Auf alle Fälle haben wir uns entschlossen zum Testen das FreeRADIUS Setup
erstmal beizubehalten, den IAS evaluieren wir paralell in einer zweiten
Testumgebung. Da wir eh acht von den HP 2650er für den Accessbereich
brauchen, holen wir uns eben zum Testen noch einen zweiten, brauchen tun
wir ihn später sowiso.

Post by Andre Beck
[...]Naja, das Script sollte doch erst laufen, wenn die Domänen-Authentifi-
zierung durch ist, und die wiederum will das Interface IP-mäßig oben
haben. Aber ja, das ist vom Timing her kritisch - siehe oben.

Na Ja auch bei XP kann sich der User mit den cached credentials anmleden.
In Verbindung mit dem dämlichen Startupoptimizing ist das wirklich
problematisch. Und die GPO 'Bei der Anmeldung auf das Netzwerk warten' löst
das (WLAN-Client) Problem auch nicht, da hier nur gewartet wird, bis das
Netztwerk Subsystem hochgefahren ist aber nicht bis die Karte auch einen
Link hat...

Post by Andre Beck

Post by Thomas Wildgruber
Kann der User sich am System schon anmelden, noch
bevor der ganze RADIUS Kram abgeschlossen ist, läuft das Anmeldescripr u.U.
nicht ab. Vor allem XP mit seinem /genialen/[tm] Startupoptimizing ist hier
nicht gerade hilfreich. Vor allem im WLAN Bereich habe ich hier schon so
meine liebe Mühe und Not gehabt...

Da ist WLAN allerdings etwas Besonderes, denn die WLAN-Assoziation läuft
u.U. erst nach der Anmeldung und aktiver Rückfrage beim Nutzer durch und
ist zudem oft sehr träge.

Träge, ja das ist wahr. Die Sache hat sich aber gebessert, so das ich
eigentlich davon ausgehe, dass die Hersteller des NIC Treibers der Sache
etwas mehr Priorität eingeräumt haben und ihn früher Starten lassen oder
Microsoft hat da mit einem Patch nachgeholfen -> Wir waren ja nicht die
Einzigen die über diese Sache gestolpert sind. Die in dieses Problem
involvierten Gruppen waren noch vor zwei Jahren voll davon, ich glaube auch
hier wurde die Sache schon öfter diskutiert...

Post by Andre Beck
[...]Im Prinzip sollte der erste DHCP Discover Broadcast den Vorgang anstoßen,
wenn das einige Sekunden nach Link Up passiert sind RSTP und LACP bis
dahin auch zufrieden und der Switchport reagiert sofort. Die RADIUS-
Interaktion bis zum Verschieben des Switchports in das korrekte Access-
VLAN sollte dann maximal eine Sekunde dauern, ich erwarte eher weniger,
gerade mit CHAP (keine aufwendige Crypto). Das macht Windows eigentlich
unproblematisch mit.

Hoffen wir es ;-)

Post by Andre Beck

Post by Thomas Wildgruber
Auch kann ich das ganze jetzt nicht unter Last testen. Mit den paar
Clients, die ich zum testen hzabe, wird wohl der Switch und auch der RADIUS
kein Problem haben aber wenn dann mal 30, 40 Clients am Switch hängen - und
die dann alle auch noch mehr oder weniger gleichzeitig daherkommen....

FreeRADIUS habe ich schon wegtreten sehen, wenn zu viele Requests auf
einmal ankamen. 100% CPU und keine Antworten mehr. Aber ich meine, das
ist in aktuellen Versionen gefixt. An sich ist das aber alles kein Akt,
die Sache sollte weniger als eine Sekunde dauern und ziemlich gut
skalieren, wenn nicht irgendwas rattig ist.

Wir testen uns da mal Stück für Stück vorwärts aber ich bin da auch
zuversichtlich. So dramatisch viele sind wir ja auch wieder nicht und wir
werden die TTL der Logoff-Period eh deaktivieren, weil die Leute ja auch
nicht jeden Tag umziehen. Nur wenn sich der Client disconnected (Reboot)
geht das ganze Spiel wieder von vorne los, mit den oben beschriebenen
Sorgen und Problemen -> Das muss dann schon sitzen. Hier in der
Testumgebung haben wir die Logoff-Period aber auf 30 Sekunden stehen, damit
wir überhaupt mal so was ähnliches wie Last erzeugen können... ;-)

Bye Tom

[Daniel Krebs]

Post by Thomas Wildgruber
RSTP, LACP und STP nutzen wir hier nicht. Wir haben das Switch Setup noch
nicht redundant ausgelegt. Ob wir es überhaupt machen bleibt noch offen.

Hast Du schonmal zwei Dosen mit einem Patchkabel kurzgeschlossen?
Spätestens danach denkst Du an STP.
Daniel

[Thomas Wildgruber]

Post by Daniel Krebs

Post by Thomas Wildgruber
RSTP, LACP und STP nutzen wir hier nicht. Wir haben das Switch Setup noch
nicht redundant ausgelegt. Ob wir es überhaupt machen bleibt noch offen.

Hast Du schonmal zwei Dosen mit einem Patchkabel kurzgeschlossen?
Spätestens danach denkst Du an STP.

Nein aber wenn es einer mal macht, werden wir wohl umgehend ein Feedback
haben, nehme ich mal an ;-) Obwohl ... Wir hatten das Thema hier aber schon
mal. Da habe ich mal versucht einen Blackout eines unserer Subnetze mit
einem Extreme Switch nachzustellen. Da wurde so ein /Kurzschluss/ mal
provoziert, was dabei aber rauskam muss ich in Google suchen gehen.

Eigentlich sollte sowas ja nicht vorkommen aber du hast natürlich recht. Wo
viele Dosen - auch unbenutzt - sind, liegen irgendwann mal viele Kabel rum,
die man eigentlich gar nicht mehr bräuchte und da kann es auch ohne
Bösartigkeit mal vorkommen, dass das falsche Ende eines Kabels eingesteckt
wird und schon sind wir da, wo mich hinhaben wolltest...

Warum haben wir das (STP) hier im Altbau deaktiviert? Es war nämlich schon
mal aktiviert - Aber ich bin AFAIR mal über ein Problem mit STP in
Verbindung mit AppleTalk gestolpert. Irgendjemand hat mir von diesem
Kombinationsproblem erzählt und ich habe es auf allen Switches deaktiviert,
welche mit AT in Verbindung kamen. Aber das ist schon eine Weile her (MAC
OS 8.x und AFAIR auch noch 9.1), gut möglich dass das mittlerweile gefixt
worden ist. Aber auch gut möglich, dass mir jemand einen Bären aufgebunden
hat.

Anyway, im Neubau wird es nur noch MAC OSX geben und das sehr dünn gesät.
Du meinst ich sollte noch mal darüber nachdenken und es auf einen Versuch
ankommen lassen? Letztlich bin ich jetzt ja sensibilisiert und kann
eventuelle Probleme schneller zuordnen...

Bye Tom

[Daniel Krebs]

Post by Thomas Wildgruber
Eigentlich sollte sowas ja nicht vorkommen aber du hast natürlich recht. Wo
viele Dosen - auch unbenutzt - sind, liegen irgendwann mal viele Kabel rum,
die man eigentlich gar nicht mehr bräuchte und da kann es auch ohne
Bösartigkeit mal vorkommen, dass das falsche Ende eines Kabels eingesteckt
wird und schon sind wir da, wo mich hinhaben wolltest...

Man sollte prinzipiell nur Switchports anhaben, die auch genutzt werden.
Da muß man natürlich entscheiden, nach wieviel Tagen man einen Port
anschaltet, wenn er nicht genutzt worden ist.
Überwachen kann man sowas sehr gut mit SNMP, steuern dann mit PHP und
einer Datenbank, die sich alles merkt.
Nutzt man ausschließlich SNMPv3, ist es freilich nicht ganz trivial.
Dazu gibt es aber auch kommerzielle Lösungen. Oder Du hast einen
Sklaven, der sowas kann und dazu Zeit hat :-)

Post by Thomas Wildgruber
Warum haben wir das (STP) hier im Altbau deaktiviert? Es war nämlich schon
mal aktiviert - Aber ich bin AFAIR mal über ein Problem mit STP in
Verbindung mit AppleTalk gestolpert. Irgendjemand hat mir von diesem
Kombinationsproblem erzählt

Das war wahrscheinlich Thomas Kaiser.
Ich kann mich aber nicht mehr an das konkrete Problem erinnern.

Post by Thomas Wildgruber
und ich habe es auf allen Switches deaktiviert,
welche mit AT in Verbindung kamen.

Hast Du etwa auf den Switchports eine OS- detection ;-)

Post by Thomas Wildgruber
Aber das ist schon eine Weile her (MAC
OS 8.x und AFAIR auch noch 9.1), gut möglich dass das mittlerweile gefixt
worden ist. Aber auch gut möglich, dass mir jemand einen Bären aufgebunden
hat.

Nein, es gab tatsächlich ein Problem. Das will ich aber jetzt nicht
recherchieren.
Du solltest:
1. prüfen, ob Du AT überhaupt noch benötigst (PAP ist ja was schönes.)
2. Dich mit den Optionen von STP/RSTP beschäftigen (Portfast ist das
Zauberwort, aber ich weiß nicht, wie die Entsprechung bei HP heißt.)
3. Testen, ob STP mit seinen Erweiterungen AT immer noch stört

Post by Thomas Wildgruber
Anyway, im Neubau wird es nur noch MAC OSX geben und das sehr dünn gesät.

Unter Umständen willst Du trotzdem nicht auf AT verzichten, wegen PAP.
Ich habe die Erfahrung gemacht, daß viele Druckerhersteller Bonjour nur
mangelhaft unterstützen, insbesondere HP.
PAP klappt bei denen komischerweise immer.
Mit IPP wiederum habe ich Probleme bei Konika Minolta- Kopierern.
PAP klappt.
Das alles natürlich mit dem Hintergrund MacOS X, welches natürlich auch
simples LPR spricht.
Für Filescharing muß man aber nun wirklich kein AT nutzen. Ich würde auf
AFP verzichten, es sei denn es ist das alleinige filesharing Protokoll.
Gemischt mit SMB kann es tödlich sein. AFAIK gibt es nur einen Anbieter,
der das im Griff hat: helios
Und wenn Du auch noch mehrere Segmante hast, mußt Du AT ggf. routen.
Mach das mal mit modernen Layer 3 Switches...
Da käme dann wieder Helios oder NetAtalk ins Spiel. Alles nicht schön.
Also goto 1. :-)

Post by Thomas Wildgruber
Du meinst ich sollte noch mal darüber nachdenken und es auf einen Versuch
ankommen lassen?

Nein, ich empfehle, von Anfang an STP zu nutzen. Aber nicht ohne daß Du
Dich mit den Möglichkeiten auseinander gesetzt hat. STP _kann_ z.B. DHCP
verhindern.
Aktiviertst Du es später, schießt Du Segmente für die Dauer der
Konvergenz- Zeit ab. Ist normalerweise nicht weiter schlimm, kann es
aber sein, sogar sehr schlimm.
Liesmal das hier:
<http://www.dista.de/netstp.htm>
Daniel, gebranntes Kind...

[Jens Link]

Post by Daniel Krebs
Überwachen kann man sowas sehr gut mit SNMP, steuern dann mit PHP und
einer Datenbank, die sich alles merkt.

Man kann sich auch mal NEDI anschauen (http://nedi.sf.net). Ich selbst
hab noch nicht damit gearbeitet, aber ein Bekannter ist ganz begeistert
davon.

Post by Daniel Krebs
Nutzt man ausschließlich SNMPv3, ist es freilich nicht ganz trivial.

So schlimm ist SNMPv3 auch nicht.

Post by Daniel Krebs
Nein, ich empfehle, von Anfang an STP zu nutzen. Aber nicht ohne daß Du
Dich mit den Möglichkeiten auseinander gesetzt hat. STP _kann_ z.B. DHCP
verhindern.

Wenn man die Access-Ports entsprechend konfiguriert ist das kein Problem.

Post by Daniel Krebs
Aktiviertst Du es später, schießt Du Segmente für die Dauer der
Konvergenz- Zeit ab. Ist normalerweise nicht weiter schlimm, kann es
aber sein, sogar sehr schlimm.

Nun ja, man sollte außerdem beim Design seines Netzes darauf achten,
dass nicht die kleine, alte Kiste irgendwo in einer Ecke des Netzwerks
zur Root-Bridge wird[1].


Footnotes:
[1] Dazu am passenden Port ein leicht defektes Kabel und man kämpft
sich am nächsten Tag durch einige hundert "Topology Change" Meldungen
des NMS. BTST

[Daniel Krebs]

Post by Jens Link
Man kann sich auch mal NEDI anschauen (http://nedi.sf.net). Ich selbst
hab noch nicht damit gearbeitet, aber ein Bekannter ist ganz begeistert
davon.

Der Film ist jedenfalls nett.
Ich habe aber auch noch nicht damit rumgespielt.

Post by Jens Link

Post by Daniel Krebs
Nein, ich empfehle, von Anfang an STP zu nutzen. Aber nicht ohne daß Du
Dich mit den Möglichkeiten auseinander gesetzt hat. STP _kann_ z.B. DHCP
verhindern.

Wenn man die Access-Ports entsprechend konfiguriert ist das kein Problem.

Natürlich.

Post by Jens Link

Post by Daniel Krebs
Aktiviertst Du es später, schießt Du Segmente für die Dauer der
Konvergenz- Zeit ab. Ist normalerweise nicht weiter schlimm, kann es aber
sein, sogar sehr schlimm.

Nun ja, man sollte außerdem beim Design seines Netzes darauf achten,
dass nicht die kleine, alte Kiste irgendwo in einer Ecke des Netzwerks
zur Root-Bridge wird[1].

Das ist klar. Bevor man STP einsetzt, sollte man sich mit den
Möglichkeiten auseinandergesetzt haben und sie auch nutzen.

Daniel

[Thomas Wildgruber]

Post by Daniel Krebs

Post by Thomas Wildgruber
RSTP, LACP und STP nutzen wir hier nicht. Wir haben das Switch Setup noch
nicht redundant ausgelegt. Ob wir es überhaupt machen bleibt noch offen.

Hast Du schonmal zwei Dosen mit einem Patchkabel kurzgeschlossen?
Spätestens danach denkst Du an STP.

Ich habe jetzt mal den alten Thread herausgesucht und versucht hier im
Testsetup einen Loop zu erzeugen. Das hat - bei deaktiviertem STP - nur
dann eine Störung verursacht, wenn zwei Ports kurzgeschlossen wurden, die
nicht über RADIUS aktiviert werden.

Haben wir für den /Kurzschluss/ Ports am HP gewählt, die über RADIUS
aktivietrt werden, passierte gar nichts. Der Switch hat den /Kurzschluss/
schlicht weg ignoriert.

Bye Tom

[Daniel Krebs]

Post by Thomas Wildgruber
dann eine Störung verursacht, wenn zwei Ports kurzgeschlossen wurden, die
nicht über RADIUS aktiviert werden.

Na wenn sie aus sind, passiert logischerweise auch nichts :-)
Aber das Kurzschließen mit einem Patchkabel ist nur eine Fehlerquelle.
Fehlerhafte NICs können eine andere sein. Hatte ich aber noch nicht.
Jens kann dazu sicher mehr sagen.
Daniel

[Florian Laws]

Post by Thomas Wildgruber

Post by Andre Beck
MacOS X bringt IIRC einen Supplicant mit, für Linux gibt es welche,
das sollte also noch gehen - wenn die PEAP können, auch gegen IAS.

Was bis jetzt aufgefallen ist, dass eine IP Camera nicht mehr funktioniert.
Die haben wir hier auch grad zum Testen rumliegen gehabt und mit in das
Setup aufgenommen. *Warum* die aber nicht mehr funktioniert können wir
jetzt abschliessend noch nicht erklären. Das einzige was uns bislang
aufgefallen ist, dass die Camera 802.1Q nicht versteht. Wir rätseln hier
grade rum, ob das von den Devices unterstützt werden muss, da wir alle im
Test involvierten Switch Ports getagget haben -> untagget konnten wir wir
sonst die Ports nicht mehreren VLANs zuweisen.

Nanu? Bei meinen .1X-Tests (mit HP 4148gl) war der Access-Port
untagged und wurde je nach Ergebnis der RADIUS-Abfrage automatisch
in das entsprechende VLAN gesteckt.

Wäre ja auch nur halb so sinnvoll, wenn der Client an einem tagged Port
dann von VLAN zu VLAN springen könnte.

Grüße,

Florian

[Thomas Wildgruber]

Post by Florian Laws

[...]Wir rätseln hier
grade rum, ob das von den Devices unterstützt werden muss, da wir alle im
Test involvierten Switch Ports getagget haben -> untagget konnten wir wir
sonst die Ports nicht mehreren VLANs zuweisen.

Nanu? Bei meinen .1X-Tests (mit HP 4148gl) war der Access-Port
untagged und wurde je nach Ergebnis der RADIUS-Abfrage automatisch
in das entsprechende VLAN gesteckt.

Um erhrlich zu sein, wir haben es mit untagged Ports noch gar nicht
versucht. Es hat für uns einfach keinen Sinn ergeben, die Ports fest auf
ein VLAN zu konfigurieren, in der Hoffnung der Switch überlegt es sich dann
doch noch mal anders und packt es in ein VLAN in welches der RADIUS gerne
gehabt hätte...

Anyway, jetzt wo wir es /untagged/ probiert haben, geht es immer noch ;-)
Danke für diese Anmerkung. Frage: In welches VLAN konfigurierst du dann per
Default die Ports? Ins Default VLAN?

Post by Florian Laws
Wäre ja auch nur halb so sinnvoll, wenn der Client an einem tagged Port
dann von VLAN zu VLAN springen könnte.

Ja blöd wäre das schon und wenn es sich vermeiden lässt... ;-)

Bye Tom

[Florian Laws]

Post by Thomas Wildgruber

Post by Florian Laws

[...]Wir rätseln hier
grade rum, ob das von den Devices unterstützt werden muss, da wir alle im
Test involvierten Switch Ports getagget haben -> untagget konnten wir wir
sonst die Ports nicht mehreren VLANs zuweisen.

Nanu? Bei meinen .1X-Tests (mit HP 4148gl) war der Access-Port
untagged und wurde je nach Ergebnis der RADIUS-Abfrage automatisch
in das entsprechende VLAN gesteckt.

Um erhrlich zu sein, wir haben es mit untagged Ports noch gar nicht
versucht. Es hat für uns einfach keinen Sinn ergeben, die Ports fest auf
ein VLAN zu konfigurieren, in der Hoffnung der Switch überlegt es sich dann
doch noch mal anders und packt es in ein VLAN in welches der RADIUS gerne
gehabt hätte...
Anyway, jetzt wo wir es /untagged/ probiert haben, geht es immer noch ;-)
Danke für diese Anmerkung. Frage: In welches VLAN konfigurierst du dann per
Default die Ports? Ins Default VLAN?

Ich habe in meinen Tests das Default VLAN verwendet, aber ich wuerde
tatsaechlich eher das VLAN verwenden, das am sinnvollsten waere, wenn
der RADIUS-Server in seiner Antwort mal keine VLAN-Information mitschickt.
Notfalls also das Quarantaene- oder Besucher-VLAN.

Gruesse,

Florian

[Andre Beck]

Post by Thomas Wildgruber
Ich habe das jetzt mal versucht heraus zu sniffen aber so richtig kann ich
den Frame jetzt nicht identifizieren, der das ganze auslöst.

Nun, es wird das erste Frame sein, das der Port empfängt ;)

Post by Thomas Wildgruber
Ich sniffe den
Traffic mit Wireshark auf einem Notebook mit, während ich es am Switch
anstecke. Das erste was aufschlägt sind meißtens Broadcasts, recht
zuverlässig ist eigentlich immer ein LLDP Paket vom HP ganz vorne mit
dabei[*]

Das geht allerdings Switch->Notebook, ist also für die Frage, wie der
Switch die MAC des angeschlossenen Endgerätes sieht, irrelevant. Wie
gesagt, im Normalfall dürfte das erste vom Endgerät verschickte Frame
ein DHCP Discover sein bzw. bei fixer IP ein Self-ARP.

Post by Thomas Wildgruber
aber das initiale Paket, welches den Vorgang auslöst vermag ich
entweder mit meinem Wireshark Setup nicht zu identifizieren oder es ist
wirklich immer etwas anderes.
[*] Hinter deren Sinn ich bis jetzt auch nicht ganz gekommen bin.

LLDP ist ein Vendor-neutraler Ersatz für CDP bei der Topology Discovery.
AFAIK hat HP kein CDP mehr lizensieren wollen (oder lizensiert bekommen)
und stellt gerade mit viel Mühe und Kollateralschäden die ganze ProCurve-
Flotte (bzw. fast die ganze) auf LLDP um.

Um zu sehen, wozu es gut ist, gib einfach auf einem halbwegs mit anderen
Switchen vernetzten Switch mal "show lldp info remote" ein oder jag den
ProCurve Manager oder NeDi drauf. Keine Managementlösung kennt die Topo-
logie eines Switchverbundes wirklich, sie benötigt dazu ein funktio-
nierendes Topology Discovery Protocol in den Geräten. Und leider hat der
Umstieg von CDP auf LLDP den Begriff "funktionierend" sehr strapaziert.

Post by Thomas Wildgruber
RSTP, LACP und STP nutzen wir hier nicht. Wir haben das Switch Setup noch
nicht redundant ausgelegt. Ob wir es überhaupt machen bleibt noch offen.

Passive LACP ist per Default an, du musst es explizit abschalten, was nur
im CLI geht. Zu STP wurde schon genug gesagt, "STP Off" als Factory Default
ist IMO eines der sträflichsten Versäumnisse seitens HP - so geht man nicht
ernsthaft den Enterprise-Markt an...

Post by Thomas Wildgruber

Post by Andre Beck
Solaris und andere Unices im freien Access? Sowas ist heute selten ;)

<seufz> Was Entwickler alles brauchen können, denen fällt jeden zweiten Tag
was Neues ein ;-)

Naja, für die paar Sonderlocken sind ein paar dedizierte Ports nicht der
Beinbruch. Dose beschriften, Entwickler instruieren, drohen dass er bei
Verstößen die Machine nur noch im Lab oder Serverraum besuchen darf, geht.

Post by Thomas Wildgruber
Was bis jetzt aufgefallen ist, dass eine IP Camera nicht mehr funktioniert.
Die haben wir hier auch grad zum Testen rumliegen gehabt und mit in das
Setup aufgenommen. *Warum* die aber nicht mehr funktioniert können wir
jetzt abschliessend noch nicht erklären. Das einzige was uns bislang
aufgefallen ist, dass die Camera 802.1Q nicht versteht.

Endgeräte müssen kein .1Q verstehen und bekommen das auch nicht zu sehen,
einzige Ausnahme sind dedizierte Ports für "Server on a stick".

Post by Thomas Wildgruber
Wir rätseln hier
grade rum, ob das von den Devices unterstützt werden muss, da wir alle im
Test involvierten Switch Ports getagget haben -> untagget konnten wir wir
sonst die Ports nicht mehreren VLANs zuweisen.

Das ist ein generelles Missverständnis. Access-Ports sind wie gesagt immer
Untagged in exakt einem VLAN. 802.1X legt fest, welches VLAN das genau
sein soll, die Switchkonfiguration sagt, welches es per Default ist, wenn
kein .1X stattfindet. Sinnvoll wäre IMO das Quarantäne-VLAN.

Post by Thomas Wildgruber

Post by Andre Beck
[...]Wenn die Erfahrungen da sind, wäre ich an einem kurzen Feedback hier
in der Gruppe interessiert.

Mach ich. Im Moment haben wir hier unser EDV Büro in das Testumfeld mit
aufgenommen, dass wären ein Drucker, unsere sechs PCs (jeder hat zwei;),
drei Laptops (zum /Spielen/) und die besagte IP-Camera. Läuft das diese und
nächste Woche störungsfrei bzw. wir haben bis dahin die letzten Probleme
beiseite geräumt, dann verbauen wir das ganze hier im Haus in einer
Abteilung mit 10 Leuten. Mehr an Last kann ich erstmal nicht erzeugen aber
ich berichte was dabei rauskommt.

Thanks. Wie heißt es so schön, "Erfahrung ist der Mechanismus, mit dem
wir Fehler wiedererkennen, wenn wir sie das nächste Mal machen" ;)

Post by Thomas Wildgruber

Post by Andre Beck
FreeRADIUS habe ich schon wegtreten sehen, wenn zu viele Requests auf
einmal ankamen. 100% CPU und keine Antworten mehr.

Wir testen uns da mal Stück für Stück vorwärts aber ich bin da auch
zuversichtlich. So dramatisch viele sind wir ja auch wieder nicht und wir
werden die TTL der Logoff-Period eh deaktivieren, weil die Leute ja auch
nicht jeden Tag umziehen. Nur wenn sich der Client disconnected (Reboot)
geht das ganze Spiel wieder von vorne los, mit den oben beschriebenen
Sorgen und Problemen -> Das muss dann schon sitzen. Hier in der
Testumgebung haben wir die Logoff-Period aber auf 30 Sekunden stehen, damit
wir überhaupt mal so was ähnliches wie Last erzeugen können... ;-)

Bei mir passierte das konkret, wenn auf einem PPPoE NAS mit einer signi-
fikant zweistelligen Nutzerzahl ein "clear pppoe session *" anstand, was
die schlagartige Wiedereinwahl des größten Teils dieser Nutzer in der
nächsten Sekunde bewirkte. Das ging -zigmal gut und dann irgendwann doch
schief, mit einem freeradius, der nur noch per SIGKILL zu beseitigen war.
Aber wie gesagt, war sicher ein Bug in dem ollen Backport, der da lief.