HUGO-PC ist an einem Ethernet-Netz angeschlossen. Seine Karte ist gemäß IEEE 802.3 eingestellt. Warum kann er sich nicht mit dem Server verbinden, der die Karte gemäß Ethernet-II eingestellt hat?
Voraussetzung: HUGO-PC kann nur IEEE 802.3, Server nur Ethernet II
- IEEE 802.3 ist standardisiertes Format, besitzt Length-Feld (maximale Datenanzahl
<= 1500)
- Ethernet II/DIX ist ein nicht standardisiertes Format, besitzt TYPE-Feld (maximale Datenanzahl > 1500)
Æ 2 verschiedene Header-Typen, einer kann mit anderen nicht kommunizieren, Datenaustausch nicht möglich (LLC-Header mit DSAP, SSAP wichtig für Kommunikation)
- Server versucht die Länge des HUGO-Frame als TYPE zu identifizieren
--- 1.2.
Bekannterweise werden im Falle von LAN-Protokollsuiten die höheren Protokolle entweder direkt (native Implementation) oder mittels LLC, NDIS oder ODI-Schichten (Schnittstellen) auf die MAC-Schicht (Ethernet oder TokenRing) aufgesetzt.
Was sind die Vorteile und Nachteile der „nativen“ Implementation gegenüber den anderen Möglichkeiten?
Vorteile:
- schneller
- optimale Funktionalitäten für festgelegte Aufgaben
Æ Performancegewinn (1 Schnittstelle fällt weg, muß nicht interpretiert werden) - Header der LLC-Schicht fällt weg Æ mehr Daten können übertragen werden Nachteile:
- Protokollabhängig (nicht gleichzeitig Ethernet/Ethernet II, LLC-Header benötigt) Æ muß auf beiden Seiten identisch implementiert sein
- Probleme lassen sich wegen geringer Verfügbarkeit des Produkts nicht lösen Æ Fehlerkontrolle nicht so ausgeprägt (im LLC zusätzliches Control-Feld)
- bedingte Weiterentwicklung, Support Æ nicht RFC Æ selber pflegen bzw. warten - keine saubere Kapselung
- Transparenz der höherliegenden Protokollebenen fällt weg, damit sind sie abhängig von der entsprechenden Verkabelung.
--- 1.3.1.
Beschreiben sie den Flußkontroll-Mechanismus auf der CSMA/CD-MAC-Ebene:
CSMA/CD hat keinen Flußkontroll-Mechanismus, hier wird nur gewartet, bis die Leitung „frei“ ist und dann wird der Frame gesendet.
Flußkontrolle wird hier in der übergeordneten Schichten realisiert.
--- 1.3.2.
Beschreiben sie den Flußkontroll-Mechanismus auf der TokenRing-MAC-Ebene:
- keine Flußkontrolle (Sliding-Window-Konzept nicht implementiert) - Flußkontrolle findet auf LLC-Ebene statt
- es gibt aber sehr wohl Zugriffskontrolle aufs Netz durch das Token (Senden darf nur derjenige, der auch das Token besitzt)
---
1.4.
HUGO-PC (Mitglied eines Ethernet-Netzes), muß Server ansprechen, der in einem TokenRing-Netz ist. Welche Funktionen muß das Netzwerkgerät erfüllen, dass die Verbindung zwischen den beiden Netzen realisiert?
- Verbindung von LAN auf physikalischer Schicht - 2 Leitungen in das TokenRing-Netz
- HW muß vorhanden sein, die Token-Konzept realisiert
- Server muß auf Netzwerk-Layer Verbindung herstellen (Router, Bridge, ...) damit Weiterleitung von Paketen aus Netz gewährleistet wird
- Umkehrung der Bit-Reihenfolge: Netzwerkgerät muß MAC-Adresse des Ethernet- Netzes bzw. TokenRing-Netzes bei Verbindung spiegeln, da vom jeweils anderen Netz in umgekehrter Reihenfolge gelesen wird
- Fragmentierung Æ logische Anpassung der Fenstergröße
--- 2.1.1.
Wann und warum braucht ein Anwender auf Data-Link-Ebene das Protokoll-SLIP?
- Wann: wenn er die Verbindung zwischen Modem und Terminalserver der FH herstellen will
- Warum: Anwender kann kein LAN-Netzwerk-Protokoll nutzen, da er über das Modem eine Verbindung aufbaut Æ benötigt Internet-Protokoll
--- 2.1.2.
Warum wird in der letzten Zeit das SLIP-Protokoll durch PPP ersetzt?
- PPP ist universell anwendbar (vielseitiger)
- unterstützt Adressierung (Æ Multipoint-Verbindungen möglich), Pakettyp- Identifikation, Fehlerkontrolle/Fehlerkorrektur, Datenkompression - schließt alle möglichen Transport-Protokolle ein (TCP/IP, SNA, XNS, IPX...)
--- 2.1.3.
Welche Vor- u. Nachteile hätte Anwender gehabt, wenn er Verbindung mit Datex-P-Netz anstatt Telefonnetz herstellen würde?
Vorteile:
- Mehrfachnutzung der Leitung (Multipoint-Konfiguration) - weltweit möglich
- Dienste des Anwenders können zusätzlich genutzt werden (bspw. X.400) - schnellere Verbindung (2 Mbit/sek)
Nachteile:
- Kosten für HW (extra Anschluß und spezielles Gerät) - hoher Preis für Account (Datenvolumen)
--- 2.2.
BSC-Protokoll läßt zu, das fehlerhafte Meldungen übertragen werden. Schlagen sie eine Lösung vor, die diese Mängel ausräumt. Welche Nachteile bringt die neue
Fehlerkorrekturlösung mit sich?
- BSC hat als Fehlerkontrollmechanismus Stop & Wait implementiert
- Umstellung auf Go-Back-N (oder Selective Repeat – ist allerdings schwieriger zu implementieren) als Fehlerkontrollmechanismus Æ dort werden nur bestätigte Meldungen versandt
- CRC und Nummerierung der Frames muß eingeführt werden
eingeführt Nachteile:
- höherer Implementierungsaufwand
- bei schlechter Leitung nicht mehr so effizient - nicht mehr BSC-konform
--- 2.3.
X.25-DataLink-Ebene besteht aus zwei Schichten: HDLC und X.25-Ebene 3. Was sind die wesentlichen Funktionsvorteile des X.25 Anschlusses gegenüber BSC-Anschluß?
- Full-Duplex
- bitorientiert (volle Datentransparenz durch festgelegtes Format)
- jeder darf Verbindung aufbauen und senden (keine Leitstation notwendig) - Nummerierung der gesendeten Frames
- Go-Back-N Fehlerüberwachung - Flußkontrolle mit Sliding-Window
--- (WS 96/97)
Welche Rolle haben die Frames #1 und #2?
#1:
dns [194.95.108.45] DLC Ethertype=0800, size=86 bytes
IP D=[194.95.104.1] S=[194.95.108.45] LEN=52 ID=20736 UDP D=53 S=1036 LEN=52
DNS C ID=2
#2:
0.0039 [194.95.108.45] dns DLC Ethertype=0800, size=246 bytes IP D=[194.95.108.45] S=[194.95.104.1] LEN=212 ID=32282 UDP D=1036 S=53 LEN=212
DNS R ID=2 STAT=OK NAME=rfhnt8001.fh-regensburg.de
- DNS-Abfrage nach IP-Adresse des rfhnt8001.fh-regensburg.de (DNS schickt IP mit zurück)
- DNS geht über UDP (D-Port = 53, S-Port = 1036)
- Frame #2 sagt aus, das rfhnt8001.fh-regensburg.de bekannt ist
--- 3.2.
Welche Rolle haben die Frames #8, #9, #10 und #11?
#08: broadcast pcu15 ARP C PA=[194.95.108.250] PRO=IP
#09: pcu15 Bridge03B1FB ARP R PA=[194.95.108.250] HA=08000203B1FB PRO=IP
#10: dns [194.95.108.250] DNS C ID=2 OP=QUERY NAME=rfhs0002.fh-rgbg.de
#11: [194.95.108.250] dns DNS R ID=2 STAT=OK NAME=rfhs0002.fh-rgbg.de Frames #8, #9: ARP-Broadcast: Wer ist DNS-Server und was ist seine HW-Adresse?
Frames #10, #11: Danach DNS-Anfrage
--- 3.3
Wie läßt sich erkennen, dass Vorgänge von 3.1. und 3.2 unterschiedlich sind?
- im ersten Fall ist HW-Adresse bekannt
- im zweiten Fall ist HW-Adresse unbekannt Æ durch ARP-Broadcast rausfinden
---
3.4.
Welche Rolle haben die Frames #3, #4 und #5?
#3:
rfhnt0001.fh-regensburg.de [194.95.108.45] DLC Ethertype=0800, size=60 bytes IP D=[194.95.108.38] S=[194.95.108.45] LEN=24 ID=20992
TCP D=21 S=1037 SYN SEQ=775485 LEN=0 WIN=8192
#4:
[194.95.108.45] rfhnt0001.fh-regensburg.de DLC Ethertype=0800, size=60 bytes IP D=[194.95.108.45] S=[194.95.108.38] LEN=24 ID=3907
TCP D=1037 S=21 SYN ACK=775486 SEQ=61932925 LEN=0 WIN=8760
#5:
rfhnt0001.fh-regensburg.de [194.95.108.45] DLC Ethertype=0800, size=60 bytes IP D=[194.95.108.38] S=[194.95.108.45] LEN=20 ID=21240
TCP D=21 S=1037 ACK=61932925 LEN=0 WIN=8760
- TCP/IP-Verbindungsaufbau mittels 3-Way-Handshake zum FTP-Server (Port #21) - SYN-Flag gesetzt deshalb ACK um 1 erhöht (normal ACKneu = SEQalt + LENalt)
--- 3.5.
Warum ist der Buchstabe „b“ zweimal mit den Frames #26, #27 übertragen worden?
#26: rfhs0002 [194.95.108.45] TELNET C PORT=1046 b
#27: [194.95.108.45] rfhs0002 TELNET R PORT=1046 b - Telnet macht Fehlerkontrolle mit Echo Checking
--- 3.6.
Wie kann man dem Rechner „rfhs0002“ mit Hilfe eines selbstbeschriebenen Programms vortäuschen, daß es sich um eine TELNET-Session handelt? (Paßwort soll bekannt sein!) - hinter Port #23 Programm schreiben, das Telnet-Sitzung simuliert
- jeder Character wird getrennt gesendet
- Paßwort wird zeichenweise übertragen, Bestätigung erfolgt als ACK (auch zeichenweise)
--- 3.7.
Mit welchen effektiven Bitraten sind die Frames #5 und #8 übertragen worden?
Wie läßt sich der Unterschied der effektiven Bitraten erklären?
#5:
rfhnt0001.fh-regensburg.de [194.95.108.45] DLC Ethertype=0800, size=60 bytes IP D=[194.95.108.38] S=[194.95.108.45] LEN=20 ID=21240
TCP D=21 S=1037 ACK=61932925 WIN=8760 Delta T = 0.0980
#8:
[194.95.108.45] rfhnt0001.fh-regensburg.de DLC Ethertype=0800, size=126 bytes IP D=[194.95.108.45] S=[194.95.108.38] LEN=92 ID=4419
TCP D=1037 S=21 ACK=775502 SEQ=61932925 LEN=72 WIN=8706 Delta T = 0.0017
Frame #5:
60 bytes * 8
--- = 47,04 bit/sek = tatsächliche Bitrate 0.0980 sek
20 bytes * 8
--- = 1632,65 bit/sek = effektive Bitrate 0.0980 sek
Frame #8:
126 bytes * 8
--- = 592941,18 bit/sek = tatsächliche Bitrate 0.0017 sek
92 bytes * 8
--- = 432941,18 bit/sek = effektive Bitrate 0.0017 sek
Längenfeld größer Æ effektive Bitrate höher (Headergröße ist gleichbleibend)
--- 3.8.
Warum ist der ID-Parameter auf IP-Ebene immer von Meldung zu Meldung unterschiedlich?
- Vermittlungsschicht von TCP-Suite garantiert keine Übertragung und auch keine Reihenfolge der Pakete
- jedes Paket benötigt eindeutige ID (Identifizierung), damit doppelte Pakete von höheren Schichten vermieden bzw. identifiziert werden können
- ohne ID wäre keine Fehlerkontrolle und Flußkontrolle realisierbar
