Hallo.
Es besteht der Wunsch, der Community eine Idee mitzuteilen, die beim Anbieterunternehmen umgesetzt wird, um schnell auf Schäden am Kupferkabel zu reagieren. Es geht um Twisted Pair und Ethernet. Natürlich gebe ich nicht vor, elegante Lösungen zu sein, aber der Service zeigte gute Ergebnisse.
Für diejenigen, die zu faul zum Lesen sind. So funktioniert es: Überwachen Sie den Fall von Sitzungen auf dem Radius, gruppieren Sie nach Schaltern, testen Sie die Linie, Helmbenachrichtigung.
Ich kann aus Unternehmensgründen nicht den gesamten Projektcode angeben, aber ich werde den Code entfernen, der für Interessenten unter den Spoilern steht. Ja, und die Implementierung für jeden Anbieter variiert. Das Ziel ist vielmehr, eine Idee zu teilen, die jemandem helfen könnte.
Die Ausrüstung im Unternehmen besteht zu 99% aus D-Link, daher sind die SNMP-MIBs für diesen Anbieter aufgeführt. Einige von ihnen sind RFCs und sollten für andere Hersteller geeignet sein.
Ein bisschen Geschichte darüber, wie alles herauskam.
Alles begann im Frühjahr 2018. Die Belastung der technischen Support-Gruppe (TP) nahm zu. Neben der Verarbeitung von Teilnehmeranrufen koordinierte TP die Installateure auch beim Anschließen neuer Teilnehmer sowie beim Aufbruch zur Wiederherstellung und zum Debuggen bestehender Kunden. Es war notwendig, das TP ein wenig zu entladen und den Installateuren einige Werkzeuge zu geben. Es wurde beschlossen, einen Messenger-Bot zu erstellen, der das Login / den Vertrag des Abonnenten akzeptiert und das Installationsprogramm das minimale Debugging direkt in den Feldern durchführen kann.
Ich wollte nicht alle Funktionen in eine Anwendung einbetten, weil Tatsächlich wäre eine solche Funktionalität auch im Browser im selben CRM nützlich, wenn ein Anruf verarbeitet wird. Daher wurde beschlossen, die Mechanismen der Interaktion mit Netzwerkgeräten, Abrechnung und Radius in einem separaten Dienst zusammenzufassen, sie zu einer API zu machen und sowohl den Bot als auch das CRM über die API zu verbinden was auch immer.
Nun ein wenig Code und weiter zum Kern des Beitrags.
Und was kann ein Installateur in den Bereichen benötigen:
- Kabeltest natürlich
- Portfehler anzeigen
- Portstatus anzeigen
- Überprüfen Sie, ob sich am Port MAC-Adressen befinden. (Plötzlich steckte der Teilnehmer das Kabel anstelle des WAN in den LAN-Port.)
- IPTV-Abonnement
- Berechtigungsprotokolle anzeigen
- Kontostand
Wir werden mit den Switches über SNMP und an einigen Stellen über Telnet interagieren.
Ich habe Bottle als Webframework verwendet.
Und so
Wir importieren das Notwendige Wir fügen ein Blatt mit API-Schlüsseln und Dekoratoren zur Überprüfung hinzu, geben jedoch nicht alle Daten hintereinander an.
Code apikeys = ['RANDOM_KEY1', 'RANDOM_KEY2'] api_error = '{"error":"apikey invalid"}' host_down_error = '{"error":"host down"}' def apikey_checker(fn): def wrapper(*args, **kwargs): if not check_apikey(): return api_error return fn(*args, **kwargs) return wrapper def check_apikey(): return 'apikey' in request.query and request.query['apikey'] in apikeys
Nun, eigentlich ein paar Funktionen für die Interaktion mit Geräten.
Code @route('/port_status/<ip>/<port>') @apikey_checker def get_port_status(ip=' ', port=' '): return snmp.port_status(ip, port) @route('/cable_test/<ip>/<port>') @apikey_checker def get_cable_test(ip, port): return snmp.cable_test(ip, port)
In snmp haben wir ein Wörterbuch mit der Interpretation der zurückgegebenen SNMP-Status des Paares am Port.
Statuswörterbuch pair_status = { '0': 'ok', '1': 'open', '2': 'short', '3': 'open-short', '4': 'crosstalk', '5': 'unknown', '6': 'count', '7': 'no-cable', '8': 'other' }
Vorbereitung des Wörterbuchs für das Port-Messergebnis. Wir werden es kopieren, um nicht jedes Mal ein neues zu erstellen.
Versteckter Text pair_result = { 'pairs': { 1: { 'status': '-', 'length': '-' }, 2: { 'status': '-', 'length': '-' }, 3: { 'status': '-', 'length': '-' }, 4: { 'status': '-', 'length': '-' }, } }
Funktion
Kabeltest def cable_test(ip, port): if not check_ip(ip):
Funktion wird zurückkehren
Ergebnis { "pairs": { "1": { "status": "other", "length": "0" }, "2": { "status": "open", "length": "4" }, "3": { "status": "open", "length": "4" }, "4": { "status": "other", "length": "0" } } }
Später habe ich eine weitere ähnliche Funktion hinzugefügt, die ausschließlich für das Skript bestimmt ist. Sie akzeptiert eine Liste von Ports als Eingabe und nicht eine und überprüft den Portstatus vor dem Testen nicht. Dies ist bei einem massiven Verbindungsabfall nicht erforderlich.
So sah der Bot aus
Nun zum Kern des Beitrags.
Vor der Server-
Debug- Implementierung wurde eine Technologie verwendet, die der in post
habr.com/post/188730 beschriebenen
ähnelt . Schleife am Port mit aktivierter SNMP-Leiter. Als das „Flugzeug“ im Hafen fiel, fiel eine Nachricht darüber in die Überwachung.
Zuerst habe ich das Skript so geschraubt, dass der Debug-Server zum Ausfall des verfolgten Links zum Switch ging, überprüfte, ob der Port wirklich lügte und nicht nur blinzelte, und die Paare darauf waren offen oder kurzgeschlossen, und dann eine Nachricht an die Bediener sendete.
Allerdings hatten nur etwa 10% der Schalter solche physischen Fallen, und dies stellte sich als nicht ausreichend heraus.
Später kam mit einem Monitorradius. Dadurch konnte der Prozentsatz der Überwachungsabdeckung auf 100% erhöht werden. Und hier unterscheidet sich schon alles von der Provider-Infrastruktur.
Wir überprüfen regelmäßig, wie viele Client-Sitzungen von einem bestimmten Switch abgefallen sind. Dies ist einfach, wenn die Schaltkreis-ID für die Schalter aktiviert ist, die die Form haben
D4: CA: 6D: 0A: 66: C9 ::
192.168.20.86 ::
20Hier haben wir den MAC des Teilnehmers, den IP-Switch, die Portnummer des Teilnehmers. Das heißt, alles was Sie zum Debuggen brauchen.
Wir gruppieren abgeschlossene Sitzungen per IP-Switch. Wenn mehr als einige solcher Sitzungen vorhanden sind (wir haben einen Trigger auf 2 Sitzungen pro Minute eingestellt), kontaktiert das Skript den Debug-Server und testet die Ports der abgebrochenen Sitzungen. Wenn die Ports immer noch liegen und die Kabelpaare offen oder kurzgeschlossen sind und die Länge von mindestens zwei Ports gleich ist (+ - 2 Meter), wie der Kabelschnitt mit den Augen des Switch genau aussieht, betrachten wir die Situation als verdächtig und senden eine Nachricht an den Bediener.
Natürlich kommt es zu Fehlalarmen, wenn das Licht im Haus blinkt, oder es fällt einfach zusammen, dass die Teilnehmer das Kabel gleichzeitig ausschalten und die Länge gleich ist, aber dies ist, wie sie sagen, der Fall, wenn es besser ist, zu übertreiben. Außerdem können Sie die Länge (reagieren Sie nur auf kurze Längen), die Anzahl der gleichzeitigen Tropfen usw. begrenzen.
Hier ist der eigentliche Bericht über ein verdächtiges Ereignis.
Und die Ergebnisse der Verarbeitung solcher Nachrichten
Es gab einen Fall, in dem das Skript eine ähnliche Nachricht sendete und nach einigen Sekunden der Switch offline ging, weil beschädigte Optik, und wenn nicht für die Geschwindigkeit der Software, dann wäre die Situation für einen typischen Stromausfall im Haus verwechselt worden.
Ein anderes Mal begann die Verwaltungsgesellschaft, das Dach ohne Vorwarnung zu reparieren, und VOKhR flog mit Maschinengewehren zu ihnen hinüber, plötzlicher Stress für Schlosser.
Das Drehbuch zeigte also gute Ergebnisse und über 4 Monate Arbeit haben VOKhR, die Polizei und die Mitarbeiter des Anbieters selbst mehr als 10 Fälle von Vandalismus erfolgreich abgeschlossen. Daher habe ich beschlossen, das Konzept einer solchen Überwachung zu teilen.
Jetzt überwacht das Skript etwa 15.000 Switches ohne physische „Traps“ und SNMP-Traps.
Viel Glück für alle im neuen Jahr!