State of the Network - September 2024

I haven't posted in a while so I thought I might get the blog up to speed.  I have been busily pushing things in the rack to an everyday state.  To do that I had an epihany about the connection between the living room manaaged switch (GS108Tv2) and the back bedroom managed switch (GS116Tv2).  It turns out that instead of using a Powerline adapter, I would be able to use a 35 foot flat Ethernet cable to accomplish the same thing.  So I obtained a flat Ethernet cable, ran it along the floorboard, through the balcony door, around the back of the balcony, through the bedroom door, and plugged into an extension Ethernet cable coming from the back bedroom managed switch.  In doing that, I managed to get the speedtest to triple on downlink (at times) and double the upload speed (at times) [201.9/237 Mbps].  I assume that this means I am approaching the 1Gbps speed between the two managed switches.  This also means that I am not susceptable to power fluctuations on the Ethernet line between the Powerline adapters.

I have also been busily rearranging the rack equipment to use the Netgear M4100-26 and Ubiquity Edgerouter-12.  The Netgear and Edgerouter have been changed to always power on when the rack has power.  This simplifies the overall structure of the rack and eliminates the need for using the two Edgerouter-X routers and another GS108Tv2 switch.  I can now power off those three components until I might need them again.  I left them plugged into the Ethernet patch panel on the bottom.  The only disadvantage is that the Netgear M4100-26 now runs hotter; but the fans at the top are putting out cold air which indicates that it is not as hot as I might assume in the rack; currently at 104 degrees F.

I am now trying to configure a monitor system that can gather statistics and send out commands to update, reboot, shutdown, etc. equipment in the rack.  I hope to continue to get closer to an automatic mode int he rack which will support experiments in the future.

Using pfSense as a Multi-WAN interface for Monitoring within the HomeLab

 I am back.  I started playing with pfSense in my Proxmox server in order to have a multi-headed connection into vlans within my network.  The purpose is to have an isolated vlan (isolated in the sense that the other vlans cannot get to it) to use as a monitoring point.  My thought is this: let pfSense become the DNS/DHCP source for a number of hardware and VM/LXC components to provide monitoring and automation activities.  I would eventually use Ansible to automate setups within the HomeLab and would use Observium/collectd to monitor the different HW components.  I could also use a component to provide CA capabilities.  The steps needed include:

1. download a tar.gzip of pfSense Community Edition from the pfSense website
2. create a VM of pfSense on the Proxmox server
3. setup the VM to link to an existing vlan in the HomeLab on the WAN side and to an isolated vlan on the LAN side
4. check the pfSense console to make sure that the ports are configured correctly
5. add a Raspberry Pi w/SSD to the isolated vlan and bring it up; helps if it is already setup to integrate with the tailscale network
6. check that the Raspberry Pi can communicate through pfSense to the WAN side and that it has an IP within the subnet of the LAN; this will become the seat of monitoring and automation for the HomeLab
7. add XRDP to the Raspberry Pi so that I can access the GUI
8. setup Putty on my Windows laptop as an SSH tunnel to the web interface to pfSense through the Raspberry Pi; repeat with other things that I wish to monitor

Seemed like a good idea at the time.  Not sure why this would be frowned upon security wise.  I just need to be sure that I am always aware of new and clever attacks that might be possible within the network.

I'm wondering if the same thing can be done with one of my spare Edgerouter-X routers.

Update: I was able to do the same thing with the Edgerouter-X router.  So in retrospect, I have spun down the Proxmox pfSense router for use later.  I don't think that I will be getting rid of it anytime soon.  It's nice to know that I now have the ability to change the different routers that I have to give a multi-head ability to my HomeLab.

OVS Changes #1 - Updating the ubuntuServer to use OVS bridges

One of the things that I wanted to do with my network was to be able to access multiple vlans while I was away on trips or from the office.  I hit upon the use of OpenVSwitch (OVS) as a means of connecting an Ubuntu VM running under VMWare on my Windows 10 laptop.  In addition, I wanted to be able to run a set of Docker containers from my Mac Mini server and have them connected to the ubuntuServer.  So, in effect I have a SDN within my house that can be connected to through my VPN server.

I had setup bridges to multiple Ethernet ports using the following template:

iface <ethernet-port-name> inet manual

auto <bridge-name>

iface <bridge-name> inet manual

        bridge_ports <ethernet-port-name>

The setup is in a number of bridge definition files located in /etc/network/interfaces.d/; one file per interface.  The only template that is in /etc/network/interfaces is the one that I have for my day-to-day network activities.  Again, I separate out vlans for different purposes making sure that the vlans do not talk to each other except in controlled instances.

What I did to use an OVS generated bridge was to remove the bridge definition file from /etc/network/interfaces.d/ and then delete the previous bridge using:

sudo ip link set <bridge-name> down

sudo brctl delbr <bridge-name>

sudo brctl show

and then perform the following command (note the ovs addition to differentiate it):

sudo ovs-vsctl add-br <bridge-name-ovs>

sudo ovs-vsctl add-port <bridge-name-ovs> <ethernet-port-name>
sudo ovs-vsctl show

Which is done for each port that I have defined, except for the day-to-day port.  It turns out that you can use the Virtual Machine Manager to pull up the VM, reset the bridge designations from the pull-down list, hit apply, then launch the VM.  Works very well with pfSense.  The interesting thing is that the <bridge-name-ovs> will now show up in an ifconfig command, where as before (when first created with OVS) would not.  Also, there are now tap devices that show up in ifconfig, like macvtap0 and macvtap1.  Those correspond to the tap device attached to the KVM VM; created from the use of Virtual Machine Manager.  I still need to figure out how to do this with Docker.

Anyway it works!  I am able to pull up the VMs on the correct vlan now.

New Network Layout #1 - Layout of my experimental network vlan

I have been very fortunate to be able to put together pretty much any network layout that I want.  I have made some changes over the years culminating in what I have currently.  Through many trials, I have been able to get to the point that I am comfortable with the layout and how it works.  The experimental network is below:

As you can see in this diagram, I have a Gateway vlan which I connect most of my toys to.  The Gateway vlan in turn is connected, through various routers to the Internet hosted by my ISP.  For purposes of this discussion, how I connect is immaterial.  I have a pfSense router which isolates the Experimental vlan (Exp) from the Gateway vlan.  I also have a Personal vlan (Pers) which is used to monitor the Exp and is isolated from the Exp by another pfSense router.  I can update/command experiments in the Exp from anywhere in the house that is connected to the Pers.  The Exp is also connected to the outside world during Christmas (and other specific times) through a Ubiquiti WAP.  When Christmas rolls around the wifi connection is turned on to command some wifi-enabled switches and some wifi-enabled LED displays via experiments in the Exp vlan.  Since I am using a lot of managed switches, I am able to connect an Ubuntu server to the Exp, along with an RPi Cluster, and additional RPi experiments.  I also have a permanent RPi development terminal that I can use to ssh into various experiments as necessary.  The Ubuntu server supplies a number of VMs that are useful for development work including a subversion repository and some bug/issue tracking software like RedMine.