<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>This is all good stuff. Thanks. Does/Should the neutron docs have an openvswitch debugging page? This belongs there for easy access. Such a page might go a long way to alleviate fears over the openvswitch backend.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Attila Fazekas<br>
<b>Sent:</b> Tuesday, April 28, 2015 1:22:44 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">You can tcpdump the ovs ports as usual.<br>
<br>
Please keep in mind ovs does not have `single contention` port.<br>
OVS does MAC learning by default and you may not see `learned` uni-cast traffic<br>
on a random trunk port. You MAY see BUM traffic, but many of them also can be canceled<br>
by neutron-ml2-ovs, AFAIK it is not enabled by default. <br>
<br>
OVS behaves like a real switch, real switches also does not have 5 Tbit/sec ports for monitoring :(<br>
If you need to tcpudump on a port which is not visible in the userspace (internal patch links) by default<br>
you should do port mirroring. [1]<br>
<br>
Usually you do not need to dump the traffic,<br>
What you should do as basic trouble shooting is checking the tags on the ports,<br>
(`ovsdb-client dump` show everything, excluding the oflow rules)<br>
<br>
Hopefully the root cause is fixed, but you should check is the port not trunk<br>
when it needs to be tagged.<br>
<br>
Neutron also dedicates the vlan-4095 on br-int as dead vlan,<br>
If you have a port in this, it can mean a miss configuration<br>
or a message lost in the void or something Exceptional happened.<br>
<br>
If you really need to redirect exceptional `out of band` traffic to a special port<br>
or to an external service (controller) it would be more complex thing<br>
then just doing the mirroring.<br>
<br>
[1] <a href="http://www.yet.org/2014/09/openvswitch-troubleshooting/">http://www.yet.org/2014/09/openvswitch-troubleshooting/</a><br>
<br>
PS.:<br>
OVS does not generates ICMP packets in many cases when a real `L3` switch would do,<br>
thats why the MTU size differences causes issues and requires extra care at configuration,<br>
when ovs used with tunneling. (OVS also can be used with vlans)<br>
<br>
Probably this caused the most headache for many user.<br>
<br>
PS2.:<br>
Somewhere I read the ovs had the PMTUD support, but it was removed because<br>
it was not conforming to the standard.<br>
It just does silent packet drop :(<br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: "Jeremy Stanley" <fungi@yuggoth.org><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>
> Sent: Tuesday, April 21, 2015 5:00:24 PM<br>
> Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network<br>
> to Neutron migration work]<br>
> <br>
> On 2015-04-21 03:19:04 -0400 (-0400), Attila Fazekas wrote:<br>
> [...]<br>
> > IMHO the OVS is less complex than netfilter (iptables, *tables),<br>
> > if someone able to deal with reading the netfilter rules he should<br>
> > be able to deal with OVS as well.<br>
> <br>
> In a simple DevStack setup, you really have that many<br>
> iptables/ebtables rules?<br>
> <br>
> > OVS has debugging tools for internal operations, I guess you are<br>
> > looking for something else. I do not have any `good debugging`<br>
> > tool for net-filter either.<br>
> [...]<br>
> <br>
> Complexity of connecting tcpdump to the bridge was the primary<br>
> concern here (convenient means of debugging network problems when<br>
> you're using OVS, less tools for debugging OVS itself though it can<br>
> come down to that at times as well). Also ebtables can easily be<br>
> configured to log every frame it blocks, forwards or rewrites<br>
> (presumably so can the OVS flow handler? but how?).<br>
> --<br>
> Jeremy Stanley<br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>