Hai
Ada keinginan untuk berbagi dengan komunitas sebuah ide yang diterapkan di perusahaan penyedia untuk dengan cepat menanggapi kerusakan pada kabel tembaga. Ini tentang twisted pair dan Ethernet. Tentu saja saya tidak berpura-pura menjadi solusi yang elegan, tetapi layanannya menunjukkan hasil yang baik.
Bagi yang malas membaca. Cara kerjanya: memantau jatuhnya sesi pada jari-jari, kelompok dengan sakelar, uji garis, pemberitahuan helm.
Saya tidak bisa memberikan seluruh kode proyek untuk alasan korporat, tetapi saya akan menghapus kode yang berada di bawah spoiler untuk mereka yang tertarik. Ya, dan implementasi untuk setiap penyedia akan berbeda. Sebaliknya, tujuannya adalah untuk membagikan gagasan yang mungkin dapat membantu seseorang.
Peralatan di perusahaan adalah 99% D-link, sehingga SNMP MIB terdaftar untuk vendor ini. Beberapa dari mereka adalah RFC dan harus cocok untuk produsen lain.
Sedikit sejarah tentang bagaimana semua itu keluar.
Semuanya dimulai pada musim semi 2018. Beban pada kelompok dukungan teknis (TP) meningkat. Selain memproses panggilan pelanggan, TP juga mengoordinasikan penginstal ketika menghubungkan pelanggan baru, serta ketika berangkat untuk restorasi dan debug pelanggan yang ada. Itu perlu untuk membongkar TP sedikit dan memberikan beberapa alat kepada installer. Diputuskan untuk membuat "bot" messenger yang akan menerima login / kontrak pelanggan dan installer dapat membuat debug minimum langsung di bidang.
Saya tidak ingin menanamkan semua fungsi dalam satu aplikasi, karena pada kenyataannya, fungsi seperti itu akan berguna juga di browser dalam CRM yang sama saat memproses panggilan, sehingga diputuskan untuk menempatkan mekanisme interaksi dengan peralatan jaringan, penagihan, radius ke dalam layanan terpisah, membuatnya menjadi API dan menghubungkan bot dan CRM melalui API dan hanya itu terserahlah.
Sekarang sedikit kode dan beralih ke esensi posting.
Jadi, apa yang dibutuhkan oleh penginstal di bidang:
- Uji kabel tentu saja
- Lihat kesalahan port
- Lihat status port
- Lihat apakah ada alamat MAC di port. (tiba-tiba pelanggan menghubungkan kabel ke port LAN dan bukan WAN)
- Berlangganan IPTV
- Lihat log otorisasi
- Status Saldo
Kami akan berinteraksi dengan sakelar melalui SNMP, dan di beberapa tempat melalui telnet.
Saya menggunakan Botol sebagai kerangka kerja web.
Dan begitulah
kami mengimpor yang diperlukan Kami menambahkan sheet dengan kunci API dan dekorator untuk verifikasi, tetapi kami tidak akan memberikan data kepada semua orang secara berurutan).
kode 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
Sebenarnya beberapa fungsi untuk berinteraksi dengan peralatan.
kode @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)
Di dalam snmp kami memiliki kamus dengan interpretasi status SNMP yang dikembalikan dari pasangan di port.
Kamus Status pair_status = { '0': 'ok', '1': 'open', '2': 'short', '3': 'open-short', '4': 'crosstalk', '5': 'unknown', '6': 'count', '7': 'no-cable', '8': 'other' }
Persiapan kamus untuk hasil pengukuran port. Kami akan menyalinnya, agar tidak membuat yang baru setiap saat.
Teks tersembunyi pair_result = { 'pairs': { 1: { 'status': '-', 'length': '-' }, 2: { 'status': '-', 'length': '-' }, 3: { 'status': '-', 'length': '-' }, 4: { 'status': '-', 'length': '-' }, } }
Fungsi
uji kabel def cable_test(ip, port): if not check_ip(ip):
fungsi akan kembali
hasil { "pairs": { "1": { "status": "other", "length": "0" }, "2": { "status": "open", "length": "4" }, "3": { "status": "open", "length": "4" }, "4": { "status": "other", "length": "0" } } }
Kemudian dia menambahkan fungsi serupa lainnya, khusus untuk skrip, ia menerima daftar port sebagai input, dan bukan salah satunya, dan tidak memeriksa status port sebelum pengujian, ini tidak perlu dengan penurunan besar-besaran pada tautan.
Seperti itulah bot itu mulai terlihat
Sekarang untuk esensi posting.
Sebelum implementasi
debug server, teknologi yang mirip dengan yang dijelaskan dalam pos
habr.com/post/188730 digunakan . Loop on port dengan SNMP ladder diaktifkan. Ketika "pesawat" jatuh di pelabuhan, pesan tentang ini jatuh ke pemantauan.
Pertama-tama, saya mengacaukan skrip sehingga ketika tautan pelacakan jatuh, server debug pergi ke sakelar, memeriksa apakah port benar-benar berbohong, dan tidak hanya berkedip, dan pasangan di atasnya terbuka atau korslet, dan kemudian mengirim pesan ke operator.
Namun, hanya sekitar 10% dari sakelar yang memiliki jebakan fisik seperti itu, dan ini ternyata hanya sedikit.
Kemudian muncul dengan jari-jari monitor. Dan ini memungkinkan untuk meningkatkan persentase cakupan pemantauan hingga 100%. Dan di sini semuanya sudah berbeda dari infrastruktur penyedia.
Kami secara berkala melihat berapa banyak sesi klien yang jatuh dari sakelar tertentu. Ini mudah dilakukan jika circuit_id diaktifkan pada sakelar, yang memiliki formulir
D4: CA: 6D: 0A: 66: C9 ::
192.168.20.86 ::
20Di sini kita memiliki MAC pelanggan, saklar IP, nomor port pelanggan. Yaitu semua yang Anda butuhkan untuk debug.
Kami mengelompokkan sesi yang diselesaikan dengan saklar IP, jika ada lebih dari beberapa sesi seperti itu (kami memiliki pemicu yang ditetapkan pada 2 sesi per menit), maka skrip menghubungi server debug dan menguji port dari sesi yang dijatuhkan. Jika port masih berbaring dan pasangan kabel terbuka atau korslet, dan panjang setidaknya dua port adalah sama (+ - 2 meter), yang persis seperti apa yang terlihat seperti potongan kabel dengan mata sakelar, maka kami mempertimbangkan situasi yang mencurigakan dan mengirim pesan ke operator.
Tentu saja akan ada positif palsu ketika lampu di rumah berkedip, atau itu hanya bertepatan bahwa pelanggan mematikan kabel pada saat yang sama dan panjangnya sama, tetapi ini masalahnya, seperti kata mereka, ketika lebih baik untuk berlebihan. Selain itu, Anda dapat membuat batasan pada panjang (hanya menanggapi panjang pendek), jumlah tetes serentak, dll.
Berikut ini adalah laporan nyata dari peristiwa yang mencurigakan.
Dan hasil pemrosesan pesan tersebut
Ada kasus ketika skrip mengirim pesan yang sama, dan setelah beberapa detik sakelar menjadi offline, karena optik rusak, dan jika bukan karena kecepatan perangkat lunak, maka situasinya akan keliru untuk pemadaman khas di rumah.
Di lain waktu, perusahaan manajemen mulai memperbaiki atap tanpa peringatan, dan VOKhR dengan senapan mesin terbang ke arah mereka, tiba-tiba stres bagi tukang kunci.
Jadi skrip mulai menunjukkan hasil yang baik dan selama 4 bulan bekerja, VOKhR, polisi, dan karyawan penyedia itu sendiri berhasil menyelesaikan lebih dari 10 kasus perusakan. Karena itu, saya memutuskan untuk membagikan konsep pemantauan tersebut.
Sekarang skrip memonitor sekitar 15.000 sakelar tanpa “perangkap” fisik dan perangkap SNMP.
Semoga sukses untuk semua orang di tahun baru!