We are entering a new era of software defined communications

What now feels like a life time ago back in the dim and distant past ,OK - not so dim and distant 1980s, I was a young apprentice engineer with my training and interests firmly focused on Hardware (micro electronics more specifically). In 1987 I made the bold step towards software engineering as a choice, since it seemed, back then, that software was the way forwards to creativity and new solutions for communications. Having "converted" to software engineering by way of a degree in Computer Science at Aberystwyth University, I then continued in that vain becoming a professional software engineer. I still didn't forget the electronics that got me started, and this combined with software engineering put this to good use as a telecommunications engineer. Moving through the heady days of Nortel Passport Frame Relay Switches, Cisco AGS and MGS routers and Cabletron hubs.

Then the Internet happened.......

SDN
For the telecoms engineers out there (like me), in my humble opinion (IMHO) SDN is the networking equivalent of softswitches? The OpenFlow API is what MEGACO/SIGTRAN is to soft-switching and the so-called Orchestration layer the Stored Program Control Logic from the switch fabric and routing fabric. The media gateway is the Hardware forwarding platform (L2 switch fabric being physical of logical vSwitch, Microsoft Network Virtualisation and Virtual Subnet Identifiers), not to mention MPLS enabled VPLS and the rest of the MPLS "family".

NFV
And now in the telecoms field we're getting all excited about Network Function Virtualisation (NFV - http://www.etsi.org/technologies-clusters/technologies/nfv) . This is really about extending the Virtualisation platforms/techniques like those provided by VMWare ESX and Microsoft HyperV into the telecoms space and placing the Functional elements of the NGN network on these virtualisation platforms. As the ETSI White paper states:

"leveraging standard IT virtualization technology to consolidate many network equipment types onto industry standard, high-volume servers, switches and storage."

This allows the economies of scale that the enterprise networks are gaining through "cloud compute" to the telco space, by implementing these traditionally custom hardware based elements (such as media gateways, firewalls, SBCs, Routers, CSCFs) in standard (commodity Servers) architecture servers and a hypervisor layer, utilising the same virtualisation tools which enable flexibility of deployment of these elements in more standard environment, enabling features such as live migration of network functions under failure, multiple instances of a network function on the same hardware elements, and more interestingly (from my perspective) the ability to create multiple instances belonging to different customers (or even carriers) on the same hardware platforms.

Time to re-write the architecture rule book.

Having fun with VRRP and Clustering on Vyatta

Having had some time post teaching to get my head down to some serious network building, I've been investigating building high resilience in to my hosted call centre designs.

I base my design as much as possible on Open Source technologies, since it gives me and the people I work for the biggest bang per buck for the technology deployments. There's been discussion on a number of blocks about Vyatta's claims around their router performance vs. Cisco and even some flaming of both parties - none of that here!


Vyatta has a place in any network. Why? Flexibility (well and of course cost), by utilising open source, standard hardware and pre-integrated hardware like Sangoma cards, you have a very versatile routing capability. Plus its easy to extend to to anything you can imagine. For example - for building redundancy across a number of routers to cope with failures VRRP has been developed in the IETF (based on Cisco HSRP), but failing over things like IPSec tunnels can be a bit more fun, so use clustering instead. HA cluster is already well implemented under Linux, but combining in a routing platform is genius, especially when its easy to configure.

We've been building routers and firewalls using Linux for a while (IP Tables and the Kernel can be a pretty slick firewall if you're happy to roll-your-own, and to be fair there are a few ways of doing it including other open source solutions like Smoothwall. Horses for course - Yes I like Smoothwall too!

The other main bonus of a Linux based Firewall Router is virtualisation - with huge pressure on data centres both from the power consumption and cost plus the greening up of IT, virtualising the resources of service and your routing/firewall infrastructure is very compelling. No a don't think a Vyatta pizza box could replace the layer 3 48Gpbs non-blocking switch right now - but if I'm virtualising my data centre - where's the switch? Actually there are fewer switch ports too, because each server could be running many Operating System instances with "software" ethernet bus bridged to the physical NICs on the device. We're in a position to team NICs in to an aggregate LAN connection of say 8 Gbps with 8 NICs in a team, and handle massive amounts of compute power in a single redundant chassis.

So just how easy does something like Vyatta make say VRRP:
interfaces {
ethernet eth0 {
address 172.16.0.252/24
hw-id 00:15:c5:fa:3c:1a
vrrp {
vrrp-group 100 {
priority 200
sync-group hotswap
virtual-address 172.16.0.254
}
}
}
ethernet eth1 {
address 192.168.25.252/24
hw-id 00:15:c5:fa:3c:1b
vrrp {
vrrp-group 200 {
priority 200
sync-group hotswap
virtual-address 192.168.25.254
}
}
}
loopback lo {
}
}

The configuration above creates a VRRP enabled interface (the master router), which will swap over to a slave in a pair (or more you can have more than two routers) if either of the Interfaces fail. Sweet.

So putting that kind of thing to good use - I can put a NIC from each router onto a separate switch if the switch fails connecting the master, then the backup will swing into action within a couple of seconds. (TCP connections won't see the joint). Now depending on how the servers connected to the switches are configured, combine NIC teaming on the servers, and you have a highly available solution.

Combine allow that with the flexibility of IPTables and an easy configuration you've a lot of bang for buck!