Zum Inhalt springen
View in the app

A better way to browse. Learn more.

Fachinformatiker.de

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

tmp

User
  • Registriert

  • Letzter Besuch

  1.    SENDMELOCATON hat auf einen Beitrag in einem Thema reagiert: GA1 Winter 2015/2016 IPv6
  2. 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.
  3. - 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.
  4.    tmp hat auf einen Beitrag in einem Thema reagiert: Single point of failure Prävention - ISP
  5. 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.
  6.    Whitehammer03 hat auf einen Beitrag in einem Thema reagiert: Netzwerkschrank ordentliche Verkabelung
  7. und für mehr Info: Cabling: The Complete Guide to Copper and Fiber-Optic Networking
  8.    tmp hat auf einen Beitrag in einem Thema reagiert: Netzwerkschrank ordentliche Verkabelung
  9. 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.
  10. 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.
  11.    PaddelCore hat auf einen Beitrag in einem Thema reagiert: Die ARP-Tabelle beim Switch?
  12.    MarcusBe hat auf einen Beitrag in einem Thema reagiert: Die ARP-Tabelle beim Switch?
  13. 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).
  14.    tmp hat auf einen Beitrag in einem Thema reagiert: Rechnernetze - Netzwerk Performance
  15.    tmp hat auf einen Beitrag in einem Thema reagiert: IPv6 Paket-Analyse - Frage
  16. genau genommen willst du wahrscheinlich dst port 22 in die eine Richtung und src port 22 in die andere Richtung freigeben
  17. 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.
  18.    tmp hat auf einen Beitrag in einem Thema reagiert: Cisco Router 926-4P Telefonica
  19. 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?
  20.    tmp hat auf einen Beitrag in einem Thema reagiert: Cisco Router 926-4P Telefonica
  21. 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.
  22. ich hab jetzt nicht verstanden, was genaufunktioniert und was nicht. Ich tippe aber auf DNS. Üblicherweise solltest du nicht unbedingt das Passwort u.Ä. mitschicken.
  23.    CoffeeJunkie hat auf einen Beitrag in einem Thema reagiert: BURNOUT IN DER IT
  24. tmp hat auf bigvic's Thema geantwortet in IT-Arbeitswelt
    Ich bezweifle, dass jetzt alles wieder gut ist. Deswegen sag ich ja, mal gucken wie es weitergeht.
  25. tmp hat auf bigvic's Thema geantwortet in IT-Arbeitswelt
    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.
  26.    tmp hat auf einen Beitrag in einem Thema reagiert: BURNOUT IN DER IT
  27.    tmp hat auf einen Beitrag in einem Thema reagiert: BURNOUT IN DER IT
  28.    tmp hat auf einen Beitrag in einem Thema reagiert: Ethernet CSMA/CD
  29.    tmp hat auf einen Beitrag in einem Thema reagiert: Subnetzmasken

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.