<div dir="ltr">So, I made some progress here. I'm running FlatDHCP, so I don't have any VLAN stuff configured on my nodes. I don't have the 8021q kernel module loaded in any of my hosts or guests.<div><br></div>
<div><div>If I load the 8021q kernel module in the CentOS guest, and I manually put an IP address on the guest's eth0, then I can reach the guest from other the cloud controller. Unfortunately, it still doesn't pick up an address via DHCP: the DHCP replies still don't make it from host:vnet0 to  guest:eth0, even though other packets are able to.</div>
<div><br></div><div style>Since the problem only occurs when the packet has to travel across the network (if I put an IP on the bridge of the compute host, I can reach the guest), it seems like the Cisco Nexus 3000 switch is putting VLAN tags in the ethernet frame, and it's confusing the guest. But I can't figure out why that would be. I've been trying to inspect the packets with tcpdump to see if the vlan tags are there. </div>
<div style><br></div><div style>I may end up just switching to VlanManager to make everything VLAN-y.</div><div style><br></div><div style>Here's what my interfaces look like on the switch </div><div style><br></div><div style>
<div>n3k-2# show interface switchport</div><div>Name: Ethernet1/1</div><div>  Switchport: Enabled</div><div>  Switchport Monitor: Not enabled</div><div>  Operational Mode: access</div><div>  Access Mode VLAN: 1 (default)</div>
<div>  Trunking Native Mode VLAN: 1 (default)</div><div>  Trunking VLANs Enabled: 1</div><div>  Administrative private-vlan primary host-association: none</div><div>  Administrative private-vlan secondary host-association: none</div>
<div>  Administrative private-vlan primary mapping: none</div><div>  Administrative private-vlan secondary mapping: none</div><div>  Administrative private-vlan trunk native VLAN: none</div><div>  Administrative private-vlan trunk encapsulation: dot1q</div>
<div>  Administrative private-vlan trunk normal VLANs: none</div><div>  Administrative private-vlan trunk private VLANs: none</div><div>  Operational private-vlan: none</div><div>  Unknown unicast blocked: disabled</div><div>
  Unknown multicast blocked: disabled</div></div><div style><br></div><div style>I don't have dot1q native tag enabled:</div><div style><br></div><div style><div>n3k-2(config)# show vlan dot1q tag native</div><div>vlan dot1q native tag is disabled</div>
</div><div style><br></div><div style><br></div><div style>Lorin</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 4:27 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You might be hitting iptables/ebtables rules.<br>
<br>
I don't understand why this would be image specific though.<br>
<br>
Can you try generating traffic from the vm and see which counters<br>
increment? (with a static ip maybe?)<br>
 -nld<br>
<br>
On Thu, Apr 4, 2013 at 2:55 PM, Lorin Hochstein<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>> wrote:<br>
> Yeah, I've only loaded vhost_net on the compute host.<br>
><br>
> I'm running CentOS 6.3 on my latest test, but I've tried with CentOS 6.4 as<br>
> well.<br>
><br>
> I made some progress today (at least a potential workaround), but permit me<br>
> to ramble for a bit. I'm trying to run non-multihost. The eth1 on my compute<br>
> nodes are bridged to br100, and there's no IP address on br100 or eth1.<br>
><br>
> Packets aren't getting into the VM from outside. If I manually put an IP<br>
> address on there and do an "arping" from the network node, the arp request<br>
> packets appear on vnet1 of the compute host but not on eth0 of the guest.<br>
> (Packets do leave, however, so I can do an arping from inside the guest and<br>
> the nova-network host will see the request. Similar to DHCP. It's like a<br>
> reverse black hole, things can only go out).<br>
><br>
> However, if I put an IP address of br100 of the compute host, then the guest<br>
> can reach the host on that address.<br>
><br>
> So, it looks like I'm going to have to switch to running multi-host to<br>
> resolve this issue, since the VM can communicate directly with a bridge on<br>
> the compute host if it has an IP.<br>
><br>
> Still, it's puzzling to me, and I don't have a sense about how to debug this<br>
> further. How do I dig in if the problem is that packets can go from<br>
> guest:eth0 to host:vnet1, but they don't go from host:vnet1 to guest:eth0<br>
> (when they originate from a different server and travel over layer 2), and<br>
> only with a specific image that works for other people?<br>
><br>
> Lorin<br>
><br>
><br>
><br>
> On Thu, Apr 4, 2013 at 11:33 AM, Narayan Desai <<a href="mailto:narayan.desai@gmail.com">narayan.desai@gmail.com</a>><br>
> wrote:<br>
>><br>
>> iirc, vhost_net is only needed on the host.<br>
>><br>
>> We have seen stability issues with 12.04 (only on particular host<br>
>> types) when using virtio without vhost_net. Enabling vhost_net on the<br>
>> host resolved the issues for us.<br>
>><br>
>> Which version of Centos are you running?<br>
>>  -nld<br>
>><br>
>> On Wed, Apr 3, 2013 at 3:59 PM, Lorin Hochstein<br>
>> <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>> wrote:<br>
>> > That was my instinct, but I've tried it both ways (toggling<br>
>> > libvirt_use_virtio_for_bridge, restarting nova-compute, launching new<br>
>> > instance), and vnc'd into the instance to confirmed that in one case the<br>
>> > virtio_net drivers were loaded, and in another case, they weren't, and<br>
>> > the<br>
>> > result was the same. But it doesn't seem to be related. It's really<br>
>> > baffling.<br>
>> ><br>
>> > Lorin<br>
>> ><br>
>> ><br>
>> > On Wed, Apr 3, 2013 at 4:47 PM, Joe Topjian <<a href="mailto:joe.topjian@cybera.ca">joe.topjian@cybera.ca</a>><br>
>> > wrote:<br>
>> >><br>
>> >> That's really bizarre -- especially since it's only CentOS images. Do<br>
>> >> you<br>
>> >> think it might be something with virtio compatibility?<br>
>> >><br>
>> >> I'm hesitant to lean on it being a compute/controller issue since other<br>
>> >> images work.<br>
>> >><br>
>> >><br>
>> >> On Wed, Apr 3, 2013 at 2:41 PM, Lorin Hochstein<br>
>> >> <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> I've tested with multiple ones, including the CentOS6 image from that<br>
>> >>> page, as well as several we have rolled on our own.<br>
>> >>><br>
>> >>> Right now I'm testing by manually putting on the IP by doing:<br>
>> >>><br>
>> >>> ip addr add <a href="http://10.40.0.4/16" target="_blank">10.40.0.4/16</a> broadcast 10.40.255.255 dev eth0<br>
>> >>><br>
>> >>> I can't ping out at all. If I try to arping out, and then tcpdump,<br>
>> >>> just<br>
>> >>> like in the DHCP case, I can see the ARP request and replies on vnet0<br>
>> >>> of the<br>
>> >>> host:<br>
>> >>><br>
>> >>> root@c220-2:~# tcpdump -i vnet0 arp<br>
>> >>> tcpdump: WARNING: vnet0: no IPv4 address assigned<br>
>> >>> tcpdump: verbose output suppressed, use -v or -vv for full protocol<br>
>> >>> decode<br>
>> >>> 16:34:42.109067 ARP, Request who-has 10.40.0.1 (Broadcast) tell<br>
>> >>> 10.40.0.4, length 28<br>
>> >>> 16:34:42.109085 ARP, Request who-has 10.40.0.1 (Broadcast) tell<br>
>> >>> 10.40.0.4, length 28<br>
>> >>> 16:34:42.109216 ARP, Reply 10.40.0.1 is-at 54:78:1a:86:50:c9 (oui<br>
>> >>> Unknown), length 46<br>
>> >>><br>
>> >>><br>
>> >>> But if I tcpdump on eth0 in the guest, I only see the arp requests,<br>
>> >>> not<br>
>> >>> the replies..<br>
>> >>><br>
>> >>><br>
>> >>> Lorin<br>
>> >>><br>
>> >>><br>
>> >>> On Wed, Apr 3, 2013 at 4:26 PM, Joe Topjian <<a href="mailto:joe.topjian@cybera.ca">joe.topjian@cybera.ca</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> What CentOS images are you using? These have worked for me:<br>
>> >>>><br>
>> >>>> <a href="https://github.com/rackerjoe/oz-image-build" target="_blank">https://github.com/rackerjoe/oz-image-build</a><br>
>> >>>><br>
>> >>>><br>
>> >>>> On Wed, Apr 3, 2013 at 2:13 PM, Lorin Hochstein<br>
>> >>>> <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>> wrote:<br>
>> >>>>><br>
>> >>>>> Hi Joe:<br>
>> >>>>><br>
>> >>>>> It happens immediately thereafter. CentOS images have never worked<br>
>> >>>>> on<br>
>> >>>>> our setup.<br>
>> >>>>><br>
>> >>>>> Lorin<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> On Wed, Apr 3, 2013 at 3:30 PM, Joe Topjian <<a href="mailto:joe.topjian@cybera.ca">joe.topjian@cybera.ca</a>><br>
>> >>>>> wrote:<br>
>> >>>>>><br>
>> >>>>>> Hi Lorin,<br>
>> >>>>>><br>
>> >>>>>> Does this happen shortly after the guests were created? Or usually<br>
>> >>>>>> a<br>
>> >>>>>> few hours/days later? If the latter, are these guests seeing large<br>
>> >>>>>> amounts<br>
>> >>>>>> of bandwidth?<br>
>> >>>>>><br>
>> >>>>>> Thanks,<br>
>> >>>>>> Joe<br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> On Wed, Apr 3, 2013 at 1:16 PM, Lorin Hochstein<br>
>> >>>>>> <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>> wrote:<br>
>> >>>>>>><br>
>> >>>>>>> Hi all:<br>
>> >>>>>>><br>
>> >>>>>>> I'm having a strange issue where networking on my CentOS guests<br>
>> >>>>>>> isn't<br>
>> >>>>>>> working properly, but things are working fine with my Ubuntu<br>
>> >>>>>>> guests.<br>
>> >>>>>>><br>
>> >>>>>>> I'm running Folsom on Ubuntu 12.04, nova-network, not multi-host.<br>
>> >>>>>>><br>
>> >>>>>>> The first symptom is that CentOS instances don't get IP addresses<br>
>> >>>>>>> via<br>
>> >>>>>>> DHCP. If I trace the DHCP requests and replies using tcpdump, I<br>
>> >>>>>>> can see the<br>
>> >>>>>>> reply from dnsmasq reach the vnetX interface of the compute host,<br>
>> >>>>>>> but it<br>
>> >>>>>>> doesn't get to the eth0 interface of the compute host. (I'm at a<br>
>> >>>>>>> loss here<br>
>> >>>>>>> about how to debug something like that).<br>
>> >>>>>>><br>
>> >>>>>>> If I try to statically configure an IP address on the guest<br>
>> >>>>>>> instead,<br>
>> >>>>>>> networking still doesn't work. I can't ping anything on the<br>
>> >>>>>>> subnet, and I<br>
>> >>>>>>> don't even see the icmp traffic on vnetX of the host.<br>
>> >>>>>>><br>
>> >>>>>>> I've tried this twiddling the following options, but no change in<br>
>> >>>>>>> behavior:<br>
>> >>>>>>><br>
>> >>>>>>> * Adding the following rule to nova-network node: iptables -A<br>
>> >>>>>>> POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM<br>
>> >>>>>>> --checksum-fill<br>
>> >>>>>>> * Adding the same rule to nova-compute node<br>
>> >>>>>>> * Setting libvirt_use_virtio_for_bridge to "yes" and "no"<br>
>> >>>>>>> (restarting<br>
>> >>>>>>> nova-compute, re-launching instances)<br>
>> >>>>>>> * With and without vhost_net loaded in nova-compute (restarting<br>
>> >>>>>>> nova-compute, re-launching instances)<br>
>> >>>>>>> * Disabling iIpv6 inside of the CentOS guest<br>
>> >>>>>>><br>
>> >>>>>>> Has anybody encountered this before?<br>
>> >>>>>>><br>
>> >>>>>>> Lorin<br>
>> >>>>>>><br>
>> >>>>>>> --<br>
>> >>>>>>> Lorin Hochstein<br>
>> >>>>>>> Lead Architect - Cloud Services<br>
>> >>>>>>> Nimbis Services, Inc.<br>
>> >>>>>>> <a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
>> >>>>>>><br>
>> >>>>>>> _______________________________________________<br>
>> >>>>>>> OpenStack-operators mailing list<br>
>> >>>>>>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>> >>>>>>><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> --<br>
>> >>>>>> Joe Topjian<br>
>> >>>>>> Systems Administrator<br>
>> >>>>>> Cybera Inc.<br>
>> >>>>>><br>
>> >>>>>> <a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a><br>
>> >>>>>><br>
>> >>>>>> Cybera is a not-for-profit organization that works to spur and<br>
>> >>>>>> support<br>
>> >>>>>> innovation, for the economic benefit of Alberta, through the use of<br>
>> >>>>>> cyberinfrastructure.<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> --<br>
>> >>>>> Lorin Hochstein<br>
>> >>>>> Lead Architect - Cloud Services<br>
>> >>>>> Nimbis Services, Inc.<br>
>> >>>>> <a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> --<br>
>> >>>> Joe Topjian<br>
>> >>>> Systems Administrator<br>
>> >>>> Cybera Inc.<br>
>> >>>><br>
>> >>>> <a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a><br>
>> >>>><br>
>> >>>> Cybera is a not-for-profit organization that works to spur and<br>
>> >>>> support<br>
>> >>>> innovation, for the economic benefit of Alberta, through the use of<br>
>> >>>> cyberinfrastructure.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> Lorin Hochstein<br>
>> >>> Lead Architect - Cloud Services<br>
>> >>> Nimbis Services, Inc.<br>
>> >>> <a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Joe Topjian<br>
>> >> Systems Administrator<br>
>> >> Cybera Inc.<br>
>> >><br>
>> >> <a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a><br>
>> >><br>
>> >> Cybera is a not-for-profit organization that works to spur and support<br>
>> >> innovation, for the economic benefit of Alberta, through the use of<br>
>> >> cyberinfrastructure.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Lorin Hochstein<br>
>> > Lead Architect - Cloud Services<br>
>> > Nimbis Services, Inc.<br>
>> > <a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-operators mailing list<br>
>> > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>> ><br>
><br>
><br>
><br>
><br>
> --<br>
> Lorin Hochstein<br>
> Lead Architect - Cloud Services<br>
> Nimbis Services, Inc.<br>
> <a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</div>