State of the Network in December 2024

So I have not been blogging about my network for some time.  I have been busy at the end of the year with other things including family and my newfound hobby of genealogy,  I am also adding some WoodShop activity in there as well. So, my time with my network has taken a sideline.  However, now that I find that my Retirement Community is going over to a different way of doing things, I find myself coming back to the rack for some more experiments.

• I have changed the configuration of the rack and have removed the switch for the xPod, and removed both of the special purpose Edgerouter-X boxes
• I added a 24 port 1U keystone panel at the bottom to use for projects in the future
• I removed the SLATE router from the living room, since I was not using it very much
• I am first going to start by modifying a test RPi to have two or more namespaces using OpenVSwitch to provide a NAT router function between the NS
• I will also setup the routing tables to make the two NS get their IPs from different DHCP servers
• I am also going to setup a set of Docker containers that lie on either side of the NAT router
• I want to test the idea that normal flow across the NAT is controlled
• I want to test the setup being done via Ansible
• I am going to print a rack panel to mount a GS108T and ER-X at the bottom of the rack for future projects

Project #32 - Setup Redundancy/Fallover in the Network

 I got to thinking about how my network is connected and realized that I don't have a way of reducing the outages or recording what has happened.  I have a project that was supposed to tell me the condition of the WiFi connections at any one time, but I don't use that information in any sense.  I also don't have a way for the front of the network to know what the back of the network is doing and vice versa. I don't have a graceful way to shut things down if the network fails from some external problem (mainly power outages which happen from time to time here).  WiFi outages also happen from time to time but they are less important since the backend of my network is mainly for hobby purposes.

Fallover is not apparent in the current setup of my network.  Is that important to me?  It depends on what I am doing at the moment.  If I am wood carving, not at all.  If I am working on an electronic circuit, also not important.  But if I am online how do I keep online without a problem.  I could switch from one network type to another, but is that efficient?  So a number of questions come to mind:

• first of all, what is missing from my network?
• how would the front fail as opposed to the middle and back?
• if the front goes down, how would I know?
• if the middle goes down how would I know?
• does it matter if the back is completely off?
• how can I keep my laptop in the back always available?
• is there a fall over that I can count on?
• can I log what is happening with the network? where?
• how does WiFi from other apartments into bedroom play into this?
• how do I detect how good of a connection I have?
• can I separate out living room from back bedroom?
• would it be profitable to switch AV2000s with a WiFi mesh connnection?
• could the AP-HD be used in a WiFi mesh configuration?

Alteration to the Network Input to/from the Rack

 I have been contemplating how to provide an interface into the rack that would allow me to provide an interface to the RPis and the Proxmox server on the rack.  So far I have had an interface to the Edgerouter-12 (ER-12) through a SLATE router.  However, I found out that the rule set that is being used here in the retirement community doesn’t allow me to access ports on the SLATE unless I am connected to their portal vlan.  I decided to start some experiments to find out what I can actually do with the network.  Be aware that all IP addresses within the retirement community are RFC1918 private addresses.

I had previously connected the SLATE router to the ER-12 through two AV2000 Ethernet over power interfaces, each with two Ethernet ports apiece.  So it was SLATE LAN -> AV2000 -> AV2000 -> ER-12 WAN.  The SLATE was connected into the resident vlan which does not allow conversation between hosts on the resident vlan.  However, I have been able to connect between a host on the resident vlan and a host on the portal vlan.  I decided to put an RPi connected to the portal vlan, but also connected to a vlan within the rack.  That way, I can connect my laptop, or iPhone/iPad to any port on the RPi.  To do this, I decided to implement a trunk line between the two AV2000s.

I resurrected one of the managed switches from the tubs that I brought to the community and configured a trunk port and an untagged port to a vlan (vlan32) specifically for traffic between the SLATE and the ER-12.  I configured the same vlan (vlan32) on my M4100-26G switch along with a trunk port that had the same setup as the trunk port on the managed switch from my tub stores.  By connecting these up I now have the following:  SLATE LAN (vlan32) -> managed switch -[T]-> AV2000 -> AV2000 -[T]-> M4100-26G -[vlan32]-> ER-12 WAN (vlan32).

Since I can get to the managed switch within the rack from the Admin vlan, I was able to set other vlans so that I can add an RPi Gateway (ServerNet vlan/portal vlan).  This allows me to setup a firewall with open ports to the ServerNet vlan from the portal vlan which is wifi facing.  Next up is the configuration of the RPi Gateway.