Packet Pushers Podcast Transcript with NetBeez on Distributed WAN
On January 18, NetBeez COO, Panos Vouzis and customer, Brad Addington, Network Engineer at AmWINS Group discussed NetBeez’ new active monitoring for the distributed WAN feature with Tech Bytes host, Greg.
Greg (00:01):
You’re listening to the Tech Bytes podcast from the Packet Pushers, a 15 minute podcast at the intersection of technology and business. We’re sponsored today by NetBeez, which provides network monitoring for the
WAN, wifi, remote workers and the cloud. Our guests are Panos Vouzis, NetBeez’s co-founder and Brad Addington, network engineer at the AmWINS group and a NetBeez’s customer. Panos and Brad, welcome to the podcast. Brad, we’re going to get to how you’re using NetBeez to monitor a large distributed WAN. But let’s start with Panos. Panos, can you give us a quick overview of NetBeez and what it monitors.
Panos (00:28):
So NetBeez is solution for network engineers that gives you visibility of the end user experience in a distributed fashion. We use sensors to capture user experience at wifi network. And actually after the whole lockdown, we just released our work from home end user agent. But it be sold on the Mac and Windows. It can capture now this user experience from home over your VPN, ISP, et cetera. It helps you troubleshoot and detect the end user issues very quickly and very easily.
Greg (00:57):
I think the key thing here is that NetBeez has actually been in business for about 10 years and you’ve been doing network visibility tools and network monitoring tools for that entire time. So you’ve had some remote working. But what you’ve done here with this new product has really shifted your focus as your customers needed it. Is that a fair statement?
Panos (01:15):
Oh yeah, definitely, definitely. And there was a big push for the market obviously. Everybody was faced suddenly with this new reality, ourselves included. We had to start working from home from day one, day two. And with this new agent now customers are able to deploy it in mass with all the management tools they have on their end users machines and capture exactly this information that they couldn’t have before, unless they called the user or unless they chatting with them.
Greg (01:44):
Let’s bring Brad in. Brad, what problems were you trying to solve and what led you to NetBeez?
Brad (01:49):
So ultimately we were looking for a monitoring solution to work in conjunction with our iWAN deployment, to better understand the end user experience at each of our branches and how key services of WAN, such as performance routing, impact that experience. Additionally, we were looking for readable and valuable data to provide to other teams and our business leaders that we were not able to get with just the WAN solution alone.
Greg (02:18):
I love the readable data, the valuable data. Because I have this pet theory that if you put a graph in front of an executive, it engages a different part of their brain that actually pays attention. Is that right?
Brad (02:28):
Yeah, that’s most definitely right. And coming from the network team and the engineering team, we tend to focus on numbers at a bits and bytes level. But for them it’s the bottom line that matters.
Greg (02:40):
So this graphical interface. So the first step was you have this iWAN, it’s probably running over the public internet as well. And so you have some degree of uncertainty and you needed to be able to get visibility into what was happening there.
Brad (02:52):
That is correct. So ultimately, we use DMVPN tunnels. And we locally offload internet traffic at each of our branches. So a lot of our applications, they’re impacted by internet backbone. And as changes occur or brownouts occur, to a degree we’re somewhat visibility into that, prior to NetBeez. And with NetBeez, with point in time monitoring such as my trace route, we can go back in time and match in correlation with what iWAN sees when it comes to thresholds crossing and things of that nature of the iWAN monitoring piece. When it makes a change, we can actually correlate that in NetBeez and see those changes.
Greg (03:33):
And also when the user rings up and says, “Oh, I’ve got a problem.” You can actually go to NetBeez and you can say, “Oh yeah, look, the packets are running slow on that branch location where the WAN is.” And you then you know it could be the internet in that area or you know what the next step of troubleshooting is.
Brad (03:47):
And in a lot of cases, when they do report problems, they’ll call it into the help desk. And then the help desk will tend to escalate up to engineering, whoever that may be. And if iWAN can catch that ahead of time, they will make a path for mediation and try to divert away from that issue. And in a lot of times we can go into NetBeez and see that change. Or if for whatever reason iWAN doesn’t do that or if a service hangs up and it doesn’t do what it’s supposed to do, when it sees those degradation in services, we can see that in NetBeez proactively and go in there and start investigating prior to the user even calling in.
Greg (04:23):
And the unique feature here that you’re using, which is not something I’ve seen everywhere is you are actually deploying an agent on the iOS routers. Tell me about that.
Brad (04:30):
So we’re just deploying a KVM image as a container on the ISR routers. So essentially the router acts as a host for our NetBeez agent.
Greg (04:42):
And that’s approved by Cisco, supported by Cisco. And it also tells you exactly what the network’s doing because the active sensor is actually there in the routing edge.
Brad (04:52):
It does two things. It is absolutely supported by Cisco and with Cisco’s DevNet push these are things that they’re trying to get more involved in, into the market of getting their customers to use these container based images on the routers. And furthermore, that agent, it actually provides us almost like a remote computer at each branch. Because it runs on Linux, which is really cool too. So we do have a lot of tools within Linux that we can use at pulling DNS information, things of that nature.
Greg (05:21):
So it ties into existing operational skills you’ve already got?
Brad (05:25):
Correct.
Greg (05:27):
Can I ask how many devices you’ve rolled this out to so far? How many NetBeez monitoring nodes you’ve got deployed?
Brad (05:32):
So we have many branches and we’re rolling one agent out per branch. So we have rolled roughly 70 agents out as of today, with about 10 more coming any day now.
Greg (05:46):
Pain threshold? When I say pain threshold, how hard was it? Was this excruciatingly difficult to get the first one up and running? Or was it really just a case of KVM instance being NetBeez’s sensors ding, done?
Brad (05:58):
No, the process and deployment was extremely straightforward. NetBeez provided documentation. The documentation, unlike a lot of documentation, was spot on. It was very accurate and it assisted greatly with the deployment. I know we all laugh in the tech industry because sometimes you get documentation, it says do it this way, this way, this way. And you get there, that option is not even available. So I’m not quite sure where to go from here. Or it requires additional research and additional time. But with the NetBeez deployment that was definitely not the case. And once we deployed one or two, we found the process to be extremely repetitive. So we were able to easily automate the process to get these agents deployed in roughly five minutes.
Speaker 4 (06:40):
I have to say maybe one of the first times I’ve heard an end user, a customer say, “We like the documentation.” That’s pretty good.
Greg (06:48):
That’s a fresh take.
Speaker 4 (06:49):
That’s a very fresh take.
Greg (06:50):
That’s a fresh take. So we talked before about some of the things that once you had the NetBeez census in place, you started seeing things you couldn’t sense before. Is there any others that you wanted to cover today?
Brad (07:04):
Some of the things that we were seeing that we weren’t seeing before were impacts on changes. And this goes beyond just this question. But what we were doing previously was we have multiple tools that help us manage and monitor changes before and after. And many teams across AmWINS utilize these tools. But with the NetBeez agent, what we’re able to do and see was down to the actual response time, down to the path it takes, everything. And it was not only helpful to the network team, but it was helpful to other IT teams within AmWINS as well. The DVAs found it extremely useful. Our app teams found it extremely useful. Our server infrastructure teams found it very useful. Because when they make changes, we were able to go back and look, okay, here was the response times or this was the standard before the change and here’s where we are now. So how far did we deviate away from that standard? Was it good? Was it bad? So those are some of the things that we’re definitely seeing after we deployed NetBeez, which was an added bonus.
Greg (08:10):
So I think that’s really probably interesting and critical in that NetBeez becomes a common tool that every stack or every silo can take advantage of and get some benefit from.
Brad (08:21):
Most definitely. Because I think from any IT department, one of the things that we tend to overlook is how our changes impact the end user experience. And be able to go back and monitor that data and see that data. And not only take that data and provide it to business leaders but say, “Hey, look, the changes we’re making are actually helping our infrastructure, our network.” It makes us all look good.
Greg (08:49):
I turned you into the truth police because when the DVA says, “I’ve done something to fix the performance.” You can hold it up and go like, “No, it isn’t.”
Brad (08:56):
Ironic. It’s funny you mention that because we actually had an issue similar to that shortly after our proof of concept of the product. Our change went on the week and we seen I think about 20 milliseconds increase in response times. And I think it was very minute, but what did you guys do? And they went back and had… Ultimately, I don’t know what was done to resolve on the DVA side. But they did revert some of those changes.
Greg (09:23):
The other part of this is that it’s keeping all the groups honest in that they can’t just say, “It’s the network.” Because everyone’s using this tool and has a common grammar to speak to each other with that. You can’t just say, “Oh, we at the DVAs know it’s not our fault because it’s the network.” When you can all look at the tool again and be like, “Nope.”
Brad (09:41):
And that’s probably my favorite thing about this is, and I don’t know, for every organization I’ve ever worked for that seems to be the commonality, is the network. And I feel like many network teams have to go out of their way to prove that no, it’s not the network, but here you go, this is probably where you should start looking thing. To have that information readily available is definitely beneficial.
Greg (10:07):
So we talked about using NetBeez in the context of your iWAN deployment. What about software as a service or cloud apps? Are you able to leverage NetBeez there in any way?
Brad (10:16):
Yeah, what I did was I worked with our Microsoft team in house and what they were able to do was give us some URLs to some of our more common Microsoft services, such as our Office 365 suite. And we’re using it to monitor HTTP response times to SharePoint. We’re using it to monitor DNS, to make sure that URLs are actually resolving correctly. We even have it tracking a my trace route going out and watching from each branch to see how if we’re using Outlook or Office 365, we want to know how the internet is actually impacting that service, especially with Voice, Microsoft Teams, things like that, that seem to be a little more susceptible to the issues and packet loss and jitter. To be able to see that, get alerts on that when something crosses a threshold that we’ve set within the NetBeez dashboard, it just makes for an overall better experience.
Greg (11:13):
Let’s shift back to Panos. Panos, you touched earlier on the remote working and we talked about the fact that it’s a transition from your existing product. It’s not a ground up thing. What customers do you have today that are using it for supporting distributed work?
Panos (11:26):
We see lots of interest from the financial services and healthcare industry. And it’s interesting what we found out. The reality is that if it’s you, Greg or Brad, that is having issue with a wifi network, most likely have to get it out and figure it out yourselves. But we see of course you have all these unskilled employees that they can be skilled to the wifi details and networks. And that’s where the sweet spot is I think, where you support these people that don’t have the technical knowledge to even give you feedback of what’s going on. And lots of people in sales support, in financial services and healthcare have this need. And we see lots of interest from that sector of the market.
Greg (12:09):
I think it’s really interesting that we talk to Bradley about the idea of the remote sensor being deployed inside the Cisco ISR router here. But it’s fundamentally the same principle when you install it on someone’s PC or their MacBook. It’s the same idea.
Panos (12:24):
Definitely, definitely. If you look at the dashboard actually it’s very uniform. You can have the same type of tests you have on the ISR routers and the same type of test running on the end user’s laptop. And that’s actually a very powerful visibility feature we have where you can compare easily data from different sources. So you can see from over the VPN what’s going on, you can see what’s going on from your [inaudible 00:12:50] or to the internet. You have split panel or not. You can very easily compare data and see where the discrepancies are and where the bottleneck might be.
Greg (12:58):
I think we’ve probably run out of time, Panos. If folks want to find out more about NetBeez or get in touch with them, where should they go?
Panos (13:04):
You can find us if course at netbeez.net. We’re very active on our blog at netbeez.net. Last blog, we’re running a series of Linux for Network Engineers, posts there. So if you are getting into them that Brad talked about and you are looking into Linux right now, it can have lots of good material over there. And @NetBeez on Twitter also we are very active on the community there.
Greg (13:29):
That’s netbeez.net and that’s NetBeez with a Z. B E E Z. Not an S. Netbeez.net. Panos and Brad, thank you for joining us and thanks to NetBeez for being a sponsor. You can find this and many more fine free technical podcasts along with our community blog. That’s at packetpushers.net. You can follow us on Twitter @packetpushers. Find us on LinkedIn. Like us on Facebook and rate us on Apple Podcasts. Last but not least remember that too much networking would never be enough.
Want to stay in-the-know?
