[ovs-dev] User-space tunneling only on LOCAL port?

Jan Scheurich jan.scheurich at ericsson.com
Wed May 11 10:33:08 UTC 2016


We are trying to set up user-space tunneling with DPDK datapath in OVS 2.5 using other internal ports on the external bridge (br-prv) than the LOCAL bridge port as local tunnel end-points. The ultimate goal is to configure the different internal ports on br-prv as VLAN access ports with different tags to separate the tunnel traffic into a number of VLANs on the physical underlay.

However, we experience that even though OVS can be configured for this and is able to resolve the remote tunnel end-point, the data plane does not work. Packets are  being dropped on egress into the tunnel port. In the other direction, tunneled packets received on br-prv are forwarded to port tep1 with VXLAN encapsulation.

The data plane only works as expected if the LOCAL port of the external bridge is configured as local tunnel end-point.

Is this limitation intended? Or is it simply a short-cut to simplify the implementation of user-space tunneling?

Here is our configuration in details:

# ovs-vsctl show
176cb2b1-0ebe-4490-9210-f60434f09cc9
    Bridge br_int
        Port br_int
            Interface br_int
                type: internal
        Port "vxlan0"
            Interface "vxlan0"
                type: vxlan
                options: {key=flow, remote_ip="10.1.2.9"}
    Bridge br-prv
        Port br-prv
            tag: 100
            Interface br-prv
                type: internal
        Port bond-dpdk
            Interface "dpdk0"
                type: dpdk
            Interface "dpdk1"
                type: dpdk
        Port "tep1"
            Interface "tep1"
                type: internal

# ifconfig -a
br_int    Link encap:Ethernet  HWaddr 66:e2:69:60:dc:42
          inet addr:172.1.1.8  Bcast:172.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::64e2:69ff:fe60:dc42/64 Scope:Link
          UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1
          RX packets:391 errors:0 dropped:391 overruns:0 frame:0
          TX packets:803 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:16722 (16.7 KB)  TX bytes:34038 (34.0 KB)

br-prv    Link encap:Ethernet  HWaddr 8c:dc:d4:ab:5b:f0
          BROADCAST PROMISC  MTU:1500  Metric:1
          RX packets:23 errors:0 dropped:0 overruns:0 frame:0
          TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1712 (1.7 KB)  TX bytes:8334 (8.3 KB)

tep1      Link encap:Ethernet  HWaddr c2:cf:a0:d4:f4:d6
          inet addr:10.1.3.8  Bcast:10.1.3.255  Mask:255.255.255.0
          inet6 addr: fe80::c0cf:a0ff:fed4:f4d6/64 Scope:Link
          UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1
          RX packets:3328 errors:0 dropped:2682 overruns:0 frame:0
          TX packets:127 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:231004 (231.0 KB)  TX bytes:11454 (11.4 KB)

# ip route
10.1.2.0/24 via 10.1.3.1 dev tep1
10.1.3.0/24 dev tep1  proto kernel  scope link  src 10.1.3.8
172.1.1.0/24 dev br_int  proto kernel  scope link  src 172.1.1.8

Apparently OVS is able to correctly resolve the VXLAN tunnel to the internal port tep1 as local end point.

# ovs-appctl ovs/route/show
Route Table:
Cached: 10.1.3.8/32 dev tep1
Cached: 172.1.1.8/32 dev br_int
Cached: ::1/128 dev lo
Cached: 10.1.2.0/24 dev tep1 GW 10.1.3.1
Cached: 10.1.3.0/24 dev tep1
Cached: 172.1.1.0/24 dev br_int
Cached: 127.0.0.0/8 dev lo
Cached: 0.0.0.0/0 dev eth0 GW 10.87.247.1

# ovs-appctl tnl/neigh/show
IP                                            MAC                 Bridge
==========================================================================
10.1.3.8                                      c2:cf:a0:d4:f4:d6   br-prv
10.1.3.1                                      00:04:96:98:78:18   br_int
10.1.3.1                                      00:04:96:98:78:18   br-prv
172.1.1.8                                     66:e2:69:60:dc:42   br_int

# ovs-vsctl list interface vxlan0
_uuid               : b2a26291-fc5c-448c-921e-c6216b24caf7
admin_state         : up
...
mac_in_use          : "1e:84:2f:1e:69:7a"
mtu                 : []
name                : "vxlan0"
ofport              : 100
ofport_request      : 100
options             : {key=flow, remote_ip="10.1.2.9"}
other_config        : {}
statistics          : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=64324, tx_dropped=0, tx_errors=0, tx_packets=1185}
status              : {tunnel_egress_iface="tep1", tunnel_egress_iface_carrier=up}
type                : vxlan

In the ofproto-dpif code handling de-tunneling there seems to be an explicit check on OFPP_LOCAL as egress port. Should other internal ports work if we just remove the check?

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 15ca565..acc8376 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3165,8 +3165,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,

                 /* XXX: Write better Filter for tunnel port. We can use inport
                 * int tunnel-port flow to avoid these checks completely. */
-                if (ofp_port == OFPP_LOCAL &&
-                    ovs_native_tunneling_is_on(ctx->xbridge->ofproto)) {
+                if (ovs_native_tunneling_is_on(ctx->xbridge->ofproto)) {

                     odp_tnl_port = tnl_port_map_lookup(flow, wc);
                 }





More information about the dev mailing list