Site-to-Site DMVPN Per-Tunnel QoS Monitoring with Flow
LiveAction has had a long heritage of the Wide Area Network (WAN). Back in 2006, we were tasked to simplify QoS (Quality of Service) for less-experienced operators, making “on-the-fly” changes to their WAN routers. LiveAction started off with QoS control and monitoring and then added NetFlow collection capabilities to provide greater visibility for individual conversations on the network.
Dynamic Multipoint Virtual Private Networks (DMVPN) has had a great impact on simplifying enterprise WAN deployments, allowing for site-to-site communication without having to statically configure every branch instance at the hub. It’s a smart design, enabling sites to communicate dynamically via multipoint tunneling. QoS in DMVPN environments is very important, since the headend, hub site typically has a lot of bandwidth, while the remote branches may have comparatively, much less. As a result, Per-Tunnel QoS is the key to ensuring that the hub doesn’t overrun traffic to any given site.
In this blog, I’ll discuss how network engineers can use NetFlow to monitor DMVPN Per-Tunnel QoS. To ensure that LiveAction’s solution, LiveNX™, can accurately report on the site-to-site data, one must set up the appropriate semantic tagging in the application. For more insights on this topic, you can also check out Aaron Kagawa’s blog: Simplifying the Network with Semantic Tagging.
Consider the following network topology managed by LiveNX. The head-end, hub site is San Jose and the two remote branches are located in Los Angeles and New York. The branches have a capacity of 10Mbps on the “INET” service provider. Per-Tunnel QoS is used at the hub WAN router connected to the “INET” service provider to shape and queue traffic heading to the branches.
In the QoS interface view for Tunnel 100, shown below, notice that LiveNX charts the outbound applications, but the user may not get QoS data on the bottom. (Note: IOS and IOS-XE only recently provided SNMP-based Per-Tunnel QoS monitoring). We added in the capability to pivot from the QoS interface view to a NetFlow Report.
LiveNX will run the Application NetFlow Report and auto set the corresponding device and interface parameters in the outbound direction, corresponding with the previously shown QoS interface view. A powerful feature of LiveNX is the ability to “slice-and-dice” NetFlow data and view the information in different dimensions with simple right-click actions. Note the following figures to see how we can pivot the data to the Site Traffic Report, identify site-to-site communication of interest, and then drill down further to get additional detail.
From the Application Report, you can pivot the data to the Site Traffic Report by right-clicking in the table, selecting “Pivot to Another Report” and choosing the “Site Traffic Report” as shown below.
Select the site-to-site traffic of interest, in this case, from San Jose to Los Angeles and drill down to the DSCP Report.
Notice that LiveNX adds “breadcrumbs” for the site-to-site traffic that we are drilling into. This is found in the “Search” bar at the top of the report.
From San Jose to Los Angeles–the following DSCP Report shows the QoS markings from site-to-site. Notice also that the bandwidth utilization is far below the remote branch’s WAN capacity of 10Mbps. This report is essentially a site-to-site DMVPN Per-Tunnel QoS Report showing traffic markings between the sites in question.
The beauty of using NetFlow to monitor Per-Tunnel QoS is that we can also get to the individual conversations making up the traffic, site-to-site. For example, we can drill down further into the EF traffic class for VoIP to identify the endpoints in the call.
Notice that the updated search “breadcrumbs” showing are now drilling into the individual conversations for traffic from San Jose to Los Angeles with QoS markings of EF.
In this environment, there is one VoIP call between WKST1 (198.18.133.36) in San Jose to PC1 (198.19.1.101) in Los Angeles, as shown below in the Address Pair Report.
Using LiveNX’s NetFlow capabilities to monitor DMVPN Per-Tunnel QoS, network engineers are able to “slice-and-dice” the data, quickly identifying all of the site-to-site traffic. They will also gain deeper insight through simple drill-downs to individual conversations.
July 29, 2016
Author: David Izumo, Sr. Technical Marketing Engineer