One of my favourite apps

Way back in the day, I had a need to browse a web service I had running at home – from work. As I didn’t really want to open the service up to every man and his dog (i.e with DST-NAT and Masq on my router) – I decided to run a SOCKS proxy on my work machine, which connects to a VM in my home network via SSH, and can then let me access this stuff – sort of like a budget version VPN. (Note – this was allowed by my employer! Don’t do it if you haven’t asked!)

The best way I could find to manage this in a painless way under Windows was called ssh-tunnel-manager. It’s a bit of open-source software you can find archived on Google Code – here. It’s a simple and elegant program that is written in C# that lets you do a bunch of things, one of which is manage SSH connections to remote hosts and treat them as SOCKS proxies.

This shows the GUI and how to add a tunnel

My use case, as shown above, is to SSH into a VM (, using an SSH key (can also use passwords, but boo!), and create a tunnel I can point my browser at to hit things in my home network (obviously you could also use this to access a dev box, cloud VM, anything really!). In the screenshot I have created a tunnel called “my_tun”, dynamic destinations and on local (to my windows machine) port 9090.

Now – make your OS/browser/whatever point at the tunne

Once the tunnel is configured and ‘up’, you can point things in your OS at the SOCKS proxy localhost:9090 (here I’m showing Firefox). Neat.

The problem I have faced recently is my home VM has upgraded from Debian 8 to Debian 9. In the process, OpenSSH has been upgraded and no longer supports the out of date Key Exchange algorithms that come bundled with ssh-tunnel-manager – so you get an error message saying the SSH connection can’t be stood up.

Lucky for us – the devs of ssh-tunnel-manager simply bundled a bunch of PuTTY executables that their code uses. Simply open up the directory “SSH Tunnel Manager \ Tools” and replace the 4 .exe files that come shipped with the software with recent ones from the PuTTY website – easy peasy – and it all just works again.

The replaced exes in all their glory

It’s a bit of a shame that the developers of ssh-tunnel-manager aren’t keeping their great software current – but lucky for us we can keep it going all by ourselves – for now!

Adding a VLAN in Ubuntu 18.04

For some reason, networking in Linux keeps on changing. Not only changing the well known naming scheme for ethernet interfaces (why), but now the way to manually set up IP addressing, VLANs etc in Ubuntu 18 has changed. Gone is the simple to use /etc/networking/interfaces file, and in its place some YAML and a new tool, netplan. Fine..

I needed to add a VLAN tagged interface to a physical NIC, which I used to call eth1.. So what I ended up doing was creating this YAML file in the /etc/netplan directory and putting in the following config:

james@james:/etc/netplan$ cat 1-eth1-vlan.yaml
version: 2
ens192: {}
id: 999
link: ens192
addresses: [“”]
– to:

What this does is:

  • Define a network (version 2 seems to be a requirement but I haven’t looked it up)
  • Binding the VLAN to physical NIC ens192
  • Defining a VLAN, with a VLAN-ID (or “id”), an IP address
  • Putting in a static route

Using iDRAC with a gen 11 Dell Server (on a Mac) – phew

This post is really a persistent note for me. Every now and then I end up going down the road where I need to administer a Dell server (typically one I can afford for home use, like a Dell R610) – only to find that everything I rely on at work (like having windows/java/etc) is out the door. Here are some steps to allow access to the iDRAC on Dell Rx10 server from a Mac, using Chrome as a browser.

1: Install Java SRE –

2: Log into the web front-end of your iDRAC (mine is at for future reference)

3: Go to the Console/Media tab and select ‘Configuration’

4: Change the plugin type from Native to Java, and disable video encryption.

5: Open System Preferences on your Mac, and find Java. Go to the ‘Security’ tab and add the https address of your iDRAC to the list of excepted sites.

6: You need to edit this file

/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/

And comment out the line that starts with “jdk.tls.disabledAlgorithms”

7: Back in the iDRAC web front-end, you can click ‘Launch’ on virtual console. This will download a .jnlp file (or a hideously renamed one, in my case). Rename this file viewer.jnlp (and accept OSX complaining about changing file extension).

8: Edit viewer.jnlp with a text editor (TextEdit or Nano will do) – and replace the ‘user’ and ‘passwd’ fields (which will be hashed numbers/text) with your iDRAC login details. Note – this step is optional, but it means you can open the console without having to log into iDRAC every time.

Should be good to go!

Juniper VMX Trial and Error

I have spent some time scratching my head on ESXi-based VMX and I thought I would share some experience. This isn’t meant to be a guide, or replace Juniper’s own docs, but to supplement (and help me remember stuff 2 years later).

My setup:

Dell server, 10 Core Xeon E5-2640 (20 thread), 48GB RAM, ESXi 6.5

I have deployed the OVAs from Juniper for VMX 17.4R1.16.

vCP: 1CPU, 4GB ram, 2x e1000 NIC (br-ext and br-int port groups)

vFCP: 14 CPU, 16 GB RAM, 2x e1000 NIC (br-ext and br-int) plus 2x e1000 NIC (to be my ge-0/0/0 and ge-0/0/1)

The br-ext port group is just on an existing DHCP enabled vSwitch, and I can SSH into the VMX components fine. It seems that in Junos 17.4, the vFPC also gets a DHCP address for its ext bridge interface, which is nice.

The br-int port group is on its own dedicated vSwitch. All my vSwitches have MTU 9000, all security options enabled (promiscuous mode, mac forging etc.. All on).

My two ‘WAN’ interfaces, which are vNIC 3 and 4 under ESXi are there to prove things are working (I have a Linux VM attached to each, via a dedicated vSwitch/port group each). I run simple iperf tests across them, no routing protocols involved at this stage. In this lab/test I am using no physical NIC, so there is no bottleneck – nor is this a particularly realistic test for the real world deployment of VMX.

My topology is:

VM1 — VMX — VM2

Confusingly for you, my VM1 and VM2 are actually called Bird and Space Host. Don’t ask. Again, I am using a vSwitch as a cable between VM and VMX, with no physical cabling required. The br-ext link connects vCP, vFPC and an external network for management.

Lite-mode Vs Performance mode:

By default, VMX runs in performance mode. I find on ESXi (due to dpdk polling), that performance mode absolutely kills my allocated CPU threads. My ESXi reports running around 95% CPU load when a performance mode FPC is sitting idle. I find this has a major impact on TCP throughput, as well as making the ESXi box hopeless for doing other tasks. I am not a kernel expert, so I don’t really understand the implications of this CPU load.. I will leave it alone.

The real issue I had with VMX was before I even got off the ground. I was using the vFPC with 4 NIC (2 for bridges, 2 for ge- ports). By default, I assigned e1000 virtio NICs to the VM. This ended with me being stuck in ‘Present Absent’, which is what ‘show chassis fpc’ would show me for FPC 0. By default, you are in performance mode – and that doesn’t like e1000 NICs. Change the two “ge-” interfaces, in my case vmnic3 and vmnic4 to ‘VMXNET3’ and it fires up and starts passing packets. This appears to be a bug specific to Junos 17.4R1 – according to a phone-call I had with JTAC.

As I have 1Gbit/s licenses for the VMX, lite-mode is fine.

Detailed ESXi Setup

One of the things I find painful with VMX is the quality of the documentation, particularly for VMWare. Juniper releases OVAs for this platform, but shrinks away from documenting the nuts and bolts sufficiently.

Starting with the vCP OVA:

VMWare details of vCP VM

I’ve set the machine to have 1 CPU, 4GB of RAM and I’m using two port-groups for the NICs, br-ext and br-int, as described earlier in this post.

I also upgraded the VM hardware version to 13 (the OVA comes as version 10). This was based on a blog post I read in the middle of the night. I wish I could say why this mattered (JTAC suggested this only improves things when using KVM-based VMX and SR-IOV, but hey).

Summary of vCP

Now onto the vFPC VM:

VMWare details of vFPC VM

As you can see in the screenshot, I have set the 16GB of memory to be reserved. This helped with performance, particularly of my testing VMs running on the same host. I have also expanded one of my ‘WAN’ interfaces to show that it’s an E1000 NIC connecting to one of my Linux hosts.

The VM hardware version of my working vFPC is version 10.

Summary of vFPC

It’s best to set up all of this hardware in advance of switching either of the VMs on. Once you do, your vFPC should pull down a DHCP address from your br-ext bridge (mine is set up as a port group on my vSwitch0, which also shares kernel management for the ESXi itself). The vCP won’t get a DHCP address by default, as that’s not supported on fxp interfaces. I configure mine via the ESXi console.

Is it working?

Once you’ve booted both VMs, you will need to give them about 4-5 minutes. From my own bashing around in the log files, it seems that the vFPC pulls down some config from the vCP and then starts up RIOT, the process which is meant to emulate the MX series’ Trio chipset.

Note – under 17.4R1.16, the vFPC won’t work correctly by default (we set our interfaces to e1000) – so you will need to do the following to enable lite-mode, from the vCP CLU (login as root, no password. Then enter ‘cli’)

james@ch-vmx-1> edit private
james@ch-vmx-1# set chassis fpc 0 lite-mode
james@ch-vmx-1# commit and-quit

james@ch-vmx-1> request system reboot [Y]

This (plus a reboot of the vFPC VM for good measure) will put you into lite-mode. Once this reboot (~5mins) process has finished, you can check 2 important things from the vCP CLI. First, check the chassis hardware and see if we’re in lite-mode for real:

james@ch-vmx-1> show chassis hardware
Hardware inventory:
Item             Version  Part number  Serial number     Description
Chassis                                VM5ACC9ED832      VMX
Routing Engine 0                                         RE-VMX
CB 0                                                     VMX SCB
FPC 0                                                    Virtual FPC
  CPU            Rev. 1.0 RIOT-LITE    BUILTIN
  MIC 0                                                  Virtual
    PIC 0                 BUILTIN      BUILTIN           Virtual

From here, you can see FPC 0’s CPU is listed as RIOT-LITE. That’s what we wanna see.

Next, you can check the status of the FPC itself:

james@ch-vmx-1> show chassis fpc 0
                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer
  0  Online           Testing   4         0        3      4      4    2047        7          0

This garbled-by-my-wordpress-theme output shows the FPC in slot 0 is up and running. The temperatire will never move on from ‘testing’ as it’s not a real probe (but it is on a real Trio-based FPC!)

To test the performance (another post on that one day, perhaps) – I fire some packets from VM1 to VM2. They rely on the VMX to do the routing, as they are in different subnets. I’m using some quite expensive hardware/software here to send a few packets around a pretend network – but it proves the thing works:

[client - sender]
james@VM1:~$ iperf -c -i 1
Client connecting to, TCP port 5001
TCP window size:  325 KByte (default)
[  3] local port 49127 connected with
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   128 MBytes  1.08 Gbits/sec
[  3]  1.0- 2.0 sec   119 MBytes   997 Mbits/sec
[  3]  2.0- 3.0 sec   118 MBytes   992 Mbits/sec
[  3]  3.0- 4.0 sec   118 MBytes   988 Mbits/sec
[  3]  4.0- 5.0 sec   119 MBytes   996 Mbits/sec
[  3]  5.0- 6.0 sec   118 MBytes   992 Mbits/sec
[  3]  6.0- 7.0 sec   118 MBytes   994 Mbits/sec
[  3]  7.0- 8.0 sec   118 MBytes   993 Mbits/sec
[  3]  8.0- 9.0 sec   119 MBytes   995 Mbits/sec
[  3]  9.0-10.0 sec   118 MBytes   991 Mbits/sec
[  3]  0.0-10.0 sec  1.17 GBytes  1.00 Gbits/sec
[server - receiver]
james@VM2:~$ iperf -s -i 1
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[  4] local port 5001 connected with
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec   127 MBytes  1.06 Gbits/sec
[  4]  1.0- 2.0 sec   119 MBytes   996 Mbits/sec
[  4]  2.0- 3.0 sec   118 MBytes   991 Mbits/sec
[  4]  3.0- 4.0 sec   118 MBytes   990 Mbits/sec
[  4]  4.0- 5.0 sec   118 MBytes   994 Mbits/sec
[  4]  5.0- 6.0 sec   118 MBytes   992 Mbits/sec
[  4]  6.0- 7.0 sec   118 MBytes   993 Mbits/sec
[  4]  7.0- 8.0 sec   119 MBytes   995 Mbits/sec
[  4]  8.0- 9.0 sec   118 MBytes   993 Mbits/sec
[  4]  9.0-10.0 sec   118 MBytes   991 Mbits/sec
[  4]  0.0-10.0 sec  1.17 GBytes   999 Mbits/sec

So there we go, a VMX in lite-mode, throwing 1Gbit/s of iperf traffic around.

Things that might be going wrong

Getting to this stage took me a while, so here are some things you might be finding are going wrong trying to use ESXi and VMX together.

1- Can’t access vFPC

This might be caused by a fairly random problem I’ve seen in 17.4R1 where 2 of the 3 NICs that the vFPC automatically stands up don’t show. You will be left with ‘int’ only. Console into the vFPC and have a look (root/root will get you in):

root@localhost:~# ifconfig| grep Link
ext       Link encap:Ethernet  HWaddr 00:50:56:9f:94:8b
int       Link encap:Ethernet  HWaddr 00:50:56:9f:03:28
lo        Link encap:Local Loopback

That shows 3, so in my case it’s working as you’d hope

2 – Throughput sucks

Check your VMX license is applied. Even the trial license is good enough for most lab cases.

james@ch-vmx-1> show system license
License usage:
                                 Licenses     Licenses    Licenses    Expiry
  Feature name                       used    installed      needed
  scale-subscriber                      0           10           0    permanent
  scale-l2tp                            0         1000           0    permanent
  scale-mobile-ip                       0         1000           0    permanent
  VMX-BANDWIDTH                         0         1000           0    permanent
  VMX-SCALE                             1            1           0    permanent

Licenses installed:
  License identifier: xxxx
  License version: 4
  Software Serial Number: xxxx
  Customer ID: xxxx.
    vmx-bandwidth-1g - vmx-bandwidth-1g
    vmx-feature-base - vmx-feature-base

You can see here I have a 1000Mbit license for bandwidth. Go me.

If you have a license applied and throughput still sucks, you might have a resource problem or some other issue. These can maybe be discussed in the comments below, but you might do better running up a thread in the Juniper official VMX support forum. Good luck!



Step by step guide: Preparing a Debian VM for Junos Automation

This is a bit specific, and, like most of my posts – a cheap way for me to remember something next time I need to do it 🙂

I am currently obsessed with network automation. My favourite ‘stack’ at the moment is Ansible, git and the Juniper Ansible libraries. There are a thousand ways to skin this particular cat, but for my current project (enforcing ‘golden config’ across a large number of devices) – this limited number of tools does the job.

As with most cool new tech, there are hundreds of posts and docs, most of which are similar enough to give the illusion of cohesion, but all critically different when it comes to the nitty-gritty, causing confusion and angst. At least, that’s my impression.

So – if you want a Junos Automation machine, ready to attack your network with Python and Ansible, follow along.

I’m using Debian 8, a fresh install. Splat these commands in to set up the bits you will need. I have tested these and find they work, resolving the dependencies and resulting in no errors.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install python-pip ansible git software-properties-common
sudo pip install -U pip setuptools
sudo ansible-galaxy install Juniper.junos
sudo pip2 install git+

You’ll end up with Ansible installed in /etc/ansible, the freshest Juniper library for Python (version 2.7) interaction via Ansible. You’ll also have git installed, one for installing the Junos EZNC package and for future use.

My end goal here is to use this system to completely automate my network, but for the time being – we’re good to start using Ansible to take baby steps towards that goal.

I have created a directory called lab-automation, and in it three sub-directories. One called scripts (for my playbooks and shell scripts), one called logs and the other called configs, for my configs! I have created a basic Ansible playbook, which uses the previously installed Juniper.junos role, and connects to my lab routers (mx1-mx4, as defined in the /etc/ansible/hosts file and my /etc/hosts file).


- name: config getter
  hosts: all
  gather_facts: no
  connection: local
    - Juniper.junos

    - name: Pull Down The Configs
        host: "{{ inventory_hostname }}"
        user: "neteam"
        logfile: ../logs/get_config.log
        format: text
        dest: "../configs/{{ inventory_hostname }}.jconf"

This will run through all my defined hosts, and using the Juniper role (installed previously, living in /etc/ansible/roles) – grab my router configs and store them in ‘configs’ directory. Note, I am using a username (same as my Linux user) and SSH key authentication, because I hate passwords and refuse to learn how to use them in Ansible 🙂

If I run this playbook, what happens?

neteam@lab-ansible:~/lab-automation$ ansible-playbook scripts/config_getter.yml

PLAY [config getter] **********************************************************

TASK: [Pull Down The Configs] *************************************************
ok: [mx3]
ok: [mx1]
ok: [mx2]
ok: [mx4]

PLAY RECAP ********************************************************************
mx1                        : ok=1    changed=0    unreachable=0    failed=0
mx2                        : ok=1    changed=0    unreachable=0    failed=0
mx3                        : ok=1    changed=0    unreachable=0    failed=0
mx4                        : ok=1    changed=0    unreachable=0    failed=0

Great. My files are pulled down from the network. I can do all kinds of fun things with the Juniper Ansible library – and so can you. Check it out here.

Juniper to Fortinet ISIS configuration

Hoo boy. I have been trying to configure a small mesh network for a fault-resilient office setup. In my network, I have a ‘square’ setup, two VMX routers, two Fortigate virtual firewall appliances, all running on top of ESXi 6.5 (two physical hypervisors). It looks like this:

Anyway. In order to redistribute the default route(s) received from the upstreams, I wanted to use iBGP inside the ‘square’ of devices.. iBGP relies on an IGP, so I chose the coolest one available, ISIS.

This is a very simple setup, but there was no way I could get an adjacency to form between the router and firewall (green to black in the diagram). I tried 100 things (changing hello intervals (pointless!), LSP generation times, MTU, MTU, MTU and several other desperate things like disabling hello-padding, enabling and disabling ‘adjacency checking’ on the Forti-devices).. Nothing.

Eventually, I enabled trace-options on the Junos side of things – I could see my adjacencies with the Forti-devices stuck in the ‘Initializing’ phase, implying the three-way-handshake was busted.. The traceoptions showed some guff, but nothing that pointed to an easily solvable problem (i.e. not MTU)..

Finally, using the debug features of the Fortigate box, I found:

id=20301 logdesc="Routing log" msg="IS-IS: PDU[RECV]: P2P-Hello IS-

Neighbor(port2-0192.1681.0020) IPv6 protocols supported mismatch

Bearing in mind, there isn’t a single bit of IPv6 config on any of these devices (yet, it’s going to be fully dual stack, don’t worry!) – so what was up.. Turns out, the Fortigate devices were a bit sensitive, and needed the following knob in my Juniper ISIS config:

james@vmx-2> show configuration protocols isis | display set
set protocols isis no-ipv6-routing

All of a sudden.. My ISIS adjacencies are up and solid.

Hopefully this will be useful to some sucker in future who chooses to use ISIS in their corporate network 🙂


Quick recipe for Layer2 Circuit local switching

I am always forgetting how to do l2circuits in Juniper, partially as there seem to be a zillion ways to configure encapsulation and VLAN handling, all of which seem to commit but seemingly very few seem to work.

This is a super quick note-to-self which describes how to locally switch (could simply be extended to LDP-signalled l2circuit over an MPLS core though) a point-to-point circuit, one end VLAN tagged and the other end untagged.

For this example, we have two interfaces – both on a single MX router called mx2.lab. Our ‘tagged’ or NNI facing interface is xe-0/0/1, and we’re using VLAN 250. Our ‘untagged’ or CPE facing interface is xe-2/2/1, not using a VLAN at all (dedicating the whole interface). This can (again) be expanded to use S/C tags, multiple encapsulations etc, but I’m not going there yet.

What we’re aiming to see is traffic coming in on a VLAN tagged interface and being locally switched to an untagged interface. To lab this, I have a VLAN-tagged interface with IP and an untagged VM, sitting on – when it’s configured, they should be able to ping one another.


We need 3 chunks of config to make this config work:

  • The tagged interface
set interfaces xe-0/0/1 unit 250 description "Tagged interface for L2Circuit Test"
set interfaces xe-0/0/1 unit 250 encapsulation vlan-ccc
set interfaces xe-0/0/1 unit 250 vlan-id 250
set interfaces xe-0/0/1 unit 250 family ccc
  • The untagged interface
set interfaces xe-2/2/1 description "Untagged interface for L2Circuit Test"
set interfaces xe-2/2/1 mtu 9100
set interfaces xe-2/2/1 encapsulation ethernet-ccc
set interfaces xe-2/2/1 unit 0 input-vlan-map push
set interfaces xe-2/2/1 unit 0 input-vlan-map vlan-id 250
set interfaces xe-2/2/1 unit 0 output-vlan-map pop
  • The l2circuit config
set protocols l2circuit local-switching interface xe-0/0/1.250 end-interface interface xe-2/2/1.0
set protocols l2circuit local-switching interface xe-0/0/1.250 ignore-encapsulation-mismatch
set protocols l2circuit local-switching interface xe-0/0/1.250 ignore-mtu-mismatch

With that config loaded on mx2.lab, packets will fly between the untagged VM on xe-2/2/1 and xe-0/0/1.250


How to connect your Raspberry Pi to eduroam

Note – I took much of the code snippet here from ‘Sruc‘ on the RPI forums, but wanted to post a clear method that I know works. Cheers Sruc!

The eduroam network (for universities, researchers and highschools around the world) is a great thing. One login lets you connect to wifi access points all over the place, as long as you’re enrolled in or working for a participating organisation.

One thing that bugged me out of the box with the Raspberry Pi (in my case, a Raspberry Pi 3 running Pixel) – was the Enterprise WPA wifi not working out of the box.

Follow these simple steps to get it working:

  • Open a Terminal from your Pi’s gui (or just use the shell if you don’t have a gui!)
  • Open up the wpa_supplicant.conf file:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
  • Paste in the following, changing the bits you normally use to log in to eduroam (your university/whatever email and password is normally what you use for authentication)

(Add this snippet below what’s already in the file, change the ‘identity’ and ‘password’ fields!)

  • Save and exit the editor (in nano that’s CTRL-O, Enter, CTRL-X)
  • Now we need to tell the Pi to reload the file, again, in the Terminal or shell
sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
  • I find a reboot here is necessary, so flip the Pi and wait for it to boot. When it returns, you should be connected to eduroam (as long as your Pi can see the eduroam SSID!)

Note – I am not sure if this will work for all instances of eduroam, as some Universities etc handle authentication differently – please check your organisation’s help pages or get in touch with them first – they usually have a guide.

Very useful Ubuntu 16 Networking Note

I hate when things change for no good reason. This week, it’s the interface naming of ethernet on Ubuntu 16. No more does it default to ‘eth0’.. It uses some other ‘ens’ style.. Garbage!

First up, find your ethernet interfaces (this VM has 1 interface to start):

dmesg | grep -i eth
james@GREG:~$ dmesg | grep -i eth
[ 1.479809] vmxnet3 0000:03:00.0 ens33: NIC Link is Up 10000 Mbps

Bah, looks gross!

Fix it by editing your grub config:

sudo nano /etc/default/grub

Change the line GRUB_CMDLINE_LINUX=””

to  GRUB_CMDLINE_LINUX=”net.ifnames=0 biosdevname=0″

Regenerate your grub file:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Edit your /etc/network/interfaces file, change the names to eth0, eth1 etc

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static

Reboot, and voila.

If you add a new interface, it will come on as ethX, following the already provisioned interfaces.

Now it looks better (I added a new 10G interface, and it comes in as eth1)

james@GREG:~$ dmesg | grep -i eth
[    1.479809] vmxnet3 0000:03:00.0 eth0: NIC Link is Up 10000 Mbps
[    2.498115] vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps

Awww yeeeeah

Openstack Newton – Provider Network Issue

When playing with an Openstack POC recently, I nearly pulled my hair out. I am running a flat provider network between my compute nodes (all Ubuntu 16.04), which connect via  Cisco 2900 with an inbuilt switch module. The Cisco has gateway addresses for the dual-stack host networks. I was using native IPv6 and NAT’d private space for IPv4.

Whenever I went to launch an instance, DHCP would work (SLAAC for v6), and the Horizon front-end would show the generated addresses assigned to the instance. Looks good. Going into the console of the instance, I’d see (with ifconfig) no IP addresses on my host NIC.. Looking in the “neutron-dhcp-agent.log” log, I would see:

2017-03-24 23:49:44.169 2476 WARNING stevedore.named [req-6710e8a6-5991-446e-b8d2-5af6c9d27625 – – – – -] Could not load neutron.agent.linux.interface.BridgeInterfaceDriver

Whenever an instance was on. Cycling over and over for the number of instances. When I looked at the bridge status (in my topology the eno4 phyical interface of the compute/controller nodes are connected to the physical provider network), I would not see eno4 in the bridge created to connect hosts to physical. The way Openstack Neutron does this is to build a bridge, then add the physical and TAP interfaces). Mine was missing. Why…

Turns out – I had an IPv6 DHCP scope on my Cisco provider network interface facing the Openstack environment. As soon as I removed this piece of config (and simply left the IPv4 and IPv6 gateways on that interface) – eno4 showed up in the bridge and it all went smoothly.

What a mission.