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.

Docker Test #1 - setting up test platform

So I decided to go out and get  a couple of parts to start running some Docker tests.  I was able to get a Raspberry Pi Zero WH from my local MicroCenter.  To that I added a USB-A connector (https://www.amazon.com/gp/product/B077W69CD1) and an OLED display (https://www.amazon.com/gp/product/B078D6NXFM) so that it is all one compact unit as shown here:

I wanted to be able to use the WiFi and Bluetooth capabilities as well as have a small OLED display with some control switches that I could use to control different Docker Containers as I develop them.  There are a few hoops that I need to get through to accomplish this.

• ​Install Redmine, get it configured for general projects
• Install Docker repository, integrate with Redmine (MySQL? Git repository?)
• Start Redmine project for test
• Get test install working on RPi for OLED screen, including buttons
• Install Docker on RPi
• Pull test into container, record steps,
• Run test to ensure it works correctly
• Push test container to local repository
• Split test code into two pieces, one for OLED explicitly and one for test code
• Pull two piece test code into two containers
• Run combined test to ensure it works correctly
• Push combined test containers to local repository

I am not going to do each of these in a specific order, however I will document what I do in this post and in 

posts to follow.  The first thing that I wanted to get accomplished was the setup of the Raspberry Pi.

- first, I mechanically put the docker test platform together

- next, I setup a 16GB micro SD using my Mac Mini with the following commands:

df -k

sudo diskutil unmount /dev/disk3s1

sudo dd bs=1m if=2015-02-16-raspbian-wheezy.img of=/dev/rdisk3

note that I actually used a newer version of raspbian (Stretch) since I was planning on keeping 

this as up to date as I possibly could.

- next, I changed two files on the /boot directory of the micro SD.

​

cd /Volumes/boot

nano wpa_supplicant.conf

​

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev

network={

   ssid="YOUR_NETWORK_NAME"

   psk="YOUR_PASSWORD"

   key_mgmt=WPA-PSK

}

touch ssh

- next, I unmounted the micro SD and checked to see that it was unmounted

sudo diskutil unmount /dev/disk3s1

df -k

- next, I installed the micro SD, booted the RPi, checked my router for the IP address of the RPi,

and set ssh on, SPI on, time zone, and expand microSD using raspi-config

- I rebooted the RPi and performed and update

sudo apt-get update

sudo apt-get upgrade

- next, I went to the website for the WaveShare OLED display at 

https://www.waveshare.com/wiki/1.3inch_OLED_HAT, gathered some reading material, and started

loading libraries from the instructions at https://www.waveshare.com/wiki/Libraries_Installation_for_RPi.

- I did manage to bork the install of the docker suite using:
curl -sSL https://get.docker.com | sh

I'm not sure of what happened but it appears that the setup I am using has some issues with
power. I apparently need more than some usb cables that I own of being able to provide enough
power; the most success that I have had was using a powered usb hub from Smays which also
doubles as an ethernet connector.  Now it appears that I will have to go back and remove docker
and re-install it on my system.

Project #13 - Add Patch Panels to the Network in Order to Ease Cabling

Since I seem to be moving cables from point to point, I thought that I would make sense for me to add a bunch of Patch Panels to the network so that I can minimize the runs needed between different parts of the network.  I think it would be a good idea to have keystone type Patch Panels instead of wired patch panels.

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.