Over the past weeks we have discussed different types of services that Inango can offer to Service Providers with a view to enhancing their offerings for residential customers. Using our Virtual Services Launcher, these services are deployed at the Providers’ data centers, yet use the in-home router to work. It is a perfect combination of leveraging an existing infra-structure in a very cost-effective, nimble and extensible way.

Today, I’d like to talk with you about a product we have developed for small business (SMB) customers. We call it pseudoLAN.

We were approached by several of our customers with a view to enabling Carrier-Class services such as MPLS pseudo-wire over low-cost, off-the-shelf routers (that many SMB’s use). Specifically, the ability to support multi-site offices, where all of the locations function together as in a single layer-2 network. Or the ability to offer remote access to people that wish to work from home (or on-the-road).

There are, of course, products for these things – but they come at a high cost, often requiring dedicated servers and sometimes even cooperation between different Providers (like a pseudo-wire crossing different SP’s). For larger corporations this is fine, but for many smaller businesses, this is not cost effective.

Our response was to develop a pseudoLAN service. It is a full layer-2 connectivity service that can combine any number of locations into a single network. Packaged into the same service is a VPN service for remote access from individual computers. For multi-site pseudoLAN, each site requires a VS-Client (in the router or in a dedicated RaspberryPi-like device). But for VPN, no client other than a standard Microsoft VPN Client is necessary. No on-site servers, or other dedicated equipment is needed.
 

 
What this means is that customers with low-cost routers can benefit from Carrier-Class services at a small fraction of the price.

Implementing the service presented a few interesting challenges. If each location is connected to the same “LAN” you clearly can’t have a DHCP Server at each site. So the pseudoLAN service includes a DHCP Server as a service, including fail-handling in case connectivity to the service is lost (i.e. a site will still be able to work).

But a deeper issue was with performance, Our Launcher platform (at the data center) connects to the SMB routers via a layer-2 tunnel. Packets are forwarded across the pseudoLAN via the Launcher. Based on ONOS, which is implemented in Java, our initial performance was woeful. So the Launcher was augmented with a forwarding “booster” – a software switch (that is optionally integrated with dpdk) that off-loads the forwarding functions from ONOS. It all happens transparently, but the results are dramatic.

This is not the place for a full in-depth discussion but we’re happy to disclose more (send us an email). But the result is a real layer-2 connected network either across multiple sites or for remote users at a fraction of what most Providers currently offer.