Nuage Networks tacks SDN to underlay
Re-attaching the control plane to the data plane, virtually
Software defined network (SDN) visibility is the new black, it seems: Nuage Networks has become the second vendor this week to play connect-the-dots between the physical layer and the overlay.
Like Big Switch Networks, which on Tuesday made its VMware NSX visibility play for Big Fabric Controller (BFC), Nuage reckons troubleshooting has become a pain-point for those operating virtual networks over the top of IP and Ethernet connections.
[So that's what's wrong with separating the control plane from the data plane? – El Reg]
If a virtual machine can't talk to its storage – or another VM, or the outside world, for that matter – it's hard to tell whether the SNAFU is the responsibility of a switch configuration, router parameters, an IP address collision, or something up at the application layer.
Unlike BFC, Nuage is looking at a bigger service provider picture: it's trying to separate SDN northbound-southbound visibility from particular hardware or operating systems. As well as VMware, the Nuage solution works with Cloudstack and OpenStack controllers.
In its canned statement the company says its Virtualised Services Assurance Platform (VSAP) works with network kit that supports standard protocols like OSPF (open shortest path first), BGP (border gateway protocol), ISIS (intermediate system to intermediate system) or even the venerable SNMP (Simple Network Management Protocol).
Those protocols let VSAP discover and model the physical network topology against the virtual for service correlation, fault analysis and remediation.
For example, a dead switch port (raising an SNMP alarm) would be associated with routes, VLANs, the virtual SDN topology, VMs, and the applications they host.
While similar correlations are possible in (for example) the Cisco ACI world, that only works on The Borg's kit, and Nuage reckons that doesn't reach up to applications.
Nuage's VSAP architecture
Demonstrated at the Open Networking User Group's Spring 2015 confab at Columbia University, VSAP starts by sniffing the Layer 3 network topology. To do this, it acts as a VM-based IGP (interior gateway protocol) listener to collect route advertisements.
Either SNMP calls or vendor CLI calls are used to construct the Layer 2 topology – as much as is possible.
The virtual networks are then reconstructed by querying the vSwitch (also collecting VM-to-virtual network mapping), and correlated with the physical networks.
VSAP also lets admins model network changes ahead of time, much like old physical network management systems do, to understand the impact of planned installations or upgrades. ®