CCNA — IP Connectivity: 140 Übungsfragen

Step 1: Identifizieren des Route-Eintrags Im Output sehen wir eine statische Route (S) für 10.10.10.0/24 mit dem Next-Hop 192.168.1.2. Das bedeutet, der Router hat diese Route mit einem Next-Hop-IP-Wert konfiguriert und nicht nur als Exit-Interface.

Step 2: Rekursive Auflösung des Next-Hop Bevor der Router Pakete an 192.168.1.2 sendet, prüft er, ob 192.168.1.2 über seine lokale Routing-Tabelle erreichbar ist. Im Beispiel ist 192.168.1.2 in das verbundene Netzwerk 192.168.1.0/24 (C) gefallen, das über GigabitEthernet0/0 erreichbar ist. Der Router löst den Next-Hop rekursiv auf und bestimmt so das physikalische Ausgangsinterface und MAC-Adresse (ARP) für die Weiterleitung.

Step 3: Weiterleitung an den Next-Hop Nach erfolgreicher Auflösung sendet der Router die Pakete an 192.168.1.2 (ARP → Layer-2-Forwarding) über GigabitEthernet0/0. Der Next-Hop ist die definierte Weiterleitungsadresse und wird bevorzugt verwendet. Trap: Verwechslung Exit-Interface vs. Next-Hop Ein häufiger Fehler ist zu glauben, dass bei Angabe eines Exit-Interfaces automatisch dieses (ohne ARP) verwendet wird oder dass eine statische Route ohne Next-Hop bevorzugt wird. Hier wurde jedoch ein Next-Hop angegeben, daher ist 192.168.1.2 maßgeblich. Warum die falschen Antworten fehlschlagen: - Antwort 2 (direktes Nutzen des Ausgangsinterface): Falsch, weil die Route einen Next-Hop-IP besitzt. Der Router verwendet das Ausgangsinterface nur, nachdem der Next-Hop rekursiv aufgelöst wurde; er sendet nicht pauschal alle Pakete nur anhand des Interfaces ohne ARP, außer bei bestimmten Punkt-zu-Punkt-Konfigurationen. - Antwort 3 (Verwerfen der Pakete): Falsch, sofern der Next-Hop erreichbar ist. Nur wenn 192.168.1.2 nicht in der Routing-Tabelle gefunden oder nicht ARP-aufgelöst werden kann, würden Pakete nicht weitergeleitet werden. Das gezeigte Routing-Output zeigt aber, dass 192.168.1.2 zur verbundenen 192.168.1.0/24 gehört. - Antwort 4 (Gateway of last resort): Falsch, weil für dieses Ziel eine spezifische statische Route existiert; das Gateway of last resort (Default-Route) wird nur verwendet, wenn keine spezifische Route vorhanden ist. Fazit: Der Router sendet an den konfigurierten Next-Hop 192.168.1.2 (Antwort 1).

Step 1: Rekursive Auflösung verstehen: Wenn eine statische Route mit einem IP-Next-Hop konfiguriert wird, muss der Router zunächst eine Route zu genau diesem Next-Hop besitzen (z. B. Connected, Static oder durch ein Routing-Protokoll), damit die statische Route in die RIB übernommen werden kann. Diese Überprüfung nennt man rekursive Auflösung. Ohne eine auflösbare Next-Hop-Route wird die statische Route nicht installiert und ist nicht nutzbar.

Step 2: Exit-Interface vs. Next-Hop: Auf echten Point‑to‑Point‑Links (z. B. serielle PPP, oder dedizierte p2p‑Tunnels) kann man eine statische Route mit nur einer Exit‑Interface‑Angabe konfigurieren; das vermeidet die Notwendigkeit der rekursiven Auflösung, weil das Interface allein genügt, um Pakete direkt in den Link zu senden. Bei Ethernet/Multiaccess ist das Verhalten anders und oft unerwünscht, weil der Router dann ARP für Ziele auf dem Segment sendet und ARP‑Ambiguitäten entstehen können.

Step 3: Fehlerverhalten und Robustheit: Wenn der Next-Hop nicht erreichbar ist, wird die statische Route typischerweise gar nicht in die RIB aufgenommen (bei rekursiver Abhängigkeit). Der Router sendet also nicht blind Pakete an einen nicht existenten Next-Hop. Trap: Ein häufiger Fehler ist die Annahme, dass man für jede statische Route einfach eine beliebige Next-Hop-IP setzen kann und der Router sendet trotzdem — in Wirklichkeit ist die Existenz einer Route zum Next-Hop entscheidend. Warum jede falsche Antwort fehlschlägt: Antwort 2 (Exit-Interface funktioniert immer auf Ethernet) ist irreführend/falsch: Auf Broadcast‑Segmenten führt das Weglassen des Next-Hops zu ARP‑Verhalten und kann zu unerwünschten Effekten führen; es ist nicht allgemein 'immer zuverlässig'. Antwort 4 (Router sendet trotzdem Pakete und verwirft sie) ist falsch: Bevor die Route in die RIB kommt, prüft der Router die Erreichbarkeit des Next-Hops; ist diese nicht gegeben, wird die statische Route typischerweise nicht installiert und es findet kein blindes Senden statt. Rationale für die richtigen Antworten: Antwort 1 ist korrekt, weil rekursive Auflösung eine grundlegende Operation beim Installieren statischer Next-Hop-Routen ist. Antwort 3 ist korrekt, weil auf Point‑to‑Point‑Links die Interface-only statische Route ein anerkanntes Mittel ist, die rekursive Abhängigkeit zu umgehen. Dieses Wissen ist zentral für Next-Hop-Designentscheidungen in Enterprise‑Topologien.

Step 1: OSPF-Kostenberechnung – Formel und Standardwerte OSPFv2 berechnet die Schnittstellenkosten (cost) mit der Formel: cost = reference_bandwidth / interface_bandwidth. Cisco-Router nutzen standardmäßig eine reference_bandwidth von 100 Mbps (historisch bedingt). Die interface_bandwidth wird in Mbps betrachtet (z. B. FastEthernet = 100, GigabitEthernet = 1000).

Step 2: Anwendung auf Gigabit-Ethernet und Rundung/Minimum Setzt man die Werte ein: cost = 100 / 1000 = 0.1. Da OSPF-Kosten in Cisco-Implementierungen als ganzzahlige Werte dargestellt werden und der minimale zulässige Kostenwert 1 ist, wird das Ergebnis auf 1 gesetzt (es gibt keine Kosten kleiner als 1). Deshalb hat eine GbE-Schnittstelle unter der Standard-reference-bandwidth von 100 Mbps Kosten 1.

Step 3: Konsequenzen und Best-Practices in Unternehmensnetzen In modernen Netzwerken mit 10Gbps- oder 40Gbps-Backbones führt die veraltete Referenzbandbreite (100 Mbps) dazu, dass viele schnelle Links denselben Kostenwert (1) erhalten, was die Pfadauswahl reduziert und zum Problem wird. Best Practice ist es, die reference-bandwidth global anzupassen (z. B. auf 10000 für 10 Gbps oder höher), sodass Kosten sinnvoll skaliert werden. Das geschieht mit dem Befehl "auto-cost reference-bandwidth <Wert>" unter OSPF-Konfiguration. Trap: falsche Annahmen über Dezimalwerte oder Minimum Ein häufiger Fehler ist die Annahme, dass OSPF Dezimal-Kosten akzeptiert (z. B. 0.1) oder dass 0 ein gültiger, niedrigster Wert wäre. In Cisco-Implementierungen sind Kosten Integer und Mindestwert = 1. Warum die falschen Antworten scheitern - 10: Dieser Wert würde etwa für eine 10 Mbps Leitung (bei reference 100) entstehen (100/10 = 10), aber nicht für Gigabit. - 0: Obwohl die Berechnung 0.1 ergibt, ist 0 kein zulässiger Kostenwert; OSPF verwendet positive Integralkosten mit Mindestwert 1. - 100: Dieser Wert würde sich ergeben, wenn die Schnittstellenbandbreite 1 Mbps wäre (100/1 = 100) — nicht relevant für Gigabit. Daher ist 100 falsch.

Step 1: Verstehen was HSRP virtualisiert: HSRP stellt eine virtuelle Router-Identität bereit (virtuelle IP + virtuelle MAC). Die virtuelle MAC-Adresse für HSRP folgt dem bekannten Format 0000.0C07.ACxx, wobei xx die HSRP-Group darstellt. Die virtuelle IP dient als Default-Gateway-Adresse für Hosts und muss deshalb im gleichen Subnetz wie die physischen Interfaces der HSRP-Teilnehmer liegen, damit ARP/Layer‑2-Arbeitsweisen korrekt funktionieren.

Step 2: Verhalten bei Übernahme/Preemption: Standardmäßig ist Preemption deaktiviert; ein Router mit höherer Priorität übernimmt nicht automatisch die Active-Rolle, bis Preemption explizit aktiviert ist. Das verhindert flappy leadership bei Router‑Boots oder kurzzeitigen Netzstörungen.

Step 3: Lastverteilung/Active-Router: HSRP ist ein First‑Hop‑Redundancy‑Protokoll, das primär Redundanz bietet; klassische HSRP‑Konfiguration hat genau einen Active-Router (per Gruppe) und verteilt nicht automatisch Last über mehrere aktive Router — Lastverteilung erfordert separate Konfigurationen (z. B. mehrere HSRP‑Gruppen oder GLBP). Trap: Eine häufige Fehlannahme ist, dass HSRP automatisch Load‑Balancing macht; tatsächlich ist HSRP auf Redundanz ausgelegt, nicht auf entropy-basierte Lastverteilung. Warum jede falsche Antwort fehlschlägt: Antwort 2 (Preemption standardmäßig aktiviert) ist falsch, weil Cisco HSRP Preemption nicht standardmäßig setzt; Administratoren müssen preempt explicit einschalten, wenn ein höher-priorisierter Router übernehmen soll. Antwort 4 (HSRP verteilt standardmäßig Last) ist ebenfalls falsch — HSRP wählt einen Active Router für die Gruppe; um Lastverteilung zu erreichen, muss man zusätzliche Techniken nutzen (mehrere HSRP‑Gruppen, VRFs, GLBP oder Policy‑Based‑Routing). Erklärung zu den richtigen Antworten: Die virtuelle MAC (Antwort 1) ist eine dokumentierte Eigenschaft von HSRP und wird tatsächlich verwendet, damit Hosts das Gateway via ARP ansprechen können; die virtuelle IP (Antwort 3) muss im selben Subnetz sein, da sonst ARP und normale L2/L3‑Forwarding-Mechanismen nicht funktionieren und der virtuelle Router nicht korrekt erreichbar wäre. Insgesamt: diese Punkte sind grundlegend für das Verständnis von HSRP-Design und Troubleshooting.

Step 1: Verständnis der HSRP-Arbeitsweise (Virtual MAC und Virtual IP) HSRP (Hot Standby Router Protocol) stellt ein virtuelles Gateway bereit, das Hosts als Default-Gateway nutzen. Dazu wird neben einer virtuellen IP auch eine virtuelle MAC-Adresse angekündigt. Diese virtuelle MAC bleibt gleich, unabhängig davon, welcher physische Router aktuell aktiv ist. Dadurch müssen Hosts ihre ARP-Tabelle nicht neu lernen; der aktive Router übernimmt einfach die virtuelle MAC-Adresse.

Step 2: Format der HSRP-virtuellen MAC Das standardisierte Format für HSRP-Version 1 lautet: 0000.0C07.ACxx, wobei 'xx' die HSRP-Gruppen-ID in hexadezimalem Format darstellt (z. B. Gruppe 10 ergibt AC0A). Dies ist ein proprietärer Cisco-Mechanismus, der eine konsistente virtuelle MAC sicherstellt.

Step 3: Warum Hosts dieselbe virtuelle MAC nach Failover sehen Beim Failover übernimmt der nun aktive HSRP-Router die gleiche virtuelle IP und sendet anschließend GARP/ARP-Antworten mit der identischen virtuellen MAC. Daher sehen die Hosts keine Veränderung in der Gateway-MAC und Unterbrechungen sind minimiert. Trap: Annahme, dass die physische MAC wechselt Viele glauben, dass nach Failover die physische MAC des neuen aktiven Geräts in ARP-Tabellen auftaucht. Das ist nicht korrekt: HSRP sorgt gerade dafür, dass die virtuelle MAC konstant bleibt, damit Endgeräte nicht bei jedem Failover ihre ARP-Einträge aktualisieren müssen. Why each wrong answer fails: - Die physische MAC-Adresse des momentan aktiven Switches: Falsch, denn HSRP nutzt eine virtuelle MAC, nicht die physische MAC eines Geräts. Wäre das so, müssten Hosts bei jedem Failover ARP-Updates durchführen, was zu Verzögerungen führen würde. - 00-50-56-xx-xx-xx (VMware OUI): Falsch; dies ist ein VMware OUI und hat keine Beziehung zu HSRP. HSRP nutzt das spezielle Cisco-Format 0000.0C07.ACxx. - Die MAC-Adresse des DHCP-Servers: Falsch; der DHCP-Server ist in der Regel ein separater Dienst und nicht in die Gateway-Redundanz mittels HSRP involviert. Hosts nutzen die virtuelle HSRP-MAC für Layer-2-Forwarding zu ihrem Default-Gateway. Zusatzhinweis für Enterprise-Umgebungen: In Multi-VRF- oder Virtualisierungsszenarien kann HSRP-Version 2 verwendet werden; das Format der virtuellen MAC ist dann etwas anders (0000.0C9F.Fxxx für VRF-bezogene Funktionen in manchen Implementierungen). Dennoch bleibt das Prinzip der konsistenten virtuellen MAC unverändert. Für automatisiertes Monitoring und Troubleshooting ist es nützlich, die HSRP-Gruppen-ID zu kennen, um die dekodierte virtuelle MAC zu identifizieren.

Step 1: Zieldefinition und Anforderungen analysieren. In diesem Zweigstellenszenario soll sämtlicher Internetverkehr primär über ISP-A geleitet werden, mit automatischem Umschalten auf ISP-B bei Ausfall. Das impliziert ein schlichtes, deterministisches Failover-Verhalten (Primär -> Backup).

Step 2: Beurteilung statischer vs. dynamischer Methoden. Die einfachste und zuverlässigste Methode für primäres/sekundäres Verhalten ist eine Standardroute zu ISP-A plus eine Floating-Static zu ISP-B mit höherer administrative distance: der Router installiert die Route mit niedrigerer AD (ISP-A). Wenn ISP-A ausfällt (z. B. Next-Hop nicht mehr erreichbar), fällt diese Route weg und die Floating-Static mit höherer AD wird als Fallback gewählt. Für anspruchsvollere Anforderungen (z. B. echtes Load Balancing, Multi-homing mit Provider-Routing oder multiple Pfade) ist ein dynamisches Routingprotokoll bzw. BGP die richtige Wahl, weil Protokolle wie OSPF/BGP Metriken, Konvergenz und Multipath handhaben können.

Step 3: Umsetzung und Härtung: Implementieren Sie die Default-Route zu ISP-A, eine Floating-Static zu ISP-B (z. B. ip route 0.0.0.0 0.0.0.0 <ISP-B-next-hop> 250) und prüfen Sie Failover mit Next-Hop-Überwachung oder Object-Tracking. Für Produktions-Internet-Redundanz sollte BGP mit ISPs in Betracht gezogen werden, da BGP Multi-homing, Routing-Policies und Pfadkontrolle bietet. Trap: Häufiger Irrtum ist, dass zwei identische Default-Routen mit gleicher Administrative Distance automatisch Failover oder Load-Balancing zwischen ISPs regeln. Bei den meisten Router-Implementierungen führt das entweder zu multipath nur für gleichwertige Wege innerhalb desselben Routing-Kontexts oder zu unerwünschten Routingentscheidungen; zudem ist BGP die standardmäßige Praxis für Multi-Homing gegenüber ISPs. Warum jede falsche Antwort scheitert: Option 2 (zwei identische Standardrouten mit gleicher AD) ist riskant — ohne korrektes Multipath-Design, AS- und Provider-Routing kann das zu inkonsistentem Verhalten, asymmetrischem Routing und SLA-Problemen führen. Option 3 (manuelles Umschalten) erfüllt nicht die Anforderung 'automatisch' und ist in Produktion ungeeignet, da menschliche Eingriffe Zeit kosten und Fehleranfällig sind. Die korrekten Antworten: Option 1 (Default + Floating Static) erfüllt die geforderte automatische primär/backup-Steuerung einfach und deterministisch. Option 4 (dynamisches Routing/BGP/OSPF) ist korrekt für ein robustes, skalierbares Multi-homing oder wenn Sie feingranulare Kontrolle über Pfade und Lastverteilung benötigen.

Step 1: OSPF-Pfadwahl-Kriterien: OSPF verwendet als Metrik die cumulative cost (Kosten), wobei der Pfad mit der niedrigsten Gesamtkosten zum Ziel als bestes Routing gewählt wird. Die Kosten jeder Schnittstelle werden addiert, um die Gesamtkosten eines Pfades zu ermitteln. Standardmäßig erfolgt nur Equal-Cost-Multipath (ECMP), wenn mehrere Pfade exakt gleiche Gesamtkosten haben.

Step 2: Anwenden auf das Szenario: Pfad 1 hat Gesamtkosten 10, Pfad 2 hat 25. Da 10 < 25, wählt OSPF Pfad 1 als primären Pfad für die Weiterleitung. Es findet keine Aufteilung des Verkehrs auf beide Pfade statt, weil die Kosten nicht gleich sind.

Step 3: Betriebsfolgen und Überlegungen zur Konvergenz: Solange die Kosten stabil bleiben, leitet R_A Verkehr über Pfad 1. Bei Ausfall oder Kostenänderung (z. B. Änderung der Interface-Bandbreite oder manuelles Setzen der Kosten) kann OSPF neu berechnen und ggf. Pfad 2 verwenden. ECMP würde nur greifen, wenn beide Pfade exakt gleiche Kosten hätten; in diesem Fall würden Verkehrslastverteilungsmechanismen auf dem Router (z. B. per-Flow- oder per-destination-Load-Balancing) greifen. Trap: Viele Bewerber verwechseln absolute Interface-Geschwindigkeit mit OSPF-Kosten oder glauben, OSPF würde automatisch beide Wege nutzen, um Last zu verteilen. OSPF nutzt nur gleiche Kosten für Multipath. Warum jede falsche Antwort fehlschlägt: - Pfad 2 (Kosten 25): Falsch, da OSPF stets den Pfad mit den geringsten Kosten bevorzugt; 25 ist höher als 10. - Beide Pfade aktiv (Lastverteilung): Falsch, denn OSPF führt nur Equal-Cost-Multipath durch; die Kosten müssen exakt gleich sein, was hier nicht der Fall ist. - Keiner: OSPF vs. statische Routen: Falsch, OSPF ist ein dynamisches Routing-Protokoll und wird in diesem Szenario Routen in die Forwarding-Tabelle eintragen und verwenden; es sendet Daten nicht pauschal über statische Routen. Diese Erläuterung zeigt, dass Pfad 1 mit Kosten 10 von OSPF ausgewählt wird, solange keine Kostenanpassungen oder Ausfälle auftreten.

Step 1: HSRP-Grundlagen. HSRP (Hot Standby Router Protocol) bietet eine virtuelle IP und eine zugehörige virtuelle MAC-Adresse, die Hosts als ihr Default-Gateway verwenden. Bei HSRP v1 hat die virtuelle MAC ein festgelegtes, patentiertes Format, das von Cisco implementiert ist.

Step 2: Detail zum MAC-Format. Das standardmäßige virtuelle MAC-Präfix für HSRP v1 lautet 0000.0C07.ACxx. Die letzten acht Bits (repräsentiert durch xx) kodieren die HSRP-Gruppennummer in hexadezimaler Darstellung. Beispiel: HSRP-Gruppe 1 ergibt 0000.0C07.AC01. Diese feste Konvention ermöglicht Switches und Hosts, die virtuelle MAC zu erkennen und konsistentes Gateway-Forwarding zu implementieren.

Step 3: Warum das wichtig ist im Netzwerkbetrieb. Wenn HSRP korrekt konfiguriert ist, antwortet immer der aktive Router auf ARP-Anfragen für die virtuelle IP mit der virtuellen MAC; bei einem Failover übernimmt der Standby-Router diese virtuelle MAC, wodurch ein transparentes Gateway-Failover für Clients erreicht wird. Trap: Manche Anwender verwechseln HSRP-MACs mit anderen virtualisierten MAC-Formaten (z. B. VRRP hat ein anderes Format oder verschiedene VMware/Hypervisor-Virtual-MACs). Auch existieren unterschiedliche Formate für HSRP v2 — dort 0000.0C9F.Fxxx — was leicht zu Verwechslungen führt. Why each wrong answer fails: - Antwort 2 (0000.5E00.01xx): Dieses Muster ist nicht das HSRP-Format; 00-00-5E ist häufig mit IANA/IPv4-Multicast-Adressen assoziiert, aber nicht HSRP. - Antwort 3 (00D0.D3FF.FFxx): Kein standardisiertes HSRP-Format; sieht plausibel aus, ist aber nicht das Cisco-HSRP-Präfix. - Antwort 4 (000C.29FF.FFxx): Dieses Präfix erinnert an virtuelle MACs, die Hypervisoren (z. B. VMware) verwenden, aber ist nicht das HSRP-spezifische Format. Nur Antwort 1 entspricht dem dokumentierten HSRP v1-Standard.

Step 1: HSRP Election-Grundlagen: HSRP wählt den Active-Router primär anhand der konfigurierten Priority. Damit ein Router mit höherer Priority eine bereits aktive Einheit ablösen kann, muss Preempt auf diesem Router aktiviert sein. Wenn Preempt deaktiviert ist, bleibt der aktuell aktive Router auch dann aktiv, wenn ein Router mit höherer Priority online kommt.

Step 2: Anwendung auf das Szenario: In diesem Fall hatte R2 vor dem Neustart von R1 die Active-Rolle. R1 hat zwar eine höhere Priority (120 vs. 110), aber Preempt ist auf R1 deaktiviert. Daher wird R1 nach dem Neustart nicht automatisch Active. Damit R1 Active wird, müssten Sie entweder Preempt auf R1 aktivieren oder R2 so beeinflussen (z. B. durch Interface-Tracking, das die Priority von R2 reduziert), dass R1 die höhere effektive Priority erhält.

Step 3: Operationales Verhalten und Empfehlungen: In Produktionsumgebungen empfiehlt es sich, Preempt nur einzusetzen, wenn der Server/Router sauber und vollständig gestartet ist; alternativ sollte man klare Prioritäten und Tracking konfigurieren, um kontrollierte Übernahmen zu ermöglichen. Bei Wartungen sollte man die HSRP-States beobachten und bei Bedarf Preempt temporär aktivieren, um gewünschte Rollen sicherzustellen. Trap: Eine häufige Fehlannahme ist zu glauben, dass die höhere konfigurierte Priority automatisch immer Active wird. Ohne Preempt ist das nicht der Fall: der gerade aktive Router bleibt aktiv, bis er ausfällt oder seine Priority reduziert wird. Why each wrong answer fails: - Option 1 (R1 wird unmittelbar Active): Falsch. Diese Annahme ignoriert den Preempt-Mechanismus. Eine höhere Priority allein erzwingt nicht automatisch eine Übernahme; Preempt muss aktiviert sein, damit der neuere Router die Active-Rolle übernimmt. - Option 4 (Bei gleichen Prioritäten entscheidet die Router-MAC-Adresse): Diese Option ist irreführend in Bezug auf das Szenario. Zwar ist der nächste Tie-Breaker bei gleicher Priority in HSRP tatsächlich die höhere IP-Adresse des Routers (nicht die MAC-Adresse), aber hier sind die Prioritäten nicht gleich; außerdem ist die IP-Adresse das Kriterium, nicht die MAC. Somit trifft diese Aussage auf das gegebene Szenario nicht zu. Zusammenfassung: R2 bleibt Active (Option 2 korrekt). Damit R1 trotzdem Active werden kann, müsste Preempt auf R1 aktiviert werden oder R2 durch Tracking/Fehler in der Priority seine höhere Rolle verlieren (Option 3 korrekt).

Step 1: Verhalten von Link-Local-Adressen verstehen – Link-Local-Adressen (fe80::/10) sind nur auf einer einzelnen Schnittstelle gültig; mehrere Interfaces können dieselbe Link-Local-Adresse auf unterschiedlichen Links haben. Deshalb muss der Router wissen, über welche Schnittstelle der Next-Hop erreichbar ist.

Step 2: Statische Route konfigurieren – Wenn Sie eine statische IPv6-Route mit einem Link-Local-Next-Hop konfigurieren, verlangen viele Router (inkl. Cisco IOS) die Angabe des Ausgangsinterfaces zusammen mit der Link-Local-Adresse (z. B. ipv6 route 2001:db8:1::/64 fe80::1 GigabitEthernet0/0). Ohne Interface wäre die Link-Local-Adresse mehrdeutig.

Step 3: Diagnostik und Reachability – Link-Local-Adressen werden von ping/traceroute ebenfalls interfacespezifisch behandelt; viele Betriebssysteme verlangen, dass Sie das Interface angeben (Scope-Id), z. B. fe80::1%GigabitEthernet0/0 oder fe80::1%eth0, sonst weiß das System nicht, auf welchem Link es das ICMP-Paket senden soll. Trap: Ein häufiger Fehler ist zu glauben, Link-Local-Next-Hops seien grundsätzlich schlechter oder flüchtig als globale Adressen; tatsächlich können Link-Local-Next-Hops stabil und sogar vorteilhaft sein, weil sie unabhängig von Global Unicast-Renumbering sind — aber sie erfordern korrekte Interface-Angabe. Warum jede falsche Antwort fehlschlägt: - Option 1 (Interface muss angegeben werden): Richtig — ohne Interface bleibt die Link-Local-Adresse mehrdeutig, deshalb verlangt die Konfiguration oft die Schnittstelle. - Option 2 (Link-Local nicht empfehlenswert, immer GUA verwenden): Falsch/irreführend — Link-Local-Next-Hops sind gängige Praxis und bringen Vorteile (z. B. Unabhängigkeit von GUA-Renumbering). Es ist nicht korrekt zu sagen, sie gingen beim Router-Neustart „verloren"; Link-Local-Adressen sind teil der Interface-Konfiguration. - Option 3 (Ping benötigt Interface-Angabe): Richtig — zur Erreichbarkeitsprüfung von Link-Local-Adressen muss in vielen Implementierungen die Scope-ID/Interface angegeben werden. - Option 4 (Verhindert, dass Route beim Renumbering gebrochen wird): Falsch/übertrieben — zwar sind Link-Local-Next-Hops resistenter gegen GUA-Renumbering, aber dies „verhindert" nicht alle möglichen Probleme: Wenn sich link-layer-Verbindungen ändern, oder wenn der Next-Hop Link-Local-Adresse sich ändert oder die Schnittstelle wechselt, kann die Route trotzdem brechen. Außerdem benötigt die statische Route oft das Interface explizit; Änderung der Interface-Namen oder -Zustände kann weiterhin Probleme verursachen. Praktischer Rat: Verwenden Sie Link-Local-Next-Hops, wenn Sie direkt verbundene Router haben und Sie die Schnittstellen stabil benennen; sonst sind globale Next-Hops mit entsprechender Überwachung leichter diagnosefähig.

Step 1: Bedeutung des show ip route-Eintrags verstehen: Die Zeile 'O 10.1.0.0/24 [110/20] via 192.168.2.2, 00:00:12, GigabitEthernet0/1' zeigt an, dass die Route durch OSPF gelernt wurde (O), das Präfix 10.1.0.0/24 ist bekannt und der Next-Hop über 192.168.2.2 erreicht werden soll, wobei Gi0/1 als Ausgangsinterface verwendet wird. Bevor der Router Pakete zum Zielnetzwerk forwarden kann, muss er die Erreichbarkeit des Next-Hops bestätigen (rekursiver Lookup/ARP auf der lokalen Verbindung).

Step 2: Häufige Fehlerursachen analysieren: Wenn Pings trotzdem fehlschlagen, sind die zwei plausibelsten Ursachen: (a) Next-Hop nicht erreichbar: Der Router könnte 192.168.2.2 nicht mit ARP auflösen (kein ARP-Eintrag), das lokale Interface könnte administrativ oder physisch down sein, oder es besteht ein Layer-2-Problem zur Nachbarschnittstelle. Ohne einen erreichbaren Next-Hop kann der Router das Paket nicht weiterleiten, obwohl die Route in der Tabelle steht. (b) ACL/Firewall blockiert Traffic: Es ist üblich, dass auf dem ausgehenden Interface eine Access Control List oder ein Device (z. B. Firewall) zwischen den Segmenten ICMP/andere Protokolle filtert. In diesem Fall wäre die Route korrekt, aber der Verkehr wird auf dem Router/einer angrenzenden Komponente blockiert.

Step 3: Troubleshooting-Schritte: Prüfen Sie 'show ip arp' auf dem Router, um zu sehen, ob 192.168.2.2 aufgelöst ist; überprüfen Sie 'show interfaces GigabitEthernet0/1' auf Betriebsstatus und Fehler; prüfen Sie 'show ip protocols' oder OSPF-Nachbarn für Stabile OSPF-Adjazenz; führen Sie 'show access-lists' aus, um ACLs zu finden, die ICMP oder das Zielnetz blockieren. Sind ARP-Einträge vorhanden und kein ACL aktiv, prüfen Sie Layer-2 und die Erreichbarkeit des Next-Hops mittels Traceroute. Trap: Ein häufiger Fehler ist anzunehmen, dass eine vorhandene Route in der Tabelle automatisch Pakete erfolgreich weiterleitet. Eine Route sagt nur, wohin Pakete gesendet würden; wenn der Next-Hop nicht erreichbar ist oder Pakete durch ACLs/FW blockiert werden, findet keine erfolgreiche Weiterleitung statt. Why each wrong answer fails: - Option 2 (Metrik zu hoch, Router verwirft Pakete deswegen): Falsch. Eine höhere OSPF-Metrik beeinflusst die Präferenz gegenüber alternativen Routen; sie führt nicht dazu, dass ein Router Pakete „absichtlich verwirft“, wenn diese Route aktiviert ist. Wenn die Route in der Routingtabelle steht, verwendet der Router sie – vorausgesetzt, der Next-Hop ist erreichbar und es existieren keine Filterregeln. - Option 4 (OSPF-Routen können keine Pakete an interne Hosts weiterleiten; nur statische Routen erlauben das): Falsch und technisch inkorrekt. Gelerntes Routing (OSPF, EIGRP, etc.) wird genauso zum Weiterleiten von Paketen verwendet wie statische Routen. Es gibt keinen generellen Mechanismus, der OSPF-Routen das Forwarding von Paketen an interne Hosts verwehrt. Fazit: Zuerst Next-Hop-Erreichbarkeit (ARP/Interface) prüfen und anschließend ACLs/FW-Filter untersuchen (Optionen 1 und 3).

Step 1: Kompatibilitätsanforderung prüfen: HSRP existiert in mehreren Versionen (v1 und v2). Diese Versionen unterscheiden sich in Protokoll-Details wie Multicast-Adressen, virtuellen MAC-Formaten und unterstützten Gruppenbereichen. HSRP-Router müssen dieselbe Version verwenden, um Nachrichten korrekt zu interpretieren und HSRP-Adjazenzen zu bilden.

Step 2: Effekt unterschiedlicher Versionen: Wenn ein Router HSRP v1 und der andere HSRP v2 nutzt, senden und empfangen sie zwar HSRP-Pakete, aber die Versionierung sorgt dafür, dass die Pakete nicht als kompatibel erkannt werden. Folge: Kein State-Austausch, keine gemeinsamen Heartbeats, und damit keine aktive/standby-Wahl oder virtueller Gateway-Betrieb.

Step 3: Betriebsfolgen und Diagnose: In der Praxis führt das zu zwei unabhängigen Routern, die beide die HSRP-Gruppeninformationen nicht teilen; es kann sogar zu Konflikten kommen, wenn beide Respondieren, was zu einem nicht bestimmten Gateway-Verhalten führen kann. Die Lösung ist, dieselbe HSRP-Version auf beiden Seiten zu konfigurieren (typischerweise v2 in neueren Umgebungen, weil v2 größere Gruppenzahlen und Verbesserungen unterstützt). Trap: Ein häufiger Denkfehler ist anzunehmen, dass HSRP-Versionen abwärtskompatibel sind oder dass nur Gruppen-ID und Priorität relevant sind. In Wahrheit ist die Versionsübereinstimmung eine zwingende Voraussetzung für HSRP-Kommunikation. Why each wrong answer fails: - "HSRP-Version 2 ist inkompatibel mit VLANs; daher kann kein HSRP in VLAN-Umgebungen mit Version 2 arbeiten.": Falsch — HSRP funktioniert in VLAN-Umgebungen mit beiden Versionen. Version 2 ist nicht inkompatibel mit VLANs; sie erweitert lediglich Funktionalität und Gruppenzahlen. - "Der Gruppen-Name muss bei beiden Routern identisch sein; eine unterschiedliche Version verändert automatisch den Gruppennamen.": Falsch — HSRP verwendet Gruppennummern und nicht 'Gruppennamen' im Sinne eines automatisch geänderten Namens. Eine unterschiedliche Version ändert den Gruppennamen nicht automatisch; das Kernproblem ist die Inkompatibilität der Protokollversionen. - "HSRP benötigt zur Kommunikation zwingend IPv6; bei IPv4-Only-Konfigurationen funktioniert HSRP nicht.": Falsch — HSRP wurde ursprünglich für IPv4 entwickelt und funktioniert problemlos in IPv4-Umgebungen. Es ist nicht auf IPv6 angewiesen. Diese Aussage verwechselt HSRP mit IPv6-spezifischen Mechanismen. Kurz: Die wahrscheinlichste Ursache ist die Versionsinkompatibilität; HSRP-Router müssen dieselbe Version (v1 oder v2) verwenden, damit eine HSRP-Beziehung gebildet werden kann.