Jump to content

Nightwalker_z

Members
  • Gesamte Inhalte

    207
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Nightwalker_z

  1. Der AP macht erst mal gar nichts. Der Client schickt normalerweise einen Gratuitous ARP - das hängt aber vom Supplicant ab. Richtig. Aber der Client könnte einen Gratuitous ARP schicken - der Client bekommt ja mit wenn er wechselt. Schließlich ist ja das Roaming eine reine Clientsache. Normalerweise geht aber der Verkehr vom Client aus. Sprich der Switch lernt ziemlich schnell die neue MAC am anderen Port. Das ist ganz falsch. Das wäre ja für das Layer-2 Roaming tödlich, wenn der Client einen DHCP renew machen würde. Dann würden ja alle bestehenden TCP Verbindungen sowas von abbrechen. Der Client macht beim Roaming keinen neuen DHCP Request! Natürlich müssen beide APs im selben Subnetz sein.
  2. Machs in kleinen Schritten... 11dBm ist schon ziemlich wenig (12,5 mW). Ansonsten, falls du ein Wartungsfenster bekommst - einfach ausprobieren. Wenn du einen IOS AP hast musst du die "dot11 aironet extensions" aktiviert haben damit das ganze tut glaube ich.
  3. Ich würde ganz klar sagen: "It depends" :-)) Also der AP und das Telefon sollten von der Sendeleistung gleich weit kommen. Also der AP sollte nicht stärker aussenden als es das Telefon tut und andersrum (Unidirectional Streams). Wegen der Sendeleistung. Das hängt von deiner WLAN Umgebung ab. Hast du mit 5bBm immer noch genügend Sendeleistung, damit du deine AP erreichst? --> Site Survey :-)
  4. Sorry - was ist ein ME? Das hört sich nach nem Client Problem an.
  5. Sorry - ich steig echt bald aus :suspect: ok - der Homeserver soll den DHCP Server spielen. Check! Also doch DHCP auf der ASA? Oder vielleicht doch dem WLAN Controller? Am besten beides? :D 1.) Entscheide dich welches Gerät den DHCP Server spielen soll. Entweder der WLC oder die ASA oder der HomeServer! Falls es der HomeServer sein soll, musst du das DHCP Relay auf dem WLC Richtung Homeserver einrichten. Deine ASA braucht nur eine ACL, dass der DHCP Unicast von der IP des WLC - Userinterfaces zum Homeserver erlaubt wird (auch der Rückweg!). Falls der DHCP Server auf dem WLC laufen soll, brauchst du keine DHCP spezifische Konfig auf der ASA. Die ASA bekommt von der DHCP Magic gar nichts mit! Falls die ASA DHCP Server sein soll, gibt es zwei Möglichkeiten: - Entweder die DHCP Proxy Funktion des WLCs muss deaktiviert werden, dass die original DHCP Discovery Message (Broadcast) des Clients an der ASA ankommt. - Oder du lässt den DHCP Proxy am WLC an. Der DHCP Discover (Broadcast) wird vom WLC abgefangen und per Unicast an die ASA geschickt. So - welche Geschmacksrichtung hast du jetzt ausprobiert? Kleiner Tipp: Lies dir in aller Ruhe die Dokumente durch, auf die ich im ersten Post verwiesen habe. Ahso, noch eine Frage: Wozu? Das ist doch prinzipiell viel unsicherer als WPA2 mit 802.1x zu nehmen. Soll das ein Guest-Network werden? Wie schon Wordo gesagt hat - geh schrittweise vor. Lass vielleicht zuerst mal die Verschlüsselung und Auth weg und stell basic-IP connectivity her. Eines nach dem anderen
  6. Entschuldige die Frage - aber testest du mit mehr als einem WLAN Client? Das hört sich für mich stark nach nem Client Problem an. Hast du schon mal gecaptured, was für DHCP Messages geschickt werden? Richte vielleicht mal einen Span Port an dem WLC Interface Richtung DHCP Server ein und capture mit. Ansonsten verstehe ich deine Aussage bezüglich 802.1x / IAS nicht wirklich. Du sagst, dass du WPA2 nutzt, weil du RADIUS nicht ans rennen bekommst. Sorry, das eine hat mit dem anderen gar nichts zu tun bzw. das schließt sich nicht aus! Erlaube mir bitte nochmal die Frage: Was hast du eigentlich im Detail vor? Welche Security Policys gelten? Ist 802.1x für WLAN gesetzt oder werden PSKs verwendet? Ich hab echt den Faden verloren, was eigentlich die konkrete Zielsetzung ist...
  7. Sorry wenn ich nur kurz und knapp drauf eingegangen bin, aber diese Fragen sind nicht spezielles, sondern nur Basics. Les die Dokumente und dann dürfte eigentlich alles klar sein. Vielleicht holt ja ein anderer Boardie noch etwas mehr aus, aber ich persönlich weiß bei den ganzen und offenen Fragen nicht, wo ich anfangen und aufhören soll. Für mich hört sich das Ganze so an, als würdest du eine gesamt WLAN-System Konzeption brauchen.
  8. Hier erst mal ein Dokumentverweis. Wenn du die Dinger durch hast, dann sind deine Fragen beantwortet: Enterprise Mobility 4.1 Design Guide [Design Zone for Mobility] - Cisco Systems Deploying Cisco 440X Series Wireless LAN Controllers - Cisco Systems Die ASA als DHCP Server oder DHCP Relay konfigurieren. Für das WLAN VLAN im WLC, fügst du als DHCP Server die VLAN IP der ASA ein. Verstehe die Frage nicht. Layer-2 oder Layer-3 roaming. Kleiner Leitsatz: Ausser bei Cisco WLAN Clients ist Roaming eine reine Clientsache! Natürlich brauchst du für Roaming mehrere APs :suspect: , welche alle die Selbe SSID zur Verfügung stellen. Je nach Größe, Konzept und flächenmäßige Trennung, segmentiert man das ganze noch in verschiedene Subnetze und macht Layer-3 Roaming. Dafür kann dir hier aber bestimmt niemand eine Pauschalempfehlung geben - das hängt echt von den lokalen Gegebenheiten ab! Hier verweise ich auf den "Mobility Design Guide" Keinen Blassen was da falsch läuft. Deine Clients haben sich mit dem WLAN verbunden und ne IP über DHCP bezogen. Was ich noch checken würde: - Router Option beim DHCP vergessen? (Default Gateway fehlt) - DNS Option beim DCHP vergessen? (keine DNS Auflösung) - Ping Default Gateway (ASA) - Namensauflösungstest Ich schätze es wird an irgendeiner ACL auf der ASA oder so liegen. Warum hast du eigentlich ACLs auf dem Controller, wenn sowieso direkt hinter dem WLC die ASA ist? Das würde ich mir wenn es geht sparen, da das normale (non-Stateful) ACLs sind. Das Logging und Management von solchen ACLs finde ich persönlich nicht so dolle! Verstehe die Frage schon wieder nicht. Stinknormales Routing und Switching? Vielleicht an der ASA noch was freischalten?! Denk daran: WLAN ist prinzipiell unsicher und macht an der Geländegrenze in der Regel nicht halt. Wenn nur schwache Authentifizierung und Verschlüsselung eingesetzt werden, würde ich das Netz Richtung innen nicht sperrangelweit aufmachen. Ich persönlich sehe alle mit einem gemeinsamen Schlüssel (WEP, WPA PERSONAL, WPA2 PERSONAL, schwache EAP Methoden, gemeinsame EAP Credentials) als unsicher an. Aber das hängt von der Security Policy deines Ladens ab. Auch hier wirst du nichts pauschales bekommen, denke ich. Sorry - das sind ja wirklich Basics. Ich rate dir echt mal die Doku zu lesen! Ansonsten wirst du beim Betrieb des Dings nicht glücklich. Aber in der Kürze: AAA Konfig entweder in der SSID oder global. Die AAA Server konfigurierst du in der Management Section glaube ich. Firewall Freischaltungen vom WLC zum AAA nicht vergessen! Mein Vorgehen: WPA2 ENTERPRISE (802.1x) mit einer sicheren EAP Methode (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST) Oder eben nur eine PSK Verschlüsselung und die Firewall ziemlich dicht machen! Für sowas sucht man da auch nicht unbedingt (Konfig). Auf der Cisco Seite findest du alles was du brauchst - und mehr. Neben den Dokumenten oben rate ich dir zu aller erst mal den "Software Configuration Guide" zu Lesen: Cisco Wireless LAN Controller Configuration Guide, Release 5.2 - Cisco Systems Das ist für die 5.2er Software. Wie gesagt, du wirst auf CCO fündig. Du kannst die Doku für die 4400 Controller benutzen.
  9. Naja, ist Geschmackssache. Bei VTP scheiden sich die Geister :-)) Aber an den Endgeräteports muss man doch sowieso "switchport access vlan xy" machen, vielleicht noch DAI, STP usw. für das VLAN anpassen. Da kommt es auf eine, maximal zwei Zeilen in der Config auch nicht an: ! vlan 12 name VLAN 12 ! Aber das ist meine persönliche Meinung. Ich finde halt, dass man mit VTP mehr Stress hat als ohne (Security, Management usw)
  10. Mach doch "vtp mode transparent" Dann steht die VLAN konfiguration in deiner running-config. Bin sowieso kein Freund von VLAN provisioning via VTP. Warum nicht einfach die VLANs auf jedem Switch manuell anlegen. Dann hat man auch nicht den Stress mit vlan.dat und co. Außerdem gab es rund um VTP auch immer gewisse Angriffsvektoren (VLAN DB löschen bei höherer Revision indem man den Server spooft). Mir ist klar, dass man durch Authentication und Endgeräteportabsicherung das ganze unterbinden kann - aber wie gesagt - ich sehe den Sinn in VTP Client/Server nicht. Übrigens, Cisco wohl auch nicht :-) Habt ihr euch schon mal nen Nexus 7000 angeschaut? Dort gibt es keinen VTP Client/Server mehr.
  11. Bei den ganzen Switchkarten (4, 24 Port ...) für die Router musst du höllisch aufpassen. Das sind alles keine richtigen Router-Ports, sondern nur Switchports. Ich denke man kann die zu L3-Ports machen (no switchport). Dennoch hast du dort sehr beschränkte bzw. keine QoS und andere Router Features. Habe zumindest noch kein Catalyst alike QoS Zeug gesehen. Also es hängt eben davon ab was du tun willst bzw. wozu die Ports genutzt werden sollen! Auf dem Router hast du normalerweise 2 WIC und 1 NM Port. Schau mal hier rein: Cisco 2600 Series Multiservice Platforms Relevant Interfaces and Modules - Cisco Systems
  12. Wie gesagt: 1 Access VLAN per Switch und dann auf der L3 Distribution mit ACLs arbeiten. Darf ich fragen, was die Anforderung ist, bzw. was der Grund für deine Anforderung ist?
  13. Hi, sorry, verstehe ich nicht ganz: Du hast ein und dasselbe Subnetz über mehrere Access Switches verteilt, schreibst aber, dass du an der Distribution Area, nur via L3 verbinden willst? Irgendwie passt das nicht zusammen :D Wie gesagt, vielleicht habe ich es auch nur falsch verstanden. Vielleicht ist ja eine Lösung, dass ein Subnetz nur auf einem Access-Switch existiert. An der Distribution-Area dann ACLs auf das L3 SVI Interface setzen und fertig. Die inter-Client Kommunikation innerhalb eines Switches wird mit den protected Ports unterbunden. Hier noch ein Auszug aus CCO: Private Vlan Edge (protected ports) - Cisco Systems
  14. Sprich aus der Wand kommen zwei RJ-45 Buchsen. Eine für die Telefone (Voice-VLAN) und eine Buchse für die PC's (Data-VLAN). Du hast das Problem, dass sich jemand einfach so in die Voice Büchse einstöpseln kann, richtig. Drei Lösungsmöglichkeiten: 1.) ACL auf der L3 Instanz des Voice VLANs (Achtung: Any Voice VLAN to Any Voice VLAN mit Signaling, Voice und Management Ports) **** ist, dass je nach Größe des Netzwerks die ACL riesig werden kann - ist schlecht zu händeln. 2.) Benutze das Voice VLAN Feature auf den Cisco Switches. Dann erwartet der Cisco Switch für das Voice VLAN getaggten Traffic. Normalerweise hat man das an nem PC nicht (ausser man fummelt etwas - das ist dann aber schon böswillige Absicht). 3.) 802.1x für die Telefone
  15. Richtig - aber das hat ja nichts mit der ACL auf dem L3-Device an sich zu tun :)
  16. Die Frage ist, warum du ein Problem damit hast? Ich sehe kein Risiko darin, dass jeder Client aus dem Subnetz auf die Broadcast-Adresse mit den BootP Ports darf. Falls du auf dem Interface auch noch eine OUT ACL gebunden hast, musst du halt die Antwort des DHCP Servers auch noch frei schalten. Achtung, das ist ein anderer Port (eine Nummer höher glaube ich)
  17. ok ... wie gesagt: Dein TS Router hat lokal jetzt 2 Layer-3 Interface. Einmal das auf dem VLAN1 (L3 Interface für die Switchkarte) und das FE0/0 (Uplink). Zwischen diesen Netzen kann der Router per Default routen, wenn "ip routing" aktiviert ist (locally connected). Ich würde auf die Switchkarte (Ports) auch mal eine gescheite Switchkonfig drauf hauen. interface FastEthernet1/0 switchport mode access switchport access vlan 1 ! Default spanning-tree portfast ! Falls dahinter Endgeräte sind - sonst kommt der Port nach dem Anstecken erst nach 30 Sekunden richtig hoch ! Kannst du von einem Endgerät, welches auf der Switchkarte angesteckt ist das VLAN1 Interface pingen (192.60.0.1)? Natürlich müssen die Endgeräte am Switch auch in diesem Subnetz sein. Falls das geht, kannst du von einem Endgerät hinter dem Switch das FE0/0 interface pingen?
  18. Hi, das sollte eigentlich schon gehen. Du musst gleichzeitig STRG, SHIFT und 6 drücken, die Tasten loslassen und dann sofort die Taste x drücken. Das geht natürlich nur, wenn du direkt auf den TS gegangen bist (TELNET, SSH, CONSOLE) und von dort aus den Reverse Telnet auf die Lines gemacht hast (telnet <LOCAL-IP> <PORT>). Das verstehe ich immer noch nicht ganz. Lass es mich noch einmal wiederholen: Dein FE0/0 Interface (192.168.0.245) geht Richtung LAN (internes Netzwerk). Das VLAN1 ist das Default Gateway für die Admin-Interfaces. Wenn ein Paket auf dem Router (TS), über das Interface FE0/0, für ein Endgerät im VLAN1, reinkommt, dann routet das dein TS automatisch weiter. Die Netze sind am TS locally connected. Du musst eben dafür sorgen, dass in deinem internen Netz (hinter dem TS), das VLAN1 bekannt ist und es Richtung 192.168.0.245 geroutet wird. Je nach der Größe deines internen Netzes kannst du das mit statischen Routen machen, oder du schaltest am TS Richtung LAN ein dynamisches Routingprotokoll an. Am TS musst du meiner Meinung nach nichts mehr tun. Ist im restlichen Campus das VLAN1 bekannt (192.60.0.0 255.255.192.0). Sprich wird in letzter Instanz das Netz an deinen TS/Router geroutet?
  19. Ich denke, dass deine Line Config in Ordnung sein sollte. Was ich nicht ganz raff ist deine Zone-Based Firewall. Du legst fest, dass Interfaces Member einer Zone sind, aber hast keinerlei Filterregeln definiert?! Keine Inspects, kein gar nichts? Warum?
  20. Also prinzipiell ist es egal von welchem IP Interface du auf die seriellen Lines zugreifen willst. Das geht von jedem Interface aus. Du greifst entweder von remote auf das Ding via Reverse Telnet zu, oder eben vom Router aus via Reverse Telnet. Welche Ports nutzt du für das Reverse Telnet? Die Ports für die Lines sollten tcp/2065-2096 sein. Ich hab noch nicht ganz das Problem verstanden. Die Ausgangssituation ist folgende: - TELNET auf jede Line geht - Mit SSH klappt der Zugriff auf die Lines nicht. Falls eine Konsole mal nicht funktioniert, kann es sein, dass sie noch in Benutzung bzw. aktiv ist (Wir durch den * angezeigt). Du hast das TELNET Fenster geschlossen, aber die Session ist noch oben. Zwei gleichzeitige Zugriffe auf eine serielle Konsole gehen nicht. Du musst dann die Verbindungen vom Router aus trennen. disconnect <LINE-NUMBER> Lange Rede kurzer Sinn: - Ich denke nicht das sowas wie "Reverse SSH" geht. Wenn es verschlüsselt sein soll, mach SSH auf deinen Terminalserver und verbinde dich von dort auf die Lines. Dann kannst du auch die Sessions richtig clearen, wenn du fertig bist ("Ctrl-Shift-6 danach x" um auf den TS zurückzukommen, danach "disconnect") eingeben. - Wenn einige Lines funktionieren und andere nicht, dann kann es am Kabel (andere Kodierung) liegen. Aber du hast nur Cisco Equipment mit einer RJ-45 Konsole angeschlossen, richtig? - Ein weiterer Grund, warum ein Endgerät funktioniert und das andere nicht, können auch falsche Speed/Parity/Stopbits Settings sein. Falls ein Gerät was anderes will, muss das in der "line" configuration angepasst werden. Edit: Ich habe bei Cisco noch kein SUPER Dokument für dieses Thema gefunden, aber diese Links solltest du dir dennoch mal durchlesen: http://www.cisco.com/en/US/tech/tk801/tk36/technologies_configuration_example09186a008014f8e7.shtml http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080093c32.shtml
  21. Klar gibt es das. Cat6500; Cat4500; Cat4900M; Nexus 5000; Nexus 7000 und die Liste ist noch viel länger :-)
  22. Die Alternative ist in den Data-Sheets zu schauen ob die AP's das hergeben: Cisco Aironet 1100 Series Access Point Data Sheet: Cisco Aironet 1100 Series Access Point Data Sheet [Cisco Aironet 1100 Series] - Cisco Systems 1130er Data Sheet: Cisco Aironet 1130AG IEEE 802.11 A/B/G Access Point [Cisco Aironet 1130 AG Series] - Cisco Systems 1140er Data Sheet: Cisco Aironet 1140 Series Access Point [Cisco Aironet 1140 Series] - Cisco Systems usw. Auf der Product Seite von Cisco kannst du die Data Sheets der einzelnen Modelle einsehen. Aussage ohne Gewähr: Ich denke alle APs können WPA2. Beim 1120er bin ich mir nicht sicher. Ob die Software WPA2 unterstützt weiss ich nicht. Aber da du ja einen Wartungsvertrag hast, kannst du ja updaten. Wichtig ist, dass die HW das Zeug kann.
  23. Das können auch 20000 Tools (die auch völlig legal sind).
  24. Nochmal ich - also in deinem Beispiel (Voice VLAN/WLAN): Auf deinem Switch konfigurierst du einen 802.1q Trunk (Vlan1 - native; Vlan 10 - Voice SSID). Beachte aber, dass das VLAN nicht als Voice VLAN konfiguriert ist (das ist nur für IP Phones, die direkt am Switchport hängen). interface FastEthernet0/0 switchport mode trunk switchport trunk encapsulation dot1q switchport nonegotiate switchport trunk allowed vlan 10 ! Blafasel :-)) Für den AP hab ich hier schon mal was geschrieben: http://www.mcseboard.de/cisco-forum-allgemein-38/zusammenfassung-wlan-einstellungen-air-ap1232ag-73401.html Schau mal in den untersten Codeschnipsel (mit VLANs).
×
×
  • Neu erstellen...