ardcore

Um physikalische Linkverbindungen zu testen reicht dir ein VLAN und ein Subnet. PC ---> Switch <---> passive Verkabelung <---> Switch <--- PC

Poste doch mal ein "show tech-support". Gerne auch als Anhang. Wird relativ lang der Output. @hades: Nein, ein Spanningtree-Problem kann man ausschliessen. Sie haben kein Netz mit redundanten Pfaden sofern es geschildert wurde.

Ein "clear counters" für das 0/18er Interface abgesetzt wie schon geschrieben?

Böses, böses Foul. Das wird nicht funktionieren.

Weil´s noch keiner genannt hat: Braveheart :uli

Du musst dir bewusstsein, dass du als Netzwerktechniker später auch sehr viel mit Software zu tun haben wirst. Auf die reine Hardware wirst du dich nicht beschränken können. Wenn du aus der Metallbranche kommst, wirst du eher praktisch veranlagt sein. Vielleicht orientierst du dich eher Richtung Elektronik wenn dir das Spass machen würde. Als Netzwerktechniker hast du sehr viel trockene Theorie zu verdauen, auch halte ich gute bis sehr gute Englisch-Kenntnisse als unabdingbar um langfristig erfolgreich zu sein. Kurz und knapp; Netzwerktechniker ja, wenn: - viel Bereitschaft zum Lernen besteht - dir auch theoretische und planerische Arbeit Spass macht - gute Englischkenntnisse vorhanden sind Den Praktikern und Bastlern würde ich eher Richtung Anlagenelektroniker, IT-Systemelekroniker raten.

Selbst die schwache Orthographie aussen vor gelassen, kannst du dir die ILS Ausbildungen an die Toilettentür nageln. Die Dinger taugen nichts.

Wenn zuviele Hops zwischen zwei Endpunkten liegen, gehen alle Daten verloren nicht nur spezifische Protokolle die bei VPN Verwendung finden. Du musst dir leider ne andere Ursache überlegen Als kleiner Tipp: Ein Blick in die Logfiles der beiden VPN-Endpunkte kann nicht schaden.

Und damit du beim Auslesen nicht stirbst, hängst du noch nen | include <MACADDRESS> hinten dran.

Bleib doch bei den privaten IP-Addressranges nach RFC1918. Das wäre schon ein Anfang.

Mindestens E8 verlangen.

Dann weisst du ja was du noch dokumentieren musst Ich bitte darum, denk dran morgen ist Stichtag Naja es ist ne Intel-NIC, aber das grenzt die Suche kaum ein. Allerdings brauchst du keinen Scan laufen lassen. Die Mac-Adress-Table der Switche ist alles was du brauchst. Es ist eine der wahrscheinlichsten Fehlerursachen. Wenn es das nicht sein sollte gehen wir die anderen möglichen Ursachen durch.

Die Transmit-Errors treten nur auf, wenn der Transmit-Buffer des Interfaces ständig überfüllt ist und deshalb Frames aus ihm verworfen werden. Für ständig volle Transmit-Buffer gibt es mehrere Möglichkeiten. Eine Möglichkeit davon ist ein Speed/Duplex-Mismatch. Deshalb meine Vermutung mit der nicht richtig funktionierenden Autonegotiation. Manche Leute brüllen wenn sie sich mit ner Nadel in den Finger picksen, andere Leute geben bei ner Fraktur keinen Laut von sich. Nur wer am lautesten Brüllt muss nicht die grössten Schmerzen haben, du verstehst? Das das Interface runterbricht, kommt einem "Herzinfarkt" gleich. Auch wenn es zu keinem "Herzinfarkt" kommt, wird der Betroffene keine 100m mehr unter 10sek sprinten und sich über "Trägheit und Schlappheit" beschweren.

Und so ne Kiste willst du weiter betreiben? Ganz klar, System neu aufsetzen.

Da haben wir´s doch. Jede Menge Transmit-Error´s. Dh. die Transmit-Buffer auf deinen Ports laufen voll. Wenn die Queues voll sind und Packete in den Queues für mehrere Sekunden nicht versendet werden können, resettet sich das Interface automatisch. Sieht man schön in deinen Logs. Schnapp dir mal nen Port, stelle dort Duplex und Speed fest ein. Ebenso auf dem am Port hängenden Endgerät. Anschliessend bitte ein "clear counters int xxx" absetzen.

Cisco rät zu maximal 500 Clients in einer Broadcastdomäne. 600 sind sicherlich noch okay, wenn auch nicht optimal. Keine Redundanz und nur ein Core-Gerät ist natürlich bescheiden. Ist weniger sinnvoll. Ne Collapsed-Backbone-Struktur ist in der grössen Ordnung schon okay. Was Definitiv sein sollte ist nen 2tes Core-Gerät. Sinnvoll. Denk aber dran das du dann Routen musst. Darum wirst du kaum herrumkommen wenn du Redundanz willst. Das kommt ganz auf die Anwendungen an. Web-Traffic interessiert das eher weniger. SAP und Konsorten reagieren sehr allergisch darauf. PS: Du schuldest mir noch ein "show int counters errors" von einem der betroffenen Ports Gruss, ardcore.

Ach das werden wir bis Freitag schon schaukeln Interessiert mich selbst das Problem. Was du noch machen kannst ist, dir einen Switch rauspicken und dort einen Testclient hinhängen. Am besten der 3550 von dem die Outputs stammen. An dem Testport am besten einen Laptop mit Live-CD o.ä. betreiben. Powermanagement im BIOS und OS am besten ganz Ausschalten. Speed und Duplexeinstellungen der NIC fest einstellen. Dann den Switch neubooten, natürlich angekündigt und in Low-Usage-Time (Mittagspause etc.). Dann jag Traffic drüber über den Port. Ein paar Endlosspings mit erhöhter Grösse an unterschiedliche Destinations reichen schon. Sollte dann wieder Fehler auf dem Gerät auftauchen oder sich User beschweren, den Output von "show tec" hier posten. Gruss, ardcore.

Das ist egal. Ich wollte nur ausschliessen das es sich um einen Buffer- oder CPU-Leak handelt. Ein Buffer- oder CPU-Leak ist nicht der Grund für dein Problem. Was gibt den "show interface xxx counters errors" auf einem der betroffenen Interfaces aus? PS: Wichtig ist das auf den betroffenen Geräten die Power-Management-Funktionalität deaktiviert ist, die es erlaubt die NIC zu deaktivieren.

Nein, Linkflapping sieht anderst aus. Dort "flappt" das Interface min. 5mal innerhalb von 10sek und geht dann in den State "errdisabled". Dies wird auch im Logfile vermerkt. Das ist bei Euch nicht der Fall. Könntest du noch den Auszug von "show proc cpu | excl 0.00%__0.00%__0.00%" angeben? (zwei Unterstriche). Danke.

Die Ausgabe von "show buffers" wäre interessant. Gruss, ardcore.

Das ist aber sehr theoretisch... rechtlich sicherlich korrekt aber in der Praxis kannst du dir die Meldung sparen Ich möchte nicht wissen wieviele hunderttausende WLAN´s über Grundstücksgrenzen funken

Solange die Geräte nicht zeitgleich/zeitnah benutzt werden sollen, die MAC-Adresse auf den Geräten angleichen. Zwar nicht schön, aber effektiv

Supernetting ? Wikipedia

Naja Routing zum Endgerät ist ja nicht wirklich was Spannendes Und Redistribution ist im CCNA auch noch kein Thema. Anonsten geb ich dir natürlich recht, die 10€ kann man auch schlechter investieren

Zeehh Deehh Peehh