sbE

super...danke!

falls noch jemand diesen thread findet...hier gibt es weiterführende infos:

You cannot connect to an 802.1X wired network after you upgrade to Windows XP Service Pack 3

dort findet man auch einen weiterführenden link bezüglich den änderungen zu AuthMode und Supplicantmode (wird nun nicht mehr über die registry gesetzt).

hallo,

bei einer vielzahl unserer systeme ist der karteireiter "authentifizierung" (eigenschaften lan-verbindung) verschwunden. dort werden die 802.1x-einstellungen geregelt...somit haben wir nun das problem, dass sich diese system nicht mehr über 802.1x authentifizieren können. am switch selbst kommt auch keine 802.1x-anfrage mehr an...von daher liegt die vermutung nahe, dass dieser umstand über einen xp-update. vor tag x (ist vielleicht ein paar wochen her) lief die 802.1x-geschichte hervorragend.

vielleicht hat jemand einen tipp für mich?

hmm, flow control...ist ne idee. auf einem hp-switch ist das defaultmäßig deaktiviert. ich schreib's mir mal hinter die ohren.

weiß jemand zufällig wie sich die tcp-window geschichte unter 2003 verhält!? wird das window während einer session automatisch nach oben geregelt!?

naja, so einfach ist das mit der testerei nicht...da kundensystem(e) und dann auch noch jeweils exchange & ads. :(

die stats der switchports sind sauber und ein mode-mismatch ist's auch nicht. da die server von dell und hp sind, und dann auch noch eine generation dazwischen liegt haben wir also auch nicht die selbe ausgangslage was die nic-treiber angeht. da muß irgendwie irgendwo eine andere gemeinsamkeit existieren. mehr server habe ich übrigens noch nicht getestet (aus zeitgründen).

im einsatz ist übrigens ca antivirus.

hi,

ich habe hier ein problem mit mehreren servern. wenn ich daten von diesen auf z.b. mein notebook kopieren möchte, dauert dies extrem lang (5 gb in 10 stunden). wenn ich aber daten von einem anderen pc au mein notebook (am gleichen switch wohlgemerkt) kopiere, flutscht das wie erwartet.

mit iperf läßt sich das kuriose verhalten noch besser darstellen:

C:\>iperf -c server1

------------------------------------------------------------

Client connecting to server1, TCP port 5001

TCP window size: 8.00 KByte (default)

------------------------------------------------------------

[ 3] local nb1 port 49359 connected with server1 port 5001

[ 3] 0.0-10.0 sec 1.56 MBytes 1.31 Mbits/sec

C:\>iperf -c pc1

------------------------------------------------------------

Client connecting to pc1, TCP port 5001

TCP window size: 8.00 KByte (default)

------------------------------------------------------------

[ 3] local nb1 port 49380 connected with pc1 port 5001

[ 3] 0.0-10.0 sec 139 MBytes 117 Mbits/sec

jetzt das interessante...

sobald ich das tcp-window auf mindestens 9kb hochsetze, explodiert die übertragungsrate förmlich auf das zu erwartende normalniveau:

C:\>iperf -c server1 -w 9k

------------------------------------------------------------

Client connecting to 172.16.1.3, TCP port 5001

TCP window size: 9.00 KByte

------------------------------------------------------------

[ 3] local pc1 port 49366 connected with server1 port 5001

[ 3] 0.0-10.0 sec 426 MBytes 358 Mbits/sec

tja, wie schon gesagt, dass problem tritt nicht nur mit einem server auf.

was kann das wohl sein!?!?!?! windows bug? böser virenscanner!!?!? schlechte treiber (sind aber unterschiedliche netzwerkkarten (hp/dell)?!?

danke dir, der link ist wirklich hilfreich!

hi,

kann mir jemand die ip-ports nennen, die bei einer anmeldung an einem active directory gebraucht werden (also für loginscript, laufwerksmapping etc)?

hintergrund ist eine beschränkung der maschinenauthentifizierung im wlan.

vielen dank schonmal

Hallo,

ich habe eine LAN-Umgebung mit 802.1x-Auhentifizerung per PEAP(MS-CHAPv2) und dynamischen VLANs (zugewiesen per Radius-Attribut via IAS). Alles funktioniert soweit bestens.

Nur manchmal erhält ein User, der per Radius-Attribut sein VLAN zugewiesen bekommt (bzw. der Switch dahinter), kein Home-Laufwerk gemappt. Meldet sich der User dann kurz ab und wieder an, bekommt er es auch. Irgendwann klappt es dann auch immer...also inkl reboot. Der IAS fragt Computerkonto und Benutzerkonto in der ADS ab und das Häkchen beim Client "als Computer authentifizieren, wenn Computerinformationen verfügbar" ist gesetzt.

Übrigens funktioniert das mappen problemlos, wenn ich die VLAN-Zuweisung per IAS "weglasse"...also eine ganz normale 802.1x-Authentifizierung durchführe.

Irgendwie klingt das nach einem Timingproblem.

Hat jemand eine Idee wie ich das Lösen könnte!?

Meines Wissens nach sollte das automatisch gehen, vorausgesetzt die Zertifizierungsstelle ist eine Enterprise CA, oder Unternehmenszertifizierungssstelle.

eine unternehmenszertifizierungsstelle ist es...aber vielleicht kann ja noch jemand auf praxiserfahrungen zurückgreifen. die suche per google und bei microsoft bringt irgendwie überhaupt nichts brauchbares. :(

oder vielleicht muß ich doch mal eine testumgebung aufbauen und die systemzeiten ein jahr vorsetzen...das müßte doch eigentlich auch klappen.

hallo,

das verhalten der zertifizierungsstelle unter windows 2003 standard ist ja weniger konfigurierbar als bei der enterprise oder datacenter edition.

was passiert nun genau, wenn ein benutzer- oder computerzertifikat ausläuft und erneuert werden muß? wird dies automatisch erneuert (erneuerungszeitraum unveränderbar auf 6 wochen) oder muß man an jedem client hand anlegen?

super...ich danke dir. ich werd's mal testen.

@darking

das klingt gar nicht mal so schlecht..."track interface xyz"...

nur weiß ich aus dem stehgreif gar nicht wie ich mit dem ciscos so einen tunnel realisiere. hast du vielleicht kurzer hand einen link für mich? cisco benutzt ja meist irgendwelche berzeichnungen, die ohne ahnung des syntax (oder eines teils davon) schwerlich zu finden sind.

Warum sollten den nicht zwei Routen mit zwei verschiedenen Metriken funktionieren, eine über den Tunnel, die andere über ISDN?

t

habe ich probiert - funzt leider nicht.

1. route über eth0 zu vpn-router ins web

2. route über bri0

wenn ich nun den vpn-router vom internet trenne macht der 1600er gar nix. der ping der workstation geht ins leere und der 1600er denkt gar nicht daran die zweite route zu "probieren". ziehe ich aber das lan-kabel des 1600 (eth0 down) springt die 2. route an und baut eine isdn-verbindung auf. aber das soll ja nicht ziel der übung sein.

nein, leider auch nicht.

also so wie ich das sehe, habe ich ohne den einsatz eines routingprotokolls keine möglichkeit mit statischen mitteln ein isdn-backup zu fahren (wenn man davon ausgeht, das der 1600er selbst nicht das interface hat, welches ins internet geht und ein backup bekommen soll).

1600:

- int eth0 ---- lan (mit vpn-router ---- internet)

- int bri0 ---- isdn backup

eieiei, mir deucht ich habe ein problem!

im cisco feature navigator tauchen die features "Reliable Static Routing Back-up using Object Tracking" oder "FHRP" nicht für den 1600er auf.

also ich glaube da hilft mir auch kein t-release mehr. :(

*seufz*

ich habe hier mal mit einer neueren ios-version (12.3(15)) für einen 1600er cisco herumprobiert, um object tracking zu testen. wenn ich die config von cisco.com (laut cisco für 12.3) eingebe, meckert der 1600er bei einer bestimmten zeile, da er wohl den befehl bzw nicht alle optionen kennt:

track 123 rtr 1 reachability

nach track 123 ist schluss - zu auswahl steht nur die option interface, aber nicht "rtr".

alles andere (also auch rtr 1 inkl icmp-test) läßt sich konfigurieren.

irgendwie verstehe ich das nicht, laut cisco sollte der track-befehl beide optionen können. andere wege wie z.b. track 123 interface rtr 1 oder ähnliches klappt genauso wenig. :(

was ist da los?? bei cisco finde ich nichts über eine änderung des befehlssyntax.

ich denke das wird schlecht möglihc sein, da als vpn-router eine linux-appliance zum einsatz kommt. hsrp ist dann wohl zu viel des guten.

keiner eine idee? :(

hallo,

ich habe hier in einem recht kleinen netzwerk (10 - 15 mitarbeiter) einen cisco 1600 übrig, welcher einmal für eine isdn-verbindung zwischen aussenstandort und zentrale benutzt wurde. seit geraumer zeit ist nun ein anderer router (bzw. eine routerlösung) per dsl im internet und baut eine vpn-verbindung zur zentrale auf.

folgender gedanke...

der 1600er soll der standardgateway für das lan werden und bei ausfall der vpn-verbindung (die ja an dem anderen router konfiguriert ist), das isdn-fallback zur zentrale aufbauen.

die geschichte mit den administrativen distanzen kenne ich nur im zusammenhang mit dynamischem routing. aber genau da liegt das problem...dynamisches routing will man nicht haben.

nun ist die frage welche andere lösung es gibt!? object tracking habe ich mir auch schon angeschaut, aber dieses feature gibts erst seit ios 12.3 - nur hat das diesre router nicht.