CCNA — Network Fundamentals: 114 Übungsfragen

Step 1: Grundlagen der /20-Subnetzmaske. Eine /20-Subnetzmaske entspricht 255.255.240.0. Das bedeutet, dass die Subnetz-Inkremente im dritten Oktett in Schritten von 16 liegen (0, 16, 32, 48, ...). Jede Subnetzadresse muss bei diesen Inkrementgrenzen beginnen und die Hostbits (die letzten 12 Bits) müssen null sein, damit es sich um die Netzwerkadresse handelt.

Step 2: Prüfen der einzelnen Optionen gegen die Inkremente. 10.0.16.0 hat das dritte Oktett 16, was ein Vielfaches von 16 ist und die Hostbits sind null: das ist ein gültiges /20-Netzwerk. 10.0.48.0 hat das dritte Oktett 48, ebenfalls ein Vielfaches von 16: ebenfalls gültig. 10.0.15.0 hat das dritte Oktett 15, das ist kein Vielfaches von 16 und liegt innerhalb des Bereichs 10.0.0.0/20 (0–15), also ist es keine Netzwerkadresse (es wäre eine Hostadresse im Netz 10.0.0.0/20). 10.0.32.128/20 hat dritte Oktett 32 (ein Vielfaches von 16), aber die vierte Oktett ist 128, die Hostbits sind nicht null — die Netzwerkadresse müsste 10.0.32.0 sein, nicht 10.0.32.128.

Step 3: Fazit und praktische Anwendung. Für korrekte Subnetzzuweisung in einem Enterprise-Umfeld muss ein Admin sicherstellen, dass die Netzwerkadresse mit den Inkrementgrenzen übereinstimmt und alle Hostbits null sind. Netzplanungswerkzeuge oder das Rechnen mit Binärmasken vermeidet Konfigurationsfehler. Trap: Eine verbreitete Falle ist das Verwechseln von gültigen Hostadressen mit Netzwerkadressen; viele denken, jede Adresse, deren dritte Oktett durch 16 teilbar ist, sei automatisch korrekt, übersehen aber mögliche Nicht-Null-Bits im vierten Oktett (wie bei 10.0.32.128). Warum jede falsche Antwort versagt: - Antwort 2 (10.0.15.0/20) ist falsch, weil 15 kein Vielfaches von 16 ist. 10.0.15.0 würde innerhalb des Netzwerks 10.0.0.0/20 liegen und ist keine korrekte Netzwerkadresse für ein neues /20-Subnetz. - Antwort 4 (10.0.32.128/20) ist falsch, weil bei einer Netzwerkadresse alle Hostbits null sein müssen. Obwohl 32 ein gültiges Inkrement ist, ist die Adresse 10.0.32.128 keine Netzwerkadresse, sondern eine Hostadresse im Netz 10.0.32.0/20. Praktischer Tipp: Beim Design großer Netze empfiehlt es sich, Subnetzkarten zu erstellen und Inkremente tabellarisch aufzuschreiben (z. B. 0,16,32,48,...), um Fehler bei Zuweisungen zu vermeiden.

Step 1: Grundlegendes Verständnis von IPv6-Addressing IPv6 wurde so entworfen, dass Subnetze typischerweise eine Länge von /64 haben. Dieses Design ermöglicht Funktionen wie SLAAC (Stateless Address Autoconfiguration) und EUI-64-basiertes Interface-ID-Generieren. Link-local-Adressen sind für die Kommunikation auf demselben Link reserviert und folgen einem vordefinierten Präfix.

Step 2: Detailbetrachtung der korrekten Aussagen SLAAC und /64: Stateless Address Autoconfiguration erwartet ein 64-Bit-Interface-ID-Feld. Viele Implementierungen erzeugen automatisch eine Interface-ID aus der MAC-Adresse (EUI-64) oder mittels Privacy-Extensions, weshalb /64 das de-facto Standard-Subnetz ist. Link-local Präfix: Das definierte Link-local-Präfix ist fe80::/10, wobei in der Praxis für die Adresse fe80:: bis febf:: reserviert sind; Router und Hosts verwenden diese Adressen für lokale Link-Operationen.

Step 3: Warum die anderen Aussagen falsch sind und praktische Konsequenzen Global Unicast Präfixe sind teilbar: Ein 2001:db8::/32-Präfix kann sehr wohl weiter unterteilt werden (z. B. in /48, /56, /64 usw.) — das ist normale Praxis beim Verteilen von Präfixen an Kunden oder in Organisationen. IPv6 ersetzt Broadcasts durch Multicast und spezielle Neighbor Discovery-Mechanismen (ICMPv6-basierte). Es gibt keine klassische IPv6-Broadcastadresse; stattdessen werden Multicast-Gruppen für ähnliche Zwecke verwendet. Trap: gängige Missverständnisse Viele glauben, IPv6-Subnetting sei zwangsläufig flexibel bis zu beliebiger Präfixlänge und dass man aus Effizienzgründen kleinere Subnetze als /64 verwenden sollte. Das ist bei SLAAC problematisch: einige Geräte, Router und Dienste erwarten /64 und könnten bei anderen Längen unerwartetes Verhalten zeigen. Ein weiterer häufiger Irrtum ist die Annahme, fe80::/16 oder fe80::/64 seien die richtigen Präfixe; korrekt ist fe80::/10 gemäß RFC, wobei die praktische Nutzung oft mit fe80::/64 kombiniert wird. Why each wrong answer fails: Option 1 (richtig): SLAAC und /64 sind ein etabliertes Paar; viele Implementierungen und RFCs setzen /64 voraus. Darum korrekt. Option 2 (richtig): Link-local-Adressen beginnen mit fe80::/10; dies ist in den Standards spezifiziert. Daher korrekt. Option 3 (falsch): Global Unicast Präfixe wie 2001::/32 können sehr wohl weiter unterteilt werden; ISPs und Unternehmen führen Subnetting von großen Präfixen durch. Es gibt keine technische Sperre gegen Subnetting dieser Präfixe. Option 4 (falsch): IPv6 verwendet keine Broadcasts mehr; Funktionen, die in IPv4 Broadcasts nutzten, werden in IPv6 über Multicast und Neighbor Discovery (ICMPv6) realisiert. Deshalb ist diese Aussage falsch. Zusammenfassung: Beim IPv6-Design sollte man /64-Subnetze für SLAAC vorsehen und Link-local (fe80::/10) korrekt einsetzen; Global-Präfixe sind frei subnettierbar, und Broadcasts existieren in IPv6 nicht.

Step 1: Bestimmung der Subnetzgröße Ein /26-Netz hat 32-26=6 Bits für Hosts -> 2^6 = 64 Adressen insgesamt. Diese werden in Blöcken von 64 Adressen entlang des 4. Oktetts angeordnet: 0, 64, 128, 192 sind die möglichen Netzanfänge im Bereich 192.168.10.0/24.

Step 2: Anwendung auf 192.168.10.64/26 Das Subnetz mit Netzwerkadresse 192.168.10.64 startet bei .64 und umfasst 64 Adressen: .64 bis .127. Die erste nutzbare Hostadresse ist Netzwerk+1 = 192.168.10.65. Die letzte nutzbare Hostadresse ist Broadcast-1 = 192.168.10.126. Die Broadcast-Adresse ist .127.

Step 3: Praxis und Bedeutung In einem Unternehmensnetz muss der Admin sicherstellen, dass z. B. Router-Interfaces und Server-Adressen in diesem Bereich keine Adresskonflikte erzeugen. Die Kenntnis von Netzwerk, Broadcast und nutzbaren Adressen ist wichtig für IP-Planung und ACLs. Trap: Häufiger Denkfehler Oft wird angenommen, ein /26 entspräche 26 Hostbits oder man rechnet mit /24-Grenzen; Anfänger übersehen die Aufteilung in 64er-Blöcke und verwechseln Netzwerk- und Broadcastadresse mit benachbarten Subnetzen. Why each wrong answer fails: - Antwort 1: (Netzwerk 192.168.10.0 bis .63) Falsch — das wäre das vorherige /26-Block (0–63), nicht der Block, der bei .64 beginnt. Diese Werte passen zu 192.168.10.0/26. - Antwort 3: (Netzwerk 192.168.10.128 bis .191) Falsch — das ist der dritte /26-Block (Start .128), nicht der .64-Block. - Antwort 4: (Netzwerk 192.168.10.192 bis .255) Falsch — das ist der vierte /26-Block (Start .192). Zusammenfassung: Für 192.168.10.64/26 gilt eindeutig Netzwerk=192.168.10.64, nutzbare Hosts .65–.126 und Broadcast .127. Diese korrekte Adresse ist in Option 2 angegeben.

Step 1: Unterschiedliche Dienste und Modellmapping verstehen — Ping verwendet ICMP, das dem OSI-Layer 3 (Network) bzw. TCP/IP Internet entspricht. Funktionierendes Ping zeigt, dass IP-Paket-Lieferung und grundlegende Routingfunktionen intakt sind. Wenn aber TCP-Dienste (z. B. HTTP auf Port 80) nicht erreichbar sind, liegt der Verdacht auf einer Schicht über Layer 3, typischerweise Layer 4 (Transport), da TCP-Handshake (SYN/SYN-ACK/ACK) fehlschlägt oder gefiltert wird.

Step 2: Praktische Fehlersuche — Prüfen Sie, ob Firewalls, ACLs oder Security-Devices den Port 80 blockieren. Verwenden Sie Tools wie telnet host 80, tcpdump/wireshark, oder Firewall-Logs, um zu sehen, ob SYN-Pakete ankommen und ob Antworten zurückgehen. Prüfen Sie außerdem, ob der Webserver lokal läuft und auf Port 80 lauscht (netstat, ss). Wenn der SYN ankommt, aber keine SYN-ACK zurückkommt, ist es ein Transport-/Filterproblem.

Step 3: Abhilfe und Tests — Wenn die Ursache eine Firewall-Regel ist, passen Sie die ACL/Firewall an oder erstellen Sie eine Ausnahmeregel. Wenn der Webserver nicht auf Port 80 lauscht, konfigurieren Sie den Service korrekt. Nach der Anpassung erneut Tests durchführen (SYN/SYN-ACK-Verlauf beobachten). Trap: Ein häufiger Trugschluss ist, anzunehmen, dass "Ping funktioniert" bedeutet, alles auf Lower Layers ist in Ordnung und man könne Layer 7 ausschließen. Ping bestätigt Layer 3, aber Layer 4 oder höher können trotzdem blockiert sein. Andere Fallen sind, assuming ICMP erlaubt => everything else allowed; das stimmt nicht. Why each wrong answer fails: - OSI-Schicht 1 (Physical) / TCP/IP Network Access: Physikalische Probleme würden auch ICMP-Pings beeinflussen. Da Pings erfolgreich sind, sind physikalische Verbindungen und Signalisierung höchstwahrscheinlich in Ordnung. - OSI-Schicht 2 (Data Link) / TCP/IP Network Access: Data Link-Probleme betreffen MAC-Adressen, Switching und Zugriff auf lokale Segmente; diese würden ebenfalls Pings beeinflussen, zumindest lokal. Erfolgreiche Pings über das Netz legen nahe, dass Layer 2 grundsätzlich funktioniert. - OSI-Schicht 3 (Network) / TCP/IP Internet: Wenn Layer 3 fehlerhaft wäre, würden ICMP-Pakete (Ping) nicht zuverlässig funktionieren. Da Pings durchgehen, ist Layer 3 nicht die primäre Fehlerschenkela des Problems. Zusammenfassung: Funktionierendes ICMP zusammen mit nicht funktionierendem TCP-Dienst weist stark auf Layer 4 (Transport) hin — typischerweise Firewall/ACL-Filterung, fehlende TCP-Listener oder Probleme im TCP-Handshake.

Step 1: Grundlegende IPv6-Adressbereiche — IPv6 definiert verschiedene Adresstypen: Link-Local-Adressen sind für die Kommunikation innerhalb eines einzelnen Netzsegmentes reserviert und beginnen mit dem Präfix FE80::/10 (das bedeutet, die ersten 10 Bits sind 1111 1110 10). Diese Adressen werden automatisch für jedes Interface generiert und benötigen keinen DHCP-Server.

Step 2: SLAAC und NDP — SLAAC (Stateless Address Autoconfiguration) erlaubt Hosts, ihre IPv6-Adresse selbstständig zu bilden. Ein Router sendet Router Advertisements (RAs) mittels NDP (Neighbor Discovery Protocol), die das Präfix und andere Parameter ankündigen. Auf Basis dieser RAs kann ein Host seine Adresse zusammensetzen (z. B. Präfix + Interface Identifier), typischerweise innerhalb eines /64-Subnetzes, da viele SLAAC-Mechanismen und Interface-Identifier (z. B. EUI-64) auf einem /64 basieren.

Step 3: ARP und Adresslängen — IPv6 ersetzt ARP durch NDP-Funktionen, die über ICMPv6-Nachrichten laufen (Neighbor Solicitation/Advertisement). IPv6-Adressen sind 128 Bit lang, nicht 32 Bit wie IPv4. Das Protokoll-Set rund um NDP bietet Funktionen für Neighbor Discovery, Router Discovery, Prefix Discovery und Duplicate Address Detection. Trap: Häufige Fehlannahmen sind, dass IPv6-Hosts ARP verwenden oder dass SLAAC kein festes Präfix erwartet. IPv6 verwendet jedoch NDP und RAs; außerdem basieren viele Implementierungen auf einem /64-Subnetz für SLAAC, weshalb /64 in Enterprise-Designs fast Standard ist. Manche denken auch, IPv6-Adressen seien „nur länger als IPv4, aber 32 Bit bleiben gleich“ — das ist falsch: IPv6 ist 128 Bit. Why each wrong answer fails: - Link-Local-Adressen beginnen standardmäßig mit FE80::/10: Richtig — das ist die definierte Link-Local-Range für IPv6. - IPv6 verwendet ARP zur Adressauflösung zwischen Layer 2 und Layer 3: Falsch — ARP ist ein IPv4-Mechanismus; IPv6 verwendet Neighbor Discovery Protocol (NDP) mit ICMPv6-Nachrichten, um MAC-Adressen zu ermitteln und Nachbarn zu entdecken. - SLAAC nutzt Router Advertisements (Teil von NDP) und erwartet typischerweise ein /64-Präfix pro Subnetz: Richtig — SLAAC funktioniert durch RAs, und die Praxis/Standards gehen von /64-Subnetzen aus, weil Interface-Identifier 64 Bits im EUI-64-Verfahren verwenden. - IPv6-Adressen sind 32 Bit lang wie IPv4: Falsch — IPv6-Adressen sind 128 Bit lang; IPv4-Adressen sind 32 Bit. Zusammenfassung: Korrekt sind die Aussagen zu FE80-Link-Local und SLAAC+RAs; ARP und 32 Bit-Behauptungen sind veraltet bzw. falsch.

Step 1: Bestimmen Sie die benötigte Host-Anzahl pro Subnetz. Gefordert sind mindestens 10 Hosts je Subnetz. Für IPv4-Subnetze müssen wir eine Präfixlänge wählen, die ausreichend viele nutzbare Host-Adressen bereitstellt. Ein /28-Netz hat 16 Adressen, davon 14 nutzbare Hosts; ein /27-Netz hat 32 Adressen, davon 30 nutzbare Hosts. Beide erfüllen also die Anforderung von mindestens 10 Hosts.

Step 2: Bestimmen Sie die minimale Anzahl an Subnetzen aus dem Ausgangsnetz 192.168.10.0/24. Sie benötigen mindestens 6 Subnetze. Wenn Sie ein /27 aus einem /24 erstellen, ergibt das 8 Subnetze (weil /24 -> /27 sind 3 zusätzliche Bits für Subnetting → 2^3 = 8). Wenn Sie /28 verwenden, erhalten Sie 16 Subnetze (4 zusätzliche Bits → 2^4 = 16). Beide Varianten liefern also mindestens 6 Subnetze.

Step 3: Abwägen von /26 und /29. Ein /26 liefert pro Subnetz 64 Adressen (62 nutzbare Hosts) — also ausreichend Hosts — aber nur 4 Subnetze aus einem /24 (2 zusätzliche Bits → 2^2 = 4), womit die Anforderung von mindestens 6 Subnetzen nicht erfüllt ist. Ein /29 liefert 8 Adressen (6 nutzbare Hosts) — das sind weniger als die geforderten 10 Hosts und somit ungeeignet. Trap: Eine häufige Fehlannahme ist, nur die Anzahl der möglichen Subnetze oder nur die Host-Anzahl zu prüfen. Beide Kriterien müssen gleichzeitig erfüllt werden. Beispielsweise hat /26 genügend Hosts, aber zu wenige Subnetze; /29 hingegen liefert viele Subnetze, aber nicht genug Hosts pro Subnetz. Why each wrong answer fails: - /29 (255.255.255.248): Dieses Netz hat nur 8 Gesamtadressen, von denen 6 für Hosts nutzbar sind. 6 < 10, somit nicht geeignet. - /26 (255.255.255.192): Obwohl ein /26 mit 62 nutzbaren Hosts die Host-Anforderung erfüllt, entstehen aus einem /24 nur 4 Subnetze (/24 → /26 = 2 zusätzliche Bits → 2^2 = 4). Die Anforderung verlangt mindestens 6 Subnetze, daher scheitert /26 an der Subnetz-Anforderung. Warum die richtigen Antworten funktionieren: - /27 (255.255.255.224): 32 Adressen, 30 nutzbare Hosts (≥10) und aus /24 entstehen 8 Subnetze (≥6) — erfüllt beide Anforderungen. - /28 (255.255.255.240): 16 Adressen, 14 nutzbare Hosts (≥10) und aus /24 entstehen 16 Subnetze (≥6) — ebenfalls erfüllt. Zusammenfassung: Sie müssen sowohl die Anzahl der Subnetze als auch die nutzbaren Hosts pro Subnetz prüfen. Nur /27 und /28 erfüllen beide Vorgaben gleichzeitig.

Step 1: Funktionsweise eines Layer‑2‑Switches Ein Layer‑2‑Switch lernt MAC‑Adressen, indem er Source‑MACs von eingehenden Frames mit dem jeweiligen Ingress‑Port in die CAM (MAC‑Address) Tabelle schreibt. Bei der Weiterleitung sucht er die Ziel‑MAC in dieser Tabelle.

Step 2: Verhalten bei unbekannter Zieladresse Wenn die Ziel‑MAC nicht in der Tabelle vorhanden ist (unknown unicast), kann der Switch nicht zielgerichtet auf einen Port forwarden. Standardmäßig flutet er das Frame als Unicast‑Flood/Broadcast an alle Ports im selben VLAN außer dem Eingangsport, damit der Zielhost die Nachricht empfängt und gegebenenfalls antwortet. Sobald eine Reply eintrifft, lernt der Switch die Ziel‑MAC und wird künftige Frames zielgerichtet zusenden.

Step 3: Operationales Troubleshooting Falls übermäßiges Flooding auftritt, prüfen Sie auf MAC‑Flapping, falsch konfigurierte Trunks oder Schleifen (STP Status). Eine dauerhaft unbekannte MAC kann z. B. durch Hosts mit wechselnden MAC‑Adressen oder durch Maschinen in falschen VLANs verursacht werden. Trap: Ein häufiger Irrtum ist die Erwartung, dass ein Switch bei unbekannten MACs den Traffic zum Router leitet. Switches sind Layer‑2‑Geräte und routen nicht; sie fluten, bis sie die richtige Port‑Zuordnung gelernt haben. Warum jede falsche Antwort scheitert: - Er verwirft das Frame, weil die Zieladresse unbekannt ist: Falsch. Das wäre ineffizient; Switches fluten stattdessen, um den Empfänger zu erreichen und späteres Lernen zu ermöglichen. - Er leitet das Frame zum Default Gateway weiter: Falsch. Ein reiner Layer‑2‑Switch kennt keine IP‑Routing‑Entscheidungen und hat kein Default Gateway‑Forwarding für unbekannte MACs. Nur Layer‑3‑Geräte können routen. - Er sendet einen ARP‑Request, um die Ziel‑MAC zu erfahren: Falsch. ARP‑Requests werden von Hosts generiert, die die MAC zu einer bekannten IP ermitteln wollen. Der Switch selbst generiert keine ARP‑Requests, da er kein IP‑Stack für Weiterleitung der Frames besitzt (außer Management‑Plane, aber nicht für Frame‑Forwarding). Fazit: Flooding bei unbekannter Ziel-MAC ist normales Lernverhalten eines Layer‑2‑Switches. Beobachten Sie dieses Verhalten mit 'show mac address-table' und untersuchen Sie Ursachen bei ungewöhnlich viel Flooding oder Performanceproblemen.

Step 1: Verständnis der Architektur Router-on-a-Stick und SVI/Trunk. Beim Router-on-a-Stick-Design hat der Router Subinterfaces (oder ein externes Router-Interface) für jedes VLAN; der Switch muss VLANs korrekt definiert haben, und der Link zum Router muss als Trunk arbeiten und die betreffenden VLANs durchlassen. Alternativ, bei L3-Switches, existieren SVIs (Switch Virtual Interfaces) als Default-Gateways.

Step 2: Warum die gewählten Ursachen wahrscheinlich sind. Wenn auf dem Switch kein SVI existiert oder VLAN 10 nicht korrekt angelegt ist, hat der Host kein erreichbares Default-Gateway (z. B. 192.168.10.1), wodurch Kommunikation zu anderen VLANs scheitert. Ebenso, wenn der Trunk zwischen Switch und Router VLAN 20 nicht erlaubt, gelangen Frames für VLAN 20 nicht zum Router für Routing — somit ist Inter-VLAN-Kommunikation unterbrochen. Beide Punkte sind typische Konfigurationsfehler beim Aufbau von VLAN- und Inter-VLAN-Routing in Enterprise-Umgebungen.

Step 3: Warum die anderen Ursachen weniger wahrscheinlich oder irreführend sind. MTU-Probleme können zwar Netzwerkkommunikation beeinträchtigen, führen aber üblicherweise nicht dazu, dass komplette Inter-VLAN-Konnektivität ausfällt; sie verursachen eher fragmentierte Verbindungen oder Probleme mit großen Paketen. Ein verlorener MAC-Address-Table-Eintrag auf dem Switch würde zu Flooding führen und möglicherweise kurzfristig die Erreichbarkeit beeinflussen, aber es verhindert nicht grundsätzlich das Routing zwischen VLANs — außerdem löst sich ein MAC-Learning-Problem oft selbst, sobald Frames ausgetauscht werden. Trap: Eine verbreitete Fehlannahme ist, dass Inter-VLAN-Routing automatisch funktioniert, sobald VLANs auf Hosts gesetzt sind. Tatsächlich erfordert es korrekte VLAN-Anlage, Trunk-Konfiguration und entweder SVIs oder Router-Subinterfaces mit passenden Tagging- (dot1Q) Einstellungen. Warum jede falsche Antwort versagt: - Antwort 3 (falsch): Falsche MTU-Werte sind selten die primäre Ursache für vollständig ausgefallene Konnektivität zwischen VLANs. MTU-Probleme erzeugen in der Regel fragmentierungsbedingte Verbindungsprobleme oder PMTUD-Ausfälle, nicht eine komplette Unterbrechung des Layer-3-Routings. - Antwort 4 (falsch): Der Verlust eines MAC-Table-Eintrags kann zu temporärem Flooding führen, verhindert aber nicht grundsätzlich das Vorhandensein eines Gateways oder die Weiterleitung von Paketen zwischen VLANs. Inter-VLAN-Routing hängt primär an der Layer-3-Konfiguration (SVI/Subinterfaces und Trunking). Praktischer Hinweis: Bei Fehleranalyse prüfen Sie systematisch: VLAN-Zuordnung der Ports, SVI/Subinterface-Konfigurationen, Trunk-Status/Allowed VLAN-Liste und dann ARP-/Routing-Tabellen, um die problematische Stelle sicher zu identifizieren.

Step 1: Bestimme die Netzgrößen und Blockgrenzen für eine /20-Maske. Eine /20-Maske entspricht 255.255.240.0. Die Subnetzgröße im dritten Oktett ist 256 - 240 = 16. Das bedeutet, Netzblöcke beginnen bei 0, 16, 32, 48, 64, 80 usw.

Step 2: Bestimme, in welchem Block das gegebene dritte Oktett liegt. Das dritte Oktett der Adresse ist 78. Die vorkommenden Blöcke lauten ...48, 64, 80... 78 liegt daher im Block, der bei 64 beginnt und bis 79 reicht (64–79).

Step 3: Setze die Host-Oktette auf Null für die Netzadresse. Da der Block bei 64 beginnt, ist die Netzadresse 172.16.64.0. Der Hostanteil umfasst die verbleibenden Bits innerhalb der /20-Netzmaske. Trap: Ein häufiger Fehler ist, nur das letzte Oktett oder die nächsten geraden Grenzen zu betrachten (z. B. 78 -> 78.0) oder die Blockgröße falsch zu berechnen (z. B. Blockgröße 8 statt 16). Bei variabler Maskierung (nicht /24) muss man die korrekte Blockgröße in dem betroffenen Oktett berechnen. Why each wrong answer fails: - 172.16.78.0: Dieses Ergebnis entsteht, wenn man fälschlich annimmt, dass die Netzgrenze auf Oktett-Grenzen (/24) liegt oder nur das letzte Oktett nullt; bei /20 ist das falsch, weil die Netzgrenze im dritten Oktett stattfindet und das dritte Oktett nicht 78, sondern 64 als Basis haben muss. - 172.16.80.0: 80 wäre der nächste Blockbeginn nach 64 (64 + 16 = 80). Die Adresse 172.16.78.33 liegt aber noch im Block 64–79, somit ist 80.0 das Netz der nachfolgenden Subnetzgruppe, nicht des gesuchten Hosts. - 172.16.96.0: 96 liegt zwei Blöcke nach 64 (64 + 32 = 96) und wäre ein viel weiter entferntes Netzwerk. Diese Option reflektiert ein Missverständnis der Blockgröße oder das Überspringen von Blöcken. Zusammenfassung: Der korrekte Weg ist, die Maske in dezimaler Form zu erkennen (255.255.240.0), die Blockgröße (16) zu berechnen, den Block zu finden, der das dritte Oktett 78 enthält (64–79) und dann die Netzadresse mit den Host-Oktetten auf Null zu bilden -> 172.16.64.0.

Step 1: ARP-Verhalten bei lokalem vs. entfernten Ziel Ein Host entscheidet zuerst anhand seiner Subnetzmaske, ob das gewünschte Ziel im lokalen Subnetz liegt. Liegt das Ziel in einem anderen Subnetz, sendet der Host das Paket nicht direkt an das Ziel, sondern an sein Default-Gateway (Router). Um das Ethernet-Frame korrekt zu adressieren, benötigt der Host die MAC-Adresse des Gateways, welche er per ARP (Address Resolution Protocol) abfragt.

Step 2: Ablauf der ARP-Auflösung und Paketzustellung Der Host prüft die Routing-Entscheidung: Ziel außerhalb des lokalen Subnetzes → Ziel per Default-Gateway erreichbar. Der Host sendet eine ARP-Broadcast-Anfrage im lokalen Netz (Wer hat IP 192.168.x.x? Sende an alle), das Gateway antwortet mit seiner MAC-Adresse. Danach verpackt der Host das IP-Paket in ein Ethernet-Frame mit der Quell-MAC des Hosts und der Ziel-MAC des Gateways und sendet es zum Switch/Router.

Step 3: Praktische Hinweise und Fehlerbehebung - Falls das Gateway nicht antwortet, prüfe ob Gateway-IP korrekt konfiguriert ist und ob der Switch-Port im richtigen VLAN ist. - ARP-Cache kann mittels 'arp -a' kontrolliert werden; leere oder falsche Einträge weisen auf Kommunikationsprobleme hin. - Beachten, dass ARP nur lokal funktioniert; Router und Layer-3-Geräte sind zur Weiterleitung zwischen Subnetzen erforderlich. Trap: Ein verbreiteter Irrtum ist, dass Hosts ARP für entfernte Ziele oder dass Router transparent ARP-Anfragen über Subnetzgrenzen hinweg weiterleiten. ARP ist auf das lokale Broadcast-Domain/Subnetz beschränkt. Why each wrong answer fails: - Der Host sendet eine ARP-Anfrage für die Ziel-IP (Layer-3-Adresse) und überträgt das Paket direkt zum Ziel-MAC: Das wäre nur korrekt, wenn das Ziel im selben IP-Subnetz liegt. Da hier explizit ein Ziel außerhalb des Subnetzes vorliegt, führt eine ARP-Anfrage für die Ziel-IP ins Leere; ARP-Anfragen für nicht-lokale IPs werden nicht beantwortet. - Der Host sendet sofort das IP-Paket an die Ziel-IP ohne ARP, weil Routing vom Router übernommen wird: Ohne ARP kennt der Host keine Ziel-MAC-Adresse für das Ethernet-Frame; daher kann kein Layer-2-Frame zugestellt werden. Router übernehmen zwar das Routing auf Layer 3, aber der Host muss zunächst das Paket an die MAC des Gateways adressieren. - Der Host tunnelt das Paket per GRE zum Router, wenn das Ziel nicht im Subnetz ist: GRE oder andere Tunnelmechanismen werden nicht automatisch vom Host für Standard-IPv4-Zielsendungen verwendet; Tunnel müssen explizit konfiguriert werden. Der Standardvorgang ist ARP für das Gateway und Lieferung an dieses. Fazit: Bei Zielen außerhalb des eigenen Subnetzes löst der Host die MAC-Adresse des Default-Gateways per ARP auf und sendet das Paket an dieses Gateway, welches das Routing übernimmt.

Step 1: Symptome und Konfiguration überprüfen: Ein Duplex-Mismatch entsteht, wenn eine Seite eines Links auf Full-Duplex fest konfiguriert ist und die andere Seite Auto-Negotiation verwendet, die auf Half-Duplex herunterhandelt. In diesem Szenario sieht man typischerweise hohe Kollisionszahlen und spitzenartige Fehler auf der half-duplex-seitigen Anzeige sowie starke Paketverluste und niedrige Durchsätze, während die Full-Duplex-Seite oft nur Retransmissions oder CRC-Fehler anzeigt.

Step 2: Warum genau passieren diese Symptome? Full-Duplex erwartet, dass beide Richtungen gleichzeitig ohne Kollisionen arbeiten können; Half-Duplex benutzt CSMA/CD und geht davon aus, dass Kollisionen möglich sind. Wenn eine Seite glaubt, sie könne gleichzeitig senden und empfangen (Full), aber die Gegenstelle sendet nach CSMA/CD-Logik und führt Kollisionserkennung durch (Half), entstehen 'späte' Kollisionen, Symbolfehler und Signale, die als Fehler zählen — die Performance bricht ein, weil viele Frames wiederholt werden müssen.

Step 3: Praktische Fehlersuche und Behebung: Prüfen Sie die Duplex-Einstellungen auf beiden Seiten; wenn Auto-Negotiation verwendet wird, sollten beide Seiten auf Auto stehen. Bei manueller Konfiguration müssen beide Seiten identisch gesetzt sein (entweder beide Full oder beide Half). Moderne Empfehlungen favorisieren Auto-Negotiation, um Inkonsistenzen zu vermeiden. Trap: Häufiger Irrtum ist, sofort von schlechtem Kabel oder VLAN-Problemen auszugehen. Zwar kann schlechtes Kabel ähnliche Symptome verursachen, aber die beschriebene asymmetrische Fehlerverteilung plus die explizite Konfiguration (eine Seite Full, andere Auto) ist ein klassischer Duplex-Mismatch-Indikator. Warum jede falsche Antwort versagt: Kabelqualität schlecht (falsch): Das könnte CRC- oder Link-Fehler erzeugen, aber würde normalerweise auf beiden Seiten zu ähnlichen Fehlerindikationen führen und nicht zu einem typischen Muster, bei dem eine Seite hohe Kollisionen meldet und die andere nicht. MTU stimmt nicht überein (falsch): MTU-Probleme führen zu Fragmentierung, PMTU-Black-Hole-Effekten oder hohen TCP-Overhead/Timeouts, aber nicht zu Kollisionen auf physikalischer Ebene. VLAN falsch konfiguriert (falsch): VLAN-Fehler können Broadcast-/Leitungsprobleme und Erreichbarkeitsfehler erzeugen, aber sie verursachen keine klassischen Halbe/Volle Duplex-bedingten Kollisionsspitzen auf einem bestimmten Port. Daher ist der Duplex-Mismatch die naheliegendste und technisch richtige Ursache.

Step 1: Grundlagen: HTTPS ist HTTP über TLS/SSL und läuft standardmäßig über TCP. Um eine gesicherte Webverbindung aufzubauen, vereinbaren Client und Server eine TLS-Sitzung und transportieren dann HTTP über diesen verschlüsselten Kanal.

Step 2: Portzuordnung: Der standardisierte TCP-Port für HTTPS ist 443; Clients verbinden sich üblicherweise zu diesem Port, sofern keine explizite Portangabe erfolgt. Firewalls und Load-Balancer werden oft so konfiguriert, dass TCP/443 für sicheren Webverkehr offen ist.

Step 3: Praxis und Ausnahmen: Manche Dienste nutzen andere Ports für HTTPS (z. B. 8443 für Verwaltungsinterfaces), aber 443 ist der Standard und sollte in Tests und Basisnetzdesigns angenommen werden. Trap: Eine häufige Verwechslung ist, dass Port 80 für Webverkehr steht — das ist korrekt für unverschlüsseltes HTTP, nicht für verschlüsseltes HTTPS. Why each wrong answer fails: - Port 22 (SSH): SSH verwendet TCP/22 und ist für sichere Shell-Verbindungen und Dateitransfer (z. B. SCP/SFTP) gedacht, nicht für Webbrowser-HTTPS. Ein Browser würde keine HTTPS-Verbindung über Port 22 erwarten. - Port 80 (HTTP): Port 80 ist der Standard für unverschlüsseltes HTTP. Wenn man Port 80 verwendet, ist die Verbindung nicht per TLS/SSL verschlüsselt, daher ist dies kein HTTPS-Port. - Port 53 (DNS): Port 53 ist für DNS-Queries (meist UDP, teils TCP) reserviert; DNS ist ein Namensauflösungsprotokoll und hat nichts mit dem Transport von HTTP/HTTPS-Inhalten zu tun. Zusammenfassung: Für verschlüsselten Webverkehr ist TCP Port 443 der korrekte Standard; die anderen Ports gehören zu anderen Protokollen und Zwecken.