Hi.
Ein seltsames Problem hier: Nach den Ferien haben die Künstler ihre Laptops ausgepackt und konnten keine Internetverbindung mehr herstellen. Die Clients (Win10) erhalten aber eine korrekte IP-Adresse via DHCP. Es ist ein Subnetz für die Fachräume mit dem Adressbereich 10.30.51.0/24
Woran kann es liegen,dass ein Client, der in der workstations-Datei “freigegeben” ist und nicht im IPFire in irgendwelchen Blacklists auftaucht, dennoch nicht online gehen darf?
Ich habe schon die Switche geprüft – alles beim alten (vor den Ferien lief es auch). Danach habe ich einen anderen Lenovo-Laptop an das gleiche Kabel gehängt und siehe da: Internet-Verbindung kommt zustande; also kein Problem der Switche o.ä. Daher der 1. Verdacht: Es muss am Client selbst oder an einem Win10-Upgrade liegen?
Allerdings haben wir danach den gleichen Lenovo-Laptop nochmal an einen anderen Port im Fachraum-Netz gehängt und plötzlich auch dort wieder: Keine Verbindung.
Danach habe ich die funkionierende IP-Adresse in der workstations-Datei getauscht und dem nicht funktionierenden Client verpasst: Damit kam die Verbinding ins Internet plötzlich zustande. Also kann es ja doch nicht mehr am Client liegen??
Nächste Idee: IPFire neustarten … keine Änderung.
Genauso seltsam: Es sind nur 2 Clients in dem Fauchraum-Netz betroffen. Alle anderen laufen.
Vielleicht hat ja jemand zufällig eine gute Idee, wonach ich da suchen soll. Die DHCP-Requests gehen wie gesagt alle problemlos durch… es sieht fast danach aus, als würden ganz gezielt die beiden Adressen 10.30.51.31 und 10.30.51.32 nicht mehr laufen … warum auch immer?!?
Hallo Michael,
du hast doch einen Cisco Layer 3 Switch.
Ich nehme an, sein MAC Speicher ist vollgelaufen.
Bitte trenn ihn mal für 3 Minuten vom Strom, schalt ihn wieder ein und
probier es nochmal.
Viele Grüße
Holger
Das wäre zumindest eine gute Erklärung für das seltsame und nicht nachvollziehbare Verhalten … ich habe ihn zunächst nur neu gestartet (remote – bin nicht mehr in der Schule). Da fiel mir im Protokoll auf, dass tatsächlich ein “arp cache overflow” gemeldet wurde. Wundert mich eigentlich, dass der Cisco da in die Knie geht?!?
Hallo Michael,
Das wäre zumindest eine gute Erklärung für das seltsame und nicht
nachvollziehbare Verhalten … ich habe ihn zunächst nur neu gestartet
(remote – bin nicht mehr in der Schule). Da fiel mir im Protokoll auf,
dass tatsächlich ein “arp cache overflow” gemeldet wurde.
genau das ist es: der arp Cache, nicht der MAC Cache.
Hast du mal die Cachewerte hochgesetzt?
Wundert mich
eigentlich, dass der Cisco da in die Knie geht?!?
… eigentlich nicht.
Der ARP Cache des Cisco SG300 den wir haben, ist eigentlich „zu klein“
für ein Netz wie ich es habe (ca. 180 Rechner).
Seit ich die Werte hochgesetzt hatte, gab es aber keien Probleme mehr.
LG
Holger
Ich meine schon, dass ich das mal erhöht hatte --Kurzzeitgedächtnis lässt grüßen. Weiß aber auch nicht mehr auswendig, wo diese Einstellung zu finden war. Welchen Wert hast du bei dir denn eingestellt? Und welchen “Timeout”??
Leider erscheint nur:
“Entschuldige, du hast keinen Zugriff auf dieses Thema!”
Hallo Michael,
Leider erscheint nur:
“Entschuldige, du hast keinen Zugriff auf dieses Thema!”
… hoppla.
Hier der Text:
In der Default-Einstellung der TCAM Resources Table ist der Wert 128
konfiguriert.
Wenn wir von ein paar VLANs ausgehen, die auch konfiguriert sind, gehen
pro VLAN 2 der 128 Einträge weg
Für die statische Route zum Gateway geht ein Eintrag weg
Pro IP-Host den der SG300 sieht geht ein weiterer Eintrag weg - und das
läuft richtig davon!
Damit ist in der Standard-Einstellung ab ca. 100 Rechnern (incl.
Servern) mit
einem Überlauf der TCAM-Tabelle zu rechnen. Das äußert sich in
Fehlermeldungen
der Art:
%ARP-E-ARPTBL: ARP Table Overflow
Sobald das passiert arbeitet der SG300 suboptimal und verwirft evtl. sogar
Frames. Bei Netzen mit mehr IP-Hosts muss man also den Wert für die
TCAM-Resources höher setzen!
Man kann noch den Zeitwert, wie lange dynamische Einträge in der ARP-Tabelle
gecacht werden, optimieren und den runter setzen. Das geht zumindest im CLI
des Switches über das Kommando:
arp timeout 300
Damit verfallen Einträge nach 5 Minuten und bleiben nicht ewig im Gerät
erhalten. Spätestens wenn aber die meisten Rechner zeitgleich an sind, hilft
das leider auch nichts mehr.
Noch mal anders, und direkt auf den Punkt gesagt: Der SG300 taugt in
Schulnetzen bis sagen wir mal max. 250 - 300 Rechnern. Man muss aber den
TCAM-Wert hochsetzen sonst ist schon bei 100 Rechnern Schluss. Für größere
Netze braucht man einen Layer-3-Switch der mehr IP-Hosts in seiner TCAM
verträgt.
Viele Grüße
Holger
Der Effekt ist verschwunden – das war’s also offenbar.
Besten Dank.