|
Anzeige
|
Netzwerkkabel ausstecken simulieren?Hallo, meine Programmierer wollen "Netzwerkkabel ausstecken" simulieren. Welche möglichkeiten gibt es außer "Stromversorgung am Switch ziehen"? Wobei sie meinen, "Stromversorgung aus" ist nicht das gleiche wie "Netzwerkkabel ziehen". Kann man das elektronisch Steuern über ein IC oder so? Nachtrag: Es geht darum, per Software den Fehlerfall "Netzwerkkabel wurde gezogen" zu simulieren. MfG Wolfgang Nimm einen managebaren Switch. Dort kannst Du die einzelnen Ports (de)aktivieren.
Gast
#7710879
Für die SW ist es das gleiche. Kein Link ist kein Link. Ob nun durch gezogenen Stecker oder Treiberstufen ohne Saft. Messtechnisch könnte man da einen Unterschied erkennen, aber auf SW Seite ist das gehupft wie gesprungen.
Ist auch nicht das gleiche wie ein gezogener Stecker ;-)
Hallo, Danke für deine Zeit. Ich denke das ist nicht geeignet, den Fehlerfall "Netzwerkkabel wurde ausgesteckt" zu simulieren. Das hätte ich vielleicht noch klarstellen sollen. :*| Danke + MfG Wolfgang
´ Danke für deine Info. Ich werde das mal so weitergeben.
Nicht ganz. Netzwerkkabel direkt am PC gezogen: Eth-Link geht down, Betriebssystem deaktiviert das Interface und alle Routen darauf, Verbindungsversuche schlagen sofort fehl. Netzwerkkabel nach Switch gezogen: Eth-Link bleibt bestehen, Betriebssystem kriegt nicht sofort mit dass das Gateway unreachable ist, Verbindungsversuche laufen irgendwann auf Timeout. Mit einem managebaren Switch kannst du beide Szenarien nachstellen: Entweder Port ganz deaktivieren, oder (z.B) Port auf ein ungenutztes VLan legen. Seitenschneider ? 8-pol Schalter oder Relais? Richtig geht das mit Cisco Routern. Ein "interface down" reicht da auch nicht. Man muss das Line Interface/Controller deaktivieren. Die stehen auch nicht in der Config des Routers, weil "normalerweise" so etwas niemand macht. :) Ein guter DHCP-Client, triggert dann, wenn der Controller wieder geladen und das Interface "Up" gesetzt wird, eine neue DHCP-Verhandlung.
klar Rastnase am Netzwerkstecker entfernen, einen pneumatischen Auswerfer vom PrüfPC ansteuern -> Festo so haben wir in der QS Netzstecker ausgeworfen und Tasten geprüft. Sollte auch mit Netzwerkstecker funktionieren. Alternativ Linearmotor der den Netzwerkstecker rein und raus-fährt.
Es ging aber nicht um "Netzwerkkabel nach Switch", sondern um "Stromkabel vom Switch".
Gast
#7710974
Davon redet ja keiner. Es wurde vorgeschlagen den Switch selbst auszuschalten und da geht der Link eben auch sofort weg. Also ist es das gleiche wie ein gezogenes Kabel. Was Du beschreibst ist kein deaktivierter Link sondern einfach nur irgendwas wo 'kein Anschluss unter dieser Nr.' Unter linux haben wir Netzwerk Namespaces und veth-pairs (Virtuelle Netzwerkkabel). https://man7.org/linux/man-pages/man4/veth.4.html https://man7.org/linux/man-pages/man8/ip-netns.8.html Erstelle ein Netzwerk Namespace, erstelle ein veth-pair, packe ein Interface des eth-pair in den Namespace. Konfiguriere die veth-pairs. Starte die Anwendung im Namespace. Beide Seiten / Interfaces des veth-pair können up / down sein, kann man mit "p link set dev <interface> up/down" ändern. Auf der "Host" Seite kannst du entweder mit einer Bridge einen Switch simulieren (https://wiki.archlinux.org/title/Network_bridge) oder eine IP geben und Routing einrichten. Im Namespace muss das Interface auch eingerichtet werden (einfach mit ip netns exec rein, damit z.B. /bin/bash starten). Muss man wie echte Interfaces einrichten. (also entweder Statisch, oder mit dhclient, etc. Auch die Routen nicht vergessen.) Mit den Netzwerk Namespaces usw. kann man so ziemlich jeden Netzwerkaufbau simulieren, ohne extra VMs zu benötigen. Das ist die selbe Technologie, die in Containern zum Einsatz kommt, wobei man hier aber keinen vollständigen Container braucht. Man könnte die Herren Programmierer auch dazu anhalten mal ins Datenblatt des PHY zu schauen welche Art von Link Detection er nach welchem 802.<x>-Standard macht. Der PHY ist nämlich für Link Detection zuständig. Damit kann man dann entscheiden wie der Test aussehen muss. Das habe ich vor ewigen Zeiten mal gemacht, und wir kamen zu dem Schluss dass Ausstecken nicht nötig ist. Wenn ich mich nicht irre, dann ist das normalerweise so, dass jede Seite in regelmäßigen Abständen eine Link Integrity Check macht, indem dafür auf ein spezielles Signal gehört wird. Bleibt das in einer gewissen Zeit aus und gibt es auch keine Frames, dann gilt der Link als down. Für Details muss man sich durch die 802.<x> Standards wühlen.
aber nicht das physische Ziehen von Netzwerkstecker!
simulieren klappt nicht, wer prüfen will muß physisch trennen.
Dummerweise, denn das ist der schwierigere Fall. Der Client glaubt sein Host wäre noch da und hängt forever. Dagegen sollte ein Watchdog implementiert sein und zyklisches neu verbinden, dann ist auch der Fall mit Kabel ziehen / Interface down abgedeckt.
WIMRE gibt es von Yamaichi einen entsprechenden Prüfstecker aus einem sehr schlagzähen Material (vermutlich PAEK), der deutlich länger als ein normaler RJ-45-Stecker ist und an der geräteabgewandten Seite zwei Flansche mit Langlöchern hat. Es gab darin auch ein bewegliches Ausgleichselement, um Scher- und Biegekräfte zu reduzieren.
Unter Windows geht das mit der rechten Maustaste auf den Adapter: -> deaktivieren Unter Linux/BSD auf der Konsole mit 'if -down/up' Kann man auch mit dem Rechner der Gegenstelle machen, wenn es für den Prüfrechner "ganz kalt" werden soll.
wurde doch schon alles vorgeschlagen ist aber keine physische Trennung aka Stecker ziehen und stecken. Die Frage sollte beinhalten wie das usecase aus sieht. Je nachdem wie low oder high-level die Entwicklung statt findet gibt es unterschiedliche Lösungen. Und nicht alle sind in allen Fällen anwendbar. Managed Switch und Port deaktivieren sollte am nähesten ran kommen, das sollte direkt mit ISO/OSI Layer 1 arbeiten, also Link auf der Gegenstelle auch auf 0 setzen. Hätte auch den Vorteil das man am Switch den Status (hat autonegotiation korrekt funktioniert nach Port wiedereinschalten usw.) abfragen kann. Auf ein Mikrotik Ding kommst du per SSH und kannst das recht einfach disablen.
Nur ist, wenn sich bei Ethernet nichts geändert hat, der Aufwand in einem automatischen Test nicht zu rechtfertigen, da der PHY nur das Ausbleiben des Link Integrity Signals detektiert. Ob du für das Ausbleiben des Signals durch automatisches physikalisches Trennen sorgst (aufwendig) oder durch Abschalten des Switch-Ports (ein paar einfache Kommandos) macht keinen Unterschied für den PHY (wenn sich, wie schon geschrieben, bei Ethernet nichts geändert hat). Daher sollten, wenn es für sie so wichtig ist, die Herren Programmierer ihren Arsch hoch bekommen und mittels PHY Datenblatt und 802.<x> Standard kontrollieren was ihr PHY genau macht. Statt einfach blind zu behaupten der Stecker muss gezogen werden. Entscheidungen basierend auf Fakten zu treffen ist viel schlauer statt wie Rumpelstilzchen mit dem Fuß aufzustampfen und darauf zu bestehen dass der Stecker gezogen werden muss. Wer darauf besteht, nur physische Trennung wäre ein echter Test, übersieht vielleicht ein weiteres praktisch vorkommendes Szenario: Link up, Traffic down. Bereits erlebt, weil der Switch im Wald stand. Wenn dann nur ein fehlender Link einen Takeover auslöst, sitzt man in der Tinte. Vielleicht ist je nach Aufgabe flexibler, auf die fehlende Funktion zu gehen, als auf das exakte Fehlerbild. Es gibt so kleine hf-taugliche Reed Relais. Einfach damit die Verbindung auftrennen. Dann muss man auch mit keinem auditor streiten ob ifdown einem gezogenen kabel ähnlich genug ist. ZB sowas hier: https://www.reichelt.com/de/en/smd-reed-relay-1-closed-contact-0-5-a-crr-05-1a-p85096.html
niemand weiß was getestet werden soll, mal reicht abschalten, mal wirklich nur Stecker ziehen. Ich vermute mal der TO weiß selber nicht was getestet werden soll. Falls man nur sehen will, wie ein PC Programm auf sowas reagiert (z.B. um den Offline Modus einer PWA zu testen oder so), wäre physisch die Verbindung zu Trennen doch etwas Overkill. Mit Network Namespaces kann man da gezielt die eine Anwendung testen, ohne das ganze System offline zu nehmen.
Man kann die Anwendung auch gut in eine VM verbannen und kann dann auf der Host-Seite munter hoch- und runterschalten. Hat bei mir für Software-Test bis jetzt immer ausgereicht. Man kann sich da auch schön mehre Virtuelle NIC einrichten und so direkt beobachten ob der Failover usw. auch sauber funktioniert. Viel interessanter wird es, wenn der VM-Host die Physik "nach außen" verliert und der VM-Client das nicht "mitgeteilt bekommt":-) Real an der Hardware-Verbindung rumschrauben kann ich mir höchstens vorstellen wenn man gerade eine NIC-Hardware bzw. deren Treiber entwickelt, sinnvoll ist? Aber für eine Anwendung, die oberhalb von einem OS läuft, eher nicht. Um irgendein µC oder sonst irgendwas ohne OS kann es ja nicht sein, wir sind hier im ja PC Bereich? Vielleicht doch noch mal eine Zusatzscheibe Salami liefern...
Wenn man das am entfernten System macht, macht es für das Testsystem aber auf der Anwendungsebene keinen relevanten Unterschied (mehr). Der OP möchte schließlich "Software" testen, keinen Treiber. Und da interessiert eh nur noch ob die API meldet: "link down"... Wenn ein echter Netzausfall herbeigeführt werden soll, gibts nichts anderes als eine physikalische Trennung. Einziger Kompromiss: Vo den 4 Adern-Paaren sollte es genügen, jeweils eine Ader per Mikro-Reed zu schalten. Da es (z.B. vom Meder) auch winzige Reed-Relais mit 5V/10mA Spulenstrom gibt, kann man das problemlos mit einem Mikrocontroller (Arduino oder ESP) ohne viel Aufwand direkt schalten.
Definiere "Netzausfall". Dieser Begriff bezieht sich für mich nicht allein auf Szenarien, in denen jemand über das Kabel stolpert. Sondern auf den Ausfall der Kommunikation, mit oder ohne physischer Trennung, klein- oder grossräumig. Der Thread beschränkt sich in der Fragestellung völlig auf die physische Trennung. Interessant ist also, was die eigentliche aber nicht genannte Aufgabe ist: Verhalten bei Netzausfall generell, oder wirklich nur dieses eine von diversen Ausfallszenarien?
Bei PoE reicht es nicht, nur eine Ader pro Paar zu trennen.
Mit Reedrelais kann man dann auch sehr gut Fehlerzustände wie z.B. Wackelkontakte simulieren. Hallo, es wurde eine PCB mit vier Relais gebaut, damit kann man PC gesteuert zwei Aderpaare trennen. Jetzt nur mal für 10/100 MBit. Das geht ganz gut. MfG Wolfgang
Kyle Kingsbury verifiziert mit seinem quelloffenen Jepsen-Framework verteilte Systeme, indem er sie unter Last setzt und dann verschiedene Fehler simuliert, darunter auch den plötzlichen Verlust und die spätere Wiederherstellung der Netzwerk-Konnektivität, und weitere. Ich habe zwar bisher noch nicht damit damit gearbeitet, aber vielleicht wäre das ja etwas für Euch? Ich ganz persönlich würde auch dazu neigen, solche Tests möglichst reproduzier zu gestalten, um verschiedene Netzwerkprobleme sauber simulieren zu können -- nicht nur den Komplettverlust der Konnektivität, sondern zum Beispiel auch die Saturierung von Netzwerken oder "flatterndes" Netzwerk, das immer wieder kurze Ausfälle hat und nach mehr oder weniger kurzer Zeit wieder funktioniert. Sowas kann einen buchstäblich in den Wahnsinn treiben und ist für eine Software, die ihre Zustände replizieren muß, mitunter eine viel größere Herausforderung als ein Totalverlust der Netzwerkverbindung(en).
Acht von diesen 5,60€ Relais sind sicher geeignet, wenn man von den Montageschwierigkeiten und der nötigen Dauerstromversorgung absieht. Ich denke vier dieser kleinen 1€ Relais, ein Taster, ein Batteriehalter und 8xAA kosten zusammen 10€ und reichen HF-technisch auch: https://www.reichelt.de/signal-relais-subminiatur-12-v-dc-2-a-2-wechsler-hfd4-12-p260147.html?&trstct=pol_20&nbc=1 Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
