LXC Networking(Using LXC/LXD)(Part 3)

Now it is finally time to start delving into the technicalities of this technology in order to build something with it. I used LXC/LXD to build a network and I then configured routing using the IS-IS routing protocol. In my use case, I installed the FRRouting daemon on my containers in order to access IP routing capabilities. This software supports OSPF, BGP, RIP, LDP, PIM and even EIGRP which used to be Cisco proprietary until recently. FRRouting is an ideal open source platform for Network Engineers who have worked with Cisco IOS because of its similar syntax.

I am running an Ubuntu 16.04 VM and it is within this host that I will be creating my containers. To install LXC/LXD I found an excellent link that everyone should refer to when starting off: https://linuxcontainers.org/lxd/getting-started-cli/

Building and configuring our 1st container

In our scenario, each container will happen to be a router running FRRouting. I usually start off by properly configuring one container and I then clone it to produce my other routers. This serves as a useful template. To interact with LXD, the commands start with lxc.

To create a container use the following command:

This will have the effect of creating a container running Ubuntu and it will be named R1. If one wishes to get a shell access to the container, issue the following\ command:

As you might have noticed, our shell prompt has changed to R1 which now means that whatever command you will now issue will run inside of the recently created container. If you are coming from a Docker background, it is like attaching yourself to the container.

Once inside the container, you will quickly come to the conclusion that you can no longer access an outside network(Internet) and that you cannot even ping the host OS. A container with no network access is of no use so let us fix this issue! LXC comes with a rich set of network options, but we will be mainly focusing on the bridge interface type. Think of a bridge interface as a virtual switch to which VMs can connect to, in order to communicate with one another. This is how to create a bridge interface:

I decided to create a bridge interface that I named internet-br. I then gave my interface an IPv4 address but no IPv6 address. Some of you might wonder, how did I figure out that this IP(192.168.30.200/24) was the right one to be configured on the bridge interface? Remember that we want to give R1 the ability to communicate with the underlying Ubuntu host and the internet. To do that I had given it an IP which was in the same subnet as the network interface of the Ubuntu host. You can issue an ifconfig or ip addr on the Ubuntu host to get information regarding its network interfaces.

Note that ifconfig is now deprecated and it is now encouraged to use the ip addr command. The IP that I statically configured on the bridge interface falls in the same range as the one of the ens33 interface of the Ubuntu VM. In other words, they are now in the same subnet and can now reach each other.

I also decided to enable NAT so that I could access resources on a public network. Remember that RFC 1918 addresses are non routable on the internet. Any router on the internet that receives an IP packet with a source address from one of these ranges will simply drop the packet. That is where NAT comes in handy becomes it translates our private IP to a public one.

We still have to hook up the bridge interface to our container named R1 and this how it an be performed:

The bridge is now connected to R1's eth0 interface, but as I have learned from a wise Cisco instructor(Chris Bryant): "Trust, but always verify". Someone could tell you that they configured something properly, but do take the time to verify their work. Just don't do it in front of them ;-)

Your container does not have an IP address so what can we can do to fix the issue? Here comes DHCP to the rescue! DHCP is a protocol used by a client to automatically obtain an IP address from a server. Let us start sending out some DHCP messages in order to acquire an IP:

I brought the eth0 interface of R1 up which caused it acquire an IP(192.168 .30. 129) via DHCP. If you happen to have name resolution issues(DNS), then edit the /etc/resolv.conf file and add the IP addresses of 2 DNS servers(8.8.4.4,8.8.8.8). If everything works out correctly, you should be able to ping a website with its hostname.

The next step is to install and configure FRRouting on R1. To do that, download the file using the wget command and then install it with the debian package manager dpkg.

After issuing those 2 commands, you have successfully installed FRRouting. However, you still need to do a little bit of tweaking to get it to work. We will first enable IPv4 routing. To do that, edit the /etc/systcl.conf file and uncomment this line:

To then commit the changes to the kernel and start the FRRouting service, issues the following commands:

The sysctl command is used to modify kernel parameters at runtime. In our case, the -p option is used to load settings from /etc/sysctl.conf file which we just edited. Afterwards, we start the FRRouting service.

The next step is to enable the correct daemons that we will utilize in our setup. To do so, edit the /etc/frr/daemons file and enable zebra and isisd by setting them equal to yes.

Now to create R2, we will simply create a clone of R1. We will then start R2 and get a shell access to it. Remember that R1 is a template that we can utilize to set up our other containers.

Now that we have 2 of our containers up and running, we still need to connect them. Let us first create another bridge interface named br1. Afterwards, we will add a Network Interface Adapter(NIC) named eth1 to each container and we will connect them to each other by setting parent=br1. We must also set their type to bridged because they will connect to a bridge interface.

I think we will stop here for now. In the next article, we will start configuring R1 and the other routers with IS-IS to enable connectivity between these systems.

Resources:

https://studyforyourcerts.blogspot.ca/2015/02/an-overview-of-ipv4-and-ipv6-comptia.html