CCNA — Network Access: 120 Übungsfragen

Step 1: Grundlagen und Bedrohung — WPA2-Personal basiert auf einem Pre-Shared Key (PSK). Ein Angreifer, der erfasste Handshakes hat, kann offline mit Wörterbuch- oder Brute-Force-Angriffen versuchen, den PSK zu erraten. Dies macht WPA2-PSK anfällig, besonders bei schwachen Passwörtern.

Step 2: Technik von WPA3 (SAE) — WPA3-Personal führt SAE (Simultaneous Authentication of Equals) ein, ein sogenanntes Password-Authenticated Key Exchange (PAKE)-Verfahren. SAE verhindert, dass ein Angreifer erfolgreich Offline-Wörterbuchangriffe gegen aufgezeichnete Handshakes durchführen kann, weil jedes Authentifizierungsversuch interaktiv zwischen Client und AP stattfinden muss und nicht einfach offline geprüft werden kann. SAE bietet auch bessere Schlüsselaushandlung mit Forward Secrecy-Eigenschaften: ein kompromittiertes Passwort in der Zukunft ermöglicht nicht das Entschlüsseln früherer aufgezeichneter Sessions.

Step 3: Auswirkungen und Migration — Durch SAE wird die Sicherheit bei Nutzung schwächerer Passwörter deutlich erhöht, aber in praktischen Umgebungen sollte dennoch ein starkes Passwort oder 802.1X-Enterprise-Authentifizierung (RADIUS) verwendet werden. WPA3 unterstützt zudem Übergangsmodi (Transition Mode) für Kompatibilität mit WPA2-Geräten, in denen beide Methoden parallel laufen können, bis eine vollständige Migration möglich ist. Trap: Eine verbreitete Fehlannahme ist, dass WPA3 automatisch alle alten Schwachstellen eliminiert oder bestimmte Legacy-Technologien ersetzt. WPA3 verbessert den Authentifizierungsprozess, ersetzt aber nicht sofort alle Management- oder Konfigurationsfehler, und Produktionsumgebungen benötigen sorgfältiges Testing bei Migration. Warum jede falsche Antwort fehlschlägt: - Option 2 (WPA3 verwendet WEP anstelle von AES): Das ist falsch und widerspricht der Realität. WEP ist ein veraltetes und unsicheres Protokoll, das seit langem nicht mehr genutzt werden sollte. WPA3 verwendet moderne Kryptographie (z. B. AES in GCM- oder CCMP-Modi) und führt Verbesserungen bei der Authentifizierung ein — es ersetzt nicht AES durch WEP. - Option 3 (WPA3 deaktiviert alle Legacy-Konten und zwingt zur Nutzung von 802.1X in jedem Netzwerk): WPA3 zwingt nicht generell zur Nutzung von 802.1X. WPA3-Enterprise bietet stärkere Sicherheitsoptionen und WPA3-Personal nutzt SAE; 802.1X bleibt eine optionale, aber sichere Methode (Enterprise Mode). WPA3 hat Übergangsmodi, um Kompatibilität mit WPA2 zu erlauben; es ist also nicht so strikt, dass Legacy-Geräte automatisch ausgeschlossen werden. - Option 4 (WPA3 reduziert die Schlüsselgröße auf 64 Bit): Das ist falsch und kontraproduktiv für Sicherheit. WPA3 verwendet starke Schlüsselgrößen und moderne Kryptographie; eine Reduktion auf 64 Bit würde die Sicherheit massiv schwächen. Tatsächlich verbessert WPA3 die Schlüsselaushandlung und bietet Forward Secrecy. Fazit: Die zentrale Verbesserung von WPA3-Personal ist SAE, das Offline-Dictionary-Angriffe wesentlich erschwert und die Sicherheit der Schlüsselaushandlung erhöht. Für höchste Sicherheit empfiehlt sich dennoch Enterprise-Mode (802.1X/RADIUS) in Unternehmensnetzwerken.

Step 1: Prinzip des Router-on-a-Stick. Bei Router-on-a-Stick nutzt ein Router ein einziges physisches Interface, das als Trunk zum Switch fungiert. Auf dem Router werden Subinterfaces angelegt, die mittels 802.1Q-Tagging jeweils ein VLAN repräsentieren. Jede Subinterface erhält eine IP-Adresse als Default-Gateway für das entsprechende VLAN.

Step 2: Konkrete Konfiguration. Für VLAN 10 und 20 sind zwei Subinterfaces erforderlich, typischerweise GigabitEthernet0/0.10 und GigabitEthernet0/0.20. Jede Subinterface benötigt die Kommandozeile 'encapsulation dot1Q 10' bzw. 'encapsulation dot1Q 20' und eine passende IP-Adresse (z. B. 192.168.10.1/24 und 192.168.20.1/24). Der Switchport am verbundenen Switch muss als 802.1Q-Trunk konfiguriert sein, der die VLANs 10 und 20 durchlässt.

Step 3: Warum Alternativen unpassend sind und Praxis-Hinweise. Zwei physische Router-Interfaces wären möglich, aber ineffizient und erfordern zwei physische Verbindungen zum Switch; in vielen Deployments ist nur ein physischer Routerport vorgesehen. NAT ist nicht geeignet, um interne VLANs sauber Layer-3 zu verbinden. IP Multinetting (mehrere IPs auf einem Layer-3 Interface ohne VLAN-Tagging) funktioniert nicht über einen Trunk, da die Switch-Seite VLAN-Tagging benötigt; Multinetting wäre nur an einem Access-Port mit mehreren IPs möglich, was aber kein VLAN-Trennungsmodell aufrecht erhält. Trap: Ein häufiger Fehler ist anzunehmen, dass man einfach mehrere IP-Adressen auf dem physischen Interface konfigurieren kann, ohne Subinterfaces und 802.1Q; das funktioniert nicht mit getaggten VLAN-Trunks. Ebenso werden Access-Ports nicht mehrere VLANs gleichzeitig transportieren. Warum jede falsche Antwort fehlschlägt: - Eine einzige IP-Adresse und IP Multinetting: Falsch für Trunking/VLAN-Tagging-Szenarien; Multinetting ohne 802.1Q führt nicht zu getrennten VLAN-Segmenten über einen Switch-Trunk. - Zwei physische Router-Interfaces: Technisch möglich, aber entspricht nicht dem klassischen Router-on-a-Stick-Design und erfordert zwei physische Verbindungen; ineffizient für viele Umgebungen. - Access-Port mit VLAN 1 und NAT: Ein Router-Access-Port kann nur ein VLAN übertragen; NAT würde die Kommunikation falsch maskieren und zerstört die VLAN-Segmentierung. NAT ist kein Ersatz für Inter-VLAN-Routing innerhalb desselben administrativen Bereichs. Fazit: Die korrekte und gebräuchliche Methode ist das Anlegen von Subinterfaces mit 'encapsulation dot1Q' und separaten IPs, kombiniert mit einem 802.1Q-Trunk auf dem Switch.

Step 1: Problem und Bedrohungsklasse bestimmen — VLAN-Hopping umfasst Techniken, mit denen Angreifer VLAN-Isolation umgehen (z. B. durch double-tagging). Zusätzlich entstehen Probleme durch unbeabsichtigte Trunk-Formation, wenn DTP an Access-Ports aktiv ist und gegenüberliegende Geräte auf dynamic modes stehen. Ziel ist, unbeabsichtigte Trunks zu verhindern und native-VLAN-basierte Angriffsvektoren zu minimieren.

Step 2: Geeignete Maßnahmen auswählen — DTP zu deaktivieren (Antwort 1) ist eine etablierte Praxis: Access-Ports sollten explizit als access und nicht dynamisch konfiguriert werden (switchport mode access). Damit wird verhindert, dass ein Angreifer oder ein falsch konfiguriertes Gerät automatisch einen Trunk aushandelt. Das Setzen der native VLAN auf eine unbenutzte VLAN-ID (Antwort 2) reduziert das Risiko bei double-tagging-Angriffen, weil Frames ohne Tag (oder mit dem native-Tag) nicht in eine produktive Endgeräte-VLAN gelangen. Viele Betreiber verwenden eine nicht genutzte VLAN-ID als native VLAN für Trunks oder setzen native VLAN konsistent und getrennt von Endgerät-VLANs.

Step 3: Umsetzung und Monitoring — Trunks manuell und konsistent auf beiden Seiten konfigurieren, native VLANs dokumentieren; optional VLAN filtering (allowed VLANs) verwenden und DTP global ausschalten oder per Port deaktivieren. Logging und regelmäßige Audits helfen, Fehlkonfigurationen zu erkennen. Trap: Manche Administrierende denken, 'automatische Trunk-Ausbildung' sei bequem und sicher, oder sie verlassen sich auf VTP, um VLAN-Konsistenz zu schaffen. In öffentlichem Betrieb sind diese Funktionen jedoch Angriffsflächen oder Fehlerquellen. Why each wrong answer fails: - Antwort 3 (VTP auf allen Access-Switches aktivieren): Falsch, weil VTP zwar die VLAN-Verteilung erleichtert, aber VTP-Domänenfehler oder falsche VTP-Serverkonfigurationen VLAN-Tabellen überschreiben und zu massiven Fehlkonfigurationen führen können. VTP kann zudem ein Sicherheitsrisiko sein, wenn nicht kontrolliert — deshalb in vielen modernen Designs deaktiviert oder nur in größeren, zentral gesteuerten Domänen vorsichtig verwendet. - Antwort 4 (switchport mode dynamic auto belassen): Falsch, weil dieses dynamic-Verhalten die Trunk-Ausbildung zulässt und Angreifer Geräte anschließen könnten, die Trunk aushandeln; dynamic auto/ desirable erhöhen unbeabsichtigte Trunks. Warum die richtigen Antworten zutreffen: - Antwort 1 (DTP deaktivieren): Richtig, weil das automatische Aushandeln von Trunks verhindert wird und damit eine häufige Ursache für unbeabsichtigte Trunks eliminiert wird. - Antwort 2 (native VLAN ungenutzt): Richtig, weil native-VLAN-basierte Angriffsszenarien (z. B. double-tagging) und unbeabsichtigte Untagging-Fälle reduziert werden, wenn native VLANs nicht für Endgeräte genutzt werden. Fazit: Schützen Sie Trunks durch explizite Konfiguration (kein DTP), konsistente native-VLAN-Strategien, Einschränkung erlaubter VLANs und Monitoring, statt auf automatische Mechanismen zu vertrauen.

Step 1: Verständnis der SVI-Betriebsbedingungen — Ein Switch Virtual Interface (SVI) repräsentiert eine Layer-3-Schnittstelle für ein VLAN auf einem Multilayer-Switch. Der logische Zustand des SVI hängt vom Vorhandensein eines aktiven VLANs auf dem Switch ab. Konkreter: Damit eine SVI den Zustand 'up' erreicht, muss das VLAN existieren und das VLAN muss durch mindestens einen aktiven Layer-2-Port (oder einen aktiven Trunk, der Verkehr für dieses VLAN führt) im Status up/up repräsentiert sein.

Step 2: Warum das SVI down ist — Wenn keine physischen Ports dem VLAN 20 zugeordnet oder alle Ports administrativ down oder ohne Link sind, betrachtet der Switch VLAN 20 als inaktiv. Infolge dessen bleibt das SVI administratively up but line protocol down (oder ähnlich), weil keine Layer-2-Konnektivität vorhanden ist, über die Frames für dieses VLAN fließen könnten. Ein Router-on-a-stick-Setup oder ein externes Gerät ist hierfür nicht notwendig; das Verhalten ist intern konsistent für Multilayer-Switches.

Step 3: Behebung und Tests — Prüfen Sie mit show vlan brief ob VLAN 20 existiert und welche Ports zugeordnet sind; vergewissern Sie sich, dass mindestens ein Port im VLAN 20 im Zustand up/up ist (z. B. ein Access-Port mit angeschlossenem Endgerät oder ein Trunk, der VLAN 20 überträgt). Anschließend sollte das SVI als operational up erscheinen. Trap: Häufig wird fälschlich angenommen, dass das SVI automatisch up wird, sobald die IP konfiguriert ist oder es eine externe Router-Konfiguration benötigt; beide Annahmen sind falsch. Warum jede falsche Antwort fehlschlägt: 2) Die Notwendigkeit eines Router-on-a-stick ist nur relevant, wenn Routing extern (am Router) erfolgen soll; auf einem Multilayer-Switch übernimmt das SVI selbst das Routing und braucht keinen Router-Subinterface, damit es up wird. 3) DHCP-Synchronisation ist irrelevant: eine SVI benötigt keine DHCP-Interaktion, um den Linkzustand zu erreichen—die IP kann statisch sein und trotzdem bleibt das Interface down, wenn kein aktives VLAN vorhanden ist. 4) SVIs sind logische VLAN-Interfaces und benötigen kein dediziertes physisches Interface; ihre Betriebsfähigkeit hängt von der Existenz aktiver Layer-2-Ports im jeweiligen VLAN ab, nicht von einer physischen Bindung. Daher ist Option 1 korrekt: stellen Sie sicher, dass VLAN 20 aktiv ist und mindestens ein Layer-2-Port im Up/Up Zustand zugewiesen ist, damit das SVI up wird.

Step 1: Anforderungen abgleichen — Die Anforderungen sind: zentrales Management, zentrale Authentifizierung und nahtloses Roaming über viele APs. Das spricht für eine Architektur, die Steuerungsfunktionen zentralisiert (z. B. WLAN-Controller), um RF-Management, roams, Security-Policies, SSID-Konfigurationen und RADIUS-Integration einheitlich zu handhaben.

Step 2: Technische Lösung — Eine controller-basierte WLAN-Architektur (Option 2) verwendet Lightweight APs, die meist CAPWAP oder einen anderen Tunnel zum Controller nutzen. Der Controller orchestriert Kanal-/Leistungszuweisung, Roaming-Entscheidungen, zentralisierte SSID- und Security-Policy-Verwaltung (inkl. 802.1X/RADIUS), und ermöglicht nahtlosen Roaming-Support (z. B. expedited handoffs, key caching oder 802.11r in modernen Lösungsstacks). Für ein Gebäude mit 50 APs ist das Management-Aufwands-vermindernd und bietet konsistente Konfigurationen, Monitoring und einfachere Firmware-/Policy-Updates.

Step 3: Implementierung und Tests — Nach der Auswahl konfigurieren Sie den Controller mit allen SSIDs, Authentifizierungsrichtlinien (WPA2/WPA3, 802.1X), RADIUS-Servern und Roaming-Optimierungen. Stellen Sie sicher, dass APs und Controller zuverlässige Backhaul-Verbindungen haben. Testen Sie Roaming mit typischen Endgeräten, prüfen Sie Session-Persistenz, und optimieren Sie RF-Parameter zentral. Trap: Oft wird angenommen, dass Cloud- oder autonome Lösungen immer genügen. Autonome APs bieten zwar Flexibilität, aber bei 50 APs wird das Management schnell unübersichtlich. Cloud-Lösungen können in manchen Fällen eine Alternative sein, liefern aber bei strengeren Anforderungen an lokale Authentifizierung, niedrige Latenz für Roaming und vollständige On-Prem-Policies nicht immer die gewünschte Kontrolle. Warum jede falsche Antwort fehlschlägt: - Option 1 (Autonome APs): Autonome (Standalone) APs müssen einzeln konfiguriert werden, was bei 50 Geräten administrativ aufwändig ist. Außerdem ist zentrales RF-Management und koordiniertes Roaming nur eingeschränkt möglich, da jedes Gerät seine eigene Konfiguration hat. Das erschwert einheitliche Policies und schnelle Firmware-Rollouts. - Option 3 (Verteilte APs mit lokalem Management auf jedem Stockwerk): Lokales Management pro Stockwerk skaliert schlecht und verursacht Inkonsistenzen. Roaming über Stockwerke hinweg würde Schwierigkeiten bereiten, da lokale Management-Instanzen nicht automatisch Roaming-Entscheidungen koordinieren wie ein zentraler Controller. - Option 4 (Nur Cloud-basierte Consumer-APs): Cloud-Consumer-APs sind oft eingeschränkt in Funktionen wie tiefere 802.1X-Integration, unternehmensgerechte QoS- oder Roaming-Optimierungen; zudem kann Abhängigkeit von externen Cloud-Diensten Compliance- und Datenschutzanforderungen verletzen. Für ein Unternehmensnetzwerk mit zentraler Authentifizierung und strengen Roaming-Anforderungen ist ein professioneller Wireless-Controller die robustere Wahl. Fazit: Für ein mittelgroßes bis großes Büro mit zentraler Authentifizierung, einheitlichen Policies und nahtlosem Roaming ist eine controller-basierte Architektur die geeignetste Lösung; sie erleichtert Management, Sicherheit und Performance-Tuning.

Step 1: Grundprinzip von WPA3 und das Problem. WPA2-PSK erlaubt bei schwachen Passwörtern Angreifern, aufgezeichnete Handshakes offline zu analysieren und Wörterbuchangriffe auszuführen. WPA3 adressiert dieses Problem durch ein verbessertes Authentifizierungsprotokoll.

Step 2: SAE (Simultaneous Authentication of Equals). SAE ist ein passwortbasiertes Authentifizierungsprotokoll, das bei jedem Verbindungsaufbau einen einzigartigen Schlüsselaustausch verwendet und damit Offline-Wörterbuchangriffe verhindert. Selbst wenn ein Angreifer den Austausch aufzeichnet, kann er nicht offline testen, ob ein bestimmtes Passwort korrekt ist, ohne online mit einem Teilnehmer zu interagieren.

Step 3: Warum SAE die richtige Antwort ist und wie es in Enterprise/HE Szenarien wirkt. In einem Unternehmen mit Many-SSIDs oder Gast-PSK-Netzen reduziert SAE das Risiko, dass ein kompromittiertes Handshake zu einem vollständigen Passwort-Bruch führt. Für roamingfähige Clients bedeutet das, dass der Schlüsselablauf und Handshake pro Verbindung sicher erfolgt, während weiterhin Mechanismen wie 802.11r für schnelles Roaming integriert werden können. Trap: Eine häufige Fehlannahme ist, dass WPA3 alle anderen Sicherheitsmechanismen ersetzt (z. B. 802.1X). Tatsächlich ist SAE eine Ergänzung für PSK-Use-Cases; Enterprise-Deployments können weiterhin 802.1X mit EAP nutzen. Warum jede falsche Antwort fehlschlägt: - 802.1X/RADIUS: 802.1X ist kein Neuzugang von WPA3 — es war bereits in WPA2-Enterprise vorhanden und bietet individuelle Authentifizierung, aber es adressiert nicht speziell das Offline-Wörterbuchproblem bei PSK-Netzen. In vielen WiFi-Umgebungen ist 802.1X weiterhin die beste Wahl für Unternehmensauthentifizierung, jedoch ist es keine WPA3-spezifische Neuerung. - Ersatz von CCMP durch TKIP: TKIP ist ein älterer, unsicherer Verschlüsselungsmodus (aus WPA-Zeiten) und wurde bewusst durch CCMP (AES) ersetzt. WPA3 verwendet moderne Kryptografie (z. B. GCMP-256 in WPA3-Enterprise), nicht die Rückkehr zu TKIP. - Automatisches Verbergen der SSID: SSID-Hiding ist keine Sicherheitsmaßnahme gegen ernsthafte Angriffe; die SSID kann leicht durch passive Sniffing-Tools entdeckt werden, und es verhindert keine Offline-Angriffe. Es ist rein obfuscation, nicht kryptografische Verbesserung. Zusammenfassung: SAE (Dragonfly) ist die WPA3-Erweiterung, die PSK-basierten WLANs speziell gegen Offline-Wörterbuchangriffe schützt. Andere Antworten betreffen bereits existierende Technologien oder falsche/ineffektive Maßnahmen.

Step 1: Grundlagen von RSTP (802.1w) verstehen: RSTP wurde entwickelt, um die lange Konvergenzzeit von klassischen STP (802.1D) zu reduzieren. Ein Kernmechanismus ist der Proposal/Agreement-Handshake, der die Port-Rollen zwischen benachbarten Switches schnell synchronisiert. Das erlaubt das sofortige Umschalten von alternativen/gestutzten Rollen auf Forwarding, sofern die Bedingungen erfüllt sind.

Step 2: Anwenden auf Punkt-zu-Punkt-Links: Auf einem dedizierten Punkt-zu-Punkt-Link tauschen die beiden RSTP-fähigen Switches BPDUs mit speziellen Flags aus (Proposal/Agreement). Der vorgeschlagene Port sendet einen Proposal; der Nachbar prüft seine lokalen Bedingungen und antwortet mit Agreement, woraufhin der ursprüngliche Port sofort in Forwarding wechselt. Dadurch entfallen lange Timer-Wartezeiten (z. B. Listening/Listening/Forwarding bei klassischen STP) und es kommt zu sehr schneller Konvergenz.

Step 3: Praktische Implikationen und Designempfehlungen: In Campus-Netzen sollten Punkt-zu-Punkt-Verbindungen zwischen Distribution/Core-Switches RSTP verwenden, sodass Proposal/Agreement die Topologieänderungen schnell verarbeitet. Edge-Ports (Access zu Endgeräten) sollten zusätzlich mit PortFast konfiguriert werden, damit diese Ports sofort Forwarding erreichen, aber das ist ein separater Mechanismus für Host-Ports. Trap: Ein häufiger Irrtum ist zu glauben, PortFast sei der Mechanismus, der RSTP-spezifische schnelle Konvergenz auf Switch-zu-Switch-Links ermöglicht. PortFast ist ausschließlich für Access-Ports gedacht und erlaubt schnellen Übergang, sollte aber nie auf normalen Trunk-Link zwischen Switches angewendet werden. Why each wrong answer fails: - Der Proposal/Agreement (richtig): Dies ist der eigentliche RSTP-Mechanismus, der schnellen Port-Zustandswechsel auf Punkt-zu-Punkt-Verbindungen erlaubt. - PortFast auf dem Distribution-Link (falsch): PortFast ist nur für Endgeräte-Ports (Access-Ports) gedacht. Wird PortFast auf einem Switch-zu-Switch-Link aktiviert, kann das zu unerwarteten Loops oder falschen Rollen führen, weil es die normalen STP/RSTP-Entscheidungen für Transit-Links umgeht. - UplinkFast auf den Access-Switches (falsch): UplinkFast ist eine Cisco-spezifische Erweiterung zur Beschleunigung von Convergence beim Ausfall eines Uplinks auf einem Multi-layer-Switch, aber es ist nicht die RSTP-eigene Proposal/Agreement-Mechanik und gilt nicht allgemein für Punkt-zu-Punkt-RSTP-Handshake. - BPDU-Guard am Port (falsch): BPDU-Guard ist eine Schutzfunktion, die Ports in den err-disabled Zustand versetzt, wenn BPDUs empfangen werden (typischerweise auf Access-Ports). Sie beschleunigt nicht die Konvergenz und verhindert eher Fehlkonfigurationen. Zusammenfassend: Für schnelle, deterministische Port-Übergänge zwischen Switches ist der RSTP-Proposal/Agreement-Mechanismus verantwortlich; PortFast und andere Cisco-Features haben andere Anwendungsfälle und können bei falscher Anwendung Probleme verursachen.

Step 1: Problem verstehen — Native VLANs werden ungetaggt über 802.1Q-Trunks transportiert. Ein Mismatch oder standardmäßiges Verwenden von VLAN 1 als native VLAN öffnet Angriffsflächen (VLAN-Hopping, CVE-Szenarien) und kann dazu führen, dass Frames ungetaggt in das falsche VLAN gelangen.

Step 2: Konkrete Schutzmaßnahmen — a) Setzen Sie die native VLAN-ID auf eine ungenutzte VLAN-Nummer (z. B. VLAN 999) auf beiden Endpunkten eines Trunks, so dass selbst wenn ungetaggte Frames auftauchen, diese in ein isoliertes VLAN geleitet werden ohne Produktionszugang. b) Schalten Sie DTP ab ('switchport nonegotiate') und konfigurieren Sie Trunks manuell ('switchport mode trunk'), damit keine automatische Aushandlung stattfindet, die zu unbeabsichtigten Trunks führen kann.

Step 3: Umsetzung und Test — Stellen Sie sicher, dass beide Seiten eines Trunks dieselbe native VLAN-ID und dieselbe Trunk-Konfiguration haben; prüfen Sie mittels 'show interfaces trunk' oder 'show spanning-tree' die getaggten/native VLANs und führen Sie Penetrationstests durch. Trap: Viele Admins denken, die beste Praxis sei, einfach alles auf Standard (VLAN 1) zu belassen, weil es einfacher ist; genau das macht das Netzwerk aber angreifbar. Warum jede falsche Antwort scheitert: Option 3 (native VLAN auf VLAN 1 belassen) — VLAN 1 ist historisch der Default und wird häufig für Management genutzt; diese Praxis erhöht die Angriffsfläche, weil viele Geräte per Default damit arbeiten. Sicherheitsbest-practices raten, VLAN 1 nicht zu verwenden bzw. native VLAN zu ändern. Option 4 (PortFast auf Trunk-Ports) — PortFast ist nur für Access-Ports an Endgeräten gedacht; auf Trunk-Ports würde PortFast STP-Sicherheitsmechanismen umgehen und Netzwerkschleifen oder Fehlverhalten bei Topologieänderungen begünstigen. Zusammenfassung: Die Kombination aus explizitem, identischem native-Vlan-Setzen auf beiden Seiten und Abschalten automatischer Trunk-Aushandlung (DTP) minimiert native-VLAN-Risiken; Standardbeibehaltung oder falsche Port-Einstellungen erhöhen dagegen das Risiko.

Step 1: Proposal/Agreement verstehen. RSTP verwendet ein Proposal/Agreement-Verfahren zwischen benachbarten Bridges: Ein designated Port schlägt vor (proposal), dass er in den Forwarding-Zustand wechseln will; der Nachbar sendet eine Agreement-Antwort, wenn seine Ports keinen Loop verursachen. Dieses Handshake erlaubt unmittelbare Übergänge von blocking->forwarding ohne das Warten auf Forward Delay/Max Age, sofern die Bedingungen stimmen.

Step 2: Portrollen Alternate und Backup. RSTP führt zusätzliche Portrollen ein: Alternate Ports bieten einen alternativen Pfad zur Root-Bridge, Backup Ports schützen gegen lokale Redundanz auf demselben Switch. Diese Rollen ermöglichen, dass bei Ausfall eines aktiven Pfads sofort ein bereits bekannte Ersatzpfad verwendet werden kann, sodass Konvergenz nahezu sofort erfolgt.

Step 3: Why timers are less important und Kompatibilität. Während RSTP kompatibel mit STP ist, verlässt es sich nicht auf die langen STP-Timer für normale Konvergenzpfade. RSTP ist so designt, dass viele Situationen ohne Timer-Wartezeiten gelöst werden, indem Portzustände aktiv ausgehandelt werden. Für Interoperabilität mit STP können jedoch noch Timer-Effekte auftreten. Trap: Ein häufiger Irrtum ist, RSTP würde lediglich die Timer verkürzen; tatsächlich führt RSTP neue Rollen und Nachrichtenaustauschmechanismen ein, die Wartezeiten überwinden. Why each wrong answer fails: - Antwort 1 (richtig): Proposal/Agreement ist ein Kernmechanismus von RSTP zum schnellen Wechsel in Forwarding. - Antwort 2 (richtig): Alternate und Backup Rollen geben vorab definierte Ersatzpfade, die sofort verwendet werden können. - Antwort 3 (falsch): RSTP behält nicht die klassischen STP-Timer als primäre Methode zur Konvergenz; es umgeht viele Timer durch aktive Verhandlungen. Die alten Timers bleiben nur für Interoperabilität mit legacy-STP relevant. - Antwort 4 (falsch): RSTP deaktiviert keine BPDU-basierten Schutzmechanismen standardmäßig; Schutzmechanismen wie BPDU Guard sind separate Features für port-sicherheit und werden nicht von RSTP deaktiviert, um Konvergenz zu beschleunigen. Fazit: Proposal/Agreement plus die speziellen Portrollen sind die Hauptgründe, warum RSTP deutlich schneller als klassisches STP konvergiert.

Step 1: Ziel des Router-on-a-Stick ist es, mehrere VLANs über einen einzigen physischen Link zwischen Switch und Router zu transportieren. Dazu müssen VLAN-Tags (in der Regel 802.1Q) auf dem Link erscheinen, damit der Router unterschiedliche Subinterfaces für jedes VLAN erkennen kann. Der Switchport am Switch muss also als Trunk konfiguriert sein.

Step 2: Auf dem Router werden für jedes VLAN Subinterfaces angelegt (z. B. Gi0/0.10 und Gi0/0.20) und mit dem Befehl encapsulation dot1q <VLAN-ID> versehen. Jede Subinterface bekommt dann die entsprechende SVI-IP-Adresse als Default-Gateway für die Hosts im jeweiligen VLAN.

Step 3: Verkehrsfluss: Frames vom Host werden vom Access-Port ins korrespondierende VLAN gestellt, der Trunk taggt die Frames (802.1Q), der Router erkennt per Subinterface das Tag und routet zwischen den Subnetzen. Trap: Ein häufiger Fehler ist die Verwechslung mit SVIs auf einem Multilayer-Switch oder die Annahme, dass ein Access-Port auf dem Switch ausreicht — beide führen dazu, dass nur ein VLAN über den Link möglich ist. Why each wrong answer fails: - Option 2 (access port / einzelne IP auf Router): Ein Access-Port transportiert nur ein VLAN. Damit könnten nur Hosts eines VLANs (hier VLAN 10) kommunizieren; VLAN 20-Verkehr würde nicht über den Link gelangen. Kein Inter-VLAN-Routing über einen Link möglich. - Option 3 (ISL und keine Subinterfaces auf Router): ISL ist ein veraltetes Cisco-eigenes Trunking-Verfahren, das in modernen Umgebungen kaum noch verwendet wird; zudem fehlt auf dem Router die notwendige Unterteilung in Subinterfaces mit VLAN-Tagging, also kein Routing der VLANs. - Option 4 (SVIs auf Switch und Router-Schnittstelle als Access): SVIs sind nur auf Multilayer-Switches sinnvoll; wenn der Router-Port als Access konfiguriert wäre, könnte er nur ein VLAN erreichen. Außerdem widerspricht dies der Idee des Router-on-a-Stick (wo der Router die Subinterfaces braucht). Kurz: Nur die Kombination aus Switch-Trunk und Router-Subinterfaces mit encapsulation dot1q ermöglicht korrektes Router-on-a-Stick Inter‑VLAN‑Routing über einen einzigen physikalischen Link.

Step 1: Verständnis der trunk allowed vlan-Optionen — Beim Konfigurieren eines 802.1Q-Trunkports gibt es zwei relevante Modi: 'switchport trunk allowed vlan <liste>' setzt die Liste der erlaubten VLANs (überschreibt), während 'switchport trunk allowed vlan add <vlan>' ein VLAN zur bestehenden Liste hinzufügt. Das Wissen ist wichtig, um unbeabsichtigte Abschneidungen von VLANs zu vermeiden.

Step 2: Anwendung im Szenario — Da die Anforderung lautet, VLAN 50 hinzuzufügen, ohne andere erlaubte VLANs zu entfernen, ist die 'add'-Variante erforderlich. 'switchport trunk allowed vlan 50' würde die allowed-Liste auf nur VLAN 50 reduzieren, was Netzwerkunterbrechungen für andere VLANs verursachen kann.

Step 3: Umsetzung und Verifikation — Konsistente Konfiguration an beiden Enden des Trunks ist empfehlenswert. Nach 'switchport trunk allowed vlan add 50' prüfen Sie mit 'show interfaces trunk' oder 'show running-config interface <int>' und verifizieren Sie, dass alle gewünschten VLANs durchgereicht werden. Bei Automatisierung können Sie Playbooks/Config-Templates verwenden, die 'add' statt 'set' verwenden, um menschliche Fehler zu vermeiden. Trap: Ein häufiger Fehler ist anzunehmen, dass 'switchport trunk allowed vlan 50' VLAN 50 hinzufügt; tatsächlich ersetzt dieser Befehl die Liste und führt oft zu Ausfällen. Ebenso verwechseln einige Admins 'native' mit 'allowed' — 'native' ändert die ungetaggte VLAN-Identität, nicht die erlaubten VLANs. Warum jede falsche Antwort fehlschlägt: - Antwort 2 (switchport trunk allowed vlan 50): Falsch, weil dieser Befehl die komplette allowed VLAN-Liste auf nur VLAN 50 setzt und damit eventuell andere VLANs entfernt — das ist genau das, was vermieden werden soll. - Antwort 3 (switchport mode access vlan 50): Falsch — das macht den Port zu einem Access-Port in VLAN 50 und entfernt Trunking komplett; das ist nicht gewünscht, wenn ein Trunk bestehen bleiben soll. - Antwort 4 (switchport trunk native 50): Falsch — dieser Befehl setzt die native (untagged) VLAN auf 50, beeinflusst jedoch nicht die Liste der erlaubten VLANs; zudem kann eine falsche native VLAN-Einstellung zu Native-VLAN-Mismatch-Problemen führen. Zusammenhang: Korrekte Trunk- und VLAN-Verwaltung berührt Switching, VLAN-Planung, STP-Auswirkungen und Sicherheitsaspekte. Automatisierungs-Tools sollten 'add'-Operationen verwenden, um Konfigurationsunterbrechungen zu vermeiden, und Monitoring sollte Änderungen an trunk-allowed-Listen melden.

Step 1: LACP-Modi verstehen LACP (Link Aggregation Control Protocol) kennt zwei Modi: active und passive. Ein Interface in 'active' sendet aktiv LACP-PDUs (Link Aggregation Control PDUs) zur Aushandlung. Ein Interface in 'passive' lauscht auf LACP-PDUs und reagiert darauf, sendet aber nicht von sich aus PDUs. Das Gegenstück ist entscheidend: zur Bildung einer Aggregation muss mindestens eine Seite aktiv LACP-PDUs senden.

Step 2: Kombinationen und deren Resultate - active/active: Beide Seiten senden PDUs, LACP bildet einen stabilen EtherChannel — funktioniert. - active/passive: Die 'active'-Seite sendet PDUs, die 'passive'-Seite empfängt und antwortet; LACP-Verhandlung findet statt und der EtherChannel wird gebildet — funktioniert. - passive/passive: Keine Seite sendet PDUs aktiv, somit findet keine Verhandlung statt und LACP bildet keinen EtherChannel — führt zum Scheitern. - on/on (keine LACP-Verhandlung, statische Bündelung): funktioniert unabhängig von LACP-Modi, aber erfordert, dass beide Seiten manuell auf 'on' gesetzt sind und alle Interface-Parameter übereinstimmen.

Step 3: Konsequenzen in der Praxis In einer heterogenen oder durch Automation verwalteten Umgebung (z. B. Konfiguration per Ansible Templates) ist zu empfehlen, konsistente Modi zu nutzen. Active/passive ist zulässig und oft verwendet, aber um Missverständnisse zu vermeiden, setzen viele Admins beide Seiten auf 'active' (oder verwenden statische 'on' nur in kontrollierten Umgebungen). Ein automatisiertes Compliance-Checkscript sollte prüfen, ob auf beiden Seiten kompatible Modi konfiguriert sind. Trap: Übliche Fehlannahme Viele glauben fälschlicherweise, dass 'passive' auf einer Seite zwingend zum Scheitern führt; tatsächlich reicht ein 'active'-Partner aus, damit LACP funktioniert. Das wirkliche Problem ist passive/passive. Why each wrong answer fails: 1) passive/passive Problem: Falsch in diesem Szenario — passive/passive würde tatsächlich scheitern, aber hier ist Switch A 'active', daher trifft diese Option nicht zu. 3) Nur active/active funktioniert: Falsch — active/passive ist ebenfalls eine gültige und funktionierende Kombination, weil die aktive Seite die PDUs initiiert. 4) Verbindung geht in Errdisable: Falsch — LACP-Verhandlungsprobleme führen nicht automatisch zu Errdisable; Errdisable tritt bei anderen Fehlerszenarien (z. B. BPDU Guard, Port-Security violation) auf. Ergebnis: Mit active auf Switch A und passive auf Switch B wird LACP erfolgreich verhandelt und der EtherChannel gebildet.