I’ve just put a video on Youtube that looks at the steps required to set up the external bridge (br-ex) on a single-interface system:

Normally I like to post solutions, but today’s post is about a vexing problem to which I have not been able to find a solution.

This started as a simple attempt to set up external connectivity on an all-in-one Icehouse install deployed on an OpenStack instance. I wanted to add eth0 to br-ex in order to model a typical method for providing external connectivity, but I ran into a very odd problem: the system would boot and work fine for a few seconds, but would then promptly lose network connectivity.

In my previous post I discussed a problem I was having setting a persistent MAC address on an OVS bridge device. It looks like the short answer is, “don’t use ip link set ...” for this purpose.

You can set the bridge MAC address via ovs-vsctl like this:

ovs-vsctl set bridge br-ex other-config:hwaddr=$MACADDR

So I’ve updated my ifconfig-br-ex to look like this:

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
ONBOOT=yes
OVSBOOTPROTO=dhcp
OVSDHCPINTERFACES=eth0
MACADDR=fa:16:3e:ef:91:ec
OVS_EXTRA="set bridge br-ex other-config:hwaddr=$MACADDR"

The OVS_EXTRA parameter gets passed to the add-br call like this:

Termshare is a tool for sharing your terminal in a browser session. It supports both read-only and read-write sessions, and unlike many other tools it does not require any software installation on the remote side. This makes it tremendously handy for:

• Streaming terminal demonstrations to a diverse audience, or
• Sharing a terminal session with someone without needing to much about with ssh, tmux, screen, etc.

I’ve successfully used Termshare under both Fedora (19 and 20) and CentOS. To get started on these platforms, you’ll need to install the Go language, git for cloning the termshare repository, and mercurial to support installation of some Go libraries:

I run OpenStack on my laptop, and I’ve been chasing down a pernicious problem with OVS bridge interfaces under both F19 and F20. My OpenStack environment relies on an OVS bridge device named br-ex for external connectivity and for making services available to OpenStack instances, but after rebooting, br-ex was consistently unconfigured, which caused a variety of problems.

This is the network configuration file for br-ex on my system:

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROT=static
IPADDR=192.168.200.1
NETMASK=255.255.255.0
ONBOOT=yes
NM_CONTROLLED=no
ZONE=openstack

Running ifup br-ex would also fail to configure the interface, but running ifdown br-ex; ifup br-ex would configure things appropriately.

These are my notes on making OpenStack play well with firewalld and NetworkManager.

NetworkManager

By default, NetworkManager attempts to start a DHCP client on every new available interface. Since booting a single instance in OpenStack can result in the creation of several virtual interfaces, this results in a lot of:

May 19 11:58:24 pk115wp-lkellogg NetworkManager[1357]: <info>
  Activation (qvb512640bd-ee) starting connection 'Wired connection 2'

You can disable this behavior by adding the following to /etc/NetworkManager/NetworkManager.conf:

Due to an unfortunate incident involving sleep mode and an overheated backpack I had the “opportunity” to rebuild my laptop. Since this meant reinstalling OpenStack I used this as an excuse to finally move to the ML2 network plugin for Neutron.

I was attempting to add an external network using the normal incantation:

neutron net-create external -- --router:external=true \
    --provider:network_type=flat \
    --provider:physical_network=physnet1

While this command completed successfully, I was left without any connectivity between br-int and br-ex, despite having in my /etc/neutron/plugins/ml2/ml2_conf.ini:

I wanted to learn about writing custom Puppet types and providers. The official documentation is a little sparse, but I finally stumbled upon the following series of articles by Gary Larizza that provide a great deal of insight into the process and a bunch of example code:

• Fun With Puppet Providers
• Who Abstracted My Ruby?
• Seriously, What Is This Provider Doing?

I was the presenter for this morning’s RDO hangout, where I ran through a simple demonstration of setting up a multinode OpenStack deployment using packstack.

The slides are online here.

Here’s the video (also available on the event page):

This is just here as a reminder for me:

An OVS interface has a variety of attributes associated with it, including an external-id field that can be used to associate resources outside of OpenVSwitch with the interface. You can view this field with the following command:

$ ovs-vsctl --columns=name,external-ids list Interface

Which on my system, with a single virtual instance, looks like this:

# ovs-vsctl --columns=name,external-ids list Interface
.
.
.
name                : "qvo519d7cc4-75"
external_ids        : {attached-mac="fa:16:3e:f7:75:b0", iface-id="519d7cc4-7593-4944-af7b-4056436f2d66", iface-status=active, vm-uuid="0330b084-03db-4d42-a231-2cd6ad89515b"}
.
.
.

Note the information contained here: