adress cache beim switch?

[anesti]

hi alle zusammen.

was sagt diese kennzahl bei switch aus???

[nic_power]

Hallo,

Im Adresscache werden die MAC-Adressen der angeschlossenen System gespeichert. D.h. der Switch kann ein System einem Port zuordnen und schickt damit einen Frame nur über den Port an dem auch das Endsystem mit der korrespondierenden MAC-Adresse (Ausnahme: Broad- und Multicastframes) hängt. Ist der Adresscache voll, so müssen die Frames geflutet und über alle Ports geschickt werden.

Nic

[cicero610y]

Hallo!

was sagt diese kennzahl bei switch aus???

Ein Switch cachet die MAC-Adressen der Ports (also die der Clients) in einer internen Tabelle. Das ist einerseits gut (er kann so schneller und ressourcenschonender arbeiten), andererseits schlecht (man kann unter Umständen diesen Cache manipulieren oder zum Überlaufen bringen).

Soweit ich weiß, muss ein Cache sogar vorhanden sein? (kann da jemand etwas dazu sagen?)

Je größer der Cache, desto besser. Irgendwann wird es aber wieder unsinnig, weil man ja nun auch nicht permament umstöpselt und unbegrenzt Ports zur Verfügung hat.

Grüße,

Florian

[LorDAriocH]

Ja, ein Cache muss vorhanden sein. Irgendwo müssen die MAC-Adressen gespeichert werden. Je größer der Cache, desto mehr Adressen können gespeichert werden. Für die Switch-Funktion ist das schon wichtig.

Denn im ARP (Adress Resolution Protocol), werden MAC- und IP-Adressen aufgelöst.

Durch eine ARP-Poison-Attacke kann man dem Switch eine falsche ARP-Tabelle unterjubeln, sodass er einen falschen Host ansteuert (Man-in-the-Middle-Attack). Auch kann man den Cache mit falschen und unnützen Adressen vollpumpen, wenn der Cache dann voll ist, schalten viele Switche in einen Hub-Modus, damit sie weiterhin funktionieren können. Damit sind die sicherheitsrelevanten Aspekte eines Switches ausgehebelt.

[cicero610y]

Hallo,

Ja, ein Cache muss vorhanden sein. Irgendwo müssen die MAC-Adressen gespeichert werden. Je größer der Cache, desto mehr Adressen können gespeichert werden. Für die Switch-Funktion ist das schon wichtig.

Habe mich eben mal kurz eingelesen und nachgedacht. Mein Ergebnis: Ein Adressen-Cache ist nicht notwendig. Er ist natürlich sinnvoll, um eben schneller arbeiten zu können, aber für die Funktion ist er meiner Meinung nach nicht essentiell. Wieso sollte er das auch? Wenn der Adressen-Cache abhanden kommt, sucht er eben bei jedem Paket aufs neue.

Ein anderer Cache ist natürlich wichtig: Ein einfacher FIFO, um zum Beispiel Pakete zwischenzuspeichern, die gerade wegen Belegung des Ports nicht abgehandelt werden können.

Denn im ARP (Adress Resolution Protocol), werden MAC- und IP-Adressen aufgelöst.

Das ist schon klar. Aber meinst Du wirklich, dass einen Switch das ARP interessiert? Hast Du schonmal gesehen, dass ein Switch ARPs durchs Netz pustet? Sind zwar beide auf Layer 2, aber machen nichts miteinander. Der Switch lernt vielleicht durch ARP-Responses, an welchem Port welcher Rechner hängt, aber die eigentliche Auflösung in die IP interessiert nicht.

Durch eine ARP-Poison-Attacke kann man dem Switch eine falsche ARP-Tabelle unterjubeln, sodass er einen falschen Host ansteuert (Man-in-the-Middle-Attack).

Soweit ich weiß, jubelt man beim ARP-Poisoning nicht dem Switch, sondern dem Ziel-Rechner ein falsches ARP-Päärchen unter. Wir reden doch hier immer noch von nem Layer-2-Switch, oder?

Auch kann man den Cache mit falschen und unnützen Adressen vollpumpen, wenn der Cache dann voll ist, schalten viele Switche in einen Hub-Modus, damit sie weiterhin funktionieren können. Damit sind die sicherheitsrelevanten Aspekte eines Switches ausgehebelt.

Das ist bekannt. Aber Du bringst nicht den ARP-Cache zum Überlaufen (und erst recht nicht den vom Switch), sondern den Adressen-Cache des Switches, also den Cache, in dem steht, an welchem Port welche MAC hängt.

Grüße,

Florian

[anesti]

Hallo,

Habe mich eben mal kurz eingelesen und nachgedacht. Mein Ergebnis: Ein Adressen-Cache ist nicht notwendig. Er ist natürlich sinnvoll, um eben schneller arbeiten zu können, aber für die Funktion ist er meiner Meinung nach nicht essentiell. Wieso sollte er das auch? Wenn der Adressen-Cache abhanden kommt, sucht er eben bei jedem Paket aufs neue.

Ein anderer Cache ist natürlich wichtig: Ein einfacher FIFO, um zum Beispiel Pakete zwischenzuspeichern, die gerade wegen Belegung des Ports nicht abgehandelt werden können.

Das ist schon klar. Aber meinst Du wirklich, dass einen Switch das ARP interessiert? Hast Du schonmal gesehen, dass ein Switch ARPs durchs Netz pustet? Sind zwar beide auf Layer 2, aber machen nichts miteinander. Der Switch lernt vielleicht durch ARP-Responses, an welchem Port welcher Rechner hängt, aber die eigentliche Auflösung in die IP interessiert nicht.

Soweit ich weiß, jubelt man beim ARP-Poisoning nicht dem Switch, sondern dem Ziel-Rechner ein falsches ARP-Päärchen unter. Wir reden doch hier immer noch von nem Layer-2-Switch, oder?

Das ist bekannt. Aber Du bringst nicht den ARP-Cache zum Überlaufen (und erst recht nicht den vom Switch), sondern den Adressen-Cache des Switches, also den Cache, in dem steht, an welchem Port welche MAC hängt.

Grüße,

Florian

bist du sicher, das ARP auf schicht 2 arbeitet?? ich habe mehrmals gelesen, das ARP auf schicht 3 arbeitet. kann es sein, das es im tcp/ip referenzmodell auf schicht 2 arbeitet und im iso/osi auf 3?? könnte ja hinkommen. beide schichten stehen ja "nebeneinander"!

@rest

danke für die antworten!

[cicero610y]

Hallo!

bist du sicher, das ARP auf schicht 2 arbeitet?? ich habe mehrmals gelesen, das ARP auf schicht 3 arbeitet. kann es sein, das es im tcp/ip referenzmodell auf schicht 2 arbeitet und im iso/osi auf 3?? könnte ja hinkommen. beide schichten stehen ja "nebeneinander"!

Jetzt bin ich aber auch ins Überlegen gekommen. Im TCP-Referenzmodell liegt es natürlich in Layer 2, da kommt ja nun nicht wirklich etwas anderes in Frage.

Im ISO/OSI-Layer ist das eine andere Sache. Nachdem ich mir RFC826 durchgelesen habe, scheint es wohl mehrere Auffassungen geben zu können. Das RFC trifft keine genauen Aussagen über die Einordnung. Und da ARP ja nun sowohl von IP (also Layer 3) als auch von Ethernet (Layer 2) etwas wissen muss, müsste es eigentlich eher auf Layer 3 liegen (weil ein Layer nie irgendetwas aus dem Layer darüber kennt) . Andererseits kann man es nicht routen, also müsste es auf Layer 2 sein.

Kurz: Ich weiß es nicht. Aber wahrscheinlich eher Layer 3.

Grüße,

Florian

[DennyB]

Das sind rein *logische* Modelle, man soll nicht immer versuchen alles moegliche auf irgendeinen bestimmten Layer festzulegen. ARP wird wohl irgendwo zwischen 2 und 3 liegen, das ist aber eigentlich auch irelevant. Beschrieben wird es allerdings meistens als Layer2-Protokoll. Genauso wie NAT meistens als Layer3 beschrieben wird, NAPT oder PAT aber eine Form von NAT ist und sicherlich ueber Layer3 arbeitet, usw.

Wie schon gesagt, es ist ein logisches Modell und nicht alles muss genau auf irgendein Layer passen.

[cicero610y]

Hallo!

Das sind rein *logische* Modelle, man soll nicht immer versuchen alles moegliche auf irgendeinen bestimmten Layer festzulegen. ARP wird wohl irgendwo zwischen 2 und 3 liegen[...]

Ja nee, is klar :-) Es war halt trotzdem eine interessante Sache zum Grübeln. Habe mir da nie irgendwelche Gedanken über die Abstrahierung von ARP auf ISO/OSI gemacht. Und gerade da das so eine merkwürdige Sache ist, macht das Spaß, sich den Kopf darüber zu zerbrechen und Argumente zu finden.

Grüße,

Florian

[Crash2001]

[...]Das ist schon klar. Aber meinst Du wirklich, dass einen Switch das ARP interessiert? Hast Du schonmal gesehen, dass ein Switch ARPs durchs Netz pustet? Sind zwar beide auf Layer 2, aber machen nichts miteinander. Der Switch lernt vielleicht durch ARP-Responses, an welchem Port welcher Rechner hängt, aber die eigentliche Auflösung in die IP interessiert nicht.[...]

Also falls die MAC-Adresse bisher keinem Switch bekannt ist, werden ARP-Broadcasts durchs Netz gejagt, um herauszufinden, an welchem Switch und an welchem Port dort die entsprechende MAC-Addresse zu erreichen ist. Siehe z.B. hier. Dort werden übrigens auch Man in the middle attacks u.s.w. beschrieben und am Beispiel eines Cisco Switches Catalyst 4500 wie sie verhindert werden können (wohl auf englisch).

Und zum Austausch... also wenn ein Switch Daten an eine bestimmte IP-Adresse ausliefern soll, dann schaut er in seinem lokalen ARP-Cache nach, ob dafür ein Eintrag existiert. Falls nicht, so fragt er die ihm bekannten Switches, ob einer von ihnen die MAC-Adresse kennt und liefert bei Bestätigung die Pakete an den entsprechenden Switch. Und ich denke mal, die Kommunikation dafür geht dann über das ARP-Protokoll...

(korrigiert mich, wenn ich das falsch sehe)

[cicero610y]

Hallo,

Also falls die MAC-Adresse bisher keinem Switch bekannt ist, werden ARP-Broadcasts durchs Netz gejagt, um herauszufinden, an welchem Switch und an welchem Port dort die entsprechende MAC-Addresse zu erreichen ist.

Ok. Nochmal: Ein normaler Switch, der auf Layer 2 arbeitet, kennt kein ARP und schickt auch keine ARP-Requests durch die Gegend. Egal wie - er tut das nicht. Ihm ist egal, ob er kaskadiert ist oder welche Rechner an einem anderen Switch in der Kaskade hängen.

Siehe z.B. hier. Dort werden übrigens auch Man in the middle attacks u.s.w. beschrieben und am Beispiel eines Cisco Switches Catalyst 4500 wie sie verhindert werden können (wohl auf englisch).

Das Ding ist meines Wissens ein Layer-3-Gerät. Erst damit kennt das Gerät mehr als Ethernet und weiß überhaupt etwas von einer IP.

Und zum Austausch... also wenn ein Switch Daten an eine bestimmte IP-Adresse ausliefern soll, dann schaut er in seinem lokalen ARP-Cache nach, ob dafür ein Eintrag existiert. Falls nicht, so fragt er die ihm bekannten Switches, ob einer von ihnen die MAC-Adresse kennt und liefert bei Bestätigung die Pakete an den entsprechenden Switch. Und ich denke mal, die Kommunikation dafür geht dann über das ARP-Protokoll...

Woher soll ein normaler Switch etwas von einer IP wissen? Er kennt das nicht, hat daher auch keinen ARP-Cache. Wie gesagt: Ein Layer-2-Switch kennt gerade mal Ethernet und muss deshalb auch nicht zwischen IP und MAC auflösen. Das macht allein der Rechner.

Kommunikation - jederzeit per Ethereal am eigenen Netz nachzuvollziehen:

1.) Rechner R soll ein über Ethernet ein TCP-Paket an das lokale Gateway G senden.

2.) R kennt lediglich die IP von G 172.24.2.1, sein ARP-Cache ist leer

3.) R fragt per ARP: "Wer ist 172.24.2.1?"

4.) Wenn kein böser Junge dazwischen, antwortet G (und dann nur der!) mit ARP-Response "172.24.2.1 ist bei 00:0A:5E:1C:63:70"

5.) R trägt dieses Päärchen in seinen ARP-Cache ein.

6.) Der TCP/IP-Stack des OS von R packt nun das ursprüngliche Paket die Layer runter zusammen und schickt es über Ethernet an 00:0A:5E:1C:63:70.

7.) Der Switch dazwischen bekommt das Paket, schaut sich (je nach Bauart) die MAC an, sieht in seinem Address-Cache nach und haut es am entsprechenden Port wieder raus oder - wenn er es nicht in seinem Address-Cache hat, an alle Ports.

Nicht anderes macht ARP - der Switch hat damit nichts zu tun.

Grüße,

Florian

[Crash2001]

Kann gut sein, dass das ein Level3-Switch ist dann - sind aber dann wohl die meisten konfigurierbaren, oder?

Aber die ARP-Pakete gehen über den Switch - er erzeugt sie zwar nicht, aber er liefert sie aus ... (wie könnte sonst schliesslich das Gateway antworten? )

Dass der keine ARP-Requests erstellt, leuchtet mir ein, aber da ein Switch einen ARP-Cache hat, könnte er doch sehr wohl auf einen ARP-Request antworten, oder?

[georg_koch]

Kann gut sein, dass das ein Level3-Switch ist dann - sind aber dann wohl die meisten konfigurierbaren, oder?

Aber die ARP-Pakete gehen über den Switch - er erzeugt sie zwar nicht, aber er liefert sie aus ... (wie könnte sonst schliesslich das Gateway antworten? )

Dass der keine ARP-Requests erstellt, leuchtet mir ein, aber da ein Switch einen ARP-Cache hat, könnte er doch sehr wohl auf einen ARP-Request antworten, oder?

Dann könnten ja alle Maschinen antworten, schliesslich führt jede Maschine im Netz einen ARP-Cache. Ist aber nicht logisch, was wenn die Zielmaschine gar nicht mehr da ist??? Es antwortet nur die gemeinte Zeilmaschine.

[Crash2001]

Laut Protokoll dürfte es zumindest jeder PC tun (zumindest wenn man wiki in dem Punkt glauben schenken darf - siehe hier). Da das aber in grösseren Netzen dazu führt, dass jeder Rechner antworten will, ist das bei den Rechnern angeblich meist nicht implementiert (denke mal die meinen im Treiber).

Am Switch hingegen würde es wie ich finde hingegen Sinn machen, das zu aktivieren, da so die Antwortzeit verkürzt werden könnte, da statt dem PC schon der Switch antworten könnte. Obs aber nun auch wirklich benutzt wird, das weiss ich auch nicht und kanns auch leider hier mangels Switch nicht ausprobieren.

[hades]

Es antwortet nur die gemeinte Zeilmaschine.

Noe, nicht immer.

Das trifft nur zu, wenn Sender und Empfaenger im selben Subnetz liegen.

Wenn der Sender und das Ziel in verschiedenen Subnetzen liegen, dann antwortet der Router auf den ARP-Request.

Layer2-Switches kennen kein ARP. L2-Switches merken sich nur die MAC im Adresscache, d.h. welche MAC an welchem Switchport angeschlossen ist.

ARP ist erst ab OSI-Layer3 verfuegbar und im TCP/IP-Stack implementiert.

Woher soll ein Geraet sonst mitbekommen, welche MAC zu welcher IP gehoert? ... und dementsprechend das Paket (Layer3) mit der richtigen Layer2-Zieladresse in einen Ethernetframe kapseln.