Last week, Oskar Stenberg asked on Unix & Linux if it were possible to configure connectivity between two networks, both using the same address range, without involving network namespaces. That is, given this high level view of the network…
…can we set things up so that hosts on the “inner” network can communicate with hosts on the “outer” network using the range 192.168.3.0/24, and similarly for communication in the other direction?
In this question, August Vrubel has some C code that sets up a tun interface and then injects a packet, but the packet seemed to disappear into the ether. In this post, I’d like to take a slightly extended look at my answer because I think it’s a great opportunity for learning a bit more about performing network diagnostics.
A problem with the original code is that it creates the interface, sends the packet, and tears down the interface with no delays, making it very difficult to inspect the interface configuration, perform packet captures, or otherwise figure out what’s going on.
My internet service provider (FIOS) doesn’t yet (sad face) offer IPv6 capable service, so I’ve set up an IPv6 tunnel using the Hurricane Electric tunnel broker. I want to provide IPv6 connectivity to multiple systems in my house, but not to all systems in my house 1. In order to meet those requirements, I’m going to set up the tunnel on the router, and then expose connectivity over an IPv6-only VLAN. In this post, we’ll walk through the steps necessary to set that up.
In this post, we’ll walk through the process of getting virtual
machines on two different hosts to communicate over an overlay network
created using the support for VXLAN in Open vSwitch (or OVS).
The test environment
For this post, I’ll be working with two systems:
node0.ovs.virt at address 192.168.122.107
node1.ovs.virt at address 192.168.122.174
These hosts are running CentOS 8, although once we get past the
package installs the instructions will be similar for other
distributions.
This is the second in a series of posts about my experience working
with OpenShift and CNV. In this post, I’ll be taking a look
at how to expose services on a virtual machine once you’ve git it up
and running.
TL;DR
Networking seems to be a weak area for CNV right now. Out of the box,
your options for exposing a service on a virtual machine on a public
address at a well known port are slim.
I recently acquired a managed switch for my home office in order to segment a few devices off onto their own isolated vlan. As part of this, I want to expose these vlans on my desktop using Open vSwitch (OVS), and I wanted to implement the configuration using NetworkManager rather than either relying on the legacy /etc/sysconfig/network-scripts scripts or rolling my own set of services. These are my notes in case I ever have to do this again.
A long time ago, I wrote an article all about OpenStack Neutron (which at that time was called Quantum). That served as an excellent reference for a number of years, but if you’ve deployed a recent version of OpenStack you may have noticed that the network architecture looks completely different. The network namespaces previously used to implement routers and dhcp servers are gone (along with iptables rules and other features), and have been replaced by OVN (“Open Virtual Network”). What is OVN? How does it work? In this article, I’d like to explore a minimal OVN installation to help answer these questions.
Recent releases of Raspbian have adopted the use of dhcpcd to
manage both dynamic and static interface configuration. If you would
prefer to use the traditional /etc/network/interfaces mechanism
instead, follow these steps.
First, disable dhcpcd and wpa_supplicant.
systemctl disable --now dhdpcd wpa_supplicant
You will need a wpa_supplicant configuration for wlan0 in
/etc/wpa_supplicant/wpa_supplicant-wlan0.conf.
If you already have an appropriate configuration in
/etc/wpa_supplicant/wpa_supplicant.conf, you can just symlink the
file:
cd /etc/wpa_supplicant
ln -s wpa_supplicant.conf wpa_supplicant-wlan0.conf
A question that crops up regularly on #docker is “How do I attach
a container directly to my local network?” One possible answer to that
question is the macvlan network type, which lets you create
“clones” of a physical interface on your host and use that to attach
containers directly to your local network. For the most part it works
great, but it does come with some minor caveats and limitations. I
would like to explore those here.
On IRC – and other online communities – it is common to use a
“pastebin” service to share snippets of code, logs, and other
material, rather than pasting them directly into a conversation.
These services will typically return a URL that you can share with
others so that they can see the content in their browser.
One of my favorite pastebin services is termbin.com, because it
works from the command line using tools you probably already have
installed. Termbin runs the fiche service, which listens for TCP
connections on port 9999, reads any content that you provide, and then
returns a URL. For example, if I wanted to share my iptables
configuration with someone I could just run: