Open Stack

On 30 January 2014 08:16, Jonathan Proulx <jon at jonproulx.com> wrote:
> 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.

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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud