[ovs-discuss] vxlan remote_ip flow help

Andrei Andone andrei.andone at softvision.ro
Mon Sep 9 12:14:09 UTC 2013


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 at 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 at localhost ~]# ovs-dpctl show
system at 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 at 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 at 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 at 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 at 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 at 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 at 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?

Thanks,
Andrei

On 09/04/2013 09:47 PM, Jesse Gross wrote:
> 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 are using on the transmit side.
>
>
> On Wed, Sep 4, 2013 at 6:12 AM, Andrei Andone 
> <andrei.andone at softvision.ro <mailto:andrei.andone at softvision.ro>> wrote:
>
>     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 two bridges, as mentioned in the initial post
>     and I could really use some hints/tips or anything to get this
>     working.
>
>     Thanks,
>     Andrei
>
>
>     On 08/30/2013 07:09 PM, Jesse Gross wrote:
>>     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
>>     <andrei.andone at softvision.ro
>>     <mailto:andrei.andone at softvision.ro>> wrote:
>>
>>         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 reached the host.
>>
>>         Thanks,
>>         Andrei
>>
>>
>>         On 08/28/2013 02:50 AM, Jesse Gross wrote:
>>>         On Tue, Aug 27, 2013 at 5:51 AM, Andrei Andone
>>>         <andrei.andone at softvision.ro
>>>         <mailto:andrei.andone at softvision.ro>> wrote:
>>>
>>>             Hello guys,
>>>
>>>             I have a question related to the
>>>             "options:remote_ip=flow" feature.
>>>
>>>             My config looks like this for one host:
>>>
>>>             [root at localhost ~]# ovs-vsctl show
>>>             e927ea5a-41d8-4bf5-9145-5be06e18bc9f
>>>                 Bridge "br-eth0"
>>>                     Port "br-eth0"
>>>                         Interface "br-eth0"
>>>                             type: internal
>>>                     Port "eth0"                   (external interface)
>>>                         Interface "eth0"
>>>                 Bridge br-vnet
>>>                     Port br-vnet
>>>                         Interface br-vnet
>>>                             type: internal
>>>                     Port "vxlan1"                 (tunnel I use)
>>>                         Interface "vxlan1"
>>>                             type: vxlan
>>>                             options: {key="10", remote_ip=flow}
>>>                     Port "vnet0"                  (port for the
>>>             virtual machine)
>>>                         Interface "vnet0"
>>>                 ovs_version: "1.12.90"
>>>             [root at localhost ~]#
>>>
>>>             If I set the "options:remote_ip=A.A.A.1" (the IP for
>>>             host 2) everything works just fine ARP requests from my
>>>             VM, pings to the subnet, etc.
>>>
>>>             If I leave it like this, it doesn't work.
>>>
>>>             I followed some instructions that I could find by
>>>             google-ing.
>>>
>>>             I know I need to set up flows to transmit and to
>>>             receive, but I'm not sure how.
>>>             Until now, for transmitting I used:
>>>
>>>             ovs-ofctl add-flow br-vnet
>>>             "in_port=1,actions=set_field:A.A.A.1->tun_dst,output:2"
>>>             (in_port = virtual network port, output = tunnel port)
>>>
>>>
>>>         Do you actually see packets going out on the wire when they
>>>         hit this flow?
>>
>>         -- 
>>         Andrei Andone
>>
>>         SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
>>         Email: andrei.andone at softvision.ro
>>         <mailto:andrei.andone at softvision.ro> | Web: www.softvision.ro
>>         <http://www.softvision.ro>
>>
>>         The content of this communication is classified as SOFTVISION
>>         Confidential and Proprietary Information.
>>
>>
>
>     -- 
>     Andrei Andone
>
>     SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
>     Email: andrei.andone at softvision.ro
>     <mailto:andrei.andone at softvision.ro> | Web: www.softvision.ro
>     <http://www.softvision.ro>
>
>     The content of this communication is classified as SOFTVISION
>     Confidential and Proprietary Information.
>
>

-- 
Andrei Andone

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.andone at softvision.ro <mailto:andrei.andone at softvision.ro> 
| Web: www.softvision.ro <http://www.softvision.ro>

The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130909/80cc58b8/attachment.html>


More information about the discuss mailing list