NetUpdate #01 - Review of the Current State of the Network

 As I sit here, now retired, I have been going over what components my network has and how I want to continue on with this HomeLab hobby.  Whether I want to admit it or not I have decided that making changes to this network is a sort of hobby in and of itself.  I enjoy trying out new things and making changes here and there to better how I use the network.  Since I am now retired, I have time to do things that I have been putting off in the network, i.e. to completion. Currently I have a number of home network things that I want to incorporate, such as:

• Cover the entire house with wifi 
• Bring in a Kanban board to be hosted on my HomeLab, instead of relying on Trello
• Make the Kanban board accessible from the outside by incorporating a VPN into the house
• Further isolate different portions of the network that do not need to be touching each other
• Have some built in redundancy in case things go south in the network
• Work up the security on the HomeLab, including isolation of an Admin vlan for the infrastructure
• Incorporate more Raspberry Pi units into the HomeLab that are on continuously
• Get back into Home Automation
• Get into CI/CD for developing software on the HomeLab
• Go with the Zero Trust Network theme throughout (encryption becomes important now)

These items will of course take time over the next few months and years to come.  I am reasonably happy with how things have turned out so far.

Tips #11 - Shorthand notation for network diagrams

The following are some example rules for diagram shorthand notation.  This was developed to be able to not only indicate where the connections are, but to identify the ports on each end.  Makes it easy to put a wiring list together.

• General Format: {port_from}[What_flow_contains]{port_to}
• Port designation: {device-port}
• {ONT} for Verizon ONT
• {SW1-5} for Switch#1, port 5
• {RT3-2} for Router#3, port 2
• {RT3-W} for Router#3, wan port
• {RPi05-D1} for Raspberry Pi #5, dongle on usb port 1
• {RPi05-E} for Raspberry Pi #5, ethernet port
• {PP1-15} for patch panel #1, port 15
• Flow designation: [non_tagged_vlan/Ttrunk_vlan_list]
• [32] for non-tagged vlan 32
• [T4,6,8] for tagged vlans 4, 6, and 8
• [12/T14,70] for non-tagged vlan 12 with tagged vlans 14 and 70
• [Trunk] for generic <defined elsewhere> trunk with tagged vlans; shorthand

Planning for a big change in the network

 There have been some happenings going on at the house that might involve some additions.  To that extent, the location of most of my networking equipment is probably going to change so that other work can be done to the older parts of the house.  I am thinking of moving my main router and switch to the new addition and along with it, most of the Ethernet connections for the old portions of the house and the new portions of the house.  I also have to bear in mind that I cannot use the main channel through the old part of the house anymore, I have to deal with other ways of getting the information through.

So, in retrospect, I am happy that I have learned some things about vlans, because they are going to become very handy in the near future unless I can find a different route for cabling.  That being said, I am also going to have to pull Ethernet cables from locations where they are no longer esthetically appealing, meaning I can't just have cables dangling from the ceiling in my computer room because that room will probably go away.  The rooms will change in what they are going to be used for.  I am planning on moving my Tool Room elsewhere in the house to accommodate more space to do what I wish to do.  Overall, I may end up with a box of Ethernet cables that I no longer need and go back to some shared trunk lines that make more sense.

I intend to have fun with these changes (should they happen) but at the same time I have to be conscious that the changes may have an affect on systems that I already have up and running.

Tips #10 - Network Setup for Raspberry Pi Static Experiments

After some time working with Raspberry Pis (RPi) I have been able to figure out the kind of network setup that makes sense when you develop over a period of time.  Here are some particulars of what I have found:

• Use of a Managed Switch with a trunk line to all of the vlans in the house saves a lot of running around.
• Use of Tasmota controlled extension cables can give you control of power to the RPis in case there are moments when you only want to concentrate on specific RPis for an experiment
• The managed switch on the desk where you wire up experiments gives you extra network connections when needed.
• The key is to be able to work on just what you want without having other thins on when you don’t need them to be on.

Tips #9 - The Sacrificial Port and Admin vlans

One thing I have discovered in my attempt to be secure is the use of Admin vlans.  An Admin vlan is a vlan that you use to limit changes to your network.  This is for internal network infrastructure protection. There are a couple of important points about this:

• Each router, Managed Switch, and Type 1 hypervisor that you have in your network is configured so that changes can only be made from the Admin vlan.
• All ACs/Rules setup in the network enforce the Admin vlan to be separate from all others and enforces the items in this list.
• You set up connections throughout the network so that you have to be physically connected to an Admin vlan port to make changes to any infrastructure elements in the network.
• We have a port on each device dedicated to the Admin vlan, but the Admin vlan is allowed to traverse between devices only on Trunk lines and those lines are physically protected as much as possible.
• All connections on the Admin vlan devices have to be encrypted; this is a zero trust approach.
• Encrypted Certs are controlled by a local Certificate Authority (CA) that is usually offline.
• The Admin vlan port is called the Sacrificial Port because that port is only used for the purpose of getting to the Admin vlan.
• The sacrificial port is protected with an 802.1x/Radius connection by MAC address; if you aren’t supposed to be there you shouldn’t be allowed to get in.
• The sacrificial Port is also there to make sure you can still control infrastructure devices if part of the network becomes unresponsive.
• The Sacrificial Port is also protected by a keyed Ethernet dust plug (suggest the color Red); key is necessary to take the plug out of the device.

Changeover of Ubuntu Server to Proxmox Box

 I have been wanting to try my hand at a Type 1 hypervisor for a while but it was too expensive.  I looked at ESXi, but decided that each change of the software meant a world of hurt for the VMs that would be running.  I do like to use KVM and have wanted to learn LXC containers, so I decided to change out the Ubuntu Server and go with Proxmox.

I changed the HW for the Proxmox server to have a 1TB SSD, repurposed the 4TB spinner from the Ubuntu Server to use, and reconnected the DVD drive.  I did a fresh install from the Proxmox 6.3-1 iso that I downloaded from the site and came up running very quickly.  I then added a number of OS isos, including CentOS, Ubuntu, and Fedora.  I was able to quickly spin up Ubuntu and start working on the challenge of other VMs and LXCs.

I connected the GUI/SSH port of the Proxmox to my admin vlan and ran the first Ubuntu VM on my Pers vlan.  So far so good.

HW #1 - TiVo over MoCA Peculiarities

 Over time, I have learned some peculiarities about the TiVo system:

• When I originally used the TiVo Bolt with a couple of TiVo Minis, I had all connections over Ethernet.  That worked out fine, but I did discover that the Minis did not let go of their tuners which resulted in an enormous amount of traffic over the ethernet lines.  Even placing the equipment on a separate vlan only partially solved the problem.
• Early on you were able to select the TiVo button on the Minis and cause the Mini to release its hold on the TiVo Bolt tuner.
• When I had the equipment blow out due to a power surge, I opted to get the TiVo Edge.  Updating the Edge and the Minis brought me into a condition in which I was unable to release the Minis from the Edge tuner.  I have since learned that they changed the TiVo Minis and thus they might be able to release the tuners somehow.
• Because of the amount of traffic for the TiVos on Ethernet, I decided to run the connections over MoCA.  I have a Verizon FIOS ONT that I connect to and ended up putting the Edge and the Minis on channel 15 in order to get it to work.  This was acceptable and now the traffic between the Minis and the Edge are isolated from my Ethernet, or so I thought.
• Since I needed to setup the TiVo Edge as a MoCA bridge, I was surprised to learn that the Ethernet connection to the Edge was absolutely hammering the unmanaged Ethernet switch it was plugged into.  This is to be expected since apparently the TiVo minis do not go directly to the TiVo Edge but actually go out the bridge, bounce off of the Ethernet switch and back to the TiVo Edge.  Normally, only the port that the TiVo Edge is plugged into shows any traffic (flashing LED).  Without the Ethernet switch, there would be a lot of traffic to deal with.