Nightwalker_z

Das ist meines Wissens nicht richtig - sorry. 802.11 beschreibt wie Ethernet nur den Physical und den MAC Layer. Der Vergleich ist wie, wenn ein Ethernet HUB, die IPs der angeschlossenen Client wissen muss. Bei einem Association Request und Response werden sicher keine IP Adressen übertragen. Er Client überträgt sog. fixed und tagged (variable) Parameter Dazu gehören u.A. Capability checks, SSID, Supported Data Rates und noch optional Vendor Specific Stuff... Bin davon überzeugt, dass mein Aufbau richtig ist. Anbei nochmal ein Screenshot von nem Capture, der nen Association process zeigt --> Keine IPs.

Naja, um komplett IP stumme Clients gehts ja auch nicht. Das war nur zur Simulation. Also ich hab schon öfter Clients gehabt, die ne statische IP haben --> kein DHCP und nach dem Einschalten einfach mal nix von sich geben. Die warten halt nur drauf, dass mal jemand die Kommunikation initiiert. Von dem her hat der WLC und der Router noch kein einziges IP Paket von dem Client gesehen. Und schon haben wir den Salat :-)

Nope - macht er nicht. Da der WLC ja weiss, welches VLAN welche IP-Netzadresse hat, da er ja selbst ne IP in jedem VLAN hat (dynamic Interface), müsste er das tun - macht er aber nicht. Wie gesagt, hab das ganze getestet, indem ich nen Client an ner SSID assoziiert hab. Auf dem Windows Client habe ich das IP Protokoll deaktiviert. Sprich der Cient schickt gar kein IP Paket raus - der WLC hat keine Chance die IP Adresse zu kennen. Damit simuliere ich nen stummen Client. Der WLC zeigt den Client auch in der Assoziationsliste mit Status "UNKNOWN IP". Jetzt kann ich von nem Wired Testclient eine beliebige (unbekannte) IP Adresse in dem Subnetz pingen. Der Router in dem Subnetz broadcastet dann nen ARP request für diese IP. Der WLC forwarded diesen ARP-request aber nicht. Hab auf zwei Art und Weisen gecaptured: 1.) Auf dem Wireless Client direkt mit Wireshark. 2.) Mit ner Cisco Aironet Karte und Backtrack. Damit kann man wunderbar auf der Luftschnittstelle capturen. Btw.: Natürlich habe ich eine unverschlüsselte SSID für den Test verwendet, da ich sonst ja die ARP Pakete nur verschlüsselt capturen kann. Es will aber einfach nicht klappen :-(( Naja - hätte ja sein können, das jemand anders auch über das Problem gestolpert ist und ggf. nen besseren Workaround als ich hab. (Mein Workaround wäre bis jetzt, nen statischen ARP Eintrag auf dem Router machen).

Hi zusammen, ich hätte da mal eine Frage bezüglich Cisco WLAN Controller. Bin im Moment ein bisschen am Spielen mit der 4400 Serie von Cisco. Mich verwundert etwas das Verhalten bezüglich ARP requests aus dem kabelgebundenen Netz. Das Normalverhalten ist so: - Der WLC kennt normalerweise alle IP Adressen der Assoziierten Clients. - Wenn ein ARP Request für die IP Adresse eines Wireless Clients kommt, wird der Request vom Controller beantwortet. Soweit so gut.... Jetzt aber zum Problem: Was ist mit Clients, von denen der Controller nicht die IP Adresse kennt. Es soll ja auch Clients geben (meistens Non-Windows), die einfach die Klappe halten, wenn sie nichts gefragt werden. Angenommen man hat einen Client mit statischer IP, die der WLC nicht kennt - was dann? Sprich der ARP request vom Kabelgebundenen Netz wird nicht vom Controller beantwortet, weil er nix weiß UND der Controller forwarded den Request nicht. --> Keine Kommunikation mit dem Client. Ich hab das einfach mal getestet mit nem Windows Client und deaktiviertem IP Protokoll in der Netzwerkumgebung. Wenn man auf den Controller schaut, sieht man nen assoziierten Client mit der IP Adresse "UNKNOWN". Jetzt mal nen Ping von nem kabelgebundenen Client in das wireless Subnetz - kein ARP Broadcast in der Luft - nix.... Hab gehofft, dass der WLC den ARP broadcastet, wenn er nen Client hat, von dem er nicht die IP Adresse kennt (Analog zum "arp cache optional" Feature bei IOS APs). Hat dieses Verhalten auch schon jemand festgestellt? Wisst ihr ob das normal ist und ob man was dagegen tun kann? Am WLC hab ich das "Forward Broadcast" Feature enabled, aber das gilt wohl nur für alle Broadcasts ausser nem ARP :-(

Hmm .. das verstehe ich nicht. Was ist denn schlecht an Stacks? Also ich seh den Einsatzzweck eher im DataCenter / Distribution Bereich als im Core ... im Core hast du ja eigentlich nur geroutete Pt-to-Pt Verbindungen. Interessant ist es eben, wenn du beispielsweise im Datacenter ein und dasselbe Subnetz auf 4 Büchsen zur Verfügung stellen musst. Das schöne ist, dass man mit VSS das ohne Spanning-Tree hinbekommt, indem man einfach EtherChannels Chassisübergreifend spannen kann. Anderer (einfacherer) Anwendungfall, der mir auf die schnelle einfällt, ist der Uplink zum Access-Layer. Normalerweise hast du zwei Distries und jeweils eine Verbindung zwischen Distri und Access (Triangel). Sprich bei PVST ist ein VLAN pro Link auf blocking. Mit VSS kann man zum Access-Switch wunderbar nen EtherChannel fahren - also man nutzt beide verfügbaren Links wunderbar aus. Schöner Nebeneffekt: Man braucht für ein VLAN auch kein HSRP/VRRP mehr - was oft ja der Konvergenzkiller ist, mit den Defaulttimern. Natürlich sollte das VSS nicht auseinanderfallen - sonst hat man ein echtes Problem :-)

Hier mal ein Output :-) WLANTESTAP(config)#dot11 ssid TEST WLANTESTAP(config-ssid)#vlan 10 Warning: Vlan 10 already mapped to SSID ANOTHER_TEST. SSIDs with same vlan association cannot be attached to the same interface. und .. WLANTESTAP(config)#int dot11Radio 0.10 WLANTESTAP(config-subif)#encapsulation dot1Q 10 %Configuration of multiple subinterfaces of the same main interface with the same VID (10) is not permitted. This VID is already configured on Dot11Radio0.1. Aber ich denke es geht schon. Hier mal ein Beispiel - hab es aber nicht getestet: dot11 ssid SSID1 authentication open vlan 10 ! dot11 ssid SSID2 authentication open vlan 10 ! interface dot11radio0 ssid SSID1 ssid SSID2 ! interface dot11radio0.1 encapsulation dot1q 10 bridge-group 10 ! interface fastethernet 0.1 encapsulation dot1q 10 bridge-group 10 ! Und schon sind beide SSIDs im selben VLAN. – Nachtrag: Pustekuchen: ap#conf t Enter configuration commands, one per line. End with CNTL/Z. ap(config)#dot11 ssid SSID1 ap(config-ssid)# authentication open ap(config-ssid)# vlan 10 ap(config-ssid)#! ap(config-ssid)#dot11 ssid SSID2 ap(config-ssid)# authentication open ap(config-ssid)# vlan 10 Warning: Vlan 10 already mapped to SSID SSID1. SSIDs with same vlan association cannot be attached to the same interface. ap(config-ssid)#! ap(config-ssid)#interface dot11radio0 ap(config-if)# ssid SSID1 ap(config-if)# ssid SSID2 Dot11Radio0: VLAN 10 is already mapped to SSID SSID1, SSID to VLAN mapping should be unique on interface. ap(config-if)#! ap(config-if)#interface dot11radio0.1 ap(config-subif)# encapsulation dot1q 10 ap(config-subif)# bridge-group 10 ap(config-subif)#! ap(config-subif)#interface fastethernet 0.1 ap(config-subif)# encapsulation dot1q 10 ap(config-subif)# bridge-group 10 ap(config-subif)#! ap(config-subif)#exit ap(config)#exit Naja ... die ganzen Messages oben sind alles Warnings (also solche schönen Wörter wie "should" und so weiter). Jetzt geht's ans Verifizieren: ap#show dot11 bssid Interface BSSID Guest SSID Dot11Radio0 001a.e35e.7b90 No SSID1 Schade ... nur die erste SSID

Vielen Dank... Ich dachte, dass ich mit "power local xx", einen absoluten und fixen Wert setze. Mir war nicht wirklich bewusst, dass ich damit auch TPC mache. Die Cisco Doku bezieht sich in diesem Punkt auch nicht auf TPC - zumindest hab ich es nicht gefunden.

Servus, hab eine Frage bezüglich IOS AP's und 802.11h. Der 802.11h Standard ist im Prinzip der ETSI 802.11a (5GHz Band) Standard. 802.11h beschreibt die Features DFS (Dynamic Frequency Selection) und TPC (Transmission Power Control). Wie ich auf den Aironet AP's DFS aktiviere ist klar: interface dot11radio1 channel dfs ! Die Frage die sich mir stellt ist, wie ich TPC aktiviere? Hat jemand ne Idee? Grüße Nightwalker_Z

Nope ... das war das Lab Exam gestern. Sonst hätte ich ja noch keine CCIE Nummer :-)

Vielen Dank... Soweit ich weiss, bekommt man sein Ergebis vom Written sofort wenn man auf fertig ist. So war das auf jeden Fall bei mir - hab das Written auf der diesjährigen Networkers gemacht. Bei dem Lab Exam ist es ein wenig anders. Die machen oft (wie bei mir) - follow the sun scoring. Das heisst, wenn ich um 16:30 in Brüssel fertig bin, wird bei R&S zumindest in Asien gescort.. ... sprich das Ergebnis ist meistens in der selben Nacht da.

Btw ... bin aus Brüssel zurück CCIE#20793 :D Grüße Nightwalker_z

Kommt ganz drauf an was für eine Zertifizierung du machen willst.... Wenn es der CCNA sein soll, dafür gibt es eine ganze Latte von "Zertifizierungszentren" Hier ist mal ein Link für den CCNA: 640-802 CCNA - IT Certification and Career Paths - Cisco Systems CCNP geht nur, wenn du bereits nen CCNA hast. Für den CCIE musst du ne schriftliche Prüfung (written exam) machen (VUE) - danach innerhalb von einem Jahr eine praktische Prüfung (lab exam). Das lab exam kannst du nur an wenigen Orten machen. Das nächste von Deutschland aus ist Brüssel. Routing and Switching - CCIE - Cisco Systems Btw.. drückt mir die Daumen - hab am Dienstag Termin in Brüssel für R&S.

VTP Mode Client/Server hat eben auch Angriffspunkte wenn man es nicht richtig macht. Ein Beispiel ist, dass jemand deine gesamte VLAN Datenbank in einer VTP Domain überschreibt. Dann steht erst mal das Netz! Deshalb - falls du VTP Client/Server unbedingt einsetzen willst, dann beachte ein paar einfache Grundregeln: - VTP mit Passwort schützen. ("vtp password" Kommando) - Auf Endgeräteports kein DTP aktivieren .... (VTP Updates werden nur auf Trunks geschickt). Und da kommt auch der nächste Punkt. Angenommen du fährst keinen Trunk zwischen Beispielsweise deinem Core und der Distribution, sondern verwendest Routet Ports, dann geht darüber kein VTP. Ich denke man hört langsam raus, dass ich wirklich eher ein VTP Mode Transparent Anhänger bin

Ich würde auch den Transparent mode machen. Von Vorteil ist, dass die gesamte VLAN Config pro Switch auch in der Startup-Config steht. Beim vtp client/server mode, steht die vlan config in einer Datei mit dem Namen VLAN.DAT - die muss man dann auch sichern. Wenn alles in der running-config steht, ist mir das irgendwie sympatischer :-))

Warum nicht einfach die neue SSID dazukonfigurieren? Die neue SSID hat was die "dot11 ssid" angeht, dieselbe Konfig wie die alte SSID. Dann noch die neue Dot11SSID auf das Radiointerface binden, fertig. Jetzt sendest du beide SSIDs aus (alt und neu). Dann ist sogar eine sanfte Migration möglich - sobald alle Clients umgestellt sind, die alte SSID aus der Konfig löschen.

Wegen dem Taschenrechner: Du hast normalerweise den Windows-Calc zur Verfügung.

Schau dir mal das an: - Tirith - Netdisco - Network Management and Discovery beides ist OpenSource Damit dürftest du klar kommen. Natürlich hat es Cisco auch gerne, wenn du CiscoWorks kaufen würdest (LMS + Campus Manager). Da hast du ein Tool namens "User-Tracking".

Hmmm ... was ist mit dem mitgelieferten Netzteil? Kannst du den AP nicht damit erstmal in Betrieb nehmen und probieren einzustellen?

Kann es sein, dass PoE nicht gleich PoE ist. Deine Power-Injektoren arbeiten ausschließlich mit 802.3af (also dem PoE Standard). Auf den Access-Points kann man noch einstellen ob es Pre-Standard oder Standard ist. Vgl auch Release Notes for Cisco Aironet 1100, 1130, 1200, 1230, 1240, and 1300 Series Access Points for Cisco IOS Release 12.3(11)JX1 - Cisco Systems

Um ein Gefühl zu bekommen, ist ein einfacher PING auch ein gutes Werkzeug. Wenn du das ein bisserl machst (so 5 Minuten), dann hast du am Schluß sogar einen Durchschnittswert über die 5 Minuten.

Ich kann Dir nur sagen, dass wir ein so ähnliches Szenario bei uns im Einsatz haben und dort funktioniert alles reibungslos. Was passiert mit dem Interface am Switch 1, wenn du das Interface am Switch 2 auf Shutdown setzt? Im Normalbetrieb - welche MAC-Adressen siehst du auf dem Switch1 - Port 1 und welche auf dem Switch2-Port 1? Bei ESX sollten sich die virtuellen Adressen auf die verfügbaren LAN Nics aufteilen, oder? Wie sieht deine virtuelle Switch Konfiguration aus (ESX Seite) ?

Danke mit nicht zu früh. Ich habe schon immer mit der Version 4 gearbeitet. Ob und welche Features die Version 3hat, kann ich dir nicht sagen. Meine Empfehlung ist ein Update zu machen, falls möglich.

Also du benutzt nicht die WCS, sondern die Web-Configoberfläche direkt auf dem Controller, oder? Ich hab hier die Version 4.1.171.0 und werd es daran erklären. Die SSID muss folgendermaßen eingestellt sein: - Layer 2 Security = WPA + WPA2 - Nur die WPA2 Policy auswählen (checken) - WPA2 Encryption = AES - Auth Key Mgmt = 802.1x - Layer 3 Security = None - AAA Server (Radius) definieren Damit sollte es eigentlich schon klappen!

Poste erstmal deine Konfig. Dann kann man dir vielleicht weiterhelfen. Was benutzt du PAGP, LACP oder keins von beiden? Also bitte erst mal die Konfig und die Hardware typen. Ansonsten können wir gleich die Glaskugel auspacken ;)

Am Controller oder WCS musst du nur den Radius Server einstellen (IP oder Name), den Radius Port und das Shared Secret zwischen Controller und Radius Server. Wenn du den IAS von Windows verwendest, musst du den Controller natürlich auch als Radius Client eintragen (PEAP). Das Eventlog von Windows (SYSTEM) - EVENT IAS hilft dir beim troubleshooting weiter. Was willst du denn Authentifizieren, bzw. welche EAP Methode willst du benutzen? EAP-PEAP, EAP-TLS, EAP-MD5 ????