I followed these instructions and the installation failed while deploying Landscape.

I dug around a bit, and found that the juju containers are unable to obtain IP address:

Apr 28 16:20:50 juju-machine-0-lxc-1 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17 (xid=0x4e269150)
Apr 28 16:21:07 juju-machine-0-lxc-1 dhclient: DHCPDISCOVER on eth0 to     255.255.255.255 port 67 interval 10 (xid=0x4e269150)
Apr 28 16:21:17 juju-machine-0-lxc-1 dhclient: DHCPDISCOVER on eth0 to    255.255.255.255 port 67 interval 12 (xid=0x4e269150)

It seems the interfaces are bridged to eth0:

# brctl show
bridge name     bridge id               STP enabled     interfaces
juju-br0        8000.005056880a1b       no              eth0
                                                        veth770EL2
                                                        vethOULXGG
                                                        vethQ7I7K9
                                                        vethR8J2R4
                                                        vethTQOU5J
                                                        vethVID53L
lxcbr0          8000.000000000000       no

While the dhcpd on the host is about to provide addresses on lxcbr0:

dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative

Any hints on how to resolve it?

share|improve this question
    
I tcpdumped the DHCP requests on brighe interface. The Request appears on both veth associated with container and the juju-br0 itself while Reply shows ONLY in bridge and NOT in veth associated with it [I filtered the traffic based on container MAC address]. That indicates that the traffic from DHCP server goes properly to juju host and for some reason is not bridged properly to container. I also checked against this solution. Still the Reply packets do not show on the veth. – Emsi Apr 29 '15 at 11:55

I found a workaround.

The core of the problem was that I was using virtual machines on ESXi. I enabled nested virtualization and managed them via virsh. For the networking to work I had to enable so called promiscuous mode on the ESXi portgroup and hence turned it into a hub (it's a shame that vSwitch does not support MAC learning).

As the virtual switch was connected using two NICs to uplink switches, promiscuous mode somehow caused the packets to be duplicated (despite the fact that all the communication was happening within single ESXi host!). The Linux bridge detected those duplicates and hence refused to bridge the packets.

Removing one physical NIC from the vmware switch solved the problem (disabling one NIC or setting as Standby or Unused did not). As removing NIC from switch was not a good solution for me I created a virtual switch without any NICs attached and created a Linux box that routed traffic to it. After that the installation went without any further issues.

I was not able to resolve it purely on the Linux bridge level.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.