NOW YOU SEE IT, NOW YOU DON'T

NOW YOU SEE IT, NOW YOU DON’T SESSION VISIBILITY IN A VIRTUALIZED WORLD

INTRODUCTION MIGRATING UP THE TECHNOLOGY CHAIN DEFINING VIRTUALIZED TRAFFIC TAPS FOR TAPS SESSION VISIBILITY CHALLENGES WITH VIRTUALIZATION MAKING SENSE OF THE NOISE CONCLUSIONS METASWITCH SERVICE ASSURANCE SERVER

WWW.METASWITCH.COM

© 2015 Metaswitch Networks. All Rights Reserved.

3 3 3 4 4 6 7 8

Page 2 of 8

INTRODUCTION A GREAT NETWORK EXPERIENCE CAN ONLY HAPPEN WHEN NETWORK OPERATORS CAN EASILY UNDERSTAND WHAT’S GOING ON IN THE NETWORK. Network operators must be able to diagnose and troubleshoot problems as they arise in the network. When there are problems, they need to be able to get to the heart of them quickly and efficiently. They need to reliably determine its root cause and address it, fast. Every second of delay could be hundreds of annoyed customers or thousands of dollars of lost revenue as peers route their calls elsewhere, and perhaps don’t come back. As network operators leverage Network Functions Virtualization (NFV) and Software Defined Networking (SDN) to rapidly roll out new services, increase service flexibility, reduce capital and operational expenditures, and become more agile, Service Assurance (SA) has struggled to keep pace. Part of SA’s struggle stems from the challenge of maintaining continuous SIP session visibility both within a virtual infrastructure as well as across hybrid physical/virtual environments.

MIGRATING UP THE TECHNOLOGY CHAIN NFV IS A NEW TECHNOLOGY MAKING INROADS INTO TELECOMMUNICATION INFRASTRUCTURE FASTER THAN ANY OTHER TECHNOLOGY, PAST OR PRESENT. IN ADDITION TO THE MULTIPLE BENEFITS, NFV ALSO CREATES NEW CHALLENGES, SUCH AS, THE ABILITY TO COMPREHENSIVELY MONITOR SESSION TRAFFIC.

In the physical world, diagnosing and troubleshooting problems as they arise in the network has typically required specialized network probes, protocol analyzers and reporting tools to capture and trace service flows. The age old approach to scaling session visibility alongside a growing network has been simple: add more network management tools, application performance management tools and security appliances. But in the virtualized world, these old paradigms no longer apply. The difficulty inherent with Virtualized Network Functions (VNFs) is that carriers have no way of knowing where to insert a probe in the network – potentially there may not even be a place to insert one! That makes it difficult to secure the network traffic, diagnose problems, ensure upstream and downstream SLA compliance, and analyze performance. Excellent SA demands that every session and service flow that the network processes be captured and recorded for analysis and reporting regardless of whether the network element is running as a VNF or as a physical device. Ideally, network operators should also be able to see detailed SIP flows for external and internal interfaces, along with the policy and routing decisions being made inside the device. But as things stand in virtualized networks today, there is a session visibility gap – dark corners where the unknown occurs.

DEFINING VIRTUALIZED TRAFFIC IN THE VIRTUALIZED WORLD, TRAFFIC IS DEFINED AT A MORE GRANULAR LEVEL THAN FROM A DATACENTER PERSPECTIVE. The virtualized world looks at data from the perspective of the host system. Therefore, North – South network traffic is defined as data that enters and exits the physical host machine. Could be a single server, could be a blade server with multiple blades each hosting multiple VNFs.

WWW.METASWITCH.COM


Page 3 of 8

East – West network traffic is defined as data that traverses multiple VNFs within the same physical host machine. Again, it could be traffic between VNFs within single server, within a single blade, or among and between multiple blades within a single physical blade server).

TAPS FOR TAPS WITH NORMAL NETWORK TOPOLOGY, MONITORING SESSION TRAFFIC WAS ALMOST COMICALLY EASY: TAP INTO THE DATA STREAM USING A TRADITIONAL (PHYSICAL) TAP. As the data exits the appliance, it is easily accessible as it travels throughout the rest of the physical network. But taps can collect only that portion of the information exchange at the physical egress points of each rack. In a virtual world, however, this model breaks down. First, the purpose-built probes that exist today require proprietary and expensive custom silicon. In all likelihood they cannot be easily ported into a software-only environment able to function inside a VM. Therefore, there are few – if any – network monitoring systems in place for virtual equipment. Second, the Management and Orchestration (MANO) layer can move VNFs around the datacenter based on considerations like capacity, demand, disaster recovery, and maintenance. Although taps can collect the data, they cannot reconcile SIP sessions that have spun up and down, thereby removing the ability to understand what happened to and during that particular session. And most certainly, any pre-existing monitoring solution utilizing those taps is absolutely missing the function that stitches those disparate session portions into one coherent whole. Therefore, relying solely on taps in a virtualized network will not provide the information needed to evaluate network performance and address customer issues.

SESSION VISIBILITY CHALLENGES WITH VIRTUALIZATION SESSION VISIBILITY SUPPORT FOR VIRTUALIZATION IS ESSENTIAL BECAUSE WITHOUT THE ABILITY TO MIGRATE SIP SESSION MONITORING IN LOCKSTEP WITH THE VMS/VNFS, REGAINING VISIBILITY WOULD REQUIRE MANUAL RECONCILIATION; A NIGHTMARE TO MANAGE IN AGILE VIRTUAL INFRASTRUCTURES. Network operators need a solution that: • • •

can follow the VM/VNF is already in place once the VM/VNF moves or is spun up provides the exact same visibility no matter where that VM/VNF appears

WWW.METASWITCH.COM


Page 4 of 8

From a monitoring perspective, north–south traffic could continue to be monitored using physical probes, as this data does in fact traverse a physical switch or network. Monitoring east–west traffic is a major area where traditional monitoring methods fail. East – West traffic never traverses a physical switch or network. Traffic passes between the VM, vNIC and vSwitch fabric and back out again. Virtual probes are hamstrung by the throughput limitations of today’s vSwitch; the limited resources of the already taxed vSwitch will be negatively impacted by the virtual probe’s overhead demands. Monitoring blade server traffic is a second major area where traditional monitoring methods fail. Bringing blade servers into the mix can further reduces session visibility, as traffic within blades and between blade servers may not traverse the physical network either. Instead, this traffic rides a midplane, with traffic between the blades in the same rack running on a dedicated backplane. Unless specific blade server tools have been deployed, both the midplane and the backplane data traffic are invisible to the physical network and its attached tools. As discussed above, monitoring traffic after actions undertaken by the MANO layer is a third major area where traditional monitoring methods fail. Therefore, the underlying network must be transparent to service personnel, and service oriented views of management, orchestration, monitoring and service assurance are absolutely required to properly diagnose and expediently resolve issues as they arise in the network. Let’s weave some examples here to drive home the difficulty of maintaining continuous SIP Session visibility in a virtualized environment: •

Consider a distributed SBC deployment. The signaling VNF and media VNF run independently on a blade server. The traffic between the signaling VNFs and media VNFs riding the mid- and backplanes of the blade host might go completely uncaptured and unmonitored.

In these next three examples, physical taps can capture traffic, but not stitch the information together into a cohesive whole. • •

•

Consider a different distributed SBC deployment. The signaling VNF and the media VNF reside on separate physical racks within the same datacenter. Consider a MANO layer that auto-scales the network capacity on demand to adjust to the dynamic nature of traffic. VNFs are spun up and down as demand waxes and wanes.

Consider the MANO layers reacting to a Disaster Recovery scenario. VNFs are moved from one physical host to another in response to host machine or datacenter outages.

WWW.METASWITCH.COM


Page 5 of 8

MAKING SENSE OF THE NOISE SO WHERE DOES THIS LEAVE US? It is clear that the migration to NFV will not occur overnight. Network operators must expect that both the physical and the virtual infrastructures will exist side by side for the foreseeable future. Therefore, session visibility within a hybrid network will have to be done in a seamless and disruption-free manner. Network operators need network diagnostics and troubleshooting tools capable of operating in both an NFV environment and in the physical realm today as SIP services are steadily increasing in complexity as a result of more sophisticated VoIP service offerings and overlaying multimedia services.

Network operators should consider selecting VNF developers that understand virtualized environments. Those that do equip their VNFs natively with always-on streaming analytics. Those that do offer a Service Assurance Server, e.g., an offboard centralized analytics engine. An engine that accepts streaming analytics simultaneously from virtualized and physical elements, regardless of vendor. An engine that integrates diagnostic and troubleshooting tools with a powerful session analyzer capable of •

•

•

•

The collection of call diagnostics from both VNFs and their physical brethren aggregating o Signaling o Routing o MOS scores o QOS metrics o SDP data The capture of all calls and network element activity, including o VNF routing decisions o Encrypted traffic Stitching together SIP sessions to display o Call flows, traces, protocol flows and full SIP decode details o Signaling, trunking, policies and routing rules o SIP message flow details (visible even if sessions are encrypted!) o Voice Quality Metric (VQM) statistics captured from RTCP traffic Comprehensive searches on a wide variety of parameters including Time of Day, Error Codes, Call/Calling/Called IDs, SIP URIs, etc.

WWW.METASWITCH.COM


Page 6 of 8

This centralized analytics engine leverages the information provided to it by the network elements to position network operators to conduct precise root-cause detection, provide degradation and/or outage notification to service personnel, stitch together the distributed architecture and elastically created and terminated VNF feeds, and determine why VNFs made the routing decisions they made.

CONCLUSIONS THE TIME IS NOW FOR NETWORK OPERATORS TO EQUIP THEMSELVES WITH TOOLS CAPABLE OF MONITORING VIRTUALIZED ENVIRONMENTS. A Service Assurance Server is needed to examine, trace and trouble-shoot SIP message flows in their networks, along with the capability to drill down into a single call flow, regardless of whether the call traverses a physical and/or virtual host. A Service Assurance Server capable of monitoring virtualized environments is absolutely required to properly diagnose and monitor whether: • •

Network operators are delivering on SLAs to their customers, and Suppliers to network operators are delivering on SLA obligations.

Beyond that, when network operators’ engineering staffs are provided a Service Assurance Server capable of monitoring virtualized environments, they will quickly and easily be able to: • • • •

Verify that the optimum network routing is utilized Check the effectiveness of the SIP and SDP manipulation activities Ascertain whether trunks are assigned correctly Ensure that LCR (Least Cost Routing) solution is working

WWW.METASWITCH.COM


Page 7 of 8

• •

Seamlessly stitch sessions together after VNF moves/adds Determine whether VNFs are located optimally

regardless of whether the call traverses a physical and/or virtual host. And a Service Assurance Server capable of monitoring virtualized environments equipped with powerful analytics and rapid access to full protocol decodes, enables network operators to dramatically accelerate network deployment while simultaneously minimize the time required to detect and resolve network problems and outages. Selecting a Service Assurance Server capable of integrating feeds from any environment enables network operators to save money by largely eliminating the need for, and the complexity of, external monitoring devices. Operational costs are thereby reduced, and subscriber satisfaction is enhanced through rapid trouble-shooting and -resolution. Demand network surveillance tools capable of monitoring virtualized environments. Without the ability to monitor virtualized environments, network operators will have limited to no visibility into the virtual segment of their network, and must resign themselves to the consequences of the session visibility gap – and those dark corners where the unknown occurs.

METASWITCH SERVICE ASSURANCE SERVER METASWITCH’S SERVICE ASSURANCE SERVER (SAS) IS A DATA REPOSITORY OF ALL THE NETWORK INFORMATION PROVIDED TO IT BY ANY NETWORK DEVICE IN YOUR NETWORK. AND ALL METASWITCH VNFS ARE NATIVELY COMPATIBLE WITH SAS. Things like SIP messages and SDP messages are all sent to and stored on SAS for retrieval and review at any time. And the routing decisions made by the devices, if sent, are also captured and stored. Multiple devices all feeding data back to the centralized SAS storage server. It’s always on and it stores data until its capacity threshold. SAS aids your network admins to find and diagnose problems in the network. SAS allows for a wide variety of search parameters to narrow the focus, and provides an intuitive graphical display of information to analyze the call flows and pinpoint issues. At any time your network admins can call up and search on any number of parameters to troubleshoot and determine if there is something not right in the network. No longer are you required to set up test calls or probes to determine what went on in the network. The information to reconstruct an issue is now at your fingertips. Furthermore, SAS provides unprecedented insight into why routing decisions were made giving you pinpoint accuracy in ferreting out configuration errors. It provides protocol details to highlight mismatches and fix customer service issues. You can find out why a device did what it did. Lastly, SAS itself can also be virtualized and scaled to match any network’s requirements. So demand Metaswitch’s Service Assurance Server (SAS) for your network today.

WWW.METASWITCH.COM


Page 8 of 8