In Ethernet networks IPoE technology is more convenient for subscribers than usual PPP. It facilitates signups, users don’t have to memorize passwords, if the signal is lost you are still on the line.
Yet migration to new technology often bothers providers — e.g, among our clients not more than a half have migrated to it. Today we will speak about why it happens and tell you how Hydra billing helps facilitate the process.
When migrating to IPoE technology providers usually face a lot of overhead problems:
But expenses don’t stop after the acceptance of IPoE — it’s necessary to provide support of subscriber binding and MAC addresses in its current condition. Being the case the work on changing the burnt down switch which used to be a routine action now turns into exciting process similar to walking through the mine field.
Subscribers also get some issues — at least every time they change a MAC address they have to call provider’s service support to have new settings introduced. Otherwise, you will not get the connection.
Taking everything mentioned above into consideration it becomes clear why a lot of providers are not eager to migrate to the new technology. Nevertheless, there are methods to make migration to IPoE easier.
One of them is to match the subscriber and their network — MAC address, access level switch address and the number of switch port — by redirecting “unknown” subscriber to the verification portal.
Authentication portal is a web form which a subscriber has to fill in with the login and password. If they are correct then new details are saved into the database for further subscriber verification.
When we started working on ways to automatize IPoE-networks with Hydra, we soon realized that a simple idea requires a more complicated solution.
First of all, there must be authentication DB to store all the current information:
Secondly, there must be a separate database to store subscriber’s network details which a switch transmits to DHCP Option 82.
Thirdly, network credentials collection must be adjusted. They come from a switch to DHCP server, which must store them in their network credentials database along with the given IP address.
Fourthly, BRAS with set services is required. One of the services — for unknown subscribers — must be given to everyone who:
When the service is on, all HTTP requests are redirected to the authentication portal. When the user fills in their login and password, the final set of subscriber’s details is retrieved from the network details database by IP address. It is saved in authentication DB as current.
There comes a question of MAC addresses binding. A lot of providers believe that one should work only with port binding. On the one hand, it simplifies the subscriber’s life — they can connect any device without extra passwords. On the other hand, a switch replacement and moving equipment (we will speak about it later on) becomes more difficult as the binding becomes the only way of subscriber identification and changing it you cannot trace what happened to it. Besides, in several network configurations which provide access with no attachment to MAC address there might be excessive use by subscribers.
Let’s look at some typical scenarios of using IPoE, possible difficulties and ways to cope with them.
At first everything seems very complicated: it’s necessary to find subscriber’s switch port and save it in the database. The good news is that migration can be organized gradually with the help of the portal and little change/update of the software. In authentication DB you can simply add a redirection flag to a switch. All subscribers with yet no current link and MAC address, logged in from the switch with replacement flag on, will be redirected to the portal.
As a result, migration is a single operation which gives minimum trouble to the subscriber and at the same time updates the network map. It can and should be done gradually to “offload” service support and work out the redirection process.
Introducing subscribers to providers in IPoE network doesn’t always go well. Finding out a MAC address in advance is problematic and securing free ports in a switch manually is extremely difficult. Indeed, we’ve come across large providers who have special employees who look for free ports. We have failed to find out how this position is called in a payroll, though.
This way of setting up connection leads to extra expenses, moreover — there is no sense in it, as the whole process can be fully automated. With the right business processes new subscribers are connected the next day or even the day the request is sent. For this an installer must always have a set of equipment, requests may come via phone and initial binding to the switch and saving MAC addresses are automated by the authentication portal.
Even in lots of large networks which use IPoE there often arises a problem of subscribers devices replacement. For instance, if a client buys a new WiFi router, he may face the problem of no access to the net — the reason of which is MAC address change. Eventually, it causes negative reaction and calls to provider’s service support or even leaving to a competitor.
The problem may be solved if during hardware replacement/re-equipment subscribers are redirected to the authentication portal where they can confirm their data — after this the MAC address of the new equipment is updated in the authentication DB.
This approach allow to decrease support requests. To our knowledge, in a network of one hundred thousand subscribers the economy may be up to 1.5 thousand calls a month.
In a classic IPoE net when changing a switch it is very important to have port bindings untouched, otherwise users will lose access to the net.
In this case the portal helps as well. In the authentication DB there is a replacement flag for the switch — it is manually set by providers service support. All subscribers logging in using such a switch via “other” port must confirm their data on the portal. After this their port binding is updated.
Thus, printing out maps binding subscribers to ports is becoming history. In big networks with tens of thousands of switches automation provides a way for significant economy.
The case when providers allow subscribers to migrate in the network happens less frequent than the previous one. Nevertheless, it can happen and using the portal it can be permitted with no extra costs. The algorithm is similar to the one with replacing the switch, but unlike it the portal allows to bind subscribers to more than one switch.
Automation helps to solve the problem of IPoE integration. We use Hydra billing as an authentication DB: the system can store all necessary data on switches and their ports, subscriber’s equipment and its MAC addresses.
IPoE portal itself consists of several HTML pages with built-in forms, which send POST requests to the server.
ESB application developed by us is used as the server. The server is integrated with network details DB, authentication DB and RADIUS agent. Its business logic processes all the cases mentioned above. Each of them is set in a configuration server file. Some of the cases (like a switch replacement) can be managed in a transparent mode with no authentication from the part of a subscriber.
