MFD3 – Link-Live Updates

This is the third blog from the Company-Previously-Known-As-Netscout’s session at Mobility Field Day 3. You can read about the AirCheck G2 v3.0 update and also the LinkRunner G2 v2.0 Update.

To catch you up, I came into MFD3 less enthusiastic than most regarding Netscout and their lineup of handheld network tools. With that said, I took notice in 2017 at MFD2 that the company was paying attention to feedback and looking for suggestions on how to improve their product offerings.

One of those improvements for MFD3 was a further expansion of the capabilities of Link-Live.

Link-Live has matured into a tool for consolidating all of your test results AND managing the tools at your disposal.

Many of these updates were covered in the LinkRunner and AirCheck updates, but bear repeating:

  • AirCheck software updates
  • AirCheck G2 Profile sharing
  • Packet capture sharing
  • Simplified App search for the LinkRunner G2
  • Files Folder – There is a lot more available that can be uploaded and saved to a project folder
  • Full AutoTest results

The most significant aspect of the Link-Live updates is a clear direction to make the LinkRunner and AirCheck entirely manageable without a Windows PC. This is a substantial shift from the past, and I am very excited to see it taking place because I stay away from Windows as much as possible.

So, the ultimate question, does the updates to the AirCheck G2 and LinkRunner G2, along with the new features of Link-Live make me change my opinion? Do I now see the ROI? Would I spend my budget, either personal or business on either tool?

The answer is “yes” to all of the above. With the divestiture of the handheld tools from Netscout into its own company, I expect the future to be bright. I think we will continue to see updates, new use cases, and great support. The handheld network tools team has won me over, and I’m happy to change my previous opinion. I will acquire both tools over the coming months for my personal toolkit, as I know my employer doesn’t have the budget. I don’t think there is more to say.

MFD3 – Huge updates for AirCheck G2 and LinkRunner G2; then Netscout announces their sale

Mobility Field Day 3 was great! If you missed it, I will be releasing a few blogs over the coming weeks from my experience at the event. In the meantime, you can watch all of the videos here:

https://techfieldday.com/event/mfd3/

One of the most interesting developments this morning was the announcement from Netscout that it was divesting its handheld network test division to StoneCalibre.

The press release can be found here:
https://www.netscout.com/news/press-release/netscout-divests-handheld-network-test-business

While this announcement creates quite a few questions around the future, I firmly believe that the great group of people who have brought us the recently announced LinkRunner G2 v2.0 and AirCheck G2 v3.0 software updates are going to keep killing it. I’m excited to see what they bring to us in the future and hope to see them presenting once again at Mobility Field Day 4.

VIAVI Observer Apex- Finding the needle faster

I participated in the Tech Field Day Extra events at Cisco Live. One of the presenters, VIAVI has been floating near the edge of my awareness for a while, so it was great to see their presentation and get a better understanding of the VIAVI Observer Platform.

Anytime I see a presentation from a monitoring solution there are three questions that I ask:

“How useful would this be for tier one technicians?”

I usually consider that question from both the perspective of a NOC and also a helpdesk technician. If a monitoring tool isn’t practical for those roles, I am the one who gets stuck using it all of the time, and therefore, it has no place in my environment.

“How useful would this tool be for me?”

If the tool can’t offer enough information to be useful for a senior engineer, I don’t want to pay for it. It also increases the complexity of passing trouble tickets up the chain as each person has to start back at zero in their own tool.

“Does this make it easier to find the problem, or just add another step?”

Monitoring tools which only show up/down status and system logs have very little use for me. I can easily find those by other means, or on the device itself, faster than I can fire up a browser, click on a bookmark, log in, navigate through a device tree, etc.

VIAVI has provided the right answers to all three questions.

product-obsever-apex-welcome

The starting page for Observer is simple. It doesn’t take forever to load as it attempts to pull data from many different sources to provide a general health overview that rarely has anything to do with the reason you opened the application. Instead, Observer’s search box is ready for any relevant text the technician may know about the problem. If you have an IP, MAC address, VLAN, or hostname, those are all great places to start. You can also choose to push into a more generalized monitoring view like Application Performance, Network Performance, etc.

The search box is the beauty of the application for me. VIAVI indexes all of the monitoring sources for things like MAC addresses, IP addresses, interfaces, usernames, and other metadata and then correlates that information together. A technician doesn’t need to look up an IP address in the ARP table, get the MAC address, look up the MAC address in the MAC address table to get the port, then check the port for errors. A search on the IP address will provide all of that information, quickly! Since VIAVI also knows the assigned VLAN, it quickly displays “Here’s a bad actor on the same VLAN that is flooding the VLAN with bad frames.” The technicians can find problems without looking directly for them. That’s a huge win. This is not looking for a needle in a haystack. This is turning on an extremely powerful magnet and letting the needle come to you.

Another great feature is that Observer creates a baseline from the information that it acquires. With that baseline that understands system X typically runs at 75 percent utilization, but is now running at 90 percent, more problems quickly float to the surface. Additionally, the baseline filters out the normal abnormal. Is it “normal” for that system to run at 75 percent utilization all of the time? Maybe so. If it is, a technician doesn’t need a warning about it. It might be operating as designed.

If a technician can’t find a solution through the dashboard, the next engineer who picks up the problem will want to dig deeper. Thanks to the stored packet traces which provided all of the metadata the technician used, the engineer can take a look at the actual packets. Aside from the standard fields like source and destination, IP’s and ports, Observer also includes a patent-pending User Experience Score which is a 1-10 scale to aid in finding problems faster within the trace files.

Taking the click-through troubleshooting one step further, Observer creates Application Dependency Maps which aid an engineer to understand all of the dependent systems quickly and which are affecting performance.

When considering my initial three questions I proposed, I feel VIAVI’s Observer is providing pretty compelling answers for each. I look forward to learning more.

In many ways, Tech Field Day offers a similar solution to VIAVI Observer. TFD allows me to filter through the marketing hype, and get to the bottom of a product or solution and whether it will be useful to me. Don’t forget to check out the many other videos and content created by Tech Field Day at Cisco Live.

Geek Tools – Cape Networks for more than just wireless

In case you missed it, a couple of weeks ago I wrote about my experience testing Cape Networks solution for wireless monitoring. You can find that post here. I first learned about Cape Networks at WLPC, and was able to have a conversation with them at Mobility Field Day 2 that you can watch here.

One point that continues to impress me about Cape Networks is the ability to test much more than WiFi.

It really comes down to the strength of the dashboard and the various tests that each sensor can run. The ability to test against internal and external systems is one example.

Screen Shot 2017-09-15 at 11.57.05 AM

Each sensor can test against web servers, iperf, or custom ports of your choosing.

Users can configure a test to run against predefined external websites like Adobe Creative Cloud, Microsoft Office 365, Dropbox, and others. But, the sensor can also test against custom websites, checking not just “Is it up?” but HTTP status codes and latency as well.

I’ve used this recently to help an outside vendor truly understand that “No, our network is not to blame” for the high latency their users are complaining about.

When all other external websites are seeing ~20ms latency, and your web application is averaging ~90ms over a period of weeks, guess what? YOU have a problem!

Screen Shot 2017-09-15 at 12.06.02 PM

Averaging 96ms of latency. Maybe that’s why the application is always slow?

Obviously, due to the nature of these tests being performed over WiFi, latency, jitter, and packet loss are all expected to be a bit higher, especially if they are performed during times of peak WiFi utilization. However, when you have tests to compare across multiple online services, it’s easy to notice standout patterns.

One feature request I would make to Cape Networks is this: Allow test to be ran across both the LAN and WiFi connections. If we can compare across these two mediums, we may also see additional information useful in diagnosing wireless issues.

Have you found a non-WiFi use for the Cape Networks sensors? If so, tell me about them in the comments.

As a MFD2 delegate, I did receive a free sensor from Cape Networks and various stickers and other low value (but tasty) snacks. All other expenses for MFD were covered by Tech Field Day. I was not compelled to write about Cape Networks in any way other than personal user experience. My employers decision to purchase sensors was based solely on the user experience and ease of problem resolution.

Geek Tools – Cape Networks for Wireless Monitoring

“Wireless isn’t working!” – everyone

How many times have we heard that mantra? As wireless engineers we know all of the intricate details that are required to be in place before wireless “just works.” We often find ourselves trying to explain this to people who see wireless as magic, and us as the magicians. They don’t care about the intricacies of roaming. They don’t care about the underlying systems, many of which we rarely control. DHCP, DNS, RADIUS, and ultimately the services they are trying to connect to.

Assuming a medium to large sized corporate environment, there is likely someone (a team) responsible for the DNS, DHCP, and Radius, and that is not likely to be the same team responsible for wireless. In very large environments, the LAN team that even provides the network cable for the AP may be a different team.

Further increasing the confusion is that problems can often appear isolated, with only a small group of users experiencing the issue.

Then the troubleshooting must begin. Is it a client issue? Were drivers or firmware recently updated on the users systems? Is there a common location, time, or AP that the experience is related to? The list of questions begin to build.

I ran into this in my own network recently. Users were complaining of being unable to connect to wireless. The problems were reported from various locations slowly over a number of days. No particular client was having consistent issues, and I never saw the problem on a customers computer while they were having it. I began looking through logs and following pretty standard troubleshooting steps. Nothing came up. It was as if the problem didn’t exist, yet I was hearing about it often enough to believe that it did.

Considering that I had just returned from Mobility Field Day 2 and participated in the Cape Networks session, I had an idea. Cape Networks provided delegates with a sensor to test. I spoke with my manager at work, a very smart guy (he hired me, right?) who agreed it would be OK to test the sensor in our environment.

The secret to the Cape Networks sensor is that it IS a client. It sees what a client experiences and its entire function is to report on the user experience. It is cloud connected, with an intuitive dashboard, that makes setup and management easy, and remote troubleshooting painless. You really should watch the Cape Networks presentation!

After installing the sensor and configuring the device for our wireless network and the internal services that I wanted it to test, I walked away and forgot about it for a day.
The next morning, I logged back in, and my issue was staring me in the face. DHCP

The time to get a DHCP address was all over the map, peaking as high as 11 seconds. Problem found! Users who experienced those peaks would clearly have issues connecting; add in their own impatience, maybe turning off and on wireless, and of course they couldn’t connect.

Before and after changes were implemented to resolve the DHCP issues users experienced.

Before and after changes were made to DHCP.

What was even more important was that I now had clear metrics that I could take to my team that manages DHCP. I could point to the problem, and then after we developed and implemented a resolution, I was able to point to the same metrics as proof that our plan worked.

As you might have guessed, complaints and rumors of complaints quickly died away.

My organization has since made the decision to invest in sensors from Cape Networks. Their reporting and ease of use make for an unmistakable value. I strongly recommend that you also check them out.

As a MFD2 delegate, I did receive a free sensor from Cape Networks and various stickers and other low value (but tasty) snacks. All other expenses for MFD were covered by Tech Field Day. I was not compelled to write about Cape Networks in any way other than personal user experience. My employers decision to purchase sensors was based solely on the user experience and ease of problem resolution.

Looking ahead to Mobility Field Day 2

This week I am attending Mobility Field Day 2, taking place in San Jose, CA! This is my seventh event with Tech Field Day and I am excited for what the week has to offer.
As an attendee at Network Field Day 8 and 9, the focus in networking was towards Datacenter and WAN. During that same time, my personal career was arcing towards wireless. I was reading, thinking, and practicing a lot of wireless for a major global manufacturing company. I left from those events feeling amazed at all that was happening within the realm of networking, but also feeling like an imposter.
I wasn’t worrying much about SDN WAN, I was too focused on designing and deploying high density wireless in a manufacturing space. I wasn’t thinking about data center, but I was instead providing coverage to warehouses in the million+ sq/ft range.
A lot has happened in my career since those events, and I have made myself at home in the realm of wireless. I continue to learn and grow as a wireless engineer, and Mobility Field Day is another step in my development. More importantly, I’m at an event that speaks to my passion. Tech Field Day events are always incredibly informative, but this one just resonates!
We have some great presenters this week, including Cape Networks, Mist Systems, Mojo NetworksNetscout, and Nyansa.
Aside from the presenters, Mobility Field Day 2 has some awesome delegates, many of whom I consider friends. The opportunity to exchange ideas, ask questions, and participate with them is very exciting.
Speaking of participation, my absolute favorite part of Mobility Field Day is that everyone can participate. Nearly all of the sessions are live streamed. You can watch with us live, send tweets or DM’s, and be part of the event yourself.
Please feel free to send me your questions on Twitter. I will be happy to ask them as time allows and you too can participate in what looks to be another great Tech Field Day event!