Mein Cisco Wireless Home Lab mit Cloud-WLAN-Controller einrichten und konfigurieren

Ich habe mein kleines Heimnetzwerk etwas aufgemotzt und habe zum Üben Netzwerk- und WLAN-Produkte aus der Cisco Welt gekauft. Gebraucht versteht sich. Und das sogar recht preisgünstig, denn zum Üben brauche ich nicht die neueste Hardware. Begleitet mich dabei, wie mein neues Cisco WLAN Home Lab entsteht – in 8 Schritten!

Zum Aufbau meines Cisco Wireless Home Labs mit gratis WLAN-Controller habe ich bei eBay-Kleinanzeigen folgende Hardware gekauft: 2x Cisco Catalyst Switch, 3x Cisco AIR-CAP2702I Access Points, 1x Dell PowerEdge R710 Server. Bereits vorhanden war 1x Mikrotik Router. Als WLAN-Controller verwende ich die Cloud-Version des neuen Cisco WLAN-Controller Catalyst 9800-CL, diese ist 90 Tage kostenlos evaluierbar und läuft unter VMware ESXi (kostenfrei).

Schritt 1: Die Komponenten meines WLAN Home Lab mit Cisco, Dell und Mikrotik

Mein Einkauf bei eBay-Kleinanzeigen. Ich hatte Glück und konnte sehr preiswert zuschlagen, dafür ist die Hardware aber nicht die neueste. Zum Lernen genau richtig!

Mein Lab besteht aus den Komponenten wie oben abgebildet, nur der Aufbau auf dem Bild ist noch nicht final. LAN-Kabel, Kaltgeräte-Stecker und einen kleinen Mikrotik-Router hatte ich bereits. Zudem wird noch ein Bildschirm (am besten mit altem VGA-Anschluss oder passendem Adapter), ein VGA-Kabel, ein serielles Konsolen-Kabel sowie eine USB-Tastatur benötigt. Ach ja, einen USB-Speicherstick zur Installation vom VMware ist sicherlich auch nicht verkehrt. Und Putty. Und Rufus!

Typ	Komponente	Anzahl	Beschreibung	Preis
Hardware	Mikrotik RB962UiGS-5HacT2HnT	1	Verwendung als Router zum WLAN-Lab. Gateway, Inter-VLAN-Routing und DHCP-Server. Static DNS. Firewall.	Bereits vorhanden
Hardware	Cisco WS-C3560V2-24PS-S V08	1	24-Port Layer3-Switch. 100MBit/s, 802.3af-PoE, VLAN.	Bei eBay-Kleinanzeigen für 35 Euro inkl. Versand.
Hardware	Cisco WS-C2960-24PC-L V06	1	24-Port Layer2-Switch. 100MBit/s, 802.3af-PoE, VLAN.	Bei eBay-Kleinanzeigen für 35 Euro inkl. Versand.
Hardware	Dell PowerEdge R710	1	4-Port Rack Server. 2x Xeon X5670 je 6 Kerne / 12 Threads (2,93 GHz, max. 3,33 GHz), 64 GB RAM 1333 MHz ECC, 2x SAS Festplatte je 1 TB, RAID-Controller. Verwendung zur Virtualisierung des Cisco WLAN Controllers (und weiterer VMs).	Bei eBay-Kleinanzeigen für 170 Euro inkl. Versand.
Hardware	Cisco AIR-AP2702I-E-K9	2	WLAN 5 802.11ac “Wave 1” Lightweight Access Point, 3×4 MIMO mit 3 Spatial Streams, ETSI Regulatory Domain.	Bei eBay-Kleinanzeigen für 62 Euro inkl. Versand.
Hardware	Cisco AIR-AP2702I-UXK9	1	WLAN 5 802.11ac “Wave 1” Lightweight Access Point, 3×4 MIMO mit 3 Spatial Streams, Universal Regulatory Domain (brauche ich für einen speziellen Test).	Bei eBay-Kleinanzeigen für 33 Euro inkl. Versand.
Software	VMware ESXi Hypervisor 6.7	1	Hypervisor für verschiedene VMs auf dem Dell PowerEdge R710, unter anderem Cisco WLAN-Controller Catalyst 9800-CL	Kostenfrei mit Evaluierungslizenz ohne Ablaufdatum.
Software	Cisco Catalyst 9800-CL Wireless Controller for Cloud	1	WLAN-Controller für Cisco APs (802.11ac Wave 1 und Wave 2, Cisco Catalyst 9100 802.11ax Access Points)	Kostenfrei mit Evaluierungslizenz für 90 Tage ab Installation.

Komponenten meines Cisco Wireless Home Labs

PoE-Switches und WLAN-5-Access-Points von Cisco

Weshalb ich mich für die obigen Komponenten entschieden habe, ist schnell erklärt. Ich suchte nach preiswerter Ausrüstung, mit der ich viele Anwendungsfälle in meinem Lab abdecken kann. Mir besonders wichtig: PoE, damit die 2702-APs auch darüber funktionieren und ich Ports am Switch abschalten und Access Points somit auch physisch neu starten kann. Zwar haben die Switches nur PoE nach 802.3af, meine gebrauchten Access Points können damit aber betrieben werden, wenngleich sie auf 3×3:3 MIMO herabfallen (statt 3×4:3 MIMO mit 802.3at).

Statt den neuesten Access Points von Cisco habe ich mich für die 2702er APs entschieden, welche aber noch mit dem Catalyst 9800-CL WLC kompatibel sind. Dafür sind sie kostengünstig. Später kann ich sie bei Bedarf durch neuere Modelle mit WLAN 6 ersetzen.

Ebenfalls einem günstigen Preis geschuldet ist die Tatsache, dass meine beiden Switches nur 100-MBit/s-Ports haben. Vielleicht werde ich künftig schnellere Hardware ergattern. Dann könnte ich auch die volle Geschwindigkeit der APs ausreizen und ich könnte Cisco APs in meinen Speedtest aufnehmen. Vorerst ist mein Plan, die SFP-Ports dafür zu missbrauchen. Wir werden sehen, ob das so einfach ist. Alles in Allem komme ich für die Cisco-Komponenten auf 165 Euro. Ich bin zufrieden.

Dell PowerEdge R710

Mehr Geld als für die Cisco-Komponenten habe ich für den Dell PowerEdge R710 ausgegeben. Ohnehin war ich schon lange auf der Suche nach einer Lösung zur Virtualisierung. Die Idee, damit nun kostengünstig einen WLAN-Controller von Cisco zumindest kurzfristig (90 Tage) gleich mitzubetreiben, motivierte mich zusätzlich.

Denn oft wird für WLAN Home Labs der „günstige“ WLAN-Controller Cisco WLC 2504 mit 5 Lizenzen empfohlen. Dieser ist allerdings nicht mehr state-of-the-art. Schließlich werden die neuen Generationen von Cisco Access Points nur auf dem Catalyst 9800 WLC unterstützt. Und ich möchte keine alte Technik studieren. Obwohl des Alters lag der günstigste Preis der besagten Appliance Cisco WLC 2504 bei immer noch etwa 170 Euro.

Für die Kosten eines alten Cisco WLC 2504 konnte ich mir also auch gleich den Server von Dell gönnen und mein Wireless Home Lab so noch um eine Lösung zur Virtualisierung erweitern. Mit dem Dell PowerEdge R710 habe ich die Möglichkeit, mein Testlabor um weitere Elemente zu ergänzen und gleichzeitig Erfahrungen beim Thema Virtualisierung sammeln. Für mich ist das gut investiertes Geld, zumal ich ohnehin nur die kostenfreie Version 6.7 des VMware ESXi Hypervisors nutzen wollte. Dieser wird dann unter anderem die VM mit dem Cisco WLC 9800-CL bereitstellen.

Schritt 2: Netzwerk-Topologie und Aufbau

Als Gateway, Router bzw. Firewall dient mein kleiner Mikrotik hAP ac, welchen ich noch rumliegen hatte. Für mein Wireless Home Lab wollte ich mich nicht gleich mit Cisco-Routern überfordern, es soll ja ein WLAN-Lab werden. Zudem kenne ich mich mit Mikrotik und deren RouterOS ganz passabel aus. Der Router schafft in der von mir geplanten Konfiguration die magischen 1 GBit/s locker und hat Funktionen für NAT und Firewall (iptables) gleich mit eingebaut. Das Gerät kann zudem VLANs und stellt gleichzeitig einen vielseitigen DHCP-Server zur Verfügung. Zusammen mit den oben beschriebenen Netzwerkgeräten ergibt das den folgenden Aufbau.

So sieht mein Cisco Wireless Home Lab aus, welches wir in den folgenden Schritten gemeinsam aufbauen werden.

Die VLAN-Konfiguration

Native VLAN / Untagged

Mein Testnetzwerk besteht aus 3 VLANs: VLAN 8, 44 und 99. Die IDs und Namen lassen sich völlig frei vergeben. Eine Sonderrolle nimmt VLAN 8 ein, denn es ist das sogenannte native VLAN: Endgeräte bzw. deren Datenverkehr ohne VLAN-Tag nach 802.1Q landen immer im VLAN 8, gleichzeitig wird ein eventuell vorhandener VLAN-Tag im native VLAN entfernt. Bei Cisco heißt das dann native VLAN und Mikrotik nennt das gleiche dann untagged VLAN. Es ist sozusagen das Basis-VLAN, ohne VLAN-Tag. Sicher gibt es bessere Erklärungen, aber mir reicht das. Schaut euch meine konkrete Konfiguration für Mikrotik und für Cisco an, dann sollte das Thema klar werden. Man muss das Konzept aber recht genau verstehen, wenn man herstellerübergreifende Komponenten verwendet, wie in meinem Fall mit Mikrotik als Router und Switches von Cisco.

Zusamengefasst: Wann immer ich ein Endgerät an einem mit VLAN 8 konfigurierten Access-Port des Switches anschließe, landet es im native VLAN und verlässt den Switch über einen Trunk-Port untagged in Richtung Router.

Ist ein Access-Port am Switch nicht auf VLAN 8 konfiguriert, sondern hat noch Default-Konfiguration, landet es im Default-VLAN 1. Wenn VLAN 1 am Trunk-Port erlaubt ist, dann kommt es beim Router mit VLAN Tag 1 an. Ist es am Trunk-Port nicht erlaubt, wird es verworfen.

Dasselbe gilt für einen entsprechend konfigurierten Trunk-Port mit native VLAN 8: Wird eine Komponente angeschlossen, welche keine VLAN-Tags sendet, landet die Komponente automatisch im native VLAN 8.

Da ich dem VLAN-8-Interface auf den Cisco Switches eine IP-Adresse vergebe, spricht man auch vom sogenannten Management-VLAN. Ein Endgerät im Management-VLAN 8 kann dann den Switch über dessen Layer-3-Adresse aufrufen. Auch dem Untagged-VLAN-Interface des Mikrotik Routers gebe ich eine IP-Adresse zwecks Management.

Warum eigentlich VLAN-ID 8? Nun, dass ist schnell erklärt, denn auch in meinem produktiven Heimnetzwerk hat mein Management-VLAN die ID 8. Nachdem VLAN 7 seit ich denken kann für den Telekom-Anschluss reserviert war, hatte ich einfach um 1 nach oben gezählt.

Tagged VLAN

VLAN 44 und 99 sind beide tagged VLANs. Ich nutze Sie, um Datenverkehr vom Management-Traffic zu trennen. Jede WLAN-SSID im Testnetz wird in ein eigenes VLAN geleitet. So kann man den Datenverkehr solide trennen, beispielsweise Gast-WLAN vom regulären WLAN. Beide VLANs haben kein Layer-3-Interface, also keine IP-Adresse.

Default Gateway und NAT

Alle VLANs dürfen über den Mikrotik Router (Default Gateway) ins Internet. Genauer gesagt schottet der Router das Testnetzwerk von meinem produktiven Heimnetzwerk ab, das ganze Cisco Wireless Home Lab befindet sich dort im VLAN 193. Im VLAN 193 kommen die Geräte nur zum Default Gateway, d.h. ins Internet.

Mein Router von Mikrotik hat eine Firewall basierend auf iptables, welche man von Linux kennt. Sie schottet mein Testnetzwerk zusätzlich vom produktiven Netzwerk ab und blockiert gleichzeitig das Routing im Testnetzwerk zwischen den VLANs 8, 44 und 99. Ohne die passenden Firewall-Regeln würde der Router nämlich genau das tun, wozu er eigentlich gedacht ist: Zwischen den Netzen und VLANs routen. Schaut euch meine Konfiguration gerne an.

In der Mikrotik-Firewall nutze ich Source-NAT, so tauchen meine ganzen Lab-Komponenten nicht als Clients im produktiven Netz auf. Lediglich der Mikrotik Router ist mit seiner IP-Adresse im VLAN 193 als Client sichtbar, unabhängig davon wie viele Komponenten und (WLAN-)Endgeräte im Cisco Wireless Home Lab aktiv sind. So behalte ich immer den Überblick im produktiven Netzwerk und kann mich im Testnetzwerk austoben. Ob dies so der Lehre entspricht? Mir egal, ich mache es eben so. Das ist ja das Schöne am Testen im Lab zu Hause.

DHCP

Eine kurze Anmerkung zum DHCP. Mein Mikrotik Router stellt pro VLAN einen DHCP-Server zur Verfügung. Üblich ist, dass nur Endgeräte ihre IP-Adressen per DHCP erhalten, für Netzwerkkomponenten ist das eher unüblich. Da sich die IP-Adressen nicht wirklich ändern sollten, werden oft statische Adresse vergeben. Dynamische Adressen würden die Verwaltung unübersichtlich, kompliziert und kaum dokumentierbar machen.

Was außerdem für statische IP-Adressen spricht: Wichtige Netzwerkkomponenten sind selbst dann noch verfügbar, sollte der DHCP-Server seinen Dienst verweigern. Der Router mit DHCP-Server hat verständlicherweise statische Adressen pro Interface konfiguriert.

Genau das Gegenteil zum verbreiteten Ansatz mache ich allerdings in meinem Test-Lab: Außer dem Router erhält nur der WLAN-Controller eine statische IP-Adresse. Die anderen Netzwerkgeräte bekommen eine dynamische IP-Adresse, die sich bisweilen ändern kann. So kann ich die IP-Adressen nicht auswendig lernen. Denn im realen Umfeld, beispielsweise großen Unternehmensnetzwerken, kann man sich kaum alle relevanten Adressen der Switches merken. Man braucht andere Methoden, um die richtigen Switches samt IP-Adresse / Hostname zu identifizieren. Da ich vorerst nur zwei Switches habe, ahme ich so etwas Komplexität nach. Denn auch hier gilt: In meinem Lab darf ich alles tun, was mir beim Verstehen der Technologie und passender Methoden hilft. Ich möchte mich folgenlos ausprobieren.

Wie erwähnt bildet der WLAN-Controller eine Ausnahme. Dieser ist wie auch in großen Profi-Netzwerken fest definiert. Neue WLAN-Access Points finden über das native VLAN erstmals den Weg zum WLAN-Controller. Wenn die VLANS am Port nicht matchen oder Ports falsch definiert sind (zum Beispiel als Access Port statt als Trunk Port), kann diese feste IP-Adresse beispielsweise per statischem DNS-Eintrag oder noch besser direkt über DHCP (Option 43) mitgegeben werden. Genau das habe ich vor.

Schritt 3: Konfiguration des Mikrotik Routers mit VLAN, DHCP, NAT und Firewall (Router-on-a-stick)

Genug des Vorspiels, fangen wir mit der Konfiguration der Komponenten an. Den Anfang mach der Mikrotik RB962UiGS-5HacT2HnT. Zum Aufwärmen, denn mit Mikrotik samt RouterOS kenne ich mich bereits aus. Ziel ist es zunächst, die Einstellungen für VLAN und DHCP vorzunehmen. Danach folgt dann Firewall samt NAT.

Wir starten mit der Default-Konfiguration des Mikrotik. Zum Zeitpunkt dieses Artikels ist die Version 6.49 von RouterOS aktuell.

Erster Start des Mikrotik hAP ac und Default-Konfiguration.

Das Skript der Default-Konfiguration hat der Router beim Zugriff über Winbox direkt eingebaut. Die Winbox ist ein Tool, mit dem bequem auf den Router zugegriffen werden kann. Entweder per Layer 2 (Rechner muss direkt am Router angeschlossen werden oder im gleichen Layer-2-Netz sein) oder per Layer 3 (IP-Adresse). Wie genau Winbox funktioniert, erklärt euch das Wiki von Mikrotik.

VLANs anlegen und IP-Adressen vergeben

Zunächst legen wir die VLANs an, wie im Kapitel zur VLAN-Konfiguration definiert. Dazu im linken Bereich den Menüpunkt „Interfaces“ anklicken, im nun sichtbaren Fenster dann den Reiter „VLAN“ auswählen.

VLANs anlegen in Mikrotik: Interfaces -> Reiter VLAN. Name des VLANs vergeben, VLAN ID festlegen und Interface (=Port) auswählen, auf dem das VLAN aktiv sein soll.

Mit dem Plus in der Ecke links oben wird ein neues VLAN erstellt. Hier geben wir zunächst nur den Namen des VLANs ein, dann vergeben wir die VLAN ID und wähle das passende Interface, also den Port aus, auf dem das VLAN aktiv sein soll. Das machen wir sowohl für VLAN 44 und VLAN 99.

Das native VLAN 8 wird hier nicht angelegt: Da es untagged zum Router kommt, also ohne 802.1Q-Tag, brauchen wir kein weiteres VLAN am Interface hierfür anlegen. Die Frames des native VLAN landen sozusagen am Interface (ether2_switch-trunk) selbst. Eben untagged.

Übrigens: Dieses Konzept nennt sich auch „Router-on-a-stick„, d.h. mein Netzwerk ist mit dem Router nur über ein Kabel verbunden. Über diesen Trunk läuft dann das gesamte Routing zum WAN-Port ab.

Wer sich besser auskennt, kann die Konfiguration natürlich auch über CLI machen. Entweder direkt aus Winbox heraus (Menüpunkt „Terminal“) oder per Tools wie Putty. Nutzt dann die folgenden Befehle für das Anlegen der VLAN-Interfaces:

/interface vlan
add interface=ether2_switch-trunk name=vlan44 vlan-id=44
add interface=ether2_switch-trunk name=vlan99 vlan-id=99

Nachdem die VLANs (bei Mikrotik auch virtuelle Interfaces genannt) erstellt sind, legen wir nun die Netzwerke und IP-Adressen der Interfaces an. In Winbox wird dazu der Menüpunkt „IP -> Adresses“ ausgewählt. Im folgenden Fenster werden pro Interface und VLAN die Netzwerk-Bereiche und Adressen an die Interfaces vergeben. Der Router muss (anders als bei Switches) eine Layer-3-Adresse in jedem VLAN haben, damit er das Routing zwischen unterschiedlichen Netzen durchführen kann.

Netzwerke und Interface-Adressen hinzufügen. Nur so ist Layer-3-Routing möglich.

Wir beginnen damit, die Default-Konfiguration auf dem Interface „Bridge“ zu ändern. Diesbezüglich ändere ich das Netzwerk von 192.168.88.0/24 auf 192.168.8.0/24. VLAN 8 soll mein native VLAN sein und ich möchte, das VLAN 8 und IP-Adresse ähnlich sind. Zudem lege ich die Adressen für Interface „vlan44“ und „vlan99“ an. Die letzte Zeile ist übrigens der WAN-Port. Er bekommt seine Adresse und Netze per DHCP aus dem produktiven Netz. Erkennbar an „D“ in Spalte 1. Alternativ kann die Konfiguration über die Konsole wie folgt geschehen:

/ip address
add address=192.168.8.1/24 comment=defconf interface=bridge network=192.168.8.0
add address=192.168.44.1/24 interface=vlan44 network=192.168.44.0
add address=192.168.99.1/24 interface=vlan99 network=192.168.99.0

DHCP-Server anlegen

Nachdem der Router nun über VLANs und entsprechenden Netzen verfügt, konfigurieren wir die DHCP-Server. Pro VLAN (und eben für native VLAN 8, also Interface „ether2_switch-trunk“) konfiguriere ich einen eigenen DHCP-Server.

In Winbox erfolgt das über Menüpunkt „IP->DHCP Server“. Ein Kick auf den Menüpunkt öffnet ein Fenster zur Verwaltung der DHCP-Server. Die Erstellung eines DHCP-Servers für ein Interface bzw. VLAN erfolgt am einfachsten über den Assistenten, welcher über den Button „DHCP Setup“ gestartet wird. Folgt einfach dem Assistenten, dieser legt den Server und den IP-Pool gleich mit an.

Ich habe pro Interface und VLAN je einen DHCP-Server angelegt. Zudem habe ich noch die DNS-Einstellungen des DHCP-Servers überprüft und unter „IP->DNS“ noch einen statischen DNS-Eintrag vergeben.

DHCP-Server, DHCP-IP-Pool, DNS am DHCP-Server und Static DNS einrichten.

Natürlich lässt sich alles auch wieder bequem per CLI konfigurieren. Nutzt dazu die folgenden Befehle zur Konfiguration von IP-Pool, DHCP-Server samt Netz sowie DNS.

/ip pool
add name=default-dhcp ranges=192.168.8.10-192.168.8.254
add name=dhcp_pool2 ranges=192.168.44.100-192.168.44.200
add name=dhcp_pool3 ranges=192.168.99.100-192.168.99.200

/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
add address-pool=dhcp_pool2 disabled=no interface=vlan44 name=dhcp2
add address-pool=dhcp_pool3 disabled=no interface=vlan99 name=dhcp3

/ip dhcp-server network
add address=192.168.8.0/24 comment=defconf dns-server=192.168.8.1 gateway=192.168.8.1
add address=192.168.44.0/24 dns-server=192.168.44.1 gateway=192.168.44.1
add address=192.168.99.0/24 dns-server=192.168.99.1 gateway=192.168.99.1

/ip dns
set allow-remote-requests=yes

/ip dns static
add address=192.168.8.1 comment=defconf name=homelab.localdomain

Firewall und NAT

Auch mein Cisco Wireless Home Lab kommt nicht ohne aktive Firewall zurecht. Schließlich möchte ich mich voll austoben dürfen und egal was ich mache, soll keinen Einfluss auf das produktive Netzwerk haben. Diesbezüglich trenne ich die beiden Netzwerke weitestgehend voneinander ab. Nur der Internetzugriff soll aus dem Testnetzwerk heraus erlaub sein.

Links: Default-Firewall, Rechts: Firewall um drei Regeln zum Verbot des inter-VLAN-Routing erweitert.

Folgende Bilder veranschaulichen den Unterschied meiner aktuellen Konfiguration im Vergleich zur Default-Konfiguration. Die Default-Konfiguration ist ein guter Anfang für unser Vorhaben, denn sie sichert den Router sehr gut von Zugriffen über die WAN-Schnittstelle ab, gleichzeitig führt sie Source-NAT für den Zugriff über die WAN-Schnittstelle ein. Über die WAN-Schnittstelle können die Geräte auf das VLAN 193 zugreifen, von dem es schnurstracks ins Internet geht. Die Regeln der Default-Konfiguration sind sinnvoll, sicher und durch die Kommentare selbsterklärend.

srcNat, wenn Out-Interface die WAN-Schnittstelle ist.

Interface List: Gruppe aus mehreren Interfaces

Kurz zur Erklärung: In den Firewall-Regeln wird bei Interface oft LAN oder WAN genannt. Es handelt sich dabei um eine sogenannten Interface-Liste. Diese lässt sich in Winbox einfach unter „Interface“ einer sogenannten Interface-Liste hinzufügen. Sozusagen werden die Interfaces gruppiert und können über diesen Gruppennamen zum Beispiel in der Firewall angesprochen werden. Achtet darauf, dass die Interfaces / VLANs der richtigen Gruppe zugeordnet sind.

Gruppierung der Interfaces in der Interface-List.

Ich habe die Firewall um drei Einträge erweitert, die das inter-VLAN-Routing, also das Routing zwischen den einzelnen VLANs, verbieten. Verschiedene VLANs machen vor allem dann Sinn, wenn der Datenverkehr der Netze separiert wird. Ohne die Regeln würde der Mikrotik Router zwischen den einzelnen Netzen routen, wie es eben seine Aufgabe ist. Übrigens auch ins WAN! Erst die Regeln verhindern dies.

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1_wan list=WAN
add interface=vlan44 list=LAN
add interface=vlan99 list=LAN

/ip firewall filter
add action=reject chain=forward in-interface=all-vlan out-interface=all-vlan reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=bridge out-interface=all-vlan reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=all-vlan out-interface=bridge reject-with=icmp-network-unreachable
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

Finale Konfiguration des Mikrotik hAP ac

Die Konfiguration der Firewall haben wir erledigt, damit sind wir mit der Einrichtung des Mikrotik RB962UiGS-5HacT2HnT fertig. Nachfolgende habe ich die finale Konfiguration dokumentiert. Sie beinhaltet alle oben beschriebenen Einstellungen, zudem sind unter anderem die WLAN-Module und nicht benötigte Interfaces deaktiviert sowie die Ports umbenannt.

Achtung: Die Software-ID, die Seriennummer sowie MAC-Adressen habe ich anonymisiert. Passt die Konfiguration dementsprechend an, solltet ihr sie so verwenden wollen.

[admin@MikroTik] > /export hide-sensitive
# nov/12/2021 20:40:51 by RouterOS 6.49
# software id = X00X-00XX
#
# model = RouterBOARD 962UiGS-5HacT2HnT
# serial number = XXXXXXXXXXXX
/interface ethernet
set [ find default-name=ether1 ] name=ether1_wan
set [ find default-name=ether2 ] name=ether2_switch-trunk
set [ find default-name=ether3 ] disabled=yes
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether5 ] name=ether5_management
set [ find default-name=sfp1 ] disabled=yes
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-XXXXXX wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-XXXXXX wireless-protocol=802.11
/interface vlan
add interface=ether2_switch-trunk name=vlan44 vlan-id=44
add interface=ether2_switch-trunk name=vlan99 vlan-id=99
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.8.10-192.168.8.254
add name=dhcp_pool2 ranges=192.168.44.100-192.168.44.200
add name=dhcp_pool3 ranges=192.168.99.100-192.168.99.200
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
add address-pool=dhcp_pool2 disabled=no interface=vlan44 name=dhcp2
add address-pool=dhcp_pool3 disabled=no interface=vlan99 name=dhcp3
/interface bridge port
add bridge=bridge comment=defconf interface=ether2_switch-trunk
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5_management
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1_wan list=WAN
add interface=vlan44 list=LAN
add interface=vlan99 list=LAN
/ip address
add address=192.168.8.1/24 comment=defconf interface=bridge network=192.168.8.0
add address=192.168.44.1/24 interface=vlan44 network=192.168.44.0
add address=192.168.99.1/24 interface=vlan99 network=192.168.99.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1_wan
/ip dhcp-server network
add address=192.168.8.0/24 comment=defconf dns-server=192.168.8.1 gateway=192.168.8.1
add address=192.168.44.0/24 dns-server=192.168.44.1 gateway=192.168.44.1
add address=192.168.99.0/24 dns-server=192.168.99.1 gateway=192.168.99.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.8.1 comment=defconf name=homelab.localdomain
/ip firewall filter
add action=reject chain=forward in-interface=all-vlan out-interface=all-vlan reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=bridge out-interface=all-vlan reject-with=icmp-network-unreachable
add action=reject chain=forward in-interface=all-vlan out-interface=bridge reject-with=icmp-network-unreachable
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=Europe/Berlin
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Schritt 4: Reset auf Werkseinstellungen und Konfiguration des Cisco C3560 Switches

Mein Cisco Wireless Home Lab besteht wie oben beschrieben aus zwei Switches, welche beide konfiguriert werden müssen. Beide Switche sind unterschiedliche Modelle, jedoch ist die Grund-Konfiguration mit Ausnahme der Trunk Encapsulation (welche nicht am C2960 konfiguriert werden muss) identisch. Wenn ihr konfiguriert, solltet ihr eurer Netzwerk-Topologie entsprechend eine andere Management-IP-Adresse in VLAN 8 und einen anderen Hostnamen vergeben. Und natürlich hängt die Konfiguration der Ports immer auch davon ab, welche Anschlüsse ihr genau benutzen wollt. Aber langsam, gehen wir Schritt für Schritt durch die Konfiguration.

Reset auf Werkseinstellung mit Mode Button

Bevor wir beginnen, sollten wir die beiden Cisco Switches auf deren Werkseinstellungen zurücksetzen. Wir erinnern uns: Ich habe die beiden Komponenten günstig gebaucht gekauft und habe daher keine Kenntnisse über die aktuelle Konfiguration der Switches. Ich kenne nicht einmal das Passwort.

Für meine Konfiguration möchte ich daher frisch auf der grünen Wiese starten. Dazu greifen wir auf den Password Recovery Mechanism zurück. Um diesen Modus zu starten, wird physischer Zugriff auf den Switch benötigt, um den sogenannten „Mode Button“ drücken zu können, welcher sich am Frontpanel des Switches befindet. Des Weiteren wird ein serielles Konsolenkabel samt Putty benötigt.

Los geht’s! Zuerst schließen wir das Konsolenkabel am entsprechenden Anschluss des Switches an, danach wird das andere Ende des Kabels in einen Computer mit Putty gesteckt. Bei mir ist das Konsolenkabel als COM4 verfügbar. Wenn ihr nicht wisst, welche Bezeichnung euer Konsolenkabel am PC hat, könnt ihr das bequem im Gerätemanager nachsehen. Dann starten wir Putty und wählen die entsprechende serielle Verbindung aus. Die Einstellung in Putty sind wie üblich: Speed (Baud) = 9600, Data bits = 8, Stop bits = 1, Parity = none.

Nachdem Putty bereit ist bereiten wir uns, den Mode-Button zu drücken. Während der Knopf gedrückt ist, stecken wir den Switch ans Stromnetz an. Nun müssen wir für ca. 15 Sekunden der Mode-Button gedrückt halten, noch während die System-LED grün blinkt. Der Mode-Button muss so lange gedrückt werden, bis die System-LED kurz gelb und dann dauerhaft grün leuchtet. Dann kann der Mode-Button losgelassen werden. Putty sollte dann den erfolgreichen Start des Password Recovery Mechanism anzeigen.

Danach haben wir das erste Mal die Möglichkeit, Befehle an den Switch zu senden. Wir geben Folgendes ein und bestätigen jede Zeile mit Druck auf die Eingabetaste.

flash_init
dir flash:

„flash_init“ initialisiert den Flash-Speicher, „dir flash:“ zeigt den Inhalt des Speichers an. Für uns entscheidend: Die Dateien config.text und vlan.dat werden nun angezeigt. Beide Dateien werde wir im nächsten Schritt löschen und so die Konfiguration des Switches auf Werkseinstellungen zurücksetzen. Dazu geben wir folgenden Befehl ein, die jeweils folgende Sicherheitsabfrage bestätigen wir mit ja. Nachdem die Löschung quittiert wurde, wiederholen wir den Löschbefehl für die zweite Datei.

del flash:config.text
[y]

del flash:vlan.dat
[y]

Wurden beide Dateien erfolgreich gelöscht, beenden wir den Password Recovery Mechanism und starten den Switch mit Werkseinstellungen in den normalen Modus. Das geschieht mit dem Boot-Befehl:

boot

Dateien im Flash anzeigen, löschen und Switch booten.

Erstkonfiguration Cisco C3560: Der Initial Configuration Dialog

Der Cisco C3560 ist nun auf Werkseinstellungen zurückgesetzt und bootet im regulären Modus. Dort lässt er sich initial konfigurieren, sogar ein Assistent steht bereit, der sogenannte Initial Configuration Dialog. Mit dessen Hilfe erhält der Switch sein Passwort und seinen Hostname. Weitere Einstellung können bequem übersprungen werden, denn jede Frage des Dialogs kann mit nein beantwortet werden.

Der Dialog ist selbsterklärend, die folgenden Bilder sollte dabei Klarheit schaffen. Wir starten das Extended Setup (auf die Frage nach dem Basic Setup antworte ich daher mit „no“), schauen dann zunächst eine Interface-Übersicht an, vergeben dann einen Hostnamen, legen secret samt enable password und terminal password fest, dann verneinen wir sowohl SNMP, IP-Adresse, Bridging und CLNS.

Die Interfaces lasse ich zunächst ebenfalls unbeachtet und konfiguriere nichts. Am Ende des Dialoges bestätige ich mit „2“ und speichere die Initialkonfiguration in den NVRAM, also den nichtflüchtigen Speicher.

Durchlaufen des Initial Configuration Dialog.

VLANs, Trunk und Access Ports mit Portfast auf dem Cisco C3560 konfigurieren

Mein Cisco Wireless Home Lab benötigt nun eine Konfiguration wie oben beschrieben. Zunächst legen wir daher die VLANs an, die der Switch kennen muss. Das geschieht mit folgenden Befehlen. Verbunden sind wir noch immer über Putty und dem seriellen Konsolenkabel.

VLANs anlegen

Also wechseln wir mit dem Befehl „enable“ in den sogenannten Privileged EXEC mode. Dieser Modus muss speziell aktiviert werden, denn er beinhaltet Konfigurationsbefehle mit weitreichenden Folgen. Dies soll zusätzliche Sicherheit bringen. Direkt nach dem Befehl muss das enable-Passwort eingegeben werden, welches wir über den Initial Configuration Dialog festgelegt hatten.

enable
Passwort

configure terminal

vlan 8
name vlan8
exit

vlan 44
name vlan44
exit

vlan 99
name vlan99
exit

Mit dem Befehl „configure terminal“ wechseln wir in den Konfigurationsmodus. Dort können wir Zeile für Zeile Konfigurationsbefehle absetzen. „vlan 8“ legt ein VLAN mit der ID 8 an. Der Switch wechselt nach der Eingabe des Befehls direkt in das VLAN zur weiteren Konfiguration. „name vlan8“ im Anschluss legt daher direkt den Namen für das VLAN 8 fest, und zwar vlan8. „exit“ verlässt die VLAN-Konfiguration. Die gleichen Befehle werden nun für VLAN 44 und VLAN 99 wiederholt.

VLANs anlegen am Cisco C3560 und VLAN-Übersicht anzeigen lassen.

Nach erfolgter Konfiguration lässt sich die aktuelle VLAN-Konfiguration anzeigen. Das geschieht mit dem Befehl „do show vlan brief“, welcher direkt im Konfigurationsmodus eingegeben werden kann. Da wir noch im Konfigurationsmodus sind, können wir die Ausführung des Befehls mit „do“ erzwingen, ansonsten müssten wir den Modus zunächst mit „exit“ verlassen, damit der Befehl akzeptiert würde.

do show vlan brief

Der Befehl zeigt im Ergebnis eine Übersicht aller angelegten VLANs inklusive Name, VLAN-Status sowie den dem jeweiligen VLAN zugewiesenen Access-Ports an. Die neu angelegten VLANs haben noch keine Ports zugewiesen. Das wollen wir jetzt ändern.

Trunk-Ports konfigurieren

Dazu müssen wir zunächst überlegen, welcher Port der Trunk-Port zum Router werden soll. Wir wählen den ersten Port, also das Interface Fa0/1. Mit „interface f0/1“ öffnen wir den Port zur Konfiguration öffnen. In der Port-Konfiguration konfigurieren wir 802.1Q-VLAN-Tagging („switchport trunk encapsulation dot1q“), wechseln den Port-Modus von Access auf Trunk („switchport mode trunk“), erlauben nur VLANs 8, 44 und 99 am Trunk („switchport trunk allowed vlan 8,44,99“) und schalten das Cisco Dynamic Trunking Protocol für den Trunk ab („switchport nonegotiate“). Dann legen wir das native VLAN 8 am Trunk-Port fest („switchport trunk native vlan 8“), damit keine Daten im VLAN 8 getaggt werden. Die Interface-Konfiguration verlassen wir, nachdem wir die Port-Konfiguration beendet haben („exit“). Zusammenfasst setzen wir also folgende Befehle ab:

interface f0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

Lasst euch nicht durch störende Meldungen im Terminal-Fenster beeinflussen. Insbesondere nach Eingabe des Befehls „switchport mode trunk“ wird der Port kurz deaktiviert und als Trunk-Port neu initialisiert. Da wir mit einem seriellen Konsolenkabel mit dem Switch verbunden sind, werden diese Meldungen angezeigt. Später per SSH ist dies nicht mehr der Fall (es sei denn, wir aktivieren genau das über den Befehl „terminal monitor“). Macht einfach mit der Eingabe der Befehle weiter.

Wir wiederholen die oberen Befehle für einen weiteren Port, denn für die Verbindung zum VMware ESXI Hypervisor wird ein weiterer Trunk-Port benötigt, welcher schon jetzt angelegt werden kann.

interface f0/3
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

Access-Port konfigurieren

Nun konfigurieren wir den ersten Access-Port. Ich möchte darüber meinen Management-PC anschließen, mein Datenverkehr soll deshalb in VLAN 8 landen. Das machen wir wie folgt, als Port wähle ich Fa0/24:

Wie bereits bei der Konfiguration des Trunk-Ports wechseln wir zunächst ins Interface. Dann ändern wir den Port-Modus auf Access, anschließend legen wir das VLAN fest, zu welchem der Port gehören soll. Abschließend verlassen wir das Interface.

interface f0/24
switchport mode access
switchport access vlan 8
exit

Abschließend können wir mit „do show int status“ eine Port-Übersicht aufrufen, mit deren Hilfe wir unsere geleistete Arbeit beurteilen können. Der Befehl listet alle Ports auf und zeigt an, welchem VLAN ein Access-Port zugeordnet ist bzw. ob der Port als Trunk-Port konfiguriert ist. „do write“ speichert die aktuelle Konfiguration in den NVRAM. Nur so ist die Konfiguration auch nach einem Neustart des Switches oder nach einem Stromausfall noch vorhanden. Das dürft ihr nicht vergessen.

do show int status
do write

Interface-Übersicht und speichern. Wenn ihr noch im Konfigurationsmodus seid, dann verwendet „do show int status“, ansonsten genügt „show int status“. Gleiches gilt für „write“ bzw. „do write“.

Management-Interface in VLAN 8 anlegen

Die bisherige Konfiguration würde eigentlich ausreichen, um den Cisco C3560 in meinem Cisco Wireless Home Lab gemäß Topologie im Testnetzwerk verwenden zu können. Allerdings müssen wir noch immer per Konsolenkabel auf den Switch zugreifen.

Das ist natürlich alles andere als optimal: Nicht nur das lästige Kabel stört mich, vielmehr möchte ich im Betrieb schnell auf die Informationen des Switches von meinem Management-PC zugreifen können. Dazu konfigurieren wir nun ein VLAN-8-Interface als Layer-3-Interface, was im Prinzip nur bedeutet: Wir geben dem Switch im VLAN 8 eine IP-Adresse, über welche ich den Switch später erreichen können. Damit wird das VLAN 8 zum eingangs erwähnten Management-VLAN. Wir nutzen folgende Befehle:

int vlan8
ip address dhcp
exit

Sobald wir die Befehle im Konfigurationsmodus abgesetzt haben, bezieht der Switch sich seine IP-Adresse per DHCP. Wie in Teil 1 erwähnt, habe ich mich bewusst dazu entschieden, die Switch-Adresse nicht statisch zu vergeben.

VLAN 8 bekommt eine Layer-3-IP-Adresse per DHCP.

SSH einrichten

Nachdem der Switch nun seine IP-Adresse im VLAN 8 besitzt, muss noch SSH konfiguriert werden, damit wir uns künftig über Putty auf den Switch verbinden können, und zwar nicht mehr über das serielle Konsolenkabel, sondern eben über jeden PC, welcher sich im Management-VLAN 8 befindet. Das macht alles einfacher.

ip domain-name homelab.localdomain
crypto key generate rsa
[2048]

username Benutzername password Passwort
line vty 0 15
transport input ssh
login local

Unmittelbar nach Eingabe der oberen Befehle können wir den Switch per SSH erreichen. Kurz zur Erklärung: “ ip domain-name homelab.localdomain“ konfiguriert einen Domainnamen für den Router. Dieser wird (wie auch der Hostname, der bereits von uns konfiguriert wurde) zur Generierung des RSA-Schlüsselpaares benötigt. Das Schlüsselpaar wiederum brauchen wir dann für die Aktivierung von SSH. „crypto key generate rsa“ generiert die nun die RSA-Schlüssel. Direkt nach dem Befehl werden wir nach der Schlüssellänge gefragt. In diesem Sinne wählen wir 2048, was auch von Cisco so empfohlen wird. Für das Generieren des Schlüssels benötigt der Switch etwas Zeit, seid hier also geduldig. Nachdem das Schlüsselpaar erstellt wurde, aktiviert der Switch schließlich SSH mit einer entsprechenden Meldung.

Zertifikat erstellen, User anlegen und SSH aktivieren.

Mit „username Benutzername password Passwort“ erstellen wir nun einen User für den Zugriff auf den Switch. Damit dieser User per SSH auf den Switch zugreifen kann, müssen wir noch die VTY-Lines entsprechend konfiguriert werden. VTY-Lines steht für virtual teletype und bezeichnet einen virtuellen Port, der für den eingehenden Zugriff über Telnet und SSH benötigt wird. Für alle vorhandenen VTY-Lines 0 bis 15 („line vty 0 15“) legen wir SSH als Zugriffsmethode fest („transport input ssh“) und schließen damit Telnet aus. Zur Authentifizierung soll die lokale Userdatenbank genutzt werden („login local“), dort haben wir ja gerade eben unseren ersten User angelegt. Nun können wir uns per SSH am Switch einloggen und den Switch wie bisher steuern.

Hinweis: Wenn wir die spannenden Terminal-Meldungen, welche wir vom Zugriff über die serielle Schnittstelle gewohnt sind, für unsere Arbeit am Switch brauchen, dann können wir mit den Befehlen „terminal monitor“ bzw. „terminal no monitor“ die Terminal-Meldungen an bzw. abschalten.

Optional: Portfast am Access Port aktivieren

Der Switch ist nun vollständig für die Verwendung in meinem Cisco Wireless Home Lab konfiguriert. Allerdings dauert es, bis einem Endgerät am Access Port eine IP-Adresse vergeben wird (bis zu 40 Sekunden). Das liegt hauptsächlich am Spanning-Tree-Protokoll, welches der Cisco Switch ab Werk aktiviert hat. Es verhindert recht zuverlässig gefährliche Netzwerk-Loops.

Das Spanning-Tree-Protokoll setzt zur Vermeidung dieser Loops auf mehrere Zustände eines Ports, unter anderem Listening und Learning, bevor es Frames am Port weiterleitet. Die Zustände Listening und Learning dauern per Definition insgesamt 30 Sekunden, während der Switch über sogenannte BPDUs die Netzwerk-Topologie berechnet. Erst nachdem dies geschehen ist und am Port kein Netzwerk-Loop erkannt wird, schaltet der Port auf Forwarding und Pakete werden übertragen. Erst jetzt bekommt ein angeschlossenes Endgerät zum Beispiel eine IP-Adresse per DHCP.

Um den Vorgang zu beschleunigen, kann der Cisco Switch C3560 pro Port so eingestellt werden, dass der die Zustände Listening und Learning überspringt und unmittelbar den Forwarding-Zustand erreicht. Das nennt sich dann Portfast. Damit leitet der Switch die Pakete sofort weiter. Die Option sollte man mit Vorsicht genießen, denn wenn an einem Port mit aktiviertem Portfast nun Layer-2-Geräte angeschlossen werden, ist die Gefahr sehr hoch, dass Loops das gesamte Netzwerk lahmlegen.

Ich habe das bereits erlebt, Netzwerk-Loops will man nicht haben. Wenn aber nur ein Endgerät, z.B. ein Computer, am Port angeschlossen wird, ist der Einsatz von Portfast durchaus üblich.

interface f0/24
spanning-tree portfast

Im Konfigurationsmodus öffnen wir zunächst den gewünschte Switchport, danach aktivieren wir Portfast am Access-Port mit „spanning-tree portfast“. Der Switch weist sehr deutlich auf die Folgen dieser Einstellung hin. Direkt im Anschluss springt der Port auf Forwarding und angeschlossene Geräte funktionieren sofort, wenn sie am Switch angeschlossen werden.

Optionales Portfast am Access Port: Steckt man ein LAN-Kabel am Port an, ist er sofort nutzbar. Ohne Portfast dauert das 30 bis 40 Sekunden.

Schritt 5: Reset auf Werkseinstellungen und Konfiguration des Cisco C2960 Switches

Den ersten unserer beiden Switches haben wir nun für unsere Zwecke vollständig konfiguriert. Er funktioniert in unserem Testnetzwerk. Fehlt noch der zweite Switch.

Glücklicherweise: Die Konfiguration des Cisco C2960 gleicht dem Cisco C3650 bis auf eine Ausnahme. Das macht die Konfiguration recht einfach. Wir wiederholen daher die obige Konfiguration des Cisco C3650 einfach für den Cisco C2960 Schritt für Schritt, vergeben aber einen anderen Hostnamen sowie eine andere Management-IP und passen die sogenannte Trunk Encapsulation am Trunk-Port an.

interface f0/1
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

Der Befehl zur Trunk Encapsulation wird für den Cisco C2960 einfach übersprungen. Der Switch ist das neuere Modell (im Vergleich zum C3560) und kapselt die VLAN-Tags daher automatisch nach 802.1Q, ganz ohne expliziten Befehl.

Local VLAN Inconsistency, Native VLAN mismatch

Nachdem nun beide Switches konfiguriert sind, verbinden wir beide Geräte mit einem LAN-Kabel. Am Cisco C2960 wähle ich Anschluss F0/1, welchen wir bereits als Trunk-Port konfiguriert haben. Das andere Kabelende stecken wir am C3560 ein, und zwar am Anschluss F0/2, denn Anschlüsse F0/1 (Port zum Mikrotik-Router) und F0/3 (Port zum Dell PowerEdge) sind bereits anderweitig vorgesehen.

Da Port F0/2 am Cisco C3560 noch nicht als Trunk-Port konfiguriert wurde, zeigt der Cisco C2960 folgendes Fehlerbild an, sobald beide Switches miteinander verbunden sind. Die native VLANs passen nicht zusammen.

Native VLAN mismatch: Inconsistent local vlan.

Zum Hintergrund: Die von uns konfigurierten Trunks erlauben nur VLAN 8, 44 und 99. Der Port F0/2 am C3560 wurde noch nicht als Trunk-Port konfiguriert. Das bedeutet: Er ist Access Port in VLAN 1. Der Switch C2960 erkennt das und das Spanning-Tree-Protocol blockt den Port für weiteren Datenverkehr, denn die beiden native VLANs passen nicht zusammen.

Um den Fehler zu beheben, konfigurieren wir auf Switchport F0/2 des C3560 einen vollständigen Trunk mit den Befehlen, wie wir sie bereits kennen. Sobald die Befehle abgesetzt wurden, passen die VLANs zusammen und der Port wird freigegeben. Denkt daran: Der C3560 braucht den Befehl zur Trunk Encapsulation!

interface f0/2
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

In Folge kann sich der Cisco C2960 unmittelbar seine IP-Adresse per DHCP besorgen und beide Switches sind fertig zum Einsatz in meinem Cisco Wireless Home Lab.

Schritt 6: Installation von VMware ESXi auf dem Dell PowerEdge R710

Die Netzwerk-Infrastruktur ist damit vorerst fertiggestellt. Ich werde sehen, ob meine Konfiguration so den Anforderungen Stand hält. Wie gesagt, deshalb labbe ich ja!

Im nächsten Schritt muss nun der VMware ESXi Hypervisor auf dem Dell PowerEdge R710 vorbereitet werden. Den Trunk-Port am Switch haben wir ja bereits konfiguriert, d.h. wir können direkt ein LAN-Kabel am passenden Port (F0/3) des Cisco C3650 anschließen, das andere Ende stecken wir an Port 1 des Dell PowerEdge. Sobald VMware ESXi dann installiert ist, sollte es per DHCP eine passende IP-Adresse bekommen.

Damit die Installation reibungslos klappt, benötigen wir einen Monitor mit VGA-Anschluss oder entsprechendem Adapter. Zudem benötigen wir einen USB-Tastatur. Beides schließen wir am Dell PowerEdge R710 an. So können wir den Server wie einen normalen Computer bedienen und den Boot-Vorgang beobachten, sowie Konfigurationen durchführen und VMware installieren.

RAID-Konfiguration überprüfen

Bevor wir mit der Installation von VMware beginnen können, sollte unbedingt die RAID-Konfiguration des Servers überprüft werden. Immerhin verwende ich ein gebrauchtes Gerät. Die Neukonfiguration des RAID-Verbundes löscht den Inhalt aller verbundenen Festplatten, ein gewünschter Nebeneffekt.

Erster Bootvorgang (links), dann F10 drücken (mitte), um ins System Service Utility zu gelangen (rechts).

Noch während des Bootvorgangs müssen die F10-Taste drücken, um ins UEFI zu gelangen. Dort stellen wir die Raid-Konfiguration ein. Wechselt dazu im Hauptmenü zum Menüpunkt „Hardware Configuration -> Configuration Wizards“.

Übrigens: Ohne Maus ist die Navigation im UEFI etwas umständlich. Nutzt die Tab-Taste, um vom Hauptmenü ins Untermenü zu gelangen! Folgt dann der Konfiguration wie in der folgenden Bildgalerie.

Gesamter Prozess zur Raid-Konfiguration (Raid 0).

Bei den Hardwarekonfigurations-Assistenten wählen wir den Assistenten zur RAID-Konfiguration. Danach sehen wir die aktuelle RAID-Konfiguration. Im nächsten Schritt wird der RAID-Controller ausgewählt. Bei meinem Dell PowerEdge R710 ist das der PERC 6/i Integrated. Wählt im nächsten Schritt Express Wizard aus.

Ich habe dann RAID 0 konfiguriert. Das liegt daran, dass ich nur zwei SAS-Festplatten verbaut habe und ich maximale Geschwindigkeit erhalten möchte. Redundanz durch RAID benötige ich nicht. In meinem Cisco Wireless Home Lab kann ich jederzeit einen Ausfall der Festplatten ertragen. Die Konfiguration des WLAN-Controllers werde ich ohnehin separat sichern. Ihr könnt natürlich eine andere RAID-Konfiguration wählen, oder sogar mit Hot Spare arbeiten.

Im letzten Schritt bestätigen wir die gewünschte Konfiguration. Per Finish gelangen wir zur Sicherheitsabfrage, die wir mit „Yes“ bestätigen. Dann haben wir RAID erfolgreich neu konfiguriert. Nach erfolgreicher Konfiguration nutzen wir „Exit and Reboot“ in der unteren linken Ecke des UEFI und starten den Dell PowerEdge neu.

VMware Image downloaden, installieren und lizensieren

Der Dell PowerEdge R710 ist nun bereit zur Installation von VMware ESXi. Zunächst müssen wir uns das passende Image von VMware herunterladen. Ich verwende nicht die neueste Version 7, sondern nutze die Version 6.7 von VMware. Neuere Versionen würden auf meinen Dell PowerEdge R710 nicht mehr funktionieren.

VMware-Account, Download und Lizenzschlüssel

Die Version 6.7 hat noch einen weiteren Vorteil: Sie ist mittlerweile komplett kostenfrei, denn eine passende Evaluierungslizenz gibt es direkt bei VMware. Den VMware vSphere Hypervisor 6.7 samt kostenloser Lizenz erhaltet ihr über diesen Link.

Um sowohl Lizenzschlüssel zu erhalten und das Software-Image herunterladen zu können, benötigen wir einen VMware-Account. Diesen könnt ihr über den genannten Link direkt mit erstellen, falls ihr noch keinen habt. Der Account ist kostenlos. Dann loggen wir uns bei VMware ein.

Nach dem Login sollten wir direkt wieder auf die passende Seite kommen, um uns für VMware ESXi 6.7 registrieren zu können. Klappt das nicht, einfach den Link oben nochmal nutzen, während ihr eingeloggt seid. Dann nutzen wir den Registrieren-Button, geben unsere persönlichen Daten ein und bestätigen alles inkl. Captcha. Nachdem wir den Prozess durchlaufen haben, werden wir mit dem Lizenz-Schlüssel samt Download der aktuellen Version belohnt.

Links: Login bei VMware und Registrierung für Version 6.7. Rechts: Lizenzschlüssel und Download der aktuellen VMware-Version.

Ladet euch nun das Software-Image auf euren PC herunter. Den Lizenzschlüssel brauchen wir erst später, wenn wir VMware ESXi 6.7 erfolgreich installiert haben und wir uns über einen Browser auf die installierte VMware-Instant auf dem Server einloggen können.

USB-Stick zur Installation vorbereiten

Nun bereiten wir den USB-Stick zwecks Installation von VMware ESXi 6.7 vor. Zu diesem Zweck nutzen wir Rufus. Rufus ist ein handliches Tool, welches bootbare USB-Sticks aus einem entsprechenden Image generieren kann. Genau das haben wir vor: Das eben heruntergeladene VMware-Image soll auf einen USB-Stick, welchen wir dann in den Dell PowerEdge R710 stecken können. Dann soll der Server vom USB-Stick booten und direkt vom Stick VMware ESXi installieren.

In Rufus wählen wir unseren USB-Stick aus, auf den das Boot-Image formatiert werden soll. Achtet darauf, dass der Stick ausreichend Speicherplatz bietet. Dann wählen wir das heruntergeladene Image aus und schreiben das Image auf den Stick. Das wird einen Moment dauern.

Solltet ihr das Image nicht mit Rufus benutzen können hilft es, das Image im Windows-Ordner C:\ abzulegen. Damit umgeht ihr das Rechteproblem.

Installation von VMware ESXi 6.7 mit USB-Stick

Nun stecken wir den gerade eben mit Rufus erstellten USB-Bootstick an den USB-Port des Dell PowerEdge R710. Das ist die Voraussetzung, um VMware ESXi für unser Cisco WLAN Home Lab auf dem Server installieren zu können.

USB-Stick wird am Dell PowerEdge R710 eingesteckt. Dann booten.

Nachdem der Stick steckt, schalten wir den Server ein. Während des Bootscreens dann sofort F11 drücken, so gelangen wir in den BIOS Boot Manager. Dort wählen wir dann einfach unseren Boot-Stick aus, bei mir ist das Front USB: Ultra Fit. Ultra Fit ist der Hersteller des Sticks, er steckt am Front-USB. So simpel kann es sein! Im folgenden Menü wird dann der ESXi 6.7 standard installer ausgewählt, dann startet auch schon die Installation des VMware Hypervisors.

Links: Auswahl USB-Stick im Bootmenü. Mitte: Auswahl des Images. Rechts: Installation von VMware ESXi 6.7 läuft.

Wir folgen den Anweisungen auf dem Bildschirm. Das Ganze ist recht selbsterklärend. Zuerst erscheint ein Hinweis zur Hardware-Kompatibilität, danach müssen wir die Lizenzbedingungen akzeptieren. Im Anschluss wird der Speicherort für die Installation ausgewählt. Überschreibt nicht den USB-Stick, sondern wählt den bereits konfigurierten RAID-Verbund aus (PERC 6/i). Nach der Sprachauswahl im nächsten Fenster legen wir dann Root-Passwort fest.

Installation von VMware ESXi. Schreibt euch das Root-Passwort auf!

Die Warnung im folgenden Fenster können wir überspringen. Wir wissen, dass die CPU in unserem Server nicht für künftige Versionen von VMware ESXi geeignet ist. Deshalb nutzen wir ja die Version 6.7, sie ist für unsere Zwecke ausreichend und kostenfrei. Im letzten Fenster starten wir die Installation nun endgültig mit Druck auf F11.

Das System wird nun einige Minuten benötigen, um die Installation fertigzustellen. Den Fortschritt können wir am hübschen Ladebalken bewundern. Nach Abschluss der Installation wird der Server neugestartet. Wir müssen den USB-Stick vorher entfernen. Dann bestätigen wir den Neustart mit Enter.

Nach dem Neustart startet VMware ESXi. Nach dem Hochfahren drücken wir F2, dann benötigen wir das Root-Passwort. Wir werden nun die Grundkonfiguration des Management-Netzwerks durchführen. Das ist schnell erledigt, denn unser Netzwerk haben wir ja bereits in den oberen Schritten konfiguriert. Von dieser Arbeit profitieren wir jetzt.

Unter „Configure Management Network -> IPv4 Configuration“ wird DHCP aktiviert, IPv6 wird nicht benötigt und daher komplett im entsprechenden Menüpunkt „IPv6 Configuration“ deaktiviert.

Management-Netzwerk konfigurieren: DHCP bei IPv4 und IPv6 komplett deaktivieren.

Wir bestätigen die Änderungen und verlassen dann das Menü. Dabei wird das Management-Interface neu gestartet. Wenn alles geklappt hat, zeigt der Start-Screen von VMware ESXi nun die per DHCP zugewiesene Management-IP-Adresse an.

Übrigens: Die VLAN-Einstellung muss nicht verwendet werden, denn wir haben unser Netzwerk entsprechend so konfiguriert, dass sich der Management-Traffic im native VLAN 8 abspielt.

VMware-Lizenz einspielen

Fast geschafft. Nun rufen wir das Web-Interface des Hypervisors das erste Mal auf. Zunächst verbinden wir einen Management-PC mit dem Access-Port, welchen wir bereits konfiguriert haben. Auf diesem PC wird der Web-Browser gestartet, in die Adresszeile geben wir die Management-IP-Adresse des Servers ein. Die Management-IP-Adresse des Hypervisors können direkt auf dem Bildschirm des Dell PowerEdge ablesen. Nach der Eingabe der IP-Adresse wir der Login-Screen wird angezeigt.

Wenn eine Zertifikatswarnung im Browser auftaucht, können wir diese überspringen, damit die Seite vollständig angezeigt wird. Dem SSL-Zertifikat wird vom Browser nicht vertraut, da es von keiner offiziellen Zertifizierungsstelle ausgestellt wurde. Für mein Cisco Wireless Home Lab lege ich darauf keinen Wert.

Login-Screen VMware ESXi. Gebt hier das Root-Passwort ein.

Im Anschluss navigieren wir über den Menüpunkt „Host -> Verwaltung“ und dem Reiter „Lizenzierung“ in den Bereich der Lizenzverwaltung. Über die Funktion „Lizenz zuweisen“ geben wir den Lizenzschlüssel ein, welchen wir aus dem VMware-Account erhalten haben. Und siehe da, die neue Lizenz funktioniert einwandfrei! Das Ablaufdatum der Lizenz? Nie.

Aktivieren von VMware ESXi mit kostenloser Lizenz ohne Ablaufdatum.

Schritt 7: Cisco Catalyst 9800-CL herunterladen und installieren

Das Schöne an Cisco ist, dass es für alles eine passenden Anleitung gibt, zum Beispiel über die Installation des Cisco WLAN-Controllers Catalyst 9800-CL in VMware. Ich musste dennoch einige Stunden mit dem Lesen der Dokumente verbringen, denn die Informationsflut hat mich anfangs schwer erschlagen. Vor allem das Zusammenspiel zwischen VMware ESXi und Cloud-WLAN-Controller hat mich einige Versuche gekostet, bis ich das Ganze ohne Netzwerk-Loops konfiguriert hatte. Wenn man weiß, wie es geht, wird der Vorgang eigentlich ganz einfach.

Aber auch hier gilt: Im meinen Cisco WLAN Home Lab probiere ich mich selbst aus. Kostet eben Zeit, macht aber auch jede Menge Spaß. Es ist eben mein Weg zu lernen. Das bedeutet aber nicht, dass der beschriebene Vorgang so in der echten Umgebung Anwendung finden sollte. Ich benötige zum Beispiel kein eigenes Interface für das Out-of-band Management sowie ein eigenes Interface für High Availability. Aber genug der Worte, legen wir mit einem einfachen Schritt los, dem Download.

Download Cisco Catalyst 9800-CL

Zunächst benötigen wir die Installationsdatei für den WLAN-Controller unter VMware ESXi. Ich habe euch Version 17.3.4c des 9800-CL verlinkt.

Cisco Catalyst 9800 Wireless Controller für Cloud – VMware ESXi. Version 17.03.04.c

Zum Download müssen wir bei Cisco eingeloggt sein. Also entweder direkt einloggen oder zuerst einen Account erstellen, der Account ist gratis. Falls ihr bereits zum Beispiel einen Account von der Cisco Networking Academy habt, könnt ihr auch diesen verwenden. Solch einen Account hatte ich bereits, seit ich mir den Cisco Packet Tracer etwas näher angeschaut hatte und den kostenlosen Kurs belegt habe. Mit dem Cisco-Account muss kein Servicevertrag verbunden sein, wenn ihr die VMware ESXi-Version verwendet.

Nach dem Download haben wir ein .ova-Image auf unserer Festplatte liegen. Dieses Image benötigen wir für die Installation als Virtuelle Maschine benötigt. Vorher müssen wir VMware ESXi aber noch kurz vorbereiten.

Portgruppen anlegen

Damit die Installation des Cloud-WLC auch einwandfrei funktioniert, müssen wir Netzwerkinterfaces anlegen. Bei VMware ESXi heißen diese Interfaces Portgruppen und werden in vSwitches zusammengefasst. Der Cisco 9800-CL WLAN-Controller benötigt eigentlich drei Interfaces (für Out-of-band Management, Management und High-Availability), ich werde aber nur ein Management Interface erstellen und verzichte auf Out-of-band und High-Availability.

Wenn ihr Out-of-band und High-Availability aber benötigt, achtet darauf, dass die beiden Interfaces auf verschiedene vSwitches am VMware ESXi gemappt werden. Ansonsten kommt es sehr wahrscheinlich zu Netzwerk-Loops, da sich die Ports die Pakete gegenseitig weiterleiten (z.B. Broadcast Storm). Denn eigentlich verhält sich der WLAN-Controller auch nur wie ein Switch. Verschiedene vSwitches verhindern dies.

Für meine Zwecke wähle ich den überschaubaren Weg ohne Out-of-band und High-Availability. Ich konfiguriere lediglich ein Management Interface und füge dem vSwitch0 eine weitere Portgruppe hinzu.

Portgruppe anlegen. Promiscuous-Modus und Gefälschte Übertragungen erlauben.

Natürlich geben wir der Portgruppe einen sinnvollen Namen, zum Beispiel „WLAN Trunk“. Bei VLAN-ID tragen wir 4095 ein, damit erstellt VMware ESXi einen Trunk-Port. Die VLAN-ID 4095 steht in VMware für alle VLANs. Und genau solch ein Trunk-Port soll unser Management-Interface am WLAN-Controller sein. Damit später auch alles einwandfrei funktioniert, klappen wir unbedingt die Einstellungen zur Sicherheit auf und akzeptieren Promiscuous-Modus und Gefälschte Übertragungen.

Wenn wir den Promiscuous-Modus nicht aktivieren, dann blockt VMware die Datenpakete des 9800-CL-WLAN-Controllers, wenn sie von unterschiedlichen MAC-Adresse kommen. Wenn dort dann WLAN zentral über den Controller getunnelt wird, tritt genau dieser Fall ein. VMware würde dann die Pakete aller MAC-Adressen verwerfen, die nicht der MAC-Adresse des virtuellen Interfaces des WLAN-Controllers entsprechen.

Wir aktivieren unbedingt auch die Gefälschten Übertragungen, ansonsten verwirft der Hypervisor alle Pakete, deren Quell- und Ziel-MAC-Adresse nicht übereinstimmen.

VM anlegen

Nun können wir endlich die Virtuelle Maschine anlegen. Dazu den entsprechenden Menüpunkt „VM erstellen/registrieren“ verwenden. Es erscheint ein Dialog zur Auswahl des Erstellungstyps der VM, bei dem wir eine virtuelle Maschine aus einer OVF- oder OVA-Datei erstellen. Durch das Cisco-Image haben wir es einfach, denn die .ova-Datei erledigt die Konfiguration der VM quasi von selbst.

Im nächsten Schritt müssen wir deshalb nur einen Namen für die Virtuelle Maschine angeben und im unteren Dialogbereich das .ova-Image von Cisco auf unserer Festplatte auswählen. Entweder per Drag&Drop oder über den Auswahldialog. Im Anschluss wird der Speicherort für die VM ausgewählt. Das ist einfach, wir haben ja bereits einen RAID-Verbund erstellt. Ich wähle meinen datastore1 aus, ihr seid hier natürlich flexibel.

Im vorletzten Schritt werden die Bereitstellungsoptionen festgelegt. Im Dialog werden die Interfaces des WLAN-Controllers mit den Ports von VMware ESXi gemappt, welche wir bereits angelegt haben. Da ich nur ein Interface im Hypervisor angelegt habe, mappe ich GigabitEthernet1, GigabitEthernet2 und GigabitEthernet3 auf das gleiche Interface, nämlich meine Portgruppe WLC Trunk. Wir sorgen gleich dafür, dass diese Konfiguration keinen Netzwerk-Loop verursacht.

Bei Bereitstellungstyp wählen wir die kleinste Variante aus: 1K APs, 10K Clients. Mehr werden wir im Home Lab garantiert nicht haben. VMware ESXi wählt anhand unserer Auswahl ein passendes Profil bestehend aus CPU, RAM, Interfaces sowie Speicherplatz aus.

Ob ihr bei der Festplattenbereitstellung Thin oder Thick auswählt, bleibt euch überlassen. Thick reserviert den Speicherplatz direkt komplett, während Thin erstmal nur den tatsächlich benötigten Speicherplatz reserviert. Ich wähle Thin.

Die letzte Option ist unscheinbar, aber für unser Vorhaben sehr, sehr wichtig: Wir deaktivieren die Option „Automatisch einschalten“! Es ist wichtig, zuerst den nächsten Schritt durchzuführen, bevor die VM das erste Mal gestartet wird. Ansonsten werden die Interfaces beim ersten Start im 9800-CL WLAN-Controller falsch angelegt.

Wenn alle Einstellungen passen, dürfen wir endlich beherzt auf Beenden klicken, die VM wird dann eingerichtet. Wir warten, bis der Upload der Festplatte abgeschlossen ist. Den momentanen Status erkennt man im unteren Bildschirmbereich unter „aktuelle Aufgaben“.

Virtuelle Netzwerkadapter OOB und HA löschen

Nach die VM dann endlich angelegt wurde, dürfen wir die VM noch nicht starten! Denn zunächst müssen wir die Netzwerkschnittstellen anpassen. Wir erinnern uns: Wir haben die Interfaces auf die identische Portgruppe gemappt. Handeln wir nicht, würde das Netzwerk-Loops verursachen.

Daher löschen wir die überflüssigen Interfaces GigabitEthernet1 (für Out-of-band Management) und GigabitEthernet3 (für High Availability). Dazu müssen wir zuerst die virtuelle Maschine auswählen, dann im Menü „Aktionen -> Einstellungen bearbeiten“ im Bereich virtuelle Hardware die beiden Netzwerkadapter löschen. Dies geschieht über das kleine x-Icon an der rechten Seite. Wir speichern die Änderungen anschließend ab, nachdem wir beide Adapter gelöscht haben. Dann können wir die VM mit dem WLAN-Controller endlich starten.

Überflüssige Netzwerkadapter für Out-of-band-Management und High-Availability vor dem ersten Start der VM entfernen!

Schritt 8: Erstkonfiguration des Cisco 9800-CL WLAN-Controllers

Nachdem die VM nun eingeschaltet wurde, sind wir nur noch wenige Meter vom Ziel entfernt. Denn als letzter großer Aufgabenbereich liegt die erstmalige Konfiguration des Cisco 9800-CL WLC vor uns. Dabei passe ich den Controller auf mein oben dargestelltes Testnetzwerk an.

Mit dem Start der VM wird im Hypervisor VMware ESXi das kleine Vorschaubild in der VM-Übersicht aktiv. Es zeigt den virtuellen Bildschirminhalt der VM intervallweise an. Klickt man darauf, bekommt man die Browser-Konsole. Zur Konfiguration des Cisco 9800-CL verwende ich allerdings die Remote-Konsole, diese ist über „Konsole -> Remote-Konsole“ abrufbar.

Während des ersten Bootvorgangs startet der Controller neu. Wir müssen uns um nichts kümmern. Erst wenn der Controller den System Configuration Dialog in der Konsole anzeigt, sollten wir zugig eingreifen und die Steuerung durch einen Tastendruck in der Remote-Konsole übernehmen. Wir brecht den Initial Configuration Dialog ab, indem wir „no“ eingeben. Gegebenenfalls müssen wir mit „yes“ bestätigen, die Autoinstallationsroutine abzubrechen. Das hängt davon ab, wann genau wir die Konsolensteuerung übernommen haben.

System Configuration Dialog / Initial Configuration Dialog

Hostname, Interface, VLAN, Static IP und Gateway

Dann beginnen wir mit der eigentlichen Konfiguration. Wie schon bei Cisco Switches gewohnt, findet die Konfiguration wieder im Privileged EXEC mode statt. Dazu wie folgt:

enable
configure terminal

hostname 9800-CL

vtp mode transparent

Mit „enable“ aktivieren wir den Privileged EXEC mode. Da am 9800-CL noch kein enable-Secret vergeben wurde, wird die Abfrage des Secrets einfach übersprungen. Wir werden später in der Konfiguration das Secret erstellen. Zunächst wechseln wir aber mit „configure terminal“ direkt in den Konfigurationsmodus.

Dort geben wir dem WLAN-Controller einen Hostnamen, zum Beispiel „9800-CL“. Dies geschieht über den Befehl „hostname 9800-CL“. „vtp mode transparent“ stellt sicher, dass die VLAN-Konfiguration am WLC andere Netzwerkgeräte garantiert nicht beeinflusst. Ansonsten würden sich die VLAN-Informationen unter Umständen über das Cisco VTP-Protokoll auf alle Switches verteilen.

Konfiguration von Hostnamen, vtp-Modus, Interface-Trunk, native VLAN, statischer IP-Adresse sowie Default Route (Gateway)

Weiter geht die Konfiguration mit Befehlen zum Interface. „int g1“ öffnet die Konfiguration für das einzige Interface unseres Cloud-WLC. Mit „no ip addr“ entfernen wir die IP-Adresse vom Interface, dann konfigurieren wir einen Trunk mit native VLAN 8 („switchport mode trunk“, „switchport trunk native vlan 8“). Native VLAN 8 ist unser Management-VLAN, mit dem wir später per Management-PC auf das GUI des WLAN-Controllers zugreifen wollen. Der Trunk selbst wird später aber auch den Datenverkehr der WLAN-Clients in den entsprechenden VLANs 44 und 99 transportieren.

Damit der Zugriff über das Management-VLAN funktioniert, müssen wir das VLAN 8 natürlich zunächst erstellen. „vlan 8“ erstellt das VLAN mit ID 8, „name vlan8“ vergibt den entsprechenden Namen. Mit „exit“ verlassen wir die VLAN-Konfiguration.

Dann noch eben schnell das virtuelle Interface in VLAN 1 ausschalten: Mit „int vlan1“ ins VLAN 1 wechseln, mit „no ip addr“ die IP-Konfiguration entfernen und mit „shut“ das Interface abschalten. „exit“ verlässt das Interface wieder.

Nun konfigurieren wir das Management-Interface auf VLAN 8. Dazu mit „int vlan8“ das virtuelle Interface öffnen. Dann vergeben wir eine statische IP-Adresse für den WLC („ip addr 192.168.8.90 255.255.255.0“) und aktivieren das Interface („no shut“). Abschließend vergeben wir noch die Default Route („ip route 0.0.0.0 0.0.0.0 192.168.8.1“), anschließend sollten wir den WLAN-Controller auch schon aus dem VLAN 8 anpingen können.

int g1
no ip addr
switchport mode trunk
switchport trunk native vlan 8

vlan 8
name vlan8
exit

int vlan1
no ip addr
shut
exit

int vlan8
ip addr 192.168.8.90 255.255.255.0
no shut
ip route 0.0.0.0 0.0.0.0 192.168.8.1

Wir sind noch immer per Konsole verbunden. Für das GUI und auch für den Zugriff über SSH müssen wir einen User anlegen. „user admin priv 15 secret Passwort“ legt einen Admin-User mit entsprechendem Passwort an, ein enable secret legen wir gleich auch noch fest („enable secret Passwort„).

„line vty 0 15“ und „login local“ kennen wir bereits von der Switch-Konfiguration. Und abschließend freut sich der Cisco WLAN-Controller 9800-CL noch über einen NTP-Server („ntp server 192.168.8.1“).

enable secret Passwort
user admin priv 15 secret Passwort

line vty 0 15
login local


ntp server 192.168.8.1

Wireless-Konfiguration, Country-Code und Trustpoint für APs

Wireless-Management-Interface, Konfiguration von Country Code, Trustpoint zum Joinen der Access Points

Die langweilige Basiskonfiguration haben wir nun erledigt. Doch nun endlich zum spannenden Teil! Zunächst müssen wir ein Interface angeben, welches wir für das Wireless-Management verwenden wollen, also das Management unserer Access Points. Wir verwenden natürlich unser native VLAN 8! Der passende Befehl lautet: „wireless management interface vlan 8“. Mit „exit“ verlassen wir das definierte Interface wieder, denn mehr gibt es hier nicht zu tun.

Wichtig ist die Definition des Country-Codes, in meinem Fall ist das „DE“. Der Country-Code wird in Großbuchstaben angegeben. Bevor das allerdings funktioniert, müssen wir die Radio-Interfaces abschalten (obwohl noch gar kein Access Point verbunden wurde!). Deshalb schalten wir mit „ap dot11 24ghz shut“ das Interface ab. Die Sicherheitsabfrage bestätigen wir mit „yes“ und dann wiederholen wir den Vorgang für das 5-GHz-Interface.

Jetzt können wir den Country-Code festlegen: „ap country DE“. Abschließend müssen wir beide Interfaces für 2,4 GHz und 5 GHz wieder anschalten („no ap dot11 24ghz shut“, „no ap dot11 5ghz shut“). Dann haben wir den Country-Code erfolgreich definiert.

wireless management interface vlan 8
exit

ap dot11 24ghz shut
[y]
ap dot11 5ghz shut
[y]
ap country DE
[y]
no ap dot11 24ghz shut
no ap dot11 5ghz shut

do show ip int brief
exit

Eine letzte wichtige Konfiguration steht nun noch aus, damit sich Access Points mit unserem Controller verbinden können: Ein gültiges Sicherheitszertifikat, der Trustpoint für die Access Points. Dieser wird NICHT im Konfigurationsmodus, sondern im Privileged EXEC mode ausgeführt. Ansonsten funktioniert es nicht.

Trustpoint erstellen, damit Access Points dem Controller beitreten können.

Wir gehen wie folgt vor: Der Befehl „wireless config vwlc-ssc key-size 2048 signature-algo sha256 password 0 Passwort“ erstellt den Trustpoint, „show wireless management trustpoint“ zeigt uns dessen Details nach der Erstellung des Zertifikats an. Wir überprüfen einfach, ob die der Trustpoint erfolgreich erstellt wurde. Ansonsten müssen wir den Vorgang wiederholen.

Wenn alles geklappt hat, dürfen wir auf keinen Fall vergessen, die Konfiguration mit „write memory“ abzuspeichern, damit unsere mühevolle Konfigurationsarbeit den nächsten Neustart überlebt. Dann haben wir es geschafft, der Cisco 9800-CL WLAN-Controller im Home Lab funktioniert und ist einsatzbereit!

wireless config vwlc-ssc key-size 2048 signature-algo sha256 password 0 Passwort

show wireless management trustpoint

write mem

Ersten Access Point verbinden

Vom Management-PC aus können wir nun die GUI im Browser aufrufen. Dazu geben wir die konfigurierte IP-Adresse des WLAN-Controllers in die Adresszeile des Browsers ein. Wir können uns dann mit dem erstellten Benutzer einloggen und sehen das Dashboard des 9800-CL WLAN-Controllers.

Jetzt wählen wir einen Port aus, an welchen wir unseren ersten Access Point verbinden möchten. Der Port muss als Trunk-Port konfiguriert sein, damit er den Datenverkehr verschiedener SSIDs über die VLANs ins Netzwerk durchlässt. Der Trunk-Port benötigt natürlich ebenfalls wieder unser native VLAN 8, damit der AP mit dem Controller in Kontakt treten kann. Passend zu meinem Netzwerkplan konfiguriere ich für mein Cisco Wireless Home Lab einen Trunk-Port am Cisco C2960 wie folgt:

interface f0/18
switchport mode trunk
switchport trunk allowed vlan 8,44,99
switchport nonegotiate
switchport trunk native vlan 8
exit

Nun schnappen wir uns einen Access Point und schließen ihn am Trunk-Port an. Der Access Point sollte dann dem Cisco 9800-CL WLAN-Controller beitreten. Wir können das im Dashboard unmittelbar sehen. Und auch die restlichen Einstellungen und Funktionen des WLC sind nur wenige Klicks entfernt!

Das Cisco Wireless Home Lab mit Cloud-WLAN-Controller ist eingerichtet, konfiguriert und funktioniert! Mit der individuellen Seriennummer, die der Cloud-Controller bei der ersten Installation erhalten, läuft der Cisco Catalyst 9800-CL WLAN-Controller im Evaluation Mode und ist 90 Tage mit beliebig vielen Access Points verwendbar. Viel Spaß beim Labben!