Tale about how we tied subscribers to the ports
Hi Habr!
I'll tell you my story.
It so happened that once I got the position of head of the technical department in one small Internet provider. The company at that time experienced some technical problems, could not be found by a techie. At that moment I was just looking for a normal job - the year before I left the great and powerful AvtoVAZ plant (I worked in the Directorate for Information Systems) - I pressed the crisis, did not give me any money. After - a year of work as a teacher in a school (in parallel, he was registered as an individual entrepreneur), in general he turned as he could. And being in the fall in another city, from a friend I find out that a techie is urgently needed. He came to the interview without much hope, and a lot of desire, and as it turned out - in vain. After about a 10-minute conversation, the director asked to leave today. And I went out.
')
As it says, then all the saying was?
The network was built on variegated equipment, the owners definitely did not give preference to any iron producer. In fact, it was a typical unmanaged network with all the ensuing disadvantages. I must say that at that time there was practically no experience with switches. Easier to say - none at all. Less than a month, as the provider was bought by another. This is where it all started.
The first thing that happens when two providers merge is the transfer of the subscriber base of the purchased provider (I will call it “B”) to the database of the buyer (let it be “A”). The task is solved quickly enough - we analyze both databases, we make the right requests, we drag the necessary information into the necessary billing. We stamp new connection instructions. Legal issues do not consider, it is not the task of the technical department. Everything, assemblers are provided with work.
The next task you faced was to document the network. It must be said that in most cases all the documentation is a book for installers with freehand diagrams - in which coupling how the fibers are welded. Everything. There is no electronic documentation. Since most of the equipment is installed uncontrollable - to understand at least in what port what is located is not possible. In general, this is a topic for a separate article, and probably not even one, but I want to briefly describe the mechanism that has been perfected for a couple of years, so I’ll not focus on the attention of readers.
In company "A", a system administrator works for a rather long time. Everything is as it should be - a beard is present, linux is everywhere and everywhere. Actually, with him we started our development. Initially, the plans were vague and personally I did not loom into anything clear and understandable. There were tasks - “to draw a network” and put under observation, as well as bring order to the information about subscribers, for the latter are unacceptable with the filled name field “Mishanya” or “The Right Person”.
As a monitoring system, we (company “B”) had the good old Friendly Pinger. Understandably, in the network of 10 pieces of hardware, Pinger will still fit, but not in the network of the provider, which has hundreds of devices. All the iron was transferred under the supervision of Zabbix'u. But the visual part was transferred to the map, for this we used:
On the map were the devices that were known. Connections were also drawn - which device was connected from which. In parallel with this, we registered the addresses of devices on the map.
The next step was to put in order the addresses of subscribers. The girls were given a clear indication that they also did not clearly follow - to write addresses completely and without grammatical errors. At the same time, the use of KLADR as an address database was asked. But when they mapped the addresses from the passports of subscribers with KLADR records, they decided that it was not worth it. Since the address field in the existing billing (UTM) was one text field, then it was impossible to track down what the girls entered. A couple of scripts, selection of all addresses from the database, removal of extra spaces, division of the address by comma and space showed us all the problem areas. All addresses in which abbreviations, errors and other problems were used were fixed. So we got a list of settlements, streets and houses. It would not be logical not to drop this information into the database. No sooner said than done. 3 tables, city, street and house were filled with information and now it was possible to implement a mechanism for selecting the address of the subscriber with the ability to supplement these tables with proxies. Complete with other tasks, it was decided to create a new interface for adding and editing subscribers. And to close the old access. The task took some time, parallel new address curves were popping up, all this was eliminated. And one fine day the problem with the crooked addresses disappeared. And there was another - now it was necessary to put in order the addresses of the equipment. We coped with this task rather quickly.
So, in the table of subscribers and the table of devices a new field appeared - house_id, by which we received the address right up to the house. And it was a serious step forward. It is worth saying that, in parallel with the development, the modernization of the network was going on - all the known copper perekidki were replaced with optics, all switches were replaced with switches of the same manufacturer. We chose D-Link and do not regret it.
In the process of working with maps, scripts for Zabbix were also written - if the device suddenly stopped working, a script was started that set a certain status for the device in the database, and the visual display of the device on the map accordingly changed. Everything is fine, Zabbix works, the directors looking at the map in the browser see what is happening on the network - loading channels, where there are problems with electricity, and so on (by the way, the "red" on the map once became one of the arguments for an uninterruptible power supply).
Meanwhile, we went further. There are subscribers with house_id, there are devices with house_id.
So:
Made by Checking ... Yeah, but what are our subscribers with house_id 337 - 7 people, but there is no such device ... Disorder, the task of installers is to find out what is installed in this house. Similarly, there is a switch there, unmanaged, with copper connected. Drew, corrected. Checked all such places, found new devices, mapped. Rode with the navigator - dorisovali missing home.
Problem. It is impossible to track whether the unmanaged switch works or not. We go in a different way - under the supervision of the port of a managed switch, from which the unmanaged is connected. Yeah, even so. Works. Zabbix reacts, even swears. And you can see on the map. The directors are satisfied. We, too.
Well, all devices are applied, new ones are immediately added to the database by the responsible admin. Quite a working scheme, but something is missing. Subscribers on the vpn-connection, constant problems with setting, installers spend time, call-center spends time explaining to subscribers how to reconfigure the connection on a freshly installed system. Not all routers support pptp. So, why not transfer the authorization to the switch ... At first the idea seems unreal, but the more we work on it, the clearer the solution becomes. What do we know about the subscriber? mac-address, on its basis ip-address specified in the billing is issued. With this ip-address, the subscriber goes to LAN and knocks on the vpn-server, where then the compliance of the ip-address, login and password is checked.
Against the background of all these events, we bring all the switches to the same configuration, we split the network into segments (the topic of a separate article), the tools for working with subscribers are growing, the system of ordering calls from subscribers, scripts for working with equipment, etc. is transferred there too. etc. On all switches, we enable sending events to the server, we begin to monitor the mac-addresses. We develop this direction. We determine that not all connections are correct - this switch is connected not from the 26th, but from the 27th port. But this subscriber mac pops up on several devices on subscriber ports, we write a network topology analysis script. The work is tedious, painstaking. At the output we get information - in which port of which device the subscriber is actually connected. We bring in a DB, we continue the analysis. Some subscribers pens registered the local ip-address, mac could not be traced. Calculated, with each such subscriber worked individually. They also closed this problem - someone changed the mac, someone put it on the machine. Everything. Beauty. We know which subscriber is connected. We know all the wilanas. Each port of the managed switch corresponds to one subscriber. We add additional fields to the forms - device and port selection. We start testing impb (ip-mac-port binding), some problems arise, contacting support for D-Link and solving together. We seek stability. We start. We perfect. We use.
The system has been operating for six months, during which time it has undergone some changes. Now it works like this: when a subscriber's device / port is changed, a new impb config is created for the switch, from which the subscriber jumps, and after binding to a new device / port, a new config is created for this device as well. The configs folder is under surveillance. If the config file has changed - it is automatically uploaded to the switch. In practice, it looks like this: the installer calls technical support, asks to bind the subscriber to such a port of such a device and calls the mac-address. Support staff drive in information, click save. Within a couple of seconds after that, the port is turned on and the impb entry is created, which stores the mac-address, ip-address (assigned to the subscriber) and port number. Thus, even knowing the mac-address of the subscriber will not be able to connect with him in any other place. And free ports are turned off. The scheme works, subscribers slowly translate. They like it.
That's basically it. We managed to get away from the authorization on the servers. And we feel the difference. The number of applications for repairs decreased significantly. The subscriber connection time was reduced by five minutes exactly (considering the synchronization time between the vpn-server and the billing). Also the problem with the compatibility of equipment was solved - now we do not limit subscribers in the choice of routers - use whatever you want. Specifically did not give any pieces of code, trying to combine in one article quite broad aspects and show the way we went. Hope that worked out.
Summarizing my story, I want to comment on why I am writing on Habr.
I'll tell you my story.
It so happened that once I got the position of head of the technical department in one small Internet provider. The company at that time experienced some technical problems, could not be found by a techie. At that moment I was just looking for a normal job - the year before I left the great and powerful AvtoVAZ plant (I worked in the Directorate for Information Systems) - I pressed the crisis, did not give me any money. After - a year of work as a teacher in a school (in parallel, he was registered as an individual entrepreneur), in general he turned as he could. And being in the fall in another city, from a friend I find out that a techie is urgently needed. He came to the interview without much hope, and a lot of desire, and as it turned out - in vain. After about a 10-minute conversation, the director asked to leave today. And I went out.
')
As it says, then all the saying was?
The network was built on variegated equipment, the owners definitely did not give preference to any iron producer. In fact, it was a typical unmanaged network with all the ensuing disadvantages. I must say that at that time there was practically no experience with switches. Easier to say - none at all. Less than a month, as the provider was bought by another. This is where it all started.
The first thing that happens when two providers merge is the transfer of the subscriber base of the purchased provider (I will call it “B”) to the database of the buyer (let it be “A”). The task is solved quickly enough - we analyze both databases, we make the right requests, we drag the necessary information into the necessary billing. We stamp new connection instructions. Legal issues do not consider, it is not the task of the technical department. Everything, assemblers are provided with work.
The next task you faced was to document the network. It must be said that in most cases all the documentation is a book for installers with freehand diagrams - in which coupling how the fibers are welded. Everything. There is no electronic documentation. Since most of the equipment is installed uncontrollable - to understand at least in what port what is located is not possible. In general, this is a topic for a separate article, and probably not even one, but I want to briefly describe the mechanism that has been perfected for a couple of years, so I’ll not focus on the attention of readers.
In company "A", a system administrator works for a rather long time. Everything is as it should be - a beard is present, linux is everywhere and everywhere. Actually, with him we started our development. Initially, the plans were vague and personally I did not loom into anything clear and understandable. There were tasks - “to draw a network” and put under observation, as well as bring order to the information about subscribers, for the latter are unacceptable with the filled name field “Mishanya” or “The Right Person”.
As a monitoring system, we (company “B”) had the good old Friendly Pinger. Understandably, in the network of 10 pieces of hardware, Pinger will still fit, but not in the network of the provider, which has hundreds of devices. All the iron was transferred under the supervision of Zabbix'u. But the visual part was transferred to the map, for this we used:
- Quantum GIS - geographic information system,
- Openstreetmap maps - substrate,
- DB postgreSQL + extension PostGIS - stores devices and communications.
On the map were the devices that were known. Connections were also drawn - which device was connected from which. In parallel with this, we registered the addresses of devices on the map.
The next step was to put in order the addresses of subscribers. The girls were given a clear indication that they also did not clearly follow - to write addresses completely and without grammatical errors. At the same time, the use of KLADR as an address database was asked. But when they mapped the addresses from the passports of subscribers with KLADR records, they decided that it was not worth it. Since the address field in the existing billing (UTM) was one text field, then it was impossible to track down what the girls entered. A couple of scripts, selection of all addresses from the database, removal of extra spaces, division of the address by comma and space showed us all the problem areas. All addresses in which abbreviations, errors and other problems were used were fixed. So we got a list of settlements, streets and houses. It would not be logical not to drop this information into the database. No sooner said than done. 3 tables, city, street and house were filled with information and now it was possible to implement a mechanism for selecting the address of the subscriber with the ability to supplement these tables with proxies. Complete with other tasks, it was decided to create a new interface for adding and editing subscribers. And to close the old access. The task took some time, parallel new address curves were popping up, all this was eliminated. And one fine day the problem with the crooked addresses disappeared. And there was another - now it was necessary to put in order the addresses of the equipment. We coped with this task rather quickly.
So, in the table of subscribers and the table of devices a new field appeared - house_id, by which we received the address right up to the house. And it was a serious step forward. It is worth saying that, in parallel with the development, the modernization of the network was going on - all the known copper perekidki were replaced with optics, all switches were replaced with switches of the same manufacturer. We chose D-Link and do not regret it.
In the process of working with maps, scripts for Zabbix were also written - if the device suddenly stopped working, a script was started that set a certain status for the device in the database, and the visual display of the device on the map accordingly changed. Everything is fine, Zabbix works, the directors looking at the map in the browser see what is happening on the network - loading channels, where there are problems with electricity, and so on (by the way, the "red" on the map once became one of the arguments for an uninterruptible power supply).
Meanwhile, we went further. There are subscribers with house_id, there are devices with house_id.
So:
- First: Foggy we can calculate how many subscribers are on each switch (if there are several devices in the house, we cannot yet);
- Second: For subscribers whose house_id matches the switch house_id, we can get the device coordinates in the database by query and show the subscriber’s house on the map accordingly.
Made by Checking ... Yeah, but what are our subscribers with house_id 337 - 7 people, but there is no such device ... Disorder, the task of installers is to find out what is installed in this house. Similarly, there is a switch there, unmanaged, with copper connected. Drew, corrected. Checked all such places, found new devices, mapped. Rode with the navigator - dorisovali missing home.
Problem. It is impossible to track whether the unmanaged switch works or not. We go in a different way - under the supervision of the port of a managed switch, from which the unmanaged is connected. Yeah, even so. Works. Zabbix reacts, even swears. And you can see on the map. The directors are satisfied. We, too.
Well, all devices are applied, new ones are immediately added to the database by the responsible admin. Quite a working scheme, but something is missing. Subscribers on the vpn-connection, constant problems with setting, installers spend time, call-center spends time explaining to subscribers how to reconfigure the connection on a freshly installed system. Not all routers support pptp. So, why not transfer the authorization to the switch ... At first the idea seems unreal, but the more we work on it, the clearer the solution becomes. What do we know about the subscriber? mac-address, on its basis ip-address specified in the billing is issued. With this ip-address, the subscriber goes to LAN and knocks on the vpn-server, where then the compliance of the ip-address, login and password is checked.
Against the background of all these events, we bring all the switches to the same configuration, we split the network into segments (the topic of a separate article), the tools for working with subscribers are growing, the system of ordering calls from subscribers, scripts for working with equipment, etc. is transferred there too. etc. On all switches, we enable sending events to the server, we begin to monitor the mac-addresses. We develop this direction. We determine that not all connections are correct - this switch is connected not from the 26th, but from the 27th port. But this subscriber mac pops up on several devices on subscriber ports, we write a network topology analysis script. The work is tedious, painstaking. At the output we get information - in which port of which device the subscriber is actually connected. We bring in a DB, we continue the analysis. Some subscribers pens registered the local ip-address, mac could not be traced. Calculated, with each such subscriber worked individually. They also closed this problem - someone changed the mac, someone put it on the machine. Everything. Beauty. We know which subscriber is connected. We know all the wilanas. Each port of the managed switch corresponds to one subscriber. We add additional fields to the forms - device and port selection. We start testing impb (ip-mac-port binding), some problems arise, contacting support for D-Link and solving together. We seek stability. We start. We perfect. We use.
The system has been operating for six months, during which time it has undergone some changes. Now it works like this: when a subscriber's device / port is changed, a new impb config is created for the switch, from which the subscriber jumps, and after binding to a new device / port, a new config is created for this device as well. The configs folder is under surveillance. If the config file has changed - it is automatically uploaded to the switch. In practice, it looks like this: the installer calls technical support, asks to bind the subscriber to such a port of such a device and calls the mac-address. Support staff drive in information, click save. Within a couple of seconds after that, the port is turned on and the impb entry is created, which stores the mac-address, ip-address (assigned to the subscriber) and port number. Thus, even knowing the mac-address of the subscriber will not be able to connect with him in any other place. And free ports are turned off. The scheme works, subscribers slowly translate. They like it.
That's basically it. We managed to get away from the authorization on the servers. And we feel the difference. The number of applications for repairs decreased significantly. The subscriber connection time was reduced by five minutes exactly (considering the synchronization time between the vpn-server and the billing). Also the problem with the compatibility of equipment was solved - now we do not limit subscribers in the choice of routers - use whatever you want. Specifically did not give any pieces of code, trying to combine in one article quite broad aspects and show the way we went. Hope that worked out.
Summarizing my story, I want to comment on why I am writing on Habr.
- The first. I would like to share the insights and ideas that have been implemented in our country. Perhaps someone will save a lot of time by reading this article.
- The second. I love the company I work for and I really like what I do. On the other hand, knowing myself, I understand that soon, when everything is finished, I can’t sit and sit on my pants, I have to move on. And most likely, the next job will not be an Internet provider. Therefore, I would like to involve like-minded people in the development. We are currently developing a network documenting tool (couplings, optics). Based on what has already been done - there is not much work left. The system will allow to document not only the optics, but let's say the pipeline, or something similar. Perhaps by common efforts we will get a decent and necessary open source project.
- Third. Well and of course full uchetka on Habré. Why not?
Source: https://habr.com/ru/post/162561/
All Articles