tmp
Mitglieder-
Gesamte Inhalte
53 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
1
tmp hat zuletzt am 28. März 2021 gewonnen
tmp hat die beliebtesten Inhalte erstellt!
Letzte Besucher des Profils
Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.
-
SENDMELOCATON reagierte auf Beitrag im Thema: GA1 Winter 2015/2016 IPv6
-
GA1 Winter 2015/2016 IPv6
tmp antwortete auf SENDMELOCATON's Thema in Prüfungsaufgaben und -lösungen
Der Header zeigt an welche Bits welches Headerfeld beschreiben. Also Bit 1-4 die Version, Bit 5-8 die Priorität, Bit 9 bis 32 das Flow Label, Bit 33 bis 48 die Länge der Payload usw. Bit 65 bis 192 dann halt die src ip und darauffolgend die dst ip. Eine Hexademizalziffer entspricht einer 4-Bit-Sequenz, da der Informationsgehalt jeweils 16 ist. 64/4=16 und 192/4=48, also beginnend mit der 17ten Hexziffer und bis zur 48ten Hexziffer steht die src ip. -
Single point of failure Prävention - ISP
tmp antwortete auf RealPride's Frage in Systemadministratoren und Netzwerktechniker
- Wie schon gesagt, zuerst brauchst du Ziele: Ich möchte für einen bestimmten Service (z.B. Internetzugang für meine Clients) eine Verfügbarkeit von 99,99% - Dann brauchst du eine Liste von Abhängigkeiten für den Service bzw. daraus resultierend, eine Liste von potentiellen Fehlerquellen. Das wäre in diesem Fall mindestens: 1. Ein Link oder Knoten in deinem Netzwerk schlägt fehl und das beeinträchtigt den Service 2. Ein Netzwerkdienst schlägt fehl und das beeinträchtigt den Service 3. Deine Internetverbindung über deinen ISP schlägt fehl. 4. Dein Service schlägt fehl. - Für alle diese Fehlerquellen brauchst du eine Wahrscheinlichkeit. Gute Datenqualität hierzu wirst du nie haben, aber wenn du vergangene Fehlerhäufigkeiten und -dauer gut aufbereitest (was ein Riesenthema ist, du brauchst natürlich eine Mindesthäufigkeit für sinnvolle Aussagen und die hast du oft nicht usw.), bekommst du immerhin eine Vorstellung der Größenordnung und das ist wesentlich besser als nichts. - Du hast jetzt eine klare Übersicht, an welcher Stelle du anfangen musst. Wenn dein Service einmal die Woche einen halben Tag lang sowieso ausfällt, brauchst du dir keine Gedanken über Multihoming machen. - Wenn du dann feststellst, dass dein ISP die Hauptfehlerquelle ist und deswegen einen zweiten möchtest, macht es Sinn, sich anzugucken, ob die beiden ISPs nicht möglicherweise denselben physischen Link teilen. Wenn ein Bagger dann die Leitung aufreißt, bringen dir die zwei ISPs nichts. -
tmp reagierte auf eine Antwort auf eine Frage: Single point of failure Prävention - ISP
-
iperf ist "handfest". Es hat (wie jedes Tool, das du benutzen wirst) einige Beschränkungen, die man kennen sollte: - Client und Server sollten ausreichend Ressourcen zur Verfügung stellen, v.A. Arbeitsspeicher kann ein Bottleneck sein - Wenn du das hast, kannst du mit mehreren Streams Bandbreiten von bis zu 10Gbits erreichen (insofern der getestete Pfad das unterstützt). Mehr wird nicht drin sein. Das schafft aber dann auch kein Fluke Linesprinter. - Ich persönlich mag es, mir traffic vorher mit scapy, hping3 oder ähnlichen Sachen zu generieren und dann einfach eine pcap-Datei mittels tcpreplay abzuspielen. So hat kann man genau definieren, was man haben will und es ist performanter, weil die Packete nicht gleichzeitig erzeugt und abgesendet werden müssen. - Wenn man 10Gbits+ generieren möchte, braucht man spezielle Hardware, z.B. DPDK-fähige NICs. - Wenn du 10Mbits und Packetverluste* hast, liegt das wahrscheinlich an deinem Netz und nicht an iperf. Um das herauszufinden, machst du ja eigentlich diese Messungen.
-
Whitehammer03 reagierte auf Beitrag im Thema: Netzwerkschrank ordentliche Verkabelung
-
Netzwerkschrank ordentliche Verkabelung
tmp antwortete auf Alexej_a7x's Thema in Ausbildung im IT-Bereich
und für mehr Info: Cabling: The Complete Guide to Copper and Fiber-Optic Networking -
tmp reagierte auf Beitrag im Thema: Netzwerkschrank ordentliche Verkabelung
-
Fragen zu Topologiefunktionen
tmp antwortete auf Rainbowberry's Thema in Prüfungsaufgaben und -lösungen
zu 1: Es gibt eine Spezifikation und eine Implementierung und die regeln was gemacht wird. Die Topologie kann Einfluss darauf haben, was sinnvoll ist, aber gibt jetzt nicht vor was gemacht wird, wenn eine Zieladresse nicht verortbar ist. zu 2: MAC braucht man, sobald mehrere Netzwerkteilnehmer auf ein geteiltes Medium zugreifen wollen. Ein Bus (je nach Definition manchmal auch ein Ring) ist ein geteiltes Medium. In einer Stern-Topologie (oder allgemein sobald ein Link nur jeweils zwei Teilnehmer duplex verbindet) hat man das nicht. Das erklären auch die Links, insofern sollten die eigentlich schon hilfreich sein. -
Fragen zu Topologiefunktionen
tmp antwortete auf Rainbowberry's Thema in Prüfungsaufgaben und -lösungen
1. Was heißt, Adressat ist nicht vorhanden? Also du bekommst ein Paket und die Zieladresse kommt in der Forwardingtabelle nicht vor? Was dann passiert ist protokollabhängig. Entweder wird das Paket gedroppt oder es wird erst versucht, den Knoten mit der Zieladresse ausfindig zu machen. Ist schwierig, allgemein zu sagen. Der Begriff Topologie bezieht sich ja erstmal nur auf den physischen Aufbau und alles andere ist ja erstmal nicht spezifiziert. 2. Wartezeit zum Senden impliziert, dass es eine Medium Access Control gibt. Von der hängen dann die minimalen und maximalen Wartezeiten ab. Zumindest beim Bus und evtll auch beim Ring. Siehe die Links von DoctorB. Mindestens beim Stern (angenommen alle links sind full duplex) gibt es keine Wartezeit vor dem Senden. -
PaddelCore reagierte auf eine Antwort auf eine Frage: Die ARP-Tabelle beim Switch?
-
MarcusBe reagierte auf eine Antwort auf eine Frage: Die ARP-Tabelle beim Switch?
-
Die ARP-Tabelle beim Switch?
tmp antwortete auf PaddelCore's Frage in Systemadministratoren und Netzwerktechniker
was isn ne SAT/SAT-Tabelle? switch address table? Wie auch immer: Die genaue Tabellenstruktur und Vorgehensweise ist einfach implementierungsabhängig. Normalerweise hat ein L3-Switch eine Tabelle, die next hops in MAC-Adressen auflöst. Diese kann entweder statisch gesetzte Einträge enthalten oder eben durch ankommenden Traffic lernen, indem sie die src mac und den ingress port ankommender Frames speichert. Wird ein neuer next hop angeschlossen, reicht ein einzelner Frame, um die neue MAC-Adresse zu lernen. Fehlende Einträge sollten also kaum vorkommen, aber wenn, dann wäre die richtige Entscheidung wohl, den betroffenen Frame zu droppen. D.h. es gibt eine Forwardingtabelle, die z.B. IP-Adressen in next hops übersetzt, und eine kleine next-hop-Tabelle, anhand der dann rausgesucht wird, welche dst mac in den Frame geschrieben werden soll. Mit anderen Worten: Was der Switch benötigt, ist eigentlich nicht die Auflösung von L3- nach L2-Adressen (aka ARP-Tabelle), sondern von Ports nach L2-Adressen. Wobei die meisten ARP-Tabellen diese Info auch enthalten. Bei einem L2-Switch werden src und dst mac im Frame nicht ersetzt, d.h. der Switch braucht fürs Forwarding gar keine Infos über MAC-Adressen von next hops, sondern muss nur wissen, an welchem Port er den Frame ausgeben soll. Wie die Forwardingtabellen erstellt werden, ist eine andere Frage (statisch gesetzt bzw. über ein Routingprotokoll + evtll andere Hilfsprotokolle). -
tmp reagierte auf Beitrag im Thema: Rechnernetze - Netzwerk Performance
-
tmp reagierte auf eine Antwort auf eine Frage: IPv6 Paket-Analyse - Frage
-
Subnetting/Supernetting mit Firewall
tmp antwortete auf verax's Frage in Systemadministratoren und Netzwerktechniker
genau genommen willst du wahrscheinlich dst port 22 in die eine Richtung und src port 22 in die andere Richtung freigeben -
Die maximale Größe einer TCP-Payload orientiert sich an der MSS. IPv4- und TCP-Header können potentiell größer sein als jeweils 20 Bytes und in solchen Situationen sollte meistens die MSS nach unten angepasst werden, damit die Paketlänge weiter unterhalb der MTU ist und es nicht zu Fragmentierung kommt. Bei festen Headerlängen ist der Informationsgehalt gleich. Ansonsten was lessbess sagt.
-
tmp reagierte auf eine Antwort auf eine Frage: Cisco Router 926-4P Telefonica
-
Cisco Router 926-4P Telefonica
tmp antwortete auf mariocisco's Frage in Systemadministratoren und Netzwerktechniker
joa also wie gesagt, ich kann in der Konfiguration erst einmal keinen Fehler erkennen. Die nächsten Schritte wären für mich: - Dass 9.9.9.9 vom PC aus nicht antwortet ist komisch. => Ist das Problem wirklich konsistent? Probier nochmal das Pingen. Bei inkonsistenter Erreichbarkeit ist es nicht unwahrscheinlich, dass das Problem außerhalb deines Netzwerks liegt. => Tritt das Problem nur auf diesem PC auf? Dann läge es wahrscheinlich an der Netzwerkskonfiguration des PCs. Versuch das Ganze mit einem zweiten Host innerhalb des Netzwerks. => Tritt das Problem bei verschiedenen IP-Adressen auf oder nur bei 9.9.9.9? => Tritt das Problem nur bei IPv4-Adressen auf? Dann solltest du die IPv4-Config nochmal checken. => Lass auf mehrere Adressen Traceroute laufen und guck wie weit sie gehen. Nur bis zum Router? => was sagt ein packet capture auf den verschiedenen Interfaces (das des PCs, die des Routers)? Kommen die ICMP-Requests an oder werden sie verworfen? -
tmp reagierte auf eine Antwort auf eine Frage: Cisco Router 926-4P Telefonica
-
Cisco Router 926-4P Telefonica
tmp antwortete auf mariocisco's Frage in Systemadministratoren und Netzwerktechniker
ah ok; ich habe zu lange nichts mit Cisco gemacht Wie auch immer, ich sehe in der Konfiguration nichts bei dem ich sofort sagen könnte, das ist es. Wenn du mal konkret sagen könntest, welche Dienste funktionieren und welche nicht bzw. die fehlgeschlagenen Sessions und Pings einfügst, könnte man vllt ein bisschen mehr helfen. Hast du nach Domainnamen oder IP-Adresse gepingt? Was ist das für ein DNS Server? Ich würde mir als nächstes die Pakete in Wireshark angucken. -
Cisco Router 926-4P Telefonica
tmp antwortete auf mariocisco's Frage in Systemadministratoren und Netzwerktechniker
ich hab jetzt nicht verstanden, was genaufunktioniert und was nicht. Ich tippe aber auf DNS. Üblicherweise solltest du nicht unbedingt das Passwort u.Ä. mitschicken. -
CoffeeJunkie reagierte auf Beitrag im Thema: BURNOUT IN DER IT
-
Ich bezweifle, dass jetzt alles wieder gut ist. Deswegen sag ich ja, mal gucken wie es weitergeht.
-
Ein sehr fähiger Kollege von mir hat Burnout, meiner Meinung nach mit Ansage. Hat sich ca. 4 Wochen freigenommen und ist jetzt wieder da, mal gucken wie es weitergeht. Neben allgemein wichtiger guter Selbstorganisation gibt es zwei grundlegende Fähigkeiten, um sowas zu verhindern: Erwartungsmanagement und Kündigungsbereitschaft.
-
tmp reagierte auf Beitrag im Thema: BURNOUT IN DER IT
-
tmp reagierte auf Beitrag im Thema: BURNOUT IN DER IT
-
tmp reagierte auf Beitrag im Thema: Ethernet CSMA/CD
-
tmp reagierte auf Beitrag im Thema: Subnetzmasken
-
Gutes IT-Dokumentations- und Pflegesystem gesucht :)
tmp antwortete auf MarNo84's Frage in Systemadministratoren und Netzwerktechniker
netbox