2014S N03 Internetzwerke

Rechnernetze Sommer 2014 Rechnernetze 3. Internetzwerke Rekursiver Au+au •  Vernetzung von Netzen über dedizierte Leitungen •  Router oder Gateway – 
– 
– 
– 
Vermitteln von Nachrichten 2 Netzanschlüsse (Multi-­‐homed host) Schutzfunktionen Beste Wege Netz 1 •  Probleme –  Adressierung –  Routing –  Maximale Nachrichtengröße Gateway •  Bekannter Vertreter –  Internet Netz 2 (c) Peter Sturm, Universität Trier 1 Rechnernetze Sommer 2014 Routing im Internetzwerk •  Zwei Aspekte –  Innerhalb eines Netzes –  Zwischen Netzen •  Ziel –  Nachricht findet Weg zum Ziel –  Bei mehreren Alternativen? •  Metriken – 
– 
– 
– 
– 
Latenz Übertragungsbandbreite Hops Kosten … All Pairs Shortest Paths •  Floyd-­‐Warshall-­‐Algorithmus –  O(n3) •  Skizze (c) Peter Sturm, Universität Trier 2 Rechnernetze Sommer 2014 Dreiecksungleichung A 5 B 13 20 C •  A kennt Weg nach C mit Kosten 20 •  A kennt Weg nach B mit Kosten 5 •  A erfährt: –  B kennt Weg nach C mit Kosten 13 Routing •  Wahl des richtigen Weges zu einem Empfänger –  Mehrere Alternativen vorhanden –  Speicherung der Alternativen –  Speicherung der aktuell “besten” Route zum Ziel •  Kosten –  meist Hop-­‐Count (c) Peter Sturm, Universität Trier 3 Rechnernetze Sommer 2014 Routingtabelle Ziel Via Knoten C B Knoten B -­‐ Kosten Device Lifeness 20 3 min eth0 5 eth1 2 min Netzwerk XYZ Q 42 eth1 3 d … … … … … •  Zielknoten, Zielnetz •  Kosten (Kostentabelle) •  Lifeness-­‐Informationen •  Periodischer Abgleich der Routing-­‐Information Große Netze •  Routingtabelle kann nicht alle Ziele speichern •  Default-­‐Router –  In allen Zweifelsfällen Ziel Kosten Via Device Lifeness Knoten C 20 B eth0 3 min Knoten B 5 -­‐ eth1 2 min Netzwerk XYZ 42 -­‐ eth1 3 d … … … … … r eth0 * (c) Peter Sturm, Universität Trier 4 Rechnernetze Sommer 2014 Internetzwerkadresse Internetzwerkadresse Internetzwerkadresse Netzwerkanteil (c) Peter Sturm, Universität Trier Hostanteil 5 Rechnernetze Sommer 2014 IP Einordnung in OSI-­‐Modell Ebene 4-­‐7 Internet-­‐Protokolle: FTP, TELNET, SMTP, DNS, NSP, NTP, HTTP, ... RPC-­‐Protokolle PVM, MPI, Corba, ... UDP Ebene 3 Ebene 1-­‐2 (c) Peter Sturm, Universität Trier TCP IP / ICMP / ARP / RARP / (Routingprotokolle) IEEE 802.X X.25 6 Rechnernetze Sommer 2014 IP-­‐Adressen (IPv4) •  Class A: 27-­‐2 Netze mit jeweils bis zu 224-­‐2 Rechnern 0 netid(7) hostid(24) •  Class B: 214-­‐2 Netze mit jeweils bis zu 216-­‐2 Rechnern 1 0 netid(14) hostid(16) •  Class C: 221-­‐2 Netze mit jeweils bis zu 28-­‐2 Rechnern 1 1 0 Bit 1 netid(21) 8 hostid(8) 16 24 Bit 32 IP-­‐Adressen (cont.) •  Schreibweise: „Dotted Decimal“ 10001000 11000111 00110110 11010010 –  = 136.199.54.210 •  Ist ein Class X-­‐Netz? •  Netzanteil? •  Hostanteil? •  Symbolische Namen –  131.199.54.210 = balvenie.uni-­‐trier.de –  Über verteilte „Datenbank“ (DNS, NSP, LADP, ...) •  IP-­‐Netadresse –  Hostanteil ist 0 (c) Peter Sturm, Universität Trier 7 Rechnernetze Sommer 2014 „Class A“-­‐Netze •  Historisch die ersten Mitglieder des Internets –  Militärische Einrichtungen ? –  Amerikanische Universitäten Multicast-­‐ und Broadcast-­‐Adressen •  Multicast 1 1 1 0 Bit 1 Multicast address(28) 8 16 –  Direkte Abbildung bei Multicast-­‐fähigen Netzen –  Flooding-­‐Algorithmen sonst –  Beispiel: Mbone 24 Bit 32 •  Tunneln bei Unicast-­‐Strecken •  Verwaltung der Multicast-­‐Gruppen –  IGMP = Internet Group Management Protocol •  Broadcast –  Nur innerhalb eines Netzes –  Hostanteil alles 1 (c) Peter Sturm, Universität Trier 8 Rechnernetze Sommer 2014 Subnetze •  Maximale Rechnernanzahl in Class-­‐A-­‐ und Class-­‐B-­‐Netzen für ein Netz (z.B. Ethernet) zu groß –  Class A: 16.777.214 Rechner –  Class B: 65.534 Rechner •  Unterteilung in Unternetze netid(14) hostid(16) 1 0 netid(14) subnetid(8) hostid(8) 1 0 Bit 8 16 24 1 •  Netzmaske definiert Grenze zwischen Subnetz und Hostanteil Bit 32 ARP und RARP Host A Host B ARPQ(IAB) •  ARP = Address Resolution Protocol –  Ermittlung einer Netzwerkadresse im gleichem Netz ARPR(IAB,NAB) •  Gegeben IA •  Gesucht NA –  Voraussetzung Broadcast-­‐fähiges Netz •  Bei dedizierten Leitungen Konfigurationssache •  RARP = Reverse ARP –  Gegeben NA, Gesucht IA –  Diskless Clients (c) Peter Sturm, Universität Trier 9 Rechnernetze Sommer 2014 IP-­‐Protokoll (IPv4) Version Header Length Type of service v hl tos Total Length identification f Fragment offset(13) Time to live protocol Header checksum source address destination address •  20 Byte Header •  Maximale Größe IP-­‐Datagramm –  64 Kbyte inkl. Header IP-­‐Protokoll (IPv4) •  Type of Service (tos) –  Hohe Zuverlässigkeit, Hoher Durchsatz, Geringe Latenz, Prioritäten •  Fragmentierung –  Identifikation zusammengehörender Fragmente –  Offset des Fragments im IP-­‐Datagramm •  Time-­‐to-­‐live –  Hop-­‐Count; wird von Routern dekrementiert (c) Peter Sturm, Universität Trier 10 Rechnernetze Sommer 2014 Aufgaben der IP-­‐Netzwerkebene •  Übertragung von IP-­‐Datagrammen Application Layer –  Routing –  Fragmentierung und Assembly TCP •  Netzverwaltung und Melden von Fehlern –  ICMP Ebene 4-­‐7 UDP IP / ICMP IEEE 802.X X.25 Ebene 3 Ebene 1-­‐2 IP Routing (Prinzip) •  „Normale“ Rechner –  Empfänger im selben Netz •  ARP falls notwendig •  Direkt Senden –  Empfänger in anderem Netz •  Nachricht an „Default Router“ •  Router –  Routingtabelle durchsuchen •  Host-­‐Match •  Network-­‐Match •  Default Router –  Weiterleiten (c) Peter Sturm, Universität Trier Routingtabelle Host Netz sonst Forward-­‐NA Forward-­‐NA Forward-­‐NA 11 Rechnernetze Sommer 2014 IP: Fragmentierung und Assembly •  Intranet-­‐Fragmentierung – 
– 
– 
– 
An jedem Hop Assembly und Fragmentierung Vorteil: Nutzung volle MTU Nachteil: Zusätzliche Kosten Problem: Fragmentverluste Netz 1 F3 F2 F1 •  Internet-­‐Fragmentierung –  Nur Fragmentierung bei kleiner werdender MTU –  Vor-­‐ und Nachteile? •  MTU-­‐Path-­‐Discovery Router –  Kleinste MTU auf dem Weg zum Empfänger bestimmen und entsprechend fragmentieren –  Wann sinnvoll? Netz 2 ICMP (c) Peter Sturm, Universität Trier 12 Rechnernetze Sommer 2014 ICMP •  Internet Control Message Protocol •  Erfüllen administrative Aufgaben im IP-­‐Netz –  Fehlermeldungen –  Informative Meldungen •  ICMP-­‐Nachrichten werden per IP übertragen –  Empfänger ist immer der ursprüngliche Sender Type Code Checksum Zusätzliche Daten (abhängig vom Typ) Byte ICMPv4 Errors Type Name 3 Destination Unreachable 4 Source Quench 5 Redirect 11 Time Exceeded 12 Parameter Problem (c) Peter Sturm, Universität Trier Bedeutung IP-­‐Datagramm konnte aus irgendwelchen Gründen (siehe Code) nicht ausgeliefert werden Überlastetes IP-­‐Gerät “bittet” Sender, die Paketrate zu reduzieren Router informiert Sender über eine bessere Route Informiert einen Sender, wenn das TTL-­‐Feld eines IP-­‐Datagramms abgelaufen ist Code gibt Aufschluß über ein allgemeines Problem bei der Auslieferung eines Datagramms 13 Rechnernetze Sommer 2014 ICMPv4 Information Type Name Bedeutung 8 Echo Request 0 Echo Reply 9 Router Advertisment Router informieren Rechner über Existenz und Fähigkeiten 10 Router Solicitation Geräte bitten zuhörende Router um ein Advertisment 13 Timestamp (Request) 14 Timestamp (Reply) 17 Address Mask Request 18 Address Mask Reply 30 Traceroute Erreichbarkeitstest auf IP-­‐Ebene Antwort auf Echo-­‐Request Anfrage für einen Zeitstempel Antwort zu 13 Gerät erfragt Subnetzmaske Antwort zu 17 Verbesserung des Traceroute-­‐
Verfahrens (experimentell) Destination Unreachable •  Paketauslieferung fehlgeschlagen •  Selbst IP-­‐Paket (also best Effort) 3 (Type) Code Checksum Anfang des auslösenden IP-­‐Pakets (Header und ersten 8 Byte Daten) Byte (c) Peter Sturm, Universität Trier 14 Rechnernetze Sommer 2014 Destination Unreachable (1) Code Message Subtype Beschreibung Angegebenes Netzwerk konnte nicht erreicht werdem 0 Network Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable Der angesprochene Rechner hat für den angegebenen UDP-­‐ oder TCP-­‐Port keinen Emfpangsprozeß eingetragen 4 Fragmentation Needed Nachricht wurde mit dem “Don’t Fragment”-­‐Flag versendet, müßte aber wegen kleinerer MTU zum Ziel fragmentiert werden (wird z.B. bei der MTU Path Discovery verwendet) 5 Source Route Failed Sender hat explizite Route angegeben, die es einem Router unmöglich macht, die Nachricht sinnvoll weiterzuleiten 6 Destination Network Unknown 7 Destination Host Unknown Angegebenes Netzwerk wurde erreicht, aber die Nachricht konnte an den spezifizierten Rechner nicht ausgeliefert werden Im IP-­‐Header definiertes Protokoll wurde vom empfangenden Host nicht verstanden Unbenutzt (stattdessen wird Code 0 verwendet) Der angegebene Rechner ist im Zielnetz unbekannt Destination Unreachable (2) Code Message Subtype Beschreibung 8 Source Host Isolated Veraltet 9 Communication with Destination Network Administratively Prohibited Sender hat keine Befugnis mit Rechnern im angegebenem Netzwerk zu kommunizieren 10 Communication with Destination Host Administratively Prohibited Sender hat keine Befugnis mit angegebenem Empfänger zu kommunizieren 11 Destination Network Unreachable for ToS Angegebener “Type of Service” wird vom Zielnetz nicht verstanden 12 Destination Host Unreachable for ToS Angegebener “Type of Service” wird vom Zielrechner nicht verstanden 13 Communication Administratively Prohibited (c) Peter Sturm, Universität Trier Nachricht wurde aufgrund einer Inhaltsfilterung geblockt 15 Rechnernetze Sommer 2014 Source Quench •  Empfangsrechner bzw. Router wird überlastet –  Pufferspeicher voll –  Hauptgrund für Verlust eines IP-­‐Pakets •  Gründe –  IP-­‐Datagramme von vielen Sendern an ein Ziel •  Gewollt oder DDoS –  Schnellerer Rechner A kommuniziert mit Rechner B –  Von schnellem Link auf langsamen Link –  Datagramm-­‐Verarbeitung behindert (z.B. HW-­‐Fehler) •  Ungenutzt Time Exceeded •  Pakete leben nicht ewig –  Pragmatischer Ausschluß von Router-­‐Loops –  Empfangsrechner erhält nicht alle Fragmente •  Ursprünglich Zeitbezug –  wegen mangelnder Uhrensynchronisation wenig sinnvoll •  Heute Beschränkung der Hops (c) Peter Sturm, Universität Trier 16 Rechnernetze Sommer 2014 traceroute •  Weg im Internet vom Sender zum Empfänger •  Strategie –  Nachricht mit wachsendem TTL-­‐Feld –  Auswertung der ICMP-­‐Rückantwort S •  Inkonsistente Sichten möglich –  … aber eher unwahrscheinlich •  Graphische Varianten –  Geographische Position einiger Router / Gatways bekannt E Beispiel (Sommer 2005) •  Von Konz nach Trier über DFN: gateway:~ # traceroute tamdhu.uni-­‐trier.de traceroute to tamdhu.uni-­‐trier.de (136.199.54.243), 30 hops max, 40 byte packets 1 ffm2-­‐d1-­‐2.mcbone.net (62.104.212.33) 148 ms 149 ms 150 ms 2 G3-­‐0-­‐4.ffm4-­‐gsr.mcbone.net (62.104.212.5) 149 ms 160 ms 150 ms 3 ir-­‐frankfurt2.g-­‐win.dfn.de (80.81.192.222) 159 ms 150 ms 150 ms 4 cr-­‐frankfurt1.g-­‐win.dfn.de (188.1.80.37) 159 ms 150 ms 150 ms 5 cr-­‐muenchen1.g-­‐win.dfn.de (188.1.18.82) 169 ms 169 ms 170 ms 6 cr-­‐stuttgart1.g-­‐win.dfn.de (188.1.18.130) 169 ms 160 ms 160 ms 7 ar-­‐kaiserslautern1.g-­‐win.dfn.de (188.1.76.34) 159 ms 160 ms 160 ms 8 ar-­‐kaiserslautern2.g-­‐win.dfn.de (188.1.77.194) 159 ms 160 ms 160 ms 9 vxr-­‐serial1-­‐0.uni-­‐trier.de (136.199.1.1) 169 ms 160 ms 160 ms 10 sw3rsm-­‐extern.uni-­‐trier.de (136.199.224.226) 169 ms 170 ms 170 ms 11 cisco-­‐224.uni-­‐trier.de (136.199.224.1) 169 ms 170 ms 170 ms 12 tamdhu.uni-­‐trier.de (136.199.54.243) 169 ms 169 ms 170 ms (c) Peter Sturm, Universität Trier 17 Rechnernetze Sommer 2014 Beispiel (November 2006) •  Von Konz nach Trier über Landesnetz: 1 p54a62d29.dip0.t-­‐ipconnect.de (84.166.45.41) 2.539 ms 1.886 ms 1.737 ms 2 * * * 3 217.0.67.146 (217.0.67.146) 43.070 ms 43.247 ms 43.305 ms 4 f-­‐ea3.f.de.net.dtag.de (62.154.17.50) 47.209 ms 48.045 ms 47.091 ms 5 62.156.139.62 (62.156.139.62) 47.426 ms 47.104 ms 47.217 ms 6 sl-­‐gw20-­‐fra-­‐1-­‐1.sprintlink.net (217.147.96.227) 47.838 ms 48.044 ms 52.928 ms 7 sle-­‐interroute-­‐1-­‐0.sprintlink.net (217.147.111.26) 50.254 ms 48.153 ms 48.216 ms 8 gi1-­‐0.fra-­‐006-­‐core-­‐1.interoute.net (212.23.42.173) 49.127 ms 48.670 ms 49.714 ms 9 po6-­‐0.fra-­‐006-­‐access-­‐1.interoute.net (212.23.42.134) 48.417 ms 47.802 ms 48.377 ms 10 212.23.33.162 (212.23.33.162) 48.336 ms 49.098 ms 46.497 ms 11 g-­‐hbf-­‐mz-­‐1.rlp-­‐net.net (217.198.240.10) 49.934 ms 49.781 ms 50.201 ms 12 g-­‐hbf-­‐ko-­‐1.rlp-­‐net.net (217.198.240.18) 50.929 ms 51.813 ms 50.569 ms 13 g-­‐hbf-­‐tr-­‐1.rlp-­‐net.net (217.198.240.26) 50.785 ms 50.235 ms 50.202 ms 14 g-­‐uni-­‐tr-­‐1.rlp-­‐net.net (217.198.240.82) 52.458 ms 52.263 ms 52.918 ms 15 uni-­‐tr-­‐gate.rlp-­‐net.net (217.198.241.194) 53.705 ms 52.484 ms 54.266 ms 16 cisco-­‐224.uni-­‐trier.de (136.199.224.1) 52.160 ms 50.609 ms 49.720 ms 17 tamdhu.uni-­‐trier.de (136.199.54.243) 56.843 ms 54.968 ms 55.155 ms Beispiel (Juni 2013) •  Von Konz nach Trier über Landesnetz: 1 192.168.41.1 (192.168.41.1) 0.562 ms 0.478 ms 0.431 ms 2 83-­‐169-­‐166-­‐162-­‐isp.superkabel.de (83.169.166.162) 11.854 ms 11.546 ms 11.356 ms 3 83-­‐169-­‐176-­‐182-­‐isp.superkabel.de (83.169.176.182) 11.508 ms 11.297 ms 11.167 ms 4 88-­‐134-­‐193-­‐5-­‐dynip.superkabel.de (88.134.193.5) 14.851 ms 14.969 ms 14.785 ms 5 88-­‐134-­‐193-­‐6-­‐dynip.superkabel.de (88.134.193.6) 14.026 ms 13.850 ms 14.311 ms 6 88-­‐134-­‐193-­‐9-­‐dynip.superkabel.de (88.134.193.9) 13.175 ms 16.138 ms 16.161 ms 7 88-­‐134-­‐204-­‐246-­‐dynip.superkabel.de (88.134.204.246) 15.955 ms 18.845 ms 18.707 ms 8 88-­‐134-­‐238-­‐181-­‐dynip.superkabel.de (88.134.238.181) 21.685 ms 18.831 ms 18.692 ms 9 88-­‐134-­‐203-­‐138-­‐dynip.superkabel.de (88.134.203.138) 17.785 ms 17.672 ms 17.470 ms 10 g-­‐decix-­‐1.rlp-­‐net.net (80.81.192.8) 16.499 ms 16.240 ms 16.185 ms 11 g-­‐hbf-­‐mz-­‐1.rlp-­‐net.net (217.198.240.102) 17.449 ms 17.325 ms 17.352 ms 12 g-­‐hbf-­‐ko-­‐1.rlp-­‐net.net (217.198.240.106) 17.243 ms 17.034 ms 18.498 ms 13 g-­‐hbf-­‐tr-­‐1.rlp-­‐net.net (217.198.240.110) 20.482 ms 20.710 ms 20.430 ms 14 g-­‐uni-­‐tr-­‐1.rlp-­‐net.net (217.198.240.74) 40.875 ms 40.913 ms 40.676 ms 15 uni-­‐tr-­‐gate.rlp-­‐net.net (217.198.241.194) 17.373 ms 17.699 ms 17.748 ms 16 cisco-­‐224.uni-­‐trier.de (136.199.224.1) 17.399 ms 17.176 ms 17.059 ms (c) Peter Sturm, Universität Trier 18