Open Stack

On Wed, Jan 29, 2014 at 1:49 PM, Joe Topjian <joe at 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.

<snip>

> 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