I will share with you an interesting experience in creating a mobile tool for working with the network.
Foreword
I have worked for several years in providers, from small to federal. When I came to the Federal, I faced a lot of routine, and there was a desire to automate that very routine process.
year 2013. I have a friend who also worked in one of the "federals", connecting clients and there was a story when he gave me a phone and climbed into the attic to do something with the switch. I stood at the bottom with a phone on which a web page with various interesting scripts was opened. These scripts performed checking the port on the switch, clearing errors and other things.
That is, the engineer, having come to the address, did not bother the administrator for nonsense, because he himself had a tool for working with the network.
It's June 2018, and I was tormented with the thoughts that "Why not write a bot that would check equipment of different levels (core, aggregation, access)?" The problem was that only I wanted to get rid of the routine, the rest lived for today.
Choosing a programming language and platform
Guys, of course Python . At the time of the ideas, I already had some skills and a little experience in scripting. The platform was chosen as a friendly one - Telegram because all IT-schnicks live there.
Choosing libraries for writing a bot
1. Library for working with Telegram. pyTelegramBotAPI was fading away, especially during the time of blocking, I wanted to quickly make friends with proxies and other things. I chose python-telegram-bot and took Conversation as a basis .
2. Library for working with equipment. Due to the simplicity of work, my choice fell on - python3-netsnmp .
The foundation has been laid, it's time to write.
Drove
The network was a zoo of iron and we had to take a separate vendor and work with it. Another important condition was the presence of MIBs for performing tasks.
One of the tasks was to check the cable length and the status of the pairs, check the status of the ports and the presence of errors on the ports.
Now many will write saying - "Well, what could not be done without SNMP?" My answer is that - "Yes, you can't, if you want to capture data in a normal human way - then only SNMP."
Now someone already burns one place and he writes that only NETCONF.
Having passed the access equipment and implemented work with it in the bot, I was faced with the fact that sometimes, indeed, for specific tasks, which the SNMP protocol does not solve, I have to go to the equipment.
The netmiko library came to my rescue- and I'm still happy with her. She solved a lot of problems not even related to the bot. The amount of equipment supported is just fire.
I also found the ipaddress library very useful for checking IP addresses.In
general, when programming, I took into account a lot of nuances, from authorizing a user in a bot to giving him various rights.
The functionality grew
Yes, the functionality did grow, and with it the support for certain equipment grew. I have added radio access equipment, optical KTV receivers.
Somehow people came to me and said that we will put on intercoms. I understand with my head that the setting will also fall on my shoulders and the shoulders of colleagues.
I began to feel, look. I read the API, which was good there. I chose the simplest library for working with HTTP and HTTPS - requests .
Having already worked with intercoms, there were needs for a database, but as usual the lazy * opera did not want to strain too much. Therefore, the choice fell on sqlite3. The library was also chosen as simple as possible - it is dataset .
The clouds are gathering.
At some point, the work became insanely much and my brainchild, in fact, lived on its own. There is a lot of work, little money - well, I think you pick up the note. I decided to leave this establishment. Having worked for several years in the federal government, I have improved my skill in working with a programming language. I was very pleased with this.
Epilogue
Perhaps this is either a big, or not a very story has come to an end. Networker in my opinion without programming anywhere, especially with a zoo of iron. As a result, the fleet of supported equipment was as follows:
- 23 models of access switches
- 3 models of optical KTV receivers
- 4 models of chassis switches
- 1 model of a chassis router
- 3 models of radio access equipment