NB: You may notice that VNET_PRIVINTERFACE already is a VLAN, but this seems to work OK so long as I reduce the MTU on instances by 4 bytes for the VLAN tag. And it still works fine with dhcpd3.
Perhaps dhcpd goes through a different code path for discovery on VLAN interfaces?
I'm just too tired to work any more on this today...I'll debug everything properly some time over the next week, but this system is far from "clean" and probably not entirely typical, so I wouldn't want to assert that things are still not fixed if it appears OK for people doing more formal testing here.
Additional info:
-- UP,LOWER_ UP> mtu 16436 qdisc noqueue state UNKNOWN MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 public. ip.address/ 32 scope global eth0:pub 90ff:fe13: 44a4/64 scope link MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc noqueue state UP 90ff:fe13: 44a4/64 scope link MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc noqueue state UNKNOWN MULTICAST, PROMISC, UP,LOWER_ UP> mtu 1500 qdisc noqueue state UP 90ff:fe13: 44a4/64 scope link /eucalyptus. conf /eucalyptus. conf
root@whirlpool:~# ip addr show
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,
link/ether 00:25:90:13:44:a4 brd ff:ff:ff:ff:ff:ff
inet a.b.c.211/24 brd 188.165.231.255 scope global eth0
inet x.y.z.220/32 scope global eth0
inet x.y.z.221/32 scope global eth0
inet x.y.z.223/32 scope global eth0
inet instance.
inet6 fe80::225:
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,
link/ether 00:25:90:13:44:a5 brd ff:ff:ff:ff:ff:ff
4: eth0.2187@eth0: <BROADCAST,
link/ether 00:25:90:13:44:a4 brd ff:ff:ff:ff:ff:ff
inet 169.254.169.254/32 scope link eth0.2187
inet 10.0.0.1/8 scope global eth0.2187
inet6 fe80::225:
valid_lft forever preferred_lft forever
7: eucabr10: <BROADCAST,
link/ether 00:25:90:13:44:a4 brd ff:ff:ff:ff:ff:ff
inet 10.32.8.1/24 brd 10.32.8.255 scope global eucabr10:priv
8: <email address hidden>: <BROADCAST,
link/ether 00:25:90:13:44:a4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::225:
valid_lft forever preferred_lft forever
---
root@whirlpool:~# cat /etc/eucalyptus
# /etc/eucalyptus
#
# These are the Ubuntu Enterprise Cloud's default Eucalyptus parameters.
# Affects: All "eucalyptus"
# See: **NOTE** below
EUCALYPTUS="/"
EUCA_USER=
# Affects: CLC, Walrus, SC "-Xmx512m"
DISABLE_DNS="N"
CLOUD_OPTS=
# Affects: SC
DISABLE_EBS="N"
DISABLE_ISCSI="N"
# Affects: CC, NC WS_SECURITY= "Y" CE="eth0" "x.y.z. 220" ACE="eth0. 2187" "option interface-mtu 1496;"
# See: **NOTE** below
ENABLE_
LOGLEVEL="DEBUG"
VNET_PUBINTERFA
VNET_CLOUDIP=
VNET_PRIVINTERF
VNET_MODE="MANAGED"
VNET_DHCPOPTS=
# Affects: CC "ROUNDROBIN" H="300" H="300" "axis2/ services/ EucalyptusNC" ="/usr/ sbin/dhcpd" "dhcpd" TUNNELLING= "N" T="256" "10.32. 0.0" "255.240. 0.0" "instance. public. ips.208- instance. public. ips.223"
# See: **NOTE** below
CC_PORT="8774"
SCHEDPOLICY=
POWER_IDLETHRES
POWER_WAKETHRES
NC_SERVICE=
VNET_DHCPDAEMON
VNET_DHCPUSER=
DISABLE_
NODES=""
VNET_ADDRSPERNE
VNET_SUBNET=
VNET_NETMASK=
#VNET_DNS=""
VNET_PUBLICIPS=
--
NB: You may notice that VNET_PRIVINTERFACE already is a VLAN, but this seems to work OK so long as I reduce the MTU on instances by 4 bytes for the VLAN tag. And it still works fine with dhcpd3.
Perhaps dhcpd goes through a different code path for discovery on VLAN interfaces?
I'm just too tired to work any more on this today...I'll debug everything properly some time over the next week, but this system is far from "clean" and probably not entirely typical, so I wouldn't want to assert that things are still not fixed if it appears OK for people doing more formal testing here.