Newby-Frage zu TCP/IP

Ein Teil gelöst....

gepeinigter_aon_neukunde — Thu, 03 Feb 2005 12:06:39 GMT

Der Offset ist zwar nur 13 Bit, aber dafür in 8-Byte-Steps.

Bleibt nur der erste Teil (ARP-IP-Zusammenspiel) offen...

Re(4): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 22:59:25 GMT

Hi !

Beide Links gehen net so ins Detail.

Link2 schlägt vor, bei allen Devices dieselbe MTU zu verwenden (aber aus einem anderen Grund) - damit tritt mein Problem net auf - das stimmt.

Aber ich will ja keinen "Hotfix" für ein aktuelles Problem, sondern verstehen, was wie warum designed wurde...

Re(3): Newby-Frage zu TCP/IP

Glockman — Wed, 02 Feb 2005 16:03:26 GMT

Hm, ja ich glaub ich kann Dir soweit noch folgen, aber irgerndwie wird's schon gehen (Sorry, hab grad keine Zeit, um das langwierig durchzudenken).

Ich hab da was außerdem was gefunden:
http://tcpmag.com/qanda/article.asp?EditorialsID=122
http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci974759,00.html

hth,

Re(6): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 15:43:42 GMT

Argh.
Dürft' die Aufgabe echt schlecht formuliert haben... Sorry.

Der Witz ist, daß C eben _NIX_ zurückschickt.
Also auch kein Time exceeded.

A wiederum liefert ja gar nicht genug Information, als daß C antworten könnte - denn nur
im 1. Fragment ist der UDP-Header... Und der soll ja in der ICMP-Antwort von C an A drinstehen (weil sonst A wiederum damit nix anfangen könnte).
Die Frage ist eben:
Warum schickt A nur das letzte Fragment... Wenn schon nur eines, dann wär' das 1. besser (dann könnt' C antworten).
Alternative wäre eben, gar nix zu schicken - ist gleich schlecht wie nur das letzte zu schicken, nur wär weniger Last auf der Leitung und der IP-Stack würd sich das Fragmentieren ersparen....

Zu Frage 2:
Was passiert also mit einem Paket >9,5K ?
Der Router B (der ja auftragsgemäß bei kleinerer MTU auf dem Zielweg fragmentiert) kann eben ein 12K-Paket net fragmentieren...

Re(2): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 15:37:59 GMT

Das glaub' ich eben nicht.

Wie soll das gehen.

Ethernet hat eine MTU von 1500 Bytes.
TR hat eine MTU von rd. 16000 Bytes.

Das bedeutet, daß 10 und ein kleines Fragment verschickt werden müßten.

Mal sehen:
1. Fragment: Offset 0, Len 1500
2. Fragment: Offset 1500, Len 1500
3. Fragment: Offset 3000, Len 1500
.....
n. Fragment: Offset (n-1)*1500, Len 1500

Wie siehts also zB beim 7. Fragment aus ?
Offset=9000, Len 1500

Offset 9000 glaub ich aber nicht bei einem nur 13-Bit-Feld...
siehst mein Problem ?

Re(2): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 15:34:09 GMT

Du verwechselst da was...
TR 4mbit hat eine "recommended/standard"-MTU von rd. 4K.
TR 16mBit eine von rund 16K.
Nachzulesen bei Stevens, ich hab mal nachgegoogelt, auf der M$-Technet-Seite findest ähnliches. Aber wie gesagt, geht ja nicht um TR spezifisch.

Mein Verständnisproblem ist:
a.) die MTU-Size ist ein 16Bit-Wert
b.) das Fragment-Offset-Feld hat aber nur 13 Bits - also 8K.

Die ICMP-Message fürs Fragmentieren, die du meinst hat
type=3 (destination unreachable) code=4 (fragmentation needed but DF-bit set)...
Sonst gibt's keine ICMP-Message mit Fragmentierung...
Und der Witz ist ja, daß das DF-Bit im Beispiel nicht gesetzt ist...

Das mit den 6 Arp-requests (Stevens saß da auf einem SVR4-Host) hat er erklärt - das
war ein Implementationsfehler von SVR4. Ich hab ihn nur der vollständigkeit halber angeführt, falls jemand Stevens am Tisch liegen hat...

Und ich schrieb eh:
Zuerst die Requests (halt 6 statt einem)
dann die Replies
und dann (dann hat ja A die Ziel-Mac) das Fragment...

Re: Newby-Frage zu TCP/IP

Glockman — Wed, 02 Feb 2005 15:22:23 GMT

Hi!

Auch wenn ich mich mit dem ganzen Protokoll-internen Aufbau nicht sonderlich auskenne, vielleicht kann ich Dir trotzdem ein wenig helfen:

2. Verständnisfrage

A und B hängen an einem 16Mbit-TR - haben also eine MTU von rd. 16K
B und C kommunizieren via Ethernet - MTU rd. 1500 Bytes.
A sende jetzt ein 12KB-Packerl an C via B.
was macht B dann ?

Ich würde mal meinen, dass B, da ja mit einem Bein im TR und einem im Eth, das Paket vom TR normal annimmt und dann für Eth angepasst wieder ausgibt - eventuell geht ein wenig Performance verloren, aber funktionieren sollte es.

Re(2): Newby-Frage zu TCP/IP

Fearry — Wed, 02 Feb 2005 15:20:24 GMT

Ausserdem, daß mit den ARP-Request hatte ich vergessen zu erwähnen, Dr.Watson hat recht...

Re: Newby-Frage zu TCP/IP

Dr. Watson — Wed, 02 Feb 2005 15:16:52 GMT

Uff, da ist jetzt schon einiges an Denkarbeit erforderlich.

Zu deinem Problem #1 kann ich spontan nur sagen, dass das ganze Szenario seltsam ist.
Warum sollte Host A mehrere / ständig ARP Request aussenden?

Es wird genau ein ARP Request gesendet, und die MAC Adresse aus dem ARP-Reply im ARP-Cache gespeichert, von wo sich Host A folglich für jedes Datenpaket dass an Host C geht, die MAC Adresse holt.

Bevor der ARP Request nicht durchgeführt wurde, bzw. ein Reply gekommen ist, werden garkeine Pakete an den gewünschten Zielhost gesendet - wie denn auch, der Sender kennt ja die Zieladresse noch nicht.

Dass Token Ring eine MTU von 16k hat, halte ich allerdings für ein Gerücht.
Laut meinen Unterlagen ist die größe für Nutzdaten bei Token Ring zwischen 1-4096Byte.
Dann würde das auch mit der Fragmentierung klappen.

Im übrigen gibt es eine ICMP-Message bzw. Fehlermeldung für's Fragmentieren - wenn ich mich recht erinnere, ist das Fehlermeldung #5.

gruß,
Dr. Watson

Re(5): Newby-Frage zu TCP/IP

Fearry — Wed, 02 Feb 2005 15:12:20 GMT

Also zur Frage 1:
IMHO kommt das auf die zeitliche Folge drauf an.
Wenn A das ICMP - Time exceeded.... bekommt bevor er alle Fragmente weggeschickt hat, wird er die folgenden nicht mehr wegschicken.
Ausserdem wieso kommen ARP-Replys aber die Fragmente empfängt C nicht??
Gut ok Proxy-ARP...

Zur Frage 2:
Was meinst du mit 3 Systeme? Werden wohl Router sein...
Und selbst wenn die Paketgröße ~9,5K sei, na und??

Re(4): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 14:44:10 GMT

Hum....
Nun denn, deine Antwort ?
hehe... Wie motivier ich Dich, doch nachzudenken ?

lg
gepeinigter..

Re(3): Newby-Frage zu TCP/IP

Fearry — Wed, 02 Feb 2005 14:42:01 GMT

Ja is schon klar...

Re(2): Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 14:22:34 GMT

Dann nimm halt was anderes mit einer größeren MTU-Size... Hyperchannel, ...
Und nein, TR ist net tot - Noch immer in einigen Firmen zu finden - Banken, ...
Außerdem geht's ja net um den speziellen Anwendungsfall (daheim/in der Firma hab ich auch net TR) - sondern um das Verständnis...

Re: Newby-Frage zu TCP/IP

Fearry — Wed, 02 Feb 2005 14:19:43 GMT

Will jetzt ned soviel denken...
Aber TR ist ja sowieso schon tot...

Newby-Frage zu TCP/IP

gepeinigter_aon_neukunde — Wed, 02 Feb 2005 12:41:37 GMT

Hi, Folks !

Acker' mich mal wieder durch Stevens "TCP/IP illustrated Vol1" durch - und renn grad in 2 Verständnisprobleme... Das traurige ist, daß ich das Buch schon mal vor langem durch war und mir damals einbildete, alles verstanden zu haben

Verständnisprob 1:
Man findet folgendes Beispiel zu Zusammenspiel ARP/MTU/UDP:
Gegeben seien 3 Rechner A,B,C, via Ethernet verbunden.
B snifft nur mit.
A hat leeren ARP-Cache, und möchte an C ein 8k-UDP-Packerl senden, ohne DF-Bit.

Was passiert ? (Zusammenfassung des abgedruckten tcpdump-Outputs:
1.) A teilt scheinbar die Pakete intern in 6 Fragmente auf
2.) A versendet 6 ARP-Requests
3.) Sobald ARP-Replies kommen, schickt er _ein_ Fragment los - das letzte.
4.) A empfängt weitere ARP-replies.
5.) von C kommt keinerlei Antwort-kein ICMP-"Time exceeded during reassembly",..

Stevens meint nun:
[2] sei ein Implementierungsfehler. Es dürfe nur max ein Request/sec kommen.
[3] sei gemäß Host requirements RFC - was stimmt. Bei ARP-Queries _muß_
man sich zumindest ein Paket aufheben - und es _sollte_ das letzte sein.
[5] hätte 2 Ursachen:
        a.) ist C von einer Berkley-Schiene weg, die senden das nie zurück
        b.) Kann C nicht mit einem ICMP-Packerl antworten, weil
            nicht genug Transport-Layer-Info im letzten Fragment sei - nur
            im ersten.

Soweit so gut - Nun meine Fragen:
Ich verstehe noch, daß C net per ICMP antworten kann - denn es fehlen ja die paar Bytes vom originating-Packerl, die A natürlich nur in Fragment 0 verschickt.
Die Frage ist: Wieso soll A das letzte Fragment losschicken ? Das macht IMHO ja NULL Sinn.
C kann so oder so damit nix anfangen (egal ob TCP/UDP/sonstwas).
Wenn C aber nix damit anfangen kann - wozu sollte A überhaupt was hinschicken ?
IMHO würde hingegen folgendes uU Sinn machen:
a.) A cached net nur ein Packerl, sondern alle... Ok, würd' wohl Speicherstreß bringen
b.) A verwirft alle Packerl (braucht ja net mal fragmentieren) und macht nur den ARP-Request. Wenn die APP über A timeouted (was so oder so passiert) gibt's den Cache-Eintrag und die Welt ist in Ordnung. Wozu also zuerst fragmentieren und dann nachschauen, ob es einen Arp-Entry gibt ? Warum net andersrum ?
c.) A generiert ein 0-Byte-Packerl an C, wenn er schon was hinschicken will.
Bei dem RFC-Ansatz "Ein Fragment - das letzte" erkenn' ich keinerlei Sinn...

2. Verständnisfrage:
Zum 2. Bereich:
Stevens behauptet in dem Kapitel, das Fragmentierung transparent sei - und
auch fragmentierte Packerl weiter fragmentiert werden können (was ja stimmt,
wenn man sich den "Mechanismus" mit Offset und Len ansieht).

Meine Frage wäre jetzt folgende:
3 Systeme A,B,C.
A und B hängen an einem 16Mbit-TR - haben also eine MTU von rd. 16K
B und C kommunizieren via Ethernet - MTU rd. 1500 Bytes.

A sende jetzt ein 12KB-Packerl an C via B.
Wenn ich's richtig gechecked habe, wird B nun fragmentieren wollen.
B kann aber net fragmentieren, weil das "Offset"-Feld fürs Fragmentieren nur
13 Bit groß ist - also der Offset net größer als 8K werden kann. Dazu noch
die rd. 1500 Bytes LEN von der Ethernet-MTU würde die maximal mögliche Paketgröße auf rd. 9.5K runtersetzen.

was macht B dann ?
soweit ich gesehen habe, gibt es dazu keine ICMP-Message ("Fragmentation
needed but DF-Bit is set" paßt ja net).
Wird das wirklich einfach "silently discarded" ? Das sabotiert ja
PMTU-Discovery komplett, oder ?

Was passiert außerdem weiter ?
A bekommt in der Folge kein ACK und macht ein Retransmit ?

Irgendwie check' ichs grad nicht - bitte um Hilfe...

Thx
gepeinigter.