On Tue, Sep 10, 2013 at 06:28:18PM +0300, Andrei Andone wrote:
> The problem was I had the tunnel configured as follows:
> ovs-vscl add-port br-vnet tun-port -- set Interface tun-port
> type=... options:remote_ip=*flow* options:key=*20
>
> *After looking into the code for flow matching I decided t
Hello all,
I finally figured out what my problem was.
As I was saying in the previous post, I thought that the tunnel does not
get identified by the bridge. Seems that I was right.
The problem was I had the tunnel configured as follows:
ovs-vscl add-port br-vnet tun-port -- set Interface tun-p
Hello,
Host 2 is configured with options:remote_ip=192.168.56.142 (host 1 IP).
But I don't think that host 2 is the problem since on host 1 I can see
the arp reply packets coming in on br-eth0 and on eth0. I do not see the
reply packet being forwarded to the vm's port (vnet0).
I'm attaching
On Mon, Sep 9, 2013 at 5:14 AM, Andrei Andone
wrote:
> Hello Jesse,
>
> I tried what you said and to only deal with the br-vnet bridge. I also
> switched to GRE tunnels for ease of viewing packets. Here's how it went:
>
> First config (host h1):
>
>
> [root@localhost ~]# ovs-vsctl show
> 0383aec
Hello Jesse,
I tried what you said and to only deal with the br-vnet bridge. I also
switched to GRE tunnels for ease of viewing packets. Here's how it went:
First config (host h1):
[root@localhost ~]# ovs-vsctl show
0383aece-fb49-47ab-b9d2-c1ee13c16a89
Bridge br-vnet
Port "vnet0"
It shouldn't matter that you have two bridges, the only one that applies in
this case is br_vnet. I would use ovs-appctl dpif/dump-flows and
ofproto/trace to debug where your packets are currently going and then
write a flow to match using fields such as tun_id, tun_src, etc. similar to
what you ar
Hello Jesse,
Sorry for the delay on my reply, I couldn't reply any sooner.
To answer your question: No, I don't have a flow for receiving, because
I couldn't really understand where I'm supposed to add the flow and how
it should look like. I've seen examples with only one bridge but I'm
using
Do you have a corresponding flow to receive the VXLAN traffic? You only
showed one for sending.
As you mentioned before, you should be able to use ofproto/trace to see
what OpenFlow rules are being hit.
On Wed, Aug 28, 2013 at 4:48 AM, Andrei Andone
wrote:
> Hello Jesse,
>
> Yes, on Wireshark
Hello Jesse,
Yes, on Wireshark listening to eth0, I see udp packets being sent and
received between the hosts (udp, destination port: 4789, which is vxlan
port). So the hosts are comunicating (the tunnel is) but I can't see any
reply on my br-vnet wireshark, or my VM receiving the answer that
On Tue, Aug 27, 2013 at 5:51 AM, Andrei Andone
wrote:
> Hello guys,
>
> I have a question related to the "options:remote_ip=flow" feature.
>
> My config looks like this for one host:
>
> [root@localhost ~]# ovs-vsctl show
> e927ea5a-41d8-4bf5-9145-5be06e18bc9f
> Bridge "br-eth0"
> Por
Hello guys,
I have a question related to the "options:remote_ip=flow" feature.
My config looks like this for one host:
[root@localhost ~]# ovs-vsctl show
e927ea5a-41d8-4bf5-9145-5be06e18bc9f
Bridge "br-eth0"
Port "br-eth0"
Interface "br-eth0"
type: intern
11 matches
Mail list logo
