Nightwalker_z

Hi, deine Interface Fragen werden direkt hier beantwortet. Die Grafik ist recht gut. Deploying Cisco 440X Series Wireless LAN Controllers - Cisco Systems Das Management Interface ist "static". Über das Interface kannst du den Controller administrieren (nicht verwechseln mit dem Service-Port). Außerdem reden die APs auch mit diesem Interface. Dieses Interface MUSS vorhanden sein. Dynamic Interfaces kannst du anlegen wie du willst. SSIDs kannst du auf das Management Interface oder Dynamic Interfaces legen. Ich persönlich würde SSIDs nur auf dynamic Interfaces mappen. Die Clients haben nix im Managementsubnetz des WLCs zu suchen (meine Meinung). Naja - das AP Manager Interface nicht. Die dynamic Interfaces haben auch nur eine IP Adresse, weil die DHCP Relay spielen können. Deshalb spielt die IP Adresse auf dyn Interfaces nur eine untergeordnete Rolle. Das Virtual Interface (1.1.1.1 in vielen Setups) kann man natürlich auch nicht anpingen. Les dir am Besten den oberen Link "440x Design Guide" komplett durch. Der ist eeeecht einfach geschrieben und sollte alle deine Fragen deckeln!

Achtung: Cisco WLAN Controller unterstützen offiziell keine 3rd Party Workgroup Bridges. Es werden laut Cisco nur Cisco IOS APs unterstützt (WDS). Zitat aus: Wireless LAN Controller (WLC) Design and Features FAQ - Cisco Systems Außerdem ist dieser Satz von Cisco auch wichtig: Aber im Endeffekt hängt es davon ab, wie die WGB konfiguriert wird. Wenn es mehrere Endgeräte hinter der WGB gibt, sehe ich keine Chancen (außer nen Cisco AP).

Hi, laut Cisco 860, Cisco 880, and Cisco 890 Series Integrated Services Routers Software Configuration Guide - Configuring the Radio [Cisco 800 Series Routers] - Cisco Systems sollte es gehen - mir ist irgendwie durch die Lappen gegangen dass es sich um nen 800er Router handelt. Nochmal - dein Ziel ist es, dass die WLAN Geräte miteinander kommunizieren können. Du hast ja PSPF noch in der Konfig aktiviert. Deshalb: interface Dot11Radio0 no bridge-group 1 port-protected !

Dann bitte mal die Konfig posten. (Achtung: Keine Lvl7 Passwörter und PSKs posten)

Je nachdem bei welcher SSID du das machen willst. Steht in der SSID Konfiguration ein VLAN drinnen? Falls ja, musst du das auf dem FastEthernet Subinterface konfigurieren, welches den VLAN Tag entsprechend setzt (encapsulation dot1q <ID>) Ansonsten einfach aufs FE1, falls du keine VLANs benutzt

VLAN? Sofern das kein EtherSwitch Module ist, brauchst/kannst du diesen Umweg gar nicht gehen. Das sind routed-ports (Router). Deshalb auf beide Interfaces direkt die IP-Adresse draufbügeln (ip address <IP-ADDR> <SUBNETMASK> und gut ist. Natürlich musst du auf diesem Router dann aber auch das Routing einrichten. Der Router muss ja wissen, welches Paket er zu welchem Interface / Next-Hop weiterleiten soll. Edit: Ich würd den 2811er nehmen. Die 1700 Serie ist schon ziemlich fertig (abhängig vom Modell) http://www.cisco.com/en/US/prod/collateral/routers/ps221/prod_end-of-life_notice0900aecd8064870e.html 27.03.2010 war "End of Software Maintenance Releases Date"

Das Feature nennt sich Public Secure Packet Forwarding (PSPF) Cisco IOS Software Configuration Guide for Cisco Aironet Access Points, 12.4(3g)JA & 12.3(8)JEB - Chapter 6 - Configuring Radio Settings [Cisco Aironet 1200 Series] - Cisco Systems Wie du das im Webinterface einstellst, kann ich dir nicht sagen. Das Webinterface ist böse - CLI ist gut ^^

Naja ... wenn du schon updatest, dann würd ich nicht auf 12.4(13) gehen. Das Ding ist doch schon mehrere Jahre alt. Warum nicht eine neuere 12.4(25) oder ein neueres T-Release? Also ich würde was relativ neues nehmen (wenn schon Update), was auch schon einigermaßen hochgepatcht ist. Natürlich immer vorher die Release Notes lesen und Testen!

Meiner Meinung nach ist AutoQoS das Böse schlechthin :D Das würde ich in nem Campus nie ausrollen. Hintenraus kommt das das Cisco 11 Klassenmodell mit allem PiPaPo und auch noch falschen Queues (Größen). Endgeräteports traue ich in der Regel auch nicht. Könnt ja jeder mit x-beliebigen Traffic kommen und den mit DSCP 46 markieren. Bin ein Fan von ACLs, die am Edge den Traffic markieren (Ports). Deine Siemens TK Jungs wissen, welche RTP Ports die verwenden (Range). Für die Queuing Konfiguration (Buffer Sizes, etc.) kann ich dir nur den QoS SRND von Cisco nahe legen. Der geht auf fast jede Eigenheit der Catalysten ein. Fast jede Generation von Catalyst Switches macht QoS anders - auf den modularen Kisten hängt die Anzahl der Queues und die Größen auch noch vom Modul ab. Deshalb würd ich an deiner Stelle den Guide durchlesen und danach mal daran denken QoS auszurollen. Das sollte auch ins komplette Unternehmenskonzept passen. Enterprise QoS Solution Reference Network Design Guide [Design Zone for WAN/MAN] - Cisco Systems

Ein 4500er ist natürlich modularer. Im Endeffekt ist aber der 49er nichts anderes als ein 4500 mit SUP6. Da rennt die exakt gleiche Software drauf. Natürlich musst du immer auch an die Einschränkungen denken. 1.) Die 6 integrierten 10GE X2 Ports sind nicht TwinGig kompatibel --> Falls du GE SFP Ports brauchst, musst du dir die 10GE Zusatzkarte reintun 2.) Kein NetFlow Support Die neuen 3750X könnt ich mir super im Server Access vorstellen (im Stack Verbund).

Hi, das kannst du doch auch mit dem WLC lösen. Der WLC unterstützt "Wired Guest Access" - such mal im 6.0er Configuration Guide danach.

Hi, warum ist da eigentlich ein MLS QoS Output? Wird der Traffic vom Client Richtung SQL Server irgendwie schon markiert (von der Applikation)? Schalt mal auf einem Switch das QoS aus (nur zum testen) und probier das ganze noch einmal. Falls der Traffic a la NFS sehr bursty ist, kann das schon mal Probleme machen.

Sorry, ich raff die Anforderungen immer noch nicht. VSS und ESX Server passen schon. Aber die Anzahl der User VLANs an einem VSS Päärchen wollen mir noch nicht so ganz in den Kopf reingehen. Zu der MST / VTP Geschichte: Stampfst du täglich mehrere VLANs aus dem Boden? Also in der Regel sollte das ganze doch "relativ" statisch sein. Wenn mal ein VLAN dazu kommt, dann muss man es eben überall wo es gebraucht wird anlegen bzw. konfigurieren (auf der Distribution und auf den Access Switches). Du musst ja sowieso Hand anlegen, da ja auch die Access-Ports in das entsprechende VLAN geschubst werden wollen (hoffe nicht, dass man ein "switchport trunk allowed vlan all" Richtung ESX Server macht). Außerdem würde ich wenn es schon VTP sein muss, nicht alle Switches in die Selbe VTP Gruppe stecken. Dann werden neue VLANs auch nicht auf dem gesamten Campus verteilt. Sprich, vielleicht nur die VSS Päärchen (VTP Server) und die dazugehörigen Access-Switches (VTP Client) in eine VTP Gruppe stecken. Die Server VLANs haben ja in der Regel nichts auf dem restlichen Campus zu suchen. Was ich wirklich, wirklich vermeiden würde ich ein dynamischen herumgemove von VLANs via VTP. Ich hab zwar noch nicht ganz verstanden warum du das willst, aber solche Mechanismen machen meiner Meinung nach die Konvergenzzeit im Fehlerfall eher nicht deterministisch.

Bei der Anzahl der VLANs macht irgendwas wie VTP schon Sinn - aber das hat nichts mit Spanning-Tree zu tun. Ich persönlich drehe VTP auch ab liebsten ab und verwende nur den Transparent Modus. Wie sieht denn die Netzwerktopologie im Moment aus? Man kann nicht einfach so mal sagen, dieses oder jenes Netzdesign ist gut oder schlecht. Das hängt alles von den Anforderungen ab!!! Hast du denn Stand jetzt einen gerouteten Campus? Oder ist der Campus immer noch komplett flach? Falls es ein gerouteter Campus ist, warum hast du so viele VLANs am Access? Vielleicht lieber noch eine Distribution Area reinziehen.... und und und - wie gesagt... Pauschal kann man (ich) da keine Empfehlung geben, ausser: Schau dass du von deinen vielen VLANs weg kommst ;-)) (falls das geht)

Ist vollkommen Wurscht... Als IP SLA Probe sollte die stärkere Maschine eingesetzt werden.

Lies dich nochmal in IP SLA ein. Du hast das glaube ich falsche verstanden. Eine UDP Voice Jitter Probe läuft immer zwischen zwei Routern. Einer ist der Sender, der andere der Responder. Dst. Address wäre in dem Fall der IP SLA Responder

Viel Spass beim Lesen: Troubleshooting Input Queue Drops and Output Queue Drops - Cisco Systems

Schau mal hier: WPA Configuration Overview - Cisco Systems Dieses Beispiel passt ganz gut. Die machen dort EAP mit WPA Wenn du WPA2 mit AES willst, ändert sich fast nichts. In den Dot11Radio0 Eigenschaften musst du nur statt "encryption mode ciphers tkip" das eingeben "encryption [vlan vlan-id] mode ciphers aes-ccm" In der SSID dann sowas wie: dot11 ssid <SSID> authentication network-eap eap_methods authentication key-management wpa vlan <ID> ! und dann noch den RADIUS Server anlegen aaa new-model ! aaa group server radius rad_eap server 192.168.2.100 auth-port 1645 acct-port 1646 . . aaa authentication login eap_methods group rad_eap Natürlich würde ich diese Konfig nicht so benutzen.. du kannst noch was am 802.1x tunen und bssid Support etc. anschalten. Aber ich will hier nicht alles vorkauen. Im Konfig Guide steht eigentlich alles super drinnen. "http://www.cisco.com/en/US/docs/wireless/access_point/12.4_10b_JA/configuration/guide/scg12410b.html"

Edit: Hab sogar einen Beleg für meine Theorie gefunden: ==> http://www.wi-fi.org/files/kc_11_WPA2_QandA_3-23-05.pdf Nach dem 802.11 Standard geht diese Kombination schon. Der Standard (802.11i) weiß auch gar nichts von WPA bzw. WPA2, sondern nur RSN (was WPA und WPA2 einschließt), TKIP und CCMP. Dennoch - die Geräte werden alle auf Wi-Fi Alliance Kompatibilität geprüft - und die Wi-Fi sagt: Nimm WPA2 + AES

Schau mal in den Konfig Guide: Cisco IOS Software Configuration Guide for Cisco Aironet Access Points Cisco IOS Releases 12.4(10b)JA and 12.3(8)JEC - Chapter 11 - Configuring Authentication Types [Cisco Aironet 1200 Series] - Cisco Systems Stichwort ist in der SSID Konfig "authentication network-eap" Die Cipher Suite (TKIP / CCMP) hat nicht viel mit der Authentication zu tun. Ich stelle mir eben die Frage warum WPA2 mit TKIP. Das sind solche Spezialfälle. Hardware die in der Lage ist WPA2 zu machen, sollte genau so gut AES-CCMP machen können. Ich würde generell nur folgende Cipher Suites im echten Leben implementieren: - WPA PERSONAL / ENTERPRISE (WPA1 TKIP mit PSK oder 802.1x) - WPA2 PERSONAL / ENTERPRISE (WPA2 AES-CCMP mit PSK oder 802.1x) Ich behaupte mal auch, dass das Deployment so von der Wi-Fi vorgesehen ist. Alles andere sind eher Corner-Cases

Das zeugt nur davon, dass das Tool wirklich gut sein muss, wenn es (im selben Thread) zweimal unabhängig voneinander vorgeschlagen wird *rauswind*

Wow - wer lesen kann ist sowas von im Vorteil :-) Sorry. Ist mir beim Überfliegen irgendwie durch die Lappen gegangen.

Nur der Vollständigkeit halber und für andere LDAP Probleme/Troubleshooting: Es gibt ein kleines, kostenloses Windows Tool, welches sich "Softerra LDAP Browser" nennt. Mit diesem Tool kann man sich an einen LDAP Server ankoppeln und per GUI einfach durch den LDAP Wald browsen. Außerdem sieht man auf anhieb schön die einzelnen Attribute der User bzw. Gruppen. Natürlich sieht man auch die ganzen schönen CNs, DNs und was es sonst noch alles gibt und kann das via Copy und Paste dann für die ASA (oder "wasauchimmer") Konfig verwenden.

Dann kann ich auch nicht weiter weiterhelfen, sorry. Aber noch ein paar Punkte und Wortklaubereien: Naja, ausser der Client macht einen GratArp oder einen von dir beobachteten lease-extend. Sprich das Problem hast du bei Clients mit statischer IP. Das ganze Roaming Zeug ist im 802.11 Standard nicht beschrieben. Sprich man wird im Feld mehrere Implementationen finden behaupte ich mal. Die einen Clients machen beim Roamen nichts, die nächsten machen einen GratArp und die nächsten eben deinen Lease Extend. Die letzten zwei Optionen sind eventuell sinnvoll, damit der Switch die CAM table updated. Naja, das machen halt Windows XP Clients so. Ab und zu mal ein ICMP auf das DG um zu sehen ob noch L3 Connectivity gegeben ist. Win7 macht nen regelmäßigen ARP Request auf die DG Adresse. Also im WLAN ist dann nicht von Roaming oder Mobility die Rede :-)) Zumindest hab ich das in noch keinem Buch/Weblink so gelesen. Sind das Cisco IOS APs? Welches Modell?

Natürlich ist er das nicht. Aber das könnte eine sinnvolle Implementierung sein bzw. manche Clients machen das auch. Aber selbst wenn der Client das nicht macht ist es kein Beinbruch! Ich mach mal die Geschichte weiter: Also ... Client wartet auf Antwort vom Server und bekommt also die Antwort nicht... was passiert? Der Client fragt erneut nach und bekommt dann die Pakete. Das ist doch grad der Sinn von TCP dachte ich. Aus der Praxis: Ich hatte damit wirklich noch NIE irgendwelche Probleme. Hast du ein konkretes Problem oder spielst du einfach irgendwelche wilden Corner-Cases durch? Das wäre mal ganz interessant zu wissen. Was denn nun? Lease extend oder renew? Zwei paar Schuhe! Wie soll ein Client überprüfen ob er noch im selben Subnetz ist? Klar macht das ein Client (Ping auf DG), aber eben nicht so oft. Der Client rafft schon irgendwann, dass das DG nicht mehr erreichbar ist und triggert DHCP. Das hat dann aber nichts mehr mit Roaming / Mobility zu tun, sondern mit Kabel abziehen und wieder aufstecken, wenn man es mit wired vergleichen möchte. Sei es wie es ist: Wenn du zwischen L3 Boundaries wechselst, kannst du nicht roamen - Punkt! Wie immer gibt es Ausnahmen: L3 Mobility via Tunneling bei Cisco WLC oder WDS. Aber mit diesen Technologien behält der Client seine ursprüngliche IP und wird ins alte Subnetz getunnelt. Geht das überhaupt? Der Befehl "[no] ip gratuitous-arps" auf den Switches ist doch sowieso ein Blender, oder? Wenn ich als Client ein ARP Paket auf die Broadcast Adresse haue, dann kommt das doch immer durch. Zumindest sagt das mein Labor :-) @Pinkman: Worauf willst du eigentlich hinaus? Hast du ein konkretes Problem oder ist das ganze akademischer Natur?