On 30 January 2014 08:16, Jonathan Proulx <j...@jonproulx.com> wrote: > On Wed, Jan 29, 2014 at 1:49 PM, Joe Topjian <j...@topjian.net> wrote: >> >>> however I can't tcpdump on the patch or gre devices.... >>> >>> # tcpdump -i patch-tun >>> tcpdump: patch-tun: No such device exists >> >> >> I can reproduce this. I suspect because patch-tun and patch-int are OVS >> patch interfaces, they are internal to OVS and not a real interface. "ip a | >> grep patch-tun" returns no results, so that supports that theory. >> > > I'm pretty sure it is the case that these are just ovs internal, just > wonder if there's a way to do the equivalent of tcpdump to see what if > anything is crossing them. It's a big gap between the tap and the eth > devices. I'm thinking ovs port mirroring may be what I need to learn, > that's what I'd to on a switch to inspect packets on a port if I > couldn't be on the device connected to it.
They are internal. You should be able to plug a port in and configure it to mirror though. So yes, ovs port mirroring. >> How about "brctl show"? There should be a bridge called qbrXXX that bridges >> the tap interface to a qvb interface. The qvb interface is a veth pair to a >> qvo interface on OVS. If you can't see packets between qbr, qvb, or qvo, >> then I'd imagine the problem is somewhere with the linux standard bridging. > > This may be getting close to the issue. I don't see any interfaces > anything like that. I'm seeing two different types of bride states on > my compute nodes, which suggest something's wrong there. On the > compute node hosting the 'bad' instances and many other nodes as well > I see: > > bridge name bridge id STP enabled interfaces > br-int 0000.da8ae1f32b4f no > int-eth1-br > tap217f1525-a7 > tap2216c86e-aa > tap95f49c26-c5 > tap9cf1249f-19 > tapa35c07ef-ef > tapdcc2d3c6-d6 > tapdebc0ece-86 > tapf1cf3384-6d > br-tun 0000.f66f85d4f940 no > eth1-br 0000.60eb69dc46df no eth1 > phy-eth1-br > virbr0 8000.000000000000 yes > > But a minority of systems show: > > ovs-system 0000.6e7205af2054 no br-int > br-tun > eth1 > eth1-br > int-eth1-br > phy-eth1-br > tap0a7aca16-ad > tap4ff9d951-c1 > tap4ffca4ce-00 > tap892a01b4-93 > tapf6ddeaf5-f4 > virbr0 8000.000000000000 yes Always use ovs-vsctl show on ovs switches - brcompat is super limited. What flows do you have defined? ovs-ofctl show br-int #(to id ports) ovs-ofctl dump-flows br-int Cheers, Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
