I was first introduced to NetBeez at Networking Field Day 9, where I saw an interesting monitoring product using Raspberry Pi-based agents and a cloud-based management and reporting console. That was back in February 2015, but I met with NetBeez a second time at Networking Field Day 12 in September 2016. Eighteen months is plenty of time to make some significant updates, so I’m going to look at the current product from a capabilities perspective and also see how it works when using it in anger. As background it may be worth reading my review of NetBeez from June 2015 first.

NetBeez Overview

By way of a refresher, the NetBeez product is made of two parts:

• an Agent (aka a Beez, which always sounds odd to say because Beez sounds like it should be the plural form of the noun);
• a web management portal to which the agents send their data and from which the agents are managed and their uploaded data are analyzed.

The Agents

• FastEthernet – As I saw at NFD9, the FastEthernet Beez agent is a Raspberry Pi in a case with a NetBeez logo on it, and the micro-SD card slot is covered by an anti-tamper label.
• Wireless – New since NFD9 is the Wireless Beez which is like a regular Beez, but comes with an 802.11ac USB wifi device. I asked whether a wireless Beez could use both the wireless interface and the wired interface to perform monitoring tests, but the answer is no; to monitor both wired and wireless requires two Beez.
• OVA – Also new, you can now spin up a VM using a Beez OVA which has pretty minimal requirements in terms of hardware (the agent runs on a Raspberry Pi, so for the most part it’s not a particularly demanding service).

Subscribers to the Enterprise tier get some additional options too:

• GigabitEthernet – The GigabitEthernet Wired Beez works like the Raspberry Pi agent but with a faster Ethernet interface.
• External – There are also external cloud-based agents, available as an AWS AMI and a Google Compute Engine instance.
• Roll Your Own – Finally, newest of the new, Enterprise tier customers are allowed to spin up an agent on a Debian-based linux server using apt-get to install the software.

Deploying Agents

Deploying agents remains as simple as it was before: connect the agent to a wired Ethernet network then power it up. Since the models I have are both Raspberry Pis, they can be powered from most USB ports. I have one of mine plugged into the USB port on a Juniper SRX 100 firewall since it saved me plugging in the (provided) wall wart power supply. Once connected to the network and configured with an IP address via DHCP, the agent then dials home to the management server, after which it can be managed as part of the account.

Software Updates

Software updates are installed automatically as they become available. Over the last 18 months I have kept my original Beez agent connected and active, and the software updates have been fairly frequent and definitely seamless. To my memory in that time there was perhaps one change made (on the server side I think) which meant that some people needed to reboot the agent manually to make it reconnect, but as I recall, that issue ended up not affecting me.

Management Server

The management server is where the magic happens, so to speak; it’s where tests are created and applied to agents, where the results are stored, and where alerting and reporting take place. My original Beez was (and is) sitting in my house, and despite my best attempts, the most value it brought to the table was the ability to shove charts at my ISP to prove how long their service outages had been. The second agent however, I connected in a corporate environment so that I could see how it fared with a private WAN and a lot of change going on.

Monitoring Network Beehiveiour

I configured my new agent to do a number of tests to local servers, destinations worldwide via the internal WAN and via the Internet. I configured a mixture of regular latency (ping, with and without DSCP set, using ICMP or TCP) and connectivity (e.g. HTTP) testing, as well as traceroute. The traceroute feature is one of my favorites because it helps–in one direction at least–answer a key troubleshooting question when problems are reported, which is well which way did the traffic go before this problem started? A more recent addition is the ability to perform iPerf tests between agents, but since my two agents are separated by NAT and the internet, I haven’t been able to test this very well. Similar problems exist for the VoIP simulation testing between agents, although in a corporate environment this is less likely to be a problem because agents should be able to talk to one another.

Another interesting feature is the ability to schedule a SpeedTest (as in speedtest.net) test to run regularly. I did set this up for a while and it was nice to see the bandwidth charts, but then I realized that I didn’t actually want to kill my WAN link every hour. Testing once a day overnight seems a little less helpful in terms of statistics, so I just deleted the test in the end.

Missing Tests?

While the bandwidth tests (iPerf/SpeedTest) are nice additions in the last year, a couple of things stand out as being needed:

• HTTP testing where the result can be evaluated against a regular expression to ensure that the service is up and working.
• DNS testing of specific hostnames, with results again evaluated to confirm accuracy. For example, I could make sure that my third party DNS host is correctly resolving key sites, and prove if the site became unavailable due to DNS failure.

Oddities

One thing I never figured out about Targets (groups of one or more destinations against which to run, as desired, Ping, HTTP, Traceroute and DNS tests) is that once a destination has been configured with a name and IP address, while the name can be edited, the IP address cannot:

This means that if you need to change a resource’s IP address, or you simply fat fingered it to begin with, the only way to fix it is to delete the old resource entry and add an entirely new one, along with all the tests that were configured. I’d really like to see this changed so that I can properly edit any target configuration at any time.

Insert Ad Break Here

Ok, no adverts then. However, since this is a long post I’ve split it into two, with the next part to be published on Monday. In part 2, I’ll discuss the web UI data presentation and some aspects of my hands on experience using NetBeez to troubleshoot real network issues. I’ll also share my conclusions, and you can decide whether this is a killer product, or if it’s in danger of extinction.

Disclosure

I was an invited delegate to Network Field Day 12, at which NetBeez presented. Sponsors pay to present to NFD delegates, and in turn that money funds my transport, accommodation and nutritional needs while I am there. That said, I don’t get paid anything to be there, and I’m under no obligation to write so much as a single tweet about any of the presenting companies, let alone write anything nice about them. If I have written about a sponsoring company, you can rest assured that I’m saying what I want to say and I’m writing it because I want to, not because I have to. NetBeez gave me a Beez FastEthernet agent and access to a shared online management portal.

You can read more here if you would like.