Fachrat Informatik - Forum

Ich hab die Prüfung vor einem Jahr gemacht, deine SEATTLE-Frage kann ich dir also grad nicht aus dem Gedächtnis beantworten.

Zum Ablauf der Prüfung: Du sitzt mit dem Professor vor seinem Computer und er zappt durch die Vorlesungsfolien (bzw. eine Auwahl davon) und stellt dir zu einigen davon Verständnisfragen. Konkret soll man dann an einem Bild aus den Folien erklären, wie ein Verfahren abläuft, wer wen wieso beim Peering bezahlt, wo wann wieso welche Pakete langgehen, wenn man einen virtuellen Router migriert... sowas halt. Also wenn man zu jeder Vorlesungsfolie was (sinnvolles) sagen kann, ist man glaub ich gut vorbereitet. Ach ja, und natürlich auf Englisch das ganze.

Die Note bekommt man übrigens im Gegensatz zu anderen Prüfungen nicht direkt nach der Prüfung mitgeteilt, sondern erst wenn alle Prüflinge dran waren, in meinem Fall war das etwa 3 Wochen später. Das entspricht zwar nicht unserer Prüfungsordnung, aber das war es mir damals nicht wert, mich drüber aufzuregen.

Hi,

ich hoffe, dass es noch rechtzeitig ankommt und du es auch noch liest:

Der Vorteil von One-hop DHT steht ja direkt in den Folien (Seite 21):

Reduced lookup complexity, fast and efficient reaction to changes

Es wird dabei keine DB mit <key,value>-Paaren angelegt. Vielleicht fasse ich es einfach schnell zusammen:

Es wird sich auf eine Hashfunktion geeinigt. Wenn nun ein neuer Node N an einem Switch A entdeckt wird, wird die Hashfunktion auf z.B. die MAC-Adresse angewandt. Daraus resultiert ein Switch B, auf dem die Route zum Node N gespeichert wird in der Forwarding Tabelle (Also <N,A>). Wenn nun ein anderer Node Node N erreichen will, fragt er den verbundenen Switch. Dieser errechnet den Hash und weiß daher, dass die Information dazu auf Switch B liegt. Er kontaktiert diesen und bekommt die direkte Route.

Vorteile gibt es massig:

Die Forwarding Tabellen sind natürlich viel kleiner, weil nicht alle Switches jede Route haben müssen. In den Folien steht Faktor 20. Die Intelligenz liegt komplett bei den Switches, sodass die End-hosts nicht extra konfiguriert werden müssen. Anstatt dass nun jeder Router ständig die Routing-Tabellen ändern muss, wenn Nodes das Netzwerk betreten oder verlassen, müssen nur zwei Switches sich darum kümmern. Keine Broadcasts also.
Thema Broadcasts: Auch ARP und DHCP werden so aufgelöst, das heißt, dass das ARP- und DHCP-Flooding wegfällt. Es wird alles per Unicast geregelt, was natürlich das Netzwerk entlastet.

Ich hoffe, dass es dir weiterhilft. Ich übernehme natürlich keine Gewähr…wäre ich ja schön blöd…

Wenn du noch Fragen hast; ich schaue heute Abend wohl noch ein paar Mal rein.

Quoted from "hamena314"

- In Kapitel 4, Folie 23: Warum sind AS4's Kunden nicht über den shared link erreichbar?

Die sind erreichbar. AS5 ist der einzige Kunde von AS4 und der wird ja an AS3 advertised. Steht ja so auch in den beiden Stichpunkten direkt darüber. Customer = Kunde in diesem Beispiel, vielleicht hast du das mit Provider verwechselt. AS1 und AS2 sind über den shared link nicht erreichbar. AS4 zahlt ja dafür, da will er natürlich den Zugriff nicht einfach so weitergeben. AS5 zahlt dafür, dass er auf alles Zugriff hat, also kann von dort auch auf AS1 und AS2 zugegriffen werden. Klarer?

Quoted

-
In Kapitel 4, Folie 66: Was soll mir die Folie sagen? Einfach nur dass
die local-prefs unterschiedlich sind und man daher lieber den einen Weg
wählen sollte? Ohne Erklär-Text wird mir das nicht ersichtlich.

Die Überschrift erklärt es ja: Asymmetry of Internet Paths. In der Folie geht es darum, dass nicht unbedingt der augenscheinlich kürzeste Weg genommen wird. In dem Fall wird der längere Pfad (=mehr Hops) genommen, weil die local pref höher ist, das heißt, der Link ist günstiger (Customer in dem Fall, siehe Kapitel 4, Folie 63).

Quoted

- In
Kapitel 4, Folie 78: Ist da ein Schreibfehler drin? "Over an iBGP
session, a router advertises only the best routes learnt from eBGP
sessions" ... das hintere "eBGP" wundert mich, weil es einen Satz später
"A route learnt from an iBGP session is never advertised over an eBGP
session" heißt. Müsste das "eBGP" daher nicht eigentlich "iBGP"
bedeuten?

Nein, das ist korrekt so. Der erste Satz bezieht sich ja darauf, dass intern über iBGP nur die besten Routen aus der eBGP session advertised werden. Der zweite sagt dagegen aus, dass über eBGP keine über iBGP gelernten Routen weitergegeben werden. Hat ja eins mit dem anderen nichts zu tun bzw. ist genau in die andere Richtung.