OVS Changes #3 - spinning up Home Assistant in a Docker Container

Now that I know how to connect a Docker Container to a specific bridge through the OVS, it's time to spin up an example.  I am trying to get into Home Automation and I have settled on the use of Home Assistant (http://www.home-assistant.io).  I am going to be reporting more on the use of this controller since it will pretty much control what I do within my house.

I have settled on the use of Z-Wave Plus components throughout the house because of the added distance and mesh connection improvements.  Home Assistant gives me the flexibility to connect to all sorts of things that normally don't go together because you know business.  Every company out there wants to do there own thing and control the whole market.  I'm not buying it if I can't use it with other companies products that have a capability I want.

I am going to first spin it up on the Experimental vlan until I am able to configure everything the way that I want.  I am intending on using OVS to connect ways of having devices on separate vlans and integrating them within the home system.  Anyway, that is the plan.

According to https://www.home-assistant.io/docs/installation/docker/, I have to do the following on Ubuntu:

$ docker run -d --name="home-assistant" -v /path/to/your/config:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant

Except in my case I need to have the container attached to a specific OVS bridge, so:

$ docker run -d --name="home-assistant" -v /path/to/your/config:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant

Update: well that didn't work out as planned.  I sent the following commands:

$ docker run -d --name="home-assistant" -v <my_HA_directory>:/config -v /etc/localtime:/etc/localtime:ro --net=none homeassistant/home-assistant

$ ovs-docker add-port <my_ovs_bridge> eth1 home-assistant --ipaddress=<home-assistant-ip>/24

What I ended up with was the home assistant available on every vlan that was in the ubuntu server.  I only want it on the <my_ovs_bridge>.  So what do I do to get it there?
​

I've gone overboard with the SD Cards

I was sitting at my kitchen table last night getting all of my RPi SD cards organized.  I just realized that I have gone overboard - I now have a total of 70 plus cards that do various things and are in various levels of completion.  Do you think I have a case of hoarder fever?  Must needs to reuse cards that I haven't touched in a while.  I know it is that many cards since I have all of them numbered.  Good grief!!

OVS Changes #2 - getting Docker containers to attach to the OVS bridges

Now that I have been successful with KVM VMs and their connections to the OVS bridges, I need to figure out how to do much of the same thing with Docker containers.  One of the reasons that I run ubuntuServer is because it is very easy (so they say) to get Docker containers running.  So now, what I am going to attempt is to startup a Docker container attached to one of the OVS bridges, used on a pfSense KVM VM.

So according to the site, http://containertutorials.com/network/ovs_docker.html, I have to do the following steps:

Install OVS (already done on my system) -

Install OVS-docker utility (already done on my system) -

Create an OVS bridge (already done on my system, except the bridge doesn't have an IP address) -

Create the docker container

Connect the container to the OVS bridge, such as

$ ovs-docker add-port ovs-br1 eth1 <container_name> --ipaddress=<ip_address_for_container>

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.

Surprised at the changes in 18.04 LTS

So I went ahead and updated my Ubuntu Server from 16.04 LTS to 18.04 LTS.  I did this in order to stay current with the loads from ubuntu and look at the new stuff at the same time.  So I performed the upgrade over the weekend; I did have some issues with the vlan setups but didn't think anything of it.  I sort of kinda followed the instructions here.  Now I have discovered that the way that Ubuntu handles networks has completely changed in 18.04 LTS (see article here on NetPlan).

So now I need to look into NetPlan and figure out how it impacts with OpenVSwitch (OVS) since I am about to use that to do some remote vlan stuff.

Update: after requesting some help in the Reddit Ubuntu forum, I found out that NetPlan is not a typical Linux community project.  This means that it is somewhat of an Ubuntu.com project.  That being said, the responder showed me how to take NetPlan out of the equation.  Instructions are at UbuntuGeek, and are duplicated here:

Note:- This is not recommended and this is for advanced users only

Edit the /etc/default/grub file

sudo nano /etc/default/grub

Add the following line

GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true"

Save and exit the file

Now update the grub using the following command

sudo update-grub

You need to install ifupdown package

sudo apt install ifupdown

Now you can add all the interface details in /etc/network/interfaces file and reboot the ubuntu PC/server.

The Network That Could #1 - Introduction

I have had people ask me what I do with my network at home.  To that, I can only say that I use it as a playground for whatever strikes my fancy.  My job is in engineering and lately it has been more focused on security engineering.  I don't get a lot of hands on at work at my level.  My home network is a way of letting off steam and learning some things in the process.  So here is a simple intro to what I do with my network in case you were interested.

I mostly use my home network for experimentation but I also have parts of the network which are specific to media streaming (TiVo, Plex) and outbound connection.  My "homelab" is rather distributed throughout the house depending on its purpose.  In my home network I have 7 managed switches (Netgear GS108Tv2 / GS116Ev2 / GS108Ev3) spread throughout my house, all connected with each other through a series of "trunk" lines. Each "trunk" line carries multple vlans in a 802.1q sense. Some of the vlans are "patch" vlans which give me the ability to patch an Ethernet connection from one location to another.  I have the switches set to prevent crossover between vlans and isolate the management to a specific vlan that is normally not connected to anything. Ports that are not used are set to a "fake" vlan that goes nowhere out of the switch for security.

I play around a lot with media, Raspberry Pis, hacking, Weather station things, and just learning weird networking things. I have a couple of servers in the network running VMs (not located in the same part of the house) and at any moment I might want to access something across the network and might need a cable or two for some reason. I just change the ports to use one of several predefined "patch" vlans and connect up to the switches. It saves a lot of time trying to pull a new Ethernet cable, especially if it is going from the basement to the attic and on to the roof.

I have one vlan, full of Raspberry Pis and Arduinos, with several ongoing projects: e.g., one is a settup to use for Christmas light switching and another is a midi project in containers that use Raspberry Pis loaded with Docker. The other vlan is being used for some experiments with routing protocols, including Quagga and IPSec within IPSec tunnels for security.

I have a hacking vlan in my home network. There are a lot of VMs and things there that are VERY vulnerable to attack - on purpose, so I can personally learn how to break into them.  This vlan is very isolated from the outside.

I'm also cheap!  I'm using Ubuntu (free) to host VMs under KVM (free) on a <$250 AMD 8core FX with 16GB memory and 1TB drive with a stolen (from another project) cabinet and power supply. I have also been playing with Docker in the same setup. I've got a number of Linux VMs and also Windows 7 and Windows 10 VMs that started out as VMWare VMs.  The Ubuntu box provides a number of pfSense VMs for routing between some vlans.  This is in addition to a Mac Mini server and several Raspberry Pis setup in multiple clusters for experimentation.

Basically, all of this grew out of getting familiar with "networking stuff" and adds to my knowledge on the job as a Systems/Software/Security Engineer.

Added some patch panels to the network over the weekend

Well, I broke down and finally added a couple of patch panels (PP) to the homelab over the weekend.  I was getting tired of having to reconstruct connections whenever I wanted to move equipment from one room to the next.  My homelab is distributed across the house and I like to think that I can move and update things at will.  The problem was that I could not conveniently switch things around because of having to move existing Ethernet cables from one location to the next.  What I needed was a set of Ethernet cables that didn't move but still allowed me to connect at will, hence the use of patch panels.

Right now I am concentrating on getting the minimal number of patch panels up along with keeping equipment and connections the same.  This is little more than routing an Ethernet cable to a patch panel and then using a patch cable to go from the PP to the device.  In the throes of putting the initial two PP together, I made the mistake of routing a piece of equipment to the patch panel as though it were part of the infrastructure.  I now know to keep lines primarily from PP to PP within the network.

I started out with a 16 port and one 24 port PP that I placed in two locations.  The first location was in the tool room where my main switch is located, that got a 16 port PP.  The main switch is like the hub for most of the other managed switches.  The second location was part of the computer room shelf where I am not concentrating most of my efforts.  I originally drew up a diagram of what I wanted to do first followed by a diagram of where I wanted to go.  I followed the first diagram pretty closely but ended up with a lot of differences due to the position of the ports and other equipment that was around it.