Esteemed Geek Speak readers -

 

Recently, a valued customer shared the following story with us. We thought it was so good, we wanted to share. They asked to remain anonymous but the story remains the same:

Long ago, in a data center far, far away...
It’s the question that every support team dreads
"is it the network or is it the application?" When faced with this challenge recently, we turned to SolarWinds® and the Deep Packet Inspection technology embedded in Network Performance Monitor v11.  During a SWOT analysis of a series of business critical applications it was determined that we needed a way to monitor network traffic focused on applications; a different view than the existing NPM (volume) and NTA (volume by applications between discrete endpoints) could provide.  We needed a way to determine how the application was performing and whether the issue truly was the underlying network or the application itself.


So, where to begin with this mountain of a task?

The challenge of sorting out which components needed attention was further complicated by the lack of tools in the new data center.  Neither a dedicated WireShark® server nor a standard Gigastore appliance was in place to help gather packets for analysis.  Enter SolarWinds DPI. Drawing the network, server, virtualization, monitoring and data center teams together, a plan to build and deploy a DPI NPAS (network packet analysis sensor) server in the remote data center was hashed out. Leveraging a Gigamon appliance that would act as the filter for the 10GB links, we built a Windows® 2008 R2 server on top of a VMware® host to house the NPAS agent.  The virtualization team configured host affinity so the guest OS didn’t get vMotioned away from the host with the physical cable in this proof-of-concept build.  With cabling in place, a promiscuous port configured, host affinity set, and a NPAS agent deployed from an additional polling engine that was local to the data center, we were then prepared to start parsing traffic at the application level.


Time was of the essence.

The alternative solution simply required too much lead time for the timeline we had to work with in this troubleshooting effort.  Ordering a Gigastore appliance or building a dedicated WireShark server would have taken weeks from order to delivery and installation.  By leveraging existing hardware and virtual servers, we were able to execute on this proof of concept in under a week.  In spite of having never deployed DPI in a lab environment, not socializing the idea of doing packet-level application monitoring with any of the other support teams, or defining a clear set of objectives, we were able to rapidly go from proposal to deployed solution with minimal effort. 


And on top of all that...

Along the way we discovered the DPI may also save time and money.  While Gigastore and Gigamon appliances are in no danger of being pushed out of core data centers, we’re now considering a Gigamon with DPI to do the ‘app vs network’ discernment for smaller data centers where the interesting traffic is less than 1 Gbps and unique application monitors are less than 50.  The networking team is eyeing DPI in hopes that it can reduce the number of manual packet analysis requests in their future and improve analysis time by targeting the specific part of an application that’s performing poorly. In turn, allowing them to focus on other mission-critical tasks.  

 

Thank you for sharing your story, IT hero and valued customer (you know who you are).

 

And for you other heroes out there, we love to hear from you too. Don't ever hesitate to contact any one of us SWI employees. Or just say it loud and proud any where on thwack, particularly on Spread the Word.