Hi,
I ran into the same issue as the one described below (post on
ovs-discuss a few months back).
The goal is to use a vport tunnel configured to use a flow-based remote
IP, e.g:
ovs-vscl add-port br-vnet tun-port -- set Interface tun-port
type=gre options:remote_ip=flow
This works fine on the sending OVS, but on the receiving OVS the same
vport won't receive any traffic (packets received trigger a "receive
tunnel port not found" warning, and are not further processed).
The original poster had found a workaround relying on also using
options:key=flow, but as far as I understand, this work around should
not be necessary: it just seems that the tunnel matching code is missing
a match.
--- a/ofproto/tunnel.c
+++ b/ofproto/tunnel.c
@@ -427,8 +427,9 @@ tnl_find(const struct flow *flow) OVS_REQ_RDLOCK(rwlock)
{ false, false, IP_SRC_ANY }, /* remote_ip, in_key. */
{ true, false, IP_SRC_CFG }, /* remote_ip, local_ip. */
{ true, false, IP_SRC_ANY }, /* remote_ip. */
- { true, true, IP_SRC_ANY }, /* Flow-based remote. */
+ { true, true, IP_SRC_ANY }, /* Flow-based remote and
flow-based key. */
{ true, true, IP_SRC_FLOW }, /* Flow-based everything. */
+ { false, true, IP_SRC_ANY }, /* Flow-based remote */
};
const struct tnl_match_pattern *p;
With this patch, a tunnel configured with just remote_ip=flow will work
fine on the receiving end.
One thing that I'm not sure is at which position this pattern should
appear in the list.
The patch also changes the comment for true/true/IP_SRC_ANY.
-Thomas
Andrei Andone, 2013-09-10 :
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-port type=...
options:remote_ip=*flow* options:key=*20
*After looking into the code for flow matching I decided to also set
the "*options:key*" parameter to "*flow*" and my flowed tunnel started
to work. Somehow I didn't see anywhere mentioned that if you use:
"remote_ip=flow" the key also has to be set to flow. Even if you
specifically set the "tun_id" argument in a flow, if the "options:key"
parameter is set to a static value, it won't work even if the
statically assigned key is correct.
Just for ease of notice: *"options:remote_ip=flow"* requires
*"options:key=flow"*
So for anyone who needs a "remote_ip=flow" example, here's the one
that worked for me:
_host1_ - IP: 192.168.0.100: (this will be the host with remote_ip=flow)
/# creating the bridge that will contain your vm port as well as the
tunnel/ port
ovs-vsctl add-br virt-br
/# creating the tunnel port/
/# `type` can be replaced with vxlan and also lisp I assume (only
tested for gre and vxlan)//
//# also we will asume that ofport 10 is not already in use and that
it will be assigned to our tunnel//
/ovs-vsctl add-port virt-br tun-port -- set Interface tun-port
type=gre options:key=*flow* options:remote_ip=*flow *ofport_request=10
/# Now we add flows://
//# 1. Sending from port 1 to tunnel (assuming port 1 is the vm end
point)/
ovs-ofctl add-flow virt-br "in_port=1
actions=set_field:10->tun_id,set_field:192.168.0.200->tun_dst,output:10"
/# 2. Sending from tunnel to the vm end point (assuming port 1 is the
vm end point)/
ovs-ofctl add-flow virt-br "in_port=10 actions=output:1"
_host2_ - IP: 192.168.0.200: (this will be the host with
remote_ip=<IP> to prove the point)
/# creating the bridge that will contain your vm port as well as the
tunnel/ port
ovs-vsctl add-br virt-br
/# creating the tunnel port/
/# make sure that the key on this port matches the key you dynamically
load on //the other host tunnel/
/# and again, let's assume that ofport 10 is not in use and will be
assigned to our tunnel port/
ovs-vsctl add-port virt-br tun-port -- set Interface tun-port type=gre
options:key=*10* options:remote_ip=*192.168.0.100 *ofport_request=10
And this is what worked for me.
Thanks for your help,
Andrei
On 09/10/2013 09:56 AM, Andrei Andone wrote:
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 to this email the wireshark captures on host 1 for
remote_ip=192.168.56.143 (file "arp-reply-with-ip") and
remote_ip=flow ("arp-reply-with-flow"). Please ignore the arp packets
between "192.168.100.1" and "192.168.100.33". As you can see in the
attached captures there are two identical requests (one captured on
br-eth0 and one on eth0) for both captures. As for the replies, both
captures have two GRE encapsulated arp responses (one on br-eth0 and
one on eth0) and only the remote_ip=IP version has the reply that is
not GRE encapsulate (capture on the vm port).
This is why I think that when I use remote_ip=flow the tunnel somehow
doesn't get identified by the br-eth0 bridge and packets are not
being forwarded to it.
Thanks,
Andrei
On 09/09/2013 11:56 PM, Jesse Gross wrote:
On Mon, Sep 9, 2013 at 5:14 AM, Andrei Andone
<andrei.and...@softvision.ro <mailto:andrei.and...@softvision.ro>>
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
0383aece-fb49-47ab-b9d2-c1ee13c16a89
Bridge br-vnet
Port "vnet0"
Interface "vnet0"
Port gre-tun
Interface gre-tun
type: gre
options: {key="10", remote_ip="192.168.56.143"}
Port br-vnet
Interface br-vnet
type: internal
Bridge "br-eth0"
Port "eth0"
Interface "eth0"
Port "br-eth0"
Interface "br-eth0"
type: internal
ovs_version: "2.0.0"
[root@localhost ~]# ovs-dpctl show
system@ovs-system:
lookups: hit:1475183 missed:278182 lost:608
flows: 137
port 0: ovs-system (internal)
port 1: br-eth0 (internal)
port 2: br-vnet (internal)
port 3: eth0
port 4: gre_system (gre: df_default=false, ttl=0)
port 5: vnet0
[root@localhost ~]# ovs-ofctl show br-vnet
OFPT_FEATURES_REPLY (xid=0x2): dpid:000052fead266b48
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC
SET_TP_DST ENQUEUE
1(vnet0): addr:fe:54:00:1d:28:97
config: 0
state: 0
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
3(gre-tun): addr:06:b5:22:a0:e5:86
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
LOCAL(br-vnet): addr:52:fe:ad:26:6b:48
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
[root@localhost ~]# ovs-ofctl dump-flows br-vnet
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=9750.473s, table=0, n_packets=5067,
n_bytes=212814, idle_age=19, arp,in_port=1
actions=load:0xc0a8388f->NXM_NX_TUN_IPV4_DST[],output:3 #
for sending from the vm through the tunnel
cookie=0x0, duration=9667.699s, table=0, n_packets=0,
n_bytes=0, idle_age=9667, arp,in_port=3 actions=output:1 #
hardcoded for receiving on tunnel and sending to the vm
cookie=0x0, duration=19879.453s, table=0, n_packets=4642,
n_bytes=313094, idle_age=13, priority=0 actions=NORMAL
** I also added the flows that set the IP (192.168.56.143 - host
2 IP) to the tun_dst these shouldn't interfere **
Here's how the datapath flows look-like while I'm successfully
arping-ing from the local vm to the remote one:
[root@localhost ~]# ovs-appctl dpif/dump-flows br-vnet
skb_priority(0),tunnel(tun_id=0xa,src=192.168.56.143,dst=192.168.56.142,tos=0x0,ttl=64,flags(key)),in_port(4),skb_mark(0),eth_type(0x0806),
packets:1, bytes:42, used:0.490s, actions:5
skb_priority(0),in_port(5),eth_type(0x0806), packets:297,
bytes:12474, used:0.491s,
actions:set(tunnel(tun_id=0xa,src=0.0.0.0,dst=192.168.56.143,tos=0x0,ttl=64,flags(df,key))),4
[root@localhost ~]#
** As you can see, both flows for sending and receiving exist
and are being used **
I then use `ovs-vsctl set Interface gre-tun
options:remote_ip=flow` (all other configs remain unchanged
event the arping command). Here's the datapath flow output:
[root@localhost ~]# ovs-appctl dpif/dump-flows br-vnet
skb_priority(0),in_port(5),eth_type(0x0806), packets:376,
bytes:15792, used:0.016s,
actions:set(tunnel(tun_id=0xa,src=0.0.0.0,dst=192.168.56.143,tos=0x0,ttl=64,flags(df,key))),4
[root@localhost ~]#
** I can only see the flow for sending being used, not the one
for receiving **
I assume I am missing a flow (or something else) that sends
packages from my physical interface (eth0) to my tunnel.
Do you have any idea what I am missing?
I would guess that the problem is on the receiving side since the
transmitter looks the same to me. What happens if you keep the side
the same while you change the transmitter to use flow-based
tunneling? Can you send the same information that you gave here for
the receiver?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
