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 <[email protected] <mailto:[email protected]>> 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?-- Andrei Andone SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, RomaniaEmail: [email protected] <mailto:[email protected]> | Web: www.softvision.ro <http://www.softvision.ro>The content of this communication is classified as SOFTVISION Confidential and Proprietary Information._______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
-- Andrei Andone SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, RomaniaEmail: [email protected] <mailto:[email protected]> | Web: www.softvision.ro <http://www.softvision.ro>
The content of this communication is classified as SOFTVISION Confidential and Proprietary Information.
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
