Packets Packets Everywhere, but Which One Do I Seek?
by Team AppNeta on

Apparent Networks: FlowView Our legacy blog entries tell the AppNeta story from the early days…Read on!

Much like the ancient mariner in Samuel Taylor Coleridge’s famous poem,  we often find ourselves awash in a sea of packets that tempt that tantalize us with their ability to quench our troubleshooting thirsts – but just like seawater to a thirsty sailor, they’re often too much of the wrong thing.

Let’s face it – the “full stack” visibility (as in layers 1 through 7 of the OSI model) afforded by packet-based capture and analysis is hard to beat.  If you have the knowledge and the right tools (deployed in the right place and at the right time – we’ll come back to this…) packet-level visibility can enable you to solve problems impossible to solve any other way.   But it’s precisely that “right place and at the right time” part that often leads to a lot of wasted time, even more wasted $’s, and ultimately YATOS (Yet Another Tool On the Shelf).   We think this is a shame since solutions like Wireshark are amazing.

As a networking professional, you have many good options for capturing and analyzing raw packets today.  They’re accurate (the vast majority offer 100% collection at various line rates…), and while features do vary, most can store many GBs (some do many TB’s…) of packet captures on their internal storage arrays – no small feat.   Great stuff for the datacenter or for that “one central spot” in your hub and spoke network – but what about the remote offices?

Today’s crop of packet capture solutions nearly all suffer from a common set of problems that are only made worse when considered from the remote office perspective:

  1. They’re generally very expensive (because they’re designed to run at the network core, not at the edge) – so deploying many of them to cover many remote offices (regardless of how great that would be…) is usually not in the budget.
  2. The same power that permits them to capture mountains of raw packets is also their Achilles heel from a network performance or troubleshooting perspective;  when looking back in history, these solutions generally make for some very large haystacks from which to find the needles.
  3. They’re not straight-forward to deploy nor easy manage once in production.  Did I mention budget already? Nothing worse than paying for an expensive IT solution than paying for it 3 times again due to the hidden costs they incur in IT personnel time to make them work as advertised.
  4. They’re complicated pieces of infrastructure with lots of moving parts and therefore, while being well-built, they’re naturally prone to hardware failures simple due to the number of components in each system.
  5. They demand access to already over-subscribed span/mirror ports on your switches and routers. This of course is provided your remote office switches or routers are new enough to even have a span port -AND- it has enough unused horsepower to leverage a span port without adding more ghosts to the network machine.
  6. If a span or mirror port is available, the switch or router often must be re-configured at each remote office in order to leverage it.  User-driven configuration error – not a problem, right … .  Did I mention budget already?
  7. Finally, if every other hurdle is cleared, most solutions leave you with a huge pile of very accurately collected packets sitting at a remote location some place. Yes, you can leverage remote access solutions to access each remote location to perform your analysis (awesome!), but what about managing access to the potentially sensitive data contained in all those piles of captured data itself?  How can you control access to this if more than one member of your team needs to do some troubleshooting? How do you make sure the data doesn’t walk out the door or that it is deleted after it is no longer needed? Hmmm – there is that nagging budget thing again since all this extra management overhead will cost you lots of hours of your most knowledgeable (and expensive) personnel.

To sum up, the vast majority of solutions today are generally pretty good at capturing packets, but they’re slow to deploy, hard to manage, and offer reliability only through complicated redundancy.  Did I mention the cost?

This week Apparent Networks is changing all of this with the introduction of FlowView Plus, an add-on module to our award-winning Remote Performance Management Service, PathView Cloud.

FlowView Plus lets you capture precisely “the right packet at the right time” from as many remote locations as you want and still easily be able to centrally analyze any of your packet captures from any location with access to the PathView Cloud service.  Since FlowView Plus is an integrated add-on module for PathView, there is a connection established between actual network performance and the associated captured packets.  FlowView Plus permits you to store as many captures as you like in the Cloud (and rest comfortably knowing they’re securely encrypted both at rest and in transit…) and pull them back to your favorite packet analysis tool of choice with single click.    Last but not least, you can quickly and easily deploy FlowView Plus in your remote offices without worrying about availability of span/mirror ports or re-configuring a single router or switch.

In short, FlowView Plus is fast to deploy, simple to manage and extremely reliable. And since it’s built upon Apparent’s award-winning platform that runs in the Cloud, it’s offers near infinite scalability.  Of course, like all of the PathView Cloud solutions, FlowView Plus is priced with remote office deployments in mind.

We’ll be addling lots of extra intelligence and functionality to FlowView Plus over the coming months – but we think this is a game changer for those of you struggling with remote office performance (and troubleshooting) management.  We’d love to hear your thoughts.

Related Links

Filed Under: Networking Technology, Performance Monitoring

Tags: FlowView , full stack , legacy , NPM , packets