Skip to content

FAQ

Questions regarding the Mini-Internet

I have a problem when running a traceroute. It takes quite some time, and the DNS service does not work.

When you run a traceroute, remember that only the hosts connected to the routers are configured to use the DNS service. If you run a traceroute from a router, it will not translate the IP addresses. If the DNS service is not reachable (e.g., because you have not configured OSPF yet), run the traceroute with the option -n. This will tell traceroute not to translate the IP addresses, and it will save you some time.

How can I erase a configuration I have done on a FRRouting router?

To erase a configuration on a FRRouting router, just use the same command you used, but add no at the beginning. For example, if you configured an IP address with ip address 1.0.0.1/24, just run no ip address 1.0.0.1/24 to erase it.

I have the error VTY configuration is locked by other VTY when I run a conf t on a FRRouting router.

Only one VTY session can configure a FRRouting router at a time. If you have this problem, it’s either because one member of your group is already configuring this router, or because VTY sessions are still running in the background and block your access to the router (for example, because you lost a previous ssh connection). In the latter case (and you are sure that nobody in your group is currently configuring this router), please send us a message on matrix, and we will fix it as soon as possible.

My neighboring ASes are not active, and I can’t get connectivity with the rest of the mini-Internet because of that.

Although each group has two providers, two customers and two peers, it can happen that some of them are inactive or have misconfigured BGP, which makes you unreachable from some parts of the mini-Internet. This can also prevent you from testing your configuration or running ping or traceroute. First of all, we encourage you to reach out to the groups managing your neighboring ASes to solve the issue together. If you cannot solve the problem, please let us know, and we will assist you.

Interessante allgemeine frühere Studierendenfragen

Pro-Tip:

Versuchen Sie zunächst, die Fragen eigenständig zu beantworten.

Könnte man Rechnernetze auch ausschließlich mittels IP-Adressierung betreiben - insbesondere wenn jedes Gerät in Zukunft ohnehin eine global eindeutige IPv6-Adresse hat? Benötigt man wirklich zusätzlich MAC-Adressen?

Der Verzicht auf die Data-Link-Schicht insgesamt ist natürlich nicht ohne Weiteres möglich, da man ja Funktionen wie die Zugriffskontrole auf das Medium, Codierung von Beginn und Ende von Nachrichten, etc. haben möchte. Es gibt allerdings tatsächlich Layer-2-Protokolle mit ganz anderen Adressierungsverfahren als MAC-Adressen (z.B. Asynchronous Transfer Mode). Analog könnte man natürlich ein Layer-2-Protokoll mit Nutzung des IPv6-Adressformates entwerfen. Der Vorteil davon wäre allerdings fraglich, denn es bestünde dann erhebliches Potential für Verwechslungen, welche Adresse welchem Zweck dient.

Davon abgesehen hilft vielleicht die folgende Überlegung zur Verwendung mehrerer Adressen:

Nehmen wir mal an, wir hätten nur IPv6-Adressierung. Wenn wir mit einem anderen Gerät kommunizieren möchten, dann würden wir zunächst schauen, ob die IP-Adresse des Gerätes sich im gleichen Netz befindet wie wir selbst oder in einem anderen, z.B. am anderen Ende der Welt.

Wenn es das gleiche Netz ist, würden wir wahrscheinlich direkt mit dem anderen Gerät kommunizieren wollen und unsere Nachrichten an dessen IP-Adresse senden – ein Verteilergerät im Netz könnte sich merken, über welchen Port die Adresse erreichbar ist und alles wäre super. Was machen wir allerdings, wenn es ein anderes Netz ist, zu dem wir keine direkte Verbindung kennen? Dann möchten wir ja das Paket zunächst an ein Gerät senden, das vielleicht den Weg kennt. Das Gerät muss ja aber auch adressiert werden um zu wissen, dass es der gewünschte (Zwischen-)Empfänger ist. Zusätzlich muss es aber auch wissen, wer der Endempfänger sein soll. Wir könnten also das IPv6-Paket in ein weiteres an das Vermittlungsgerät adressiertes IPv6-Paket einpacken und hätten wieder zwei geschachtelte Adressen…

Alternativ könnte man natürlich einfach alles an das Vermittlungsgerät senden und dort entscheiden, ob es zur nächsten Vermittlungsstelle oder ins lokale Netz soll. Für große lokale Netze skaliert das aber sehr schlecht und wenn es mehr als eine nächsten Vermittlungsstelle gibt, würde man wieder eine extra Adressierung benötigen. Der komplette Verzicht auf Subnetze würde zwar die Kommunikation mit nur einer Adresse erlauben, aber auch die Hierarchie soweit abflachen, dass das System nicht mehr skalierbar ist.

Gehören die Präambel und der Start of Frame Delimiter zur Gasamtlänge des Ethernet-Frames?

Laut IEEE 802.3 von 2022 (über VPN der TU unter https://ieeexplore.ieee.org/document/9844436 abrufbar, Seite 239f.) gehören Preamble und Start Frame Delimiter (SFD) nicht zum Ethernet-Frame. Beide sind jedoch Teil des Ethernet-Packets.

In der Praxis wird zwischen Ethernet-Frame und Ethernet-Packet typischerweise jedoch nicht unterschieden, wahrscheinlich weil der ursprüngliche (und inzwischen vielfach überarbeitete) Standard von 1985 (über VPN der TU unter https://ieeexplore.ieee.org/document/7508550 abrufbar, Seite 23f.) nur Ethernet-Frames beschreibt und Preamble sowie Start Frame Delimiter dazu zählt. Die kompliziertere neue Nomenklatur hat sich praktisch nicht so recht durchgesetzt und z.B. in der Dokumentation von Geräteherstellern ist weiterhin meist nur von Ethernet-Frames die Rede.

Somit muss man leider sagen, dass die Bezeichnung Ethernet-Frame immer im Kontext zu interpretieren ist. Im akademisch-/wissenschaftlichen Kontext würde ich vom aktuellen IEEE-Standard ausgehen. Für die Kommunikation mit Netzwerkadministratoren und die praktische Arbeit mit Netzwerkgeräten ist weiterhin die alte Nomenklatur gebräuchlich.

Einheitlich sind jedoch in neuem und altem Standard die Konventionen hinsichtlich der Längebezeichnungen: “The minimum and maximum frame size limits […] refer to that portion […] from the destination address field through the frame check sequence field, inclusive […]“

Sind Neighbor Solicitation Nachrichten (SLAAC) an die neu erzeugte Multicast-Gruppe oder an die neue Unicast-Adresse adressiert?

Auf der Basisebene von IPv6 besitzen Neighbor Solicitation Nachrichten eine destination-Adresse. Zusätzlich existiert darüber hinaus auch auf Ebene von NDP/ICMPv6 eine target-Adresse. Die destination-Adresse ist die solicited-node multicast-Adresse, die target-Adresse die neu generierte link-lokale Unicast-Adresse.

Hier noch eine präzisere Beschreibung: “Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection.” (RFC 4861 - https://web.archive.org/web/20160703221504/https://tools.ietf.org/html/rfc4861#ref-ADDRCONF ) “Before sending a Neighbor Solicitation, an interface MUST join the all-nodes multicast address and the solicited-node multicast address of the tentative address.
The former ensures that the node receives Neighbor Advertisements from other nodes already using the address; the latter ensures that two nodes attempting to use the same address simultaneously should detect each other’s presence. To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation’s Target Address is set to the address being checked, the IP source is set to the unspecified address, and the IP destination is set to the solicited-node multicast address of the target address.” (RFC 4862 - https://web.archive.org/web/20160703221500/https://tools.ietf.org/html/rfc4862#section-5.4 )

Wie kann man sich die Probleme durch NAT konkret vorstellen?

NAT macht viele sonst einfache Dinge ziemlich komplex. Es vermutlich am einfachsten, sich die Probleme mit NAT am Beispiel zu überlegen. Ein absoluter Klassiker wenn es um NAT-Probleme geht sind Telefonieanwendungen. Da Telefonie auch schon ohne NAT im Detail ganz besonders kompliziert sein kann, vereinfachen wir im Folgenden ein wenig.

Nehmen wir also mal an, Alice und Bob wollen über das deutsche IP-Festnetz telefonieren und haben auf unserem PC jeweils einen SIP-Client installiert, welcher sich mit einem Telefonieserver der Telekom verbinden soll. Dem SIP-Client teilen die beiden jeweils den Namen des SIP-Registrar-Servers mit und ihre Benutzerdaten, mit denen sie sich anmelden wollen. DNS wird den Namen des SIP-Servers zu einer IP-Adresse auflösen und uns den statisch konfigurierten Port für SIP senden, sagen wir Port 5060. Wenn jetzt der Server der Telekom nur eine private IP hätte und hinter einem NAT-Gerät stünde, welches die öffentliche IP-Adresse hat, die Alice und Bob mittels DNS herausgefunden haben, dann soll sowohl die Anfrage von Alice als auch die Anfrage von Bob an den gleichen Port des gleichen Servers gehen – die NAT mappings (Zuordnungen von interner IP und Port zu externer IP und Port) müssen also statisch sein. Das ist aus meiner Sicht kein großer Nachteil – gut, man spart keine IP-Adressen – aber über die Ästhetik kann man streiten.

Sagen wir also mal der Einfachheit wegen, die Telekom hat dem SIP-Server direkt eine öffentliche IP gegeben. Vielleicht wollen wir dann mittels traceroute prüfen, ob wir überhaupt IP-Konnektivität zu dem SIP-Server haben. Da Alice und Bob beide mit unserem Heimrouter NAT nutzen, wird also die Quelladresse ihres Rechners in eine öffentliche IP umgeschrieben. Dieser Header wird dann von den Hops auf dem Weg in die time-to-live-exceeded-ICMP-Nachrichten gepackt und die ICMP-Nachrichten in ein IP-Paket an die jeweilige öffentliche IP-Adresse von Alice bzw. Bob. Auf dem Weg zurück würde “dummes” NAT vielleicht nur die IP-Zieladresse wieder in unsere private Adresse übersetzen und wir bekämen eine time-to-live-exceeded-ICMP-Nachricht für eine Anfrage, welche als source-Adresse anscheinend gar nicht die uns bekannte private IP-Adresse hatte. Um das zu verhindern, verändert NAT auch unsere ICMP-Daten (für Details siehe RFC 5508 - https://www.rfc-editor.org/rfc/rfc5508).

Bei NAT in die andere Richtung gedacht (also Zielnetz nutzt NAT) kann es tatsächlich vorkommen, dass traceroute für mehrere Router in einem privaten Netz die gleiche öffentliche IP-Adresse zurückliefert. Wahrscheinlich hat dann der Hersteller/Admin des NAT-Geräts die Eingriffe in die ICMP-Pakete speziell angepasst, um keine internen Informationen preiszugeben.

Dann bauen wir nun endlich unsere Verbindung mit dem SIP-Server auf. Die Antworten des Servers müssen aber vielleicht auf dem Weg durch ein uraltes automones System fragementiert werden und kommen völlig durcheinander an. Im ersten Fragment ist der TCP-Header gelandet, der uns sagt, an welchen Port unserer NAT-Box die Antwort gehen soll, sodass die NAT-Box anhand dieses Ports entscheiden kann, dass die Antwort des SIP-Servers an einen bestimmten Port unseres PCs mit einer bestimmten privaten IP-Adresse weitergesendet werden muss. Da allerdings das erste Fragment vielleicht als letztes ankommt, muss die NAT-Box alle 200 Fragmente die vielleicht davor ankommen, aber keine der benötigten Zielinformationen beinhalten, irgendwo zwischenspeichern und dann wieder korrekt zuordnen. Ein Alptraum!

Irgendwann sind vielleicht Alice und Bob beide am SIP-Server registriert und starten den Telefonanruf. Der Verbindungsaufbau, Klingelzeichen etc. werden ausgehandelt und dann wollen sie tatsächlich Sprachdaten übertragen. Allerdings sollen die latenzsensitiven Sprachdaten ja nicht erst über den Server der Telekom, sondern direkt zwischen den beiden Rechnern ausgetauscht werden. Aus diesem Grund wird eine RTP-Direktverbindung über UDP ausgehandelt. Problem: Unsere Rechner kennen für die Aushandlung nur ihre privaten IPs und über die können sich unsere Computer nicht erreichen. Das Ergebnis: erfolgreicher Verbindungsaufbau via SIP aber Stille am Telefonhörer.

Die Lösung ist dann, dass unsere NAT-Box auch die ganzen SIP-Nachrichten auf Applikationsebene anschaut und die Adressaushandlung dahingehend manipuliert, dass die privaten IPs gegen die öffentlichen ausgetauscht werden. Was macht man allerdings, wenn die Aushandlung verschlüsselt stattfindet oder die NAT-Box das Protokoll nicht kennt? Speziell für Telefonie gibt es Verfahren wie ICE, STUN und TURN damit es trotzdem funktioniert, aber wirklich schön ist das alles nicht…

Kann man zwei verschiedene TCP-Verbindungen zwischen zwei Hosts aufbauen, bei denen die Quell- und Zielports jeweils identisch sind?

Es ist an sich möglich, zwei verschiedene TCP-Verbindungen zwischen zwei Hosts aufbauen, bei denen die Quell- und Zielports jeweils identisch sind, sofern nämlich die Quell/Ziel-IP-Adressen der Verbindungen unterschiedlich sind, also die Hosts zwei IP-Adressen haben. Nutzen kann man das z.B. bei Multipath TCP. Das tolle an Multipath-TCP ist unter anderem, dass es mit traditionellem TCP arbeitet und somit mit der bestehenden Netzinfrastruktur kompatibel ist. Da eine Verbindung 5 Komponenten hat, kann man im Allgemeinen zwei Verbindungen voneinander unterscheiden, selbst wenn sie in 3 Komponenten (Protokoll und beide Ports) übereinstimmen.

Man sagt üblicherweise, dass eine “Verbindung” durch ein “5-Tuple” (Protokoll [z.B. Nr. 6 für TCP und Nummer 17 für UDP] plus Quell- und Ziel-IP-Adressen sowie Ports) charakterisiert ist. Der Begriff ist z.B. im Firewallbereich relevant. “Verbindung” meint in diesem Kontext nicht verbindungsorientiert. UDP ist z.B. nicht verbindungsorientiert, sodass es keine Verbindung im engeren Sinne gibt. Dennoch arbeiten klassische Layer-4-Firewalls mit dem “5-Tuple” zur Identifizierung von Traffic und man kann das Konzept der Verbindung im erweiterten Sinn als Daten mit Übereinstimmung der 5 Parameter auch auf Protokolle wie UDP übertragen.

Muss man für das Szenario zweier verschiedener TCP-Verbindungen zwischen zwei Hosts mit Nutzung identischer Quell- und Zielports für beide Verbindungen Multipath TCP nutzen?

Nein. Man stelle sich vor, ein Telefon ist via WLAN und via LTE mit dem Internet verbunden. Dafür nutzt es zwei Netzwerkadapter und bekommt auch (mindestens) zwei unterschiedliche IP-Adressen. Jetzt könnte das Telefon über WLAN eine ganz klassische TCP-Verbindung zu Port 80 des Webservers der TU aufbauen, um das PDF der Prüfungsordnung zu laden und zufällig dafür den Port 50000 als Source-Port wählen. Nebenbei könnte eine zweite ganz normale TCP-Verbindung über LTE auch mit Port 80 des gleichen Webservers der TU bestehen, um z.B. die letzten Neuigkeiten aus dem Rektorat zu laden, wobei zufällig der gleiche Port 50000 als Source-Port gewählt wird. Durch die unterschiedlichen Source-IPs sind die Verbindungen unterscheidbar, obwohl Quell- und Zielport von beiden identisch sind.

Müssen für den Aufruf einer Webseite, welche ein CDN nutzt, zwei DNS Auflösungen stattfinden - eine für die Anfrage an die eigentliche Webseite und eine für den Inhalt vom CDN?

Nein, bei einem CDN sind nicht immer zwei DNS-Auflösungen erforderlich. Eine Website kann z.B. bei Cloudflare (CDN-Anbieter) gehostet sein und ein PDF der Klausur zum Download anbieten. Wenn jemand es herunterladen möchte, fragt er seinen Recursive-Resolver nach der IP zum Namen und bekommt die IP des nächstgelegenen Cloudflare-Servers auf den das Dokument repliziert wurde. An den dann hoffentlich nahe beim anfragenden Studenten gelegenen Server geht entsprechend die Anfrage für das PDF. Das CDN sorgt erstmal nur dafür, dass es einen Server in dessen Nähe gibt, auf dem das Dokument liegt, sodass die Anfrage je nach Standort nicht erst um die halbe Welt muss. DNS liefert dann abhängig vom Standort basierend auf dem Recursive-Resolver, der IP, etc. die IP-Adresse des hoffentlich nächstgelegenen Servers.