Prior to launching our new product called ‘IPoE Portal’ we had come to the conclusion that highlighted the need for automation when switching to IPoE. Here’s our key takeaways for those who are looking forward to do it and would like to do it right.

Why is it still here

Switching from PPP to IPoE turns out to be a real pain for telecoms with Ethernet networks. Though IPoE is much more user-friendly as it offers easier sign up, no need to remember passwords and no connection breaks.

Half of our client base have not switched yet and there are far more companies out there that procrastinate about it. There are reasons to put things off and it’s mostly about costs:

• new equipment — network switches that support DHCP Option 82;
• new cable infrastructure — cable and port inventory system;
• new software — MAC addresses storage and authentication system.

IPoE requires you to keep MAC addresses up to date and replace broken switches with cable/port mapping in mind. Mixing up ports causes connection breaks and clients still have to get support for every new MAC address. That’s exactly what slows telecoms down but there’s a way to make the whole process easier.

Solution

In order to map a subscriber to his/her network data (MAC address, switch address and port number) you have to hand it over to authentication portal. The portal requests subscriber’s login information and adds new requisites into the authentication DB.

We have learned a couple of lessons about it from building our own IPoE solution at Hydra. You’re going to need:

• Authentication DB that stores data about switches and ports, subscribers’ devices and their owners, mapping data necessary for authentication.
• A DB for subscribers’ network data (requisites) that’s handled by DHCP Option 82.
• Network data (requisites) collection process involving DHCP server that adds it to the requisites DB together with subscribers’ IPs.
• BRAS setup with services for subscribers with wrong ports (switch replacement situation), wrong MAC addresses with working ports (new devices), wrong MACs with wrong ports (new subscribers).

Some companies decide to go ports-only and free subscribers of the need to manually signup new devices. This move complicates switch replacements as the MAC address is the only thing that allows to map authentication data. On the other hand, adding MAC addresses to the process prevents possible network abuse.

Here we have 5 common situations with IPoE that you’re going to learn how to deal with.

1. Migration from PPPLooks complicated as you have to keep track of ports-to-subscribers mapping and store it in your DB. In fact, there’s no need to setup each and every switch, so all you have to do is use our situation #5 and add redirect attribute in your authentication DB. This way subscribers with no MAC address mapping go to the portal.This option makes it possible to update network map with minimum hassle for clients. It should be rolled out step by step in order to distribute possible workload for your support teams.
2. New subscriber setupGetting started with IPoE network is not always easy for new subscribers and operators as well. Mapping MAC address and finding free ports are two tricky tasks and some large companies even assign special employees on this task. This problem involves extra costs and can be solved with automation.Some telecoms signup new subscribers in the same day as they arrive or do it in the range of 24 hours. It requires network installers to have necessary equipment and mobile apps that serves them requests. The authentication portal does the rest of the work and maps subscribers to appropriate switches with MAC addresses stored in authentication DB.
3. New devices setupEven solid networks with integrated IPoE suffer from the problem of new customer devices setup. New Wi-Fi router means new MAC address and unsuccessful authentication resulting in customer support requests and possible churn.There’s a way to handle this situation by redirecting subscribers to the portal where they sign in and confirm necessary updates. Next, the authentication DB is updated with new MAC addresses. This move cuts about 1,5k monthly support requests per 100k subscribers.
4. Access switch replacementClassic IPoE network requires ports mapping when replacing access switches so that it remains the same and subscribers stay connected. The portal does all the dirty work with its authentication DB being updated as soon as subscribers log in from the wrong port and confirm necessary updates.This way automation cuts costs and network installers are free to use any ports when replacing switches and finally get rid of port mapping print outs.
5. Subscribers migrationThe portal solves the problem if you’d like to allow migration from one spot to another. The algorithm is similar to access switch replacement case.

Hydra’s implementation

Hydra billing system serves as the authentication DB and stores necessary information about switches, ports, customers’ devices and MAC addresses. The portal is just a couple of HTML pages with built in forms that trigger HTTP POST requests.

Our ESB (Enterprise Service Bus) app runs as the server with integrated network data DB, authentication DB and RADIUS agent. It handles all the situations listed above with special presets available.

Automation with Hydra makes IPoE integration a no-brainer and cuts potential costs related to maintenance.