Experimenting with network topology and throughput.

[agent_kith]

Why did I drop pfSense and go with Untangle? Well, the main reason really is because I have broken jumbo frames routing on pfSense and couldn't get this feature back working again.

Second reason, it gives me more insight into my home network that I couldn't really get before in pfSense.

Sure pfSense has a app called ntopng that can do a subset of what Untangle can do, but it's not integrated like Untangle is. The Untangle offers more features, and is more powerful.

As an example, looking at the Untangle Dashboard I noticed the majority of traffic that crossed my network is an application called NFS. For the uninitiated, NFS is a file sharing protocol (allows me to share files over the network).

This chart breakdown tells me NFS took up >80% of the network traffic over the past 24 hours. This is not good if this NFS comes out from network interface of my NAS (Media). I need to keep this network interface as quiet as possible because this is the network my music PC is also on.

It's important that the NAS do not talk to my music PC and other machines at the same time. The reason is because I'm using Jumbo Frames.
 

 
Hovering the mouse over that green area above, it tells me that is 25 GB of NFS data. This graph is a plot of the past 24 hours, so that's > 1 GB an hour!

On the same dashboard is a widget that shows me the traffic that enters/leaves the network. This is just an example as the problem is already fixed after I took these screen caps. Looking at the widget then, I can confirm the NFS is indeed coming out from my NAS VLAN, and into the Development VLAN (where all my Snakeoil development machines sits on).
 

Knowing this, I now go into the 'Sessions' section, and list all the network connections on the DEV VLAN (You can also just list the connections on the Media VLAN). From the list I identified the machine that causes all the NFS network activity (again this is just an example, not the actual screen cap of the problem):
 

The problem machine is responsible for storing all the source code of Snakeoil. In here I also know the development machine is constantly transferring files in and out of the NAS at a rate of 250 - 500 Kb/s in and out). So the time it took me to notice there's an issue and isolate the problem took less than 30 seconds.

Here's the breakdown of traffic in the past hour since the problem is fixed, no more NFS traffic hogging the network.
 

So the majority of the traffic is now something called UDP. Extrapolate that hourly data to 24 hours means it'll be around 4 GB of data per 24 hours. The traffic is significantly less than before. And looking at the network layout widget, there's way less data entering and exiting the media interface now.

The words above in bold is important. As the above is a problem where data crosses VLANs (i.e. coming in and out from different network).

Traffic that's internal inside the Media VLAN will not be shown here, and for all we know, could be as busy as hell. You'll need a different tool to see if the Media VLAN is busy. I've always used the packet capture feature on the Meraki equipment for this. But you can also do something similar on Untangle:
 

So the above output (blanked out) basically tells me the Media VLAN indeed is relatively free from 'unnecessary' traffic.

All is good again. Now will this bring any enhances to audio? At the end of the day, I am now assured my network is running in peak form. That (re)assurance gives me peace of mind, which in turn means I'll be able to enjoy music better. You can't lose!