在最近的升级中（从Ubuntu Lucid上的Openstack Diablo到Ubuntu Precise上的Openstack Essex），我们发现DNS数据包经常（几乎总是）在桥接接口（br100）上被丢弃。 对于我们的计算节点主机，这是使用mlx4_en驱动程序模块的Mellanox MT26428。
我们已经find了两个解决方法：
使用一个旧的清晰的内核（例如2.6.32-41-generic）。 这会导致其他问题，特别是缺lesscgroup和旧版本的kvm和kvm_amd模块（我们怀疑kvm模块版本是我们偶尔会看到虚拟机将使用100％CPU的错误的来源）。 过去几个月来我们一直在这里跑，但不能永远留在这里。
对于较新的Ubuntu Precise内核（3.2.x），我们发现如果我们使用sysctl来禁用网桥上的netfilter（参见下面的sysctl设置），那么DNS开始再次完美工作。 我们认为这是我们问题的解决scheme，直到我们意识到closures网桥接口上的netfilter当然意味着DNAT规则redirect虚拟机的nova-api-metadata服务器请求（即redirect数据包发往169.254。计算节点的IP地址：8775）将被完全绕过。
长话短说：3.x内核，我们可以有可靠的networking和破碎的元数据服务，或者我们可以破坏networking和元数据服务，如果有任何虚拟机服务，将工作得很好。 我们还没有find两种方法。
任何人看到这个问题或之前的任何事情？ 得到了解决？ 或在正确的方向指针？
我们怀疑它是特定于Mellanox驱动程序，但我们不确定（我们已经尝试了几个不同版本的mlx4_en驱动程序，从3.2.x内核的版本开始一直到来自mellanox网站的最新1.5.8.3驱动程序来自Quantal的3.5.x内核中的mlx4_en驱动程序完全不工作）
顺便说一句，我们的计算节点拥有内置的mellanox NIC的超微H8DGT主板：
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
我们没有使用系统中的其他两个NIC，只连接了Mellanox和IPMI卡。
网桥netfilter的sysctl设置：
net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0
自从发现了这个bridge-nf sysctl解决方法之后，我们在网上发现了几个网页，其中包括Openstack的最新networking故障排除页面和一个与此博客相关的启动板错误报告 ，解决scheme）….当你知道要search什么东西的时候更容易find东西:)，但是我们还没有发现它引起的DNAT问题。
2012-09-12更新：
之前我应该提到的东西 – 即使在没有安装任何OpenStack甚至libvirt软件包的机器上也会出现这种情况。 相同的硬件，相同的一切，但没有比安装的Ubuntu 12.04基础系统更多。
在内核2.6.32-41-generic上，网桥按预期工作。
在内核3.2.0-29-generic上，使用以太网接口，它完美的工作。 除非net.bridge.bridge-nf-call-iptables = 0，否则在同一个网卡上使用网桥将会失败
所以，似乎很清楚，问题是在mellanox驱动程序，更新的内核的桥接代码，netfilter代码。 或者他们之间的一些互动。
有趣的是，我有其他的机器（没有mellanox卡）与桥接接口，不会出现这个问题。 从廉价的r8169卡到在一些Sun Fire X2200 M2服务器上采用更高质量的broadcom tg3 Gbit卡以及采用超微主板的intel gb卡。 就像我们的OpenStack计算节点一样，它们都使用网桥接口作为它们的主IP地址（有时是唯一的）接口 – 它们是这样configuration的，所以我们可以使用带有真实IP地址而不是NAT的libvirt＆kvm来运行虚拟机。
所以，这表明这个问题是特定于mellanox驱动程序的，虽然我上面提到的博客文章也有一些与使用bnx2驱动程序的broadcom NIC类似的问题。