Ask Your Question
3

Neutron/OVS VLAN-tagging of DHCP requests?

asked 2014-01-06 21:38:58 -0500

ross-golder gravatar image

updated 2014-01-06 21:41:30 -0500

Hi guys,

I'm having trouble figuring out why a Cirros test VM on my compute node is not obtaining a DHCP address from my controller node, over a Neutron/OVS/VLAN arrangement. So, the scenario in more detail...

2x DELL PowerEdge R420s, running stock Ubuntu 13.10 Saucy (OpenStack Havana). 2x NetGear GS724 switches

Primary switch is for 192.168.1.0/24 traffic, with gateway router at 1.1. Both DELLs connected via their primary (em0) interface.

Secondary switch is for 10.0.0.0/24 traffic, with no gateway. Both DELLs connected via their secondary (em1) interface.

First DELL is called 'controller1'. Second DELL is called 'compute1'. I'll focus on the compute node's configuration for now, as I'm having trouble tracing where the DHCP request packet goes within this domain.

First, the underlying /etc/network/interfaces network config...

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto em1
iface em1 inet static
    address 0.0.0.0

# The primary network interface
auto br-ex
iface br-ex inet static
    address 192.168.1.11
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1

auto em2
iface em2 inet static
    address 0.0.0.0

auto br-int
iface br-int inet static
    address 10.0.0.11
    netmask 255.255.255.0

OVS bridges configured as per 'ovs-vsctl show'...

b8840243-e3a1-43de-badb-cfbe0ce1405c
    Bridge br-int
        Port int-br-ex
            Interface int-br-ex
        Port "em2"
            Interface "em2"
        Port phy-br-int
            Interface phy-br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tapc015b393-e7"
            tag: 3
            Interface "tapc015b393-e7"
        Port int-br-int
            Interface int-br-int
    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
        Port "em1"
            Interface "em1"
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "1.10.2"

The tap interface belongs to my 'test1' Cirros guest, and I can see DHCP request packets on it if I tcpdump it as the VM boots.

I have the OpenVSwitch (OVS) plugin configured as follows:

[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet2:1000:2999
local_ip = 10.0.0.11
bridge_mappings = physnet2:br-int

[agent]

[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[database]
connection=(snipped)

FTR, the controller node is the same, with the local_ip being 10.0.0.11

On Neutron, there is a virtual 'testnet':

+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | c7497b77-a716-4ad6-8d44-3fa9b2dcfaf0 |
| name                      | testnet                              |
| provider:network_type     | vlan                                 |
| provider:physical_network | physnet2                             |
| provider:segmentation_id  | 1001                                 |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | 8821440b-839b-4e91-85ca-1f2651ed6896 |
| tenant_id                 | 83b3ca4a4ec94070904d5112aeb1baab     |
+---------------------------+--------------------------------------+

And a virtual 'testsubnet':

+------------------+--------------------------------------------------+
| Field            | Value                                            |
+------------------+--------------------------------------------------+
| allocation_pools | {"start": "192.168.9.2", "end": "192.168.9.254"} |
| cidr             | 192.168.9.0/24                                   |
| dns_nameservers  | 8.8.8.8                                          |
| enable_dhcp      | True                                             |
| gateway_ip       | 192.168.9.1                                      |
| host_routes      |                                                  |
| id               | 8821440b-839b-4e91-85ca-1f2651ed6896             |
| ip_version       | 4                                                |
| name             | testsubnet                                       |
| network_id       | c7497b77-a716-4ad6-8d44-3fa9b2dcfaf0             |
| tenant_id        | 83b3ca4a4ec94070904d5112aeb1baab                 |
+------------------+--------------------------------------------------+

My confusion seems to arise from not being quite clear about where the VLAN id is being set and what to exactly, so I can trace the packet beyond the tap interface.

It seems I am not quite grokking the relationship between the 'provider:segmentation_id', and the OVS 'tag id'. The segmentation_id seems to have been correctly taken from ... (more)

edit retag flag offensive close delete

Comments

I have the same problem and same question. Our setup is a little different with a XenServer virtualization host, controller node (keystone, glance, nova-api, etc.), compute node (nova-compute), and network node (neutron). I want to manually configure the vlan tag on the cirros test vm for testing...

Andrew Kinney ( 2014-02-06 19:34:51 -0500 )edit

...but I can't find any docs on cirros network configuration. I think I might be able to make some progress with that documentation in hand. I'm looking into the possibility of other images to test with that natively support vlans.

Andrew Kinney ( 2014-02-06 19:36:10 -0500 )edit

Ultimately, our situation is this bug: https://bugs.launchpad.net/neutron/+bug/1268955

Andrew Kinney ( 2014-02-27 21:45:52 -0500 )edit

Your bridge_mapping is using br-int, it should be using the bridge for mapping to the physical, br-ex I believe in your case. Also br-int should not be configured with IP address, and why does it have an em2? I'm not keen on configuring br-ex with IPs either. What guide says to do all this?

darragh-oreilly ( 2014-03-05 02:01:53 -0500 )edit

Thanks, darrah-oreilly. You helped nudge me in the right direction there.

ross-golder ( 2014-04-05 21:34:04 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-03-05 01:23:54 -0500

ross-golder gravatar image

updated 2014-04-05 21:34:56 -0500

In the end, I saw that you can see the VLAN (802.1Q) tag for a packet in tcpdump. I was able to see tag information for the DHCP packets I was looking for using, e.g.

# tcpdump -i em2 -n -e port 67
tcpdump: WARNING: em2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:28:00.596374 fa:16:3e:9e:d6:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 1003, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:9e:d6:26, length 300

At this point, I began to realise that I'd somehow managed to get the meanings/uses of the 'br-ex' and 'br-int' bridges confused. So I created a couple of new bridges for each host, named after the physical interfaces (i.e. 'br-em1' and 'br-em2'), and moved the physical ports to those bridges. This clarified things a little.

Most importantly, in doing so (and having read a ton more docs by then), I started to figure out what the 'int-*' ports were about and realised that I'd put 'em2' (physical) port on the 'integration' bridge, which was causing two DHCP packets per request to be sent out.

Anyway, the situation now is that it is sending correctly tagged DHCP packets out via the em2 port. The problem seems to be that the switch (NetGear GS724T v3) is not forwarding tagged packets to the other two hosts, as they are not receiving them on their 'em2' interfaces.

Unfortunately, in trying to configure 'VLAN trunking' between the ports on that switch, I've inadvertently locked myself out of it, and am waiting for some on-site staff to unwind a paperclip and do a factory reset :)

edit flag offensive delete publish link more

Comments

FTR, I found this article helpful too, in understanding how the ports on the bridges interact with each other... http://techbackground.blogspot.com/20...

ross-golder ( 2014-04-05 21:37:40 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

Follow
1 follower

Stats

Asked: 2014-01-06 21:38:58 -0500

Seen: 402 times

Last updated: Apr 05