This patch enables user-space tunnels to work over internal (tap) ports other
than
the bridge LOCAL port. This feature can e.g. be used to implement tunnels over
different VLANs on the same physical port by adding multiple internal ports
to the physical bridge as VLAN access ports:
ovs-vsctl add-br br-int -- set bridge br-int datapath_type=netdev
ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan
options:remote_ip=10.1.2.20 options:key=flow
ovs-vsctl add-port br-int vxlan1 -- set interface vxlan1 type=vxlan
options:remote_ip=10.1.3.20 options:key=flow
ovs-vsctl add-br br-phy -- set bridge br-phy datapath_type=netdev
ovs-vsctl add-port br-phy dpdk0 -- set Interface dpdk0 type=dpdk
ovs-vsctl add-port br-phy tep1 vlan_mode=access tag=1000 -- set interface tep1
type=internal
ovs-vsctl add-port br-phy tep2 vlan_mode=access tag=2000 -- set interface tep2
type=internal
ifconfig tep1 10.1.2.10/24 up
ifconfig tep2 10.1.3.10/24 up
Tunnel connectivity over a setup like the above has been manually tested.
Signed-off-by: Jan Scheurich <jan.scheur...@web.de>
---
ofproto/ofproto-dpif-xlate.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 15ca565..556b2e2 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -2737,13 +2737,15 @@ tnl_route_lookup_flow(const struct flow *oflow,
ovs_assert(xcfg);
HMAP_FOR_EACH (xbridge, hmap_node, &xcfg->xbridges) {
- if (!strncmp(xbridge->name, out_dev, IFNAMSIZ)) {
- struct xport *port;
- HMAP_FOR_EACH (port, ofp_node, &xbridge->xports) {
- if (!strncmp(netdev_get_name(port->netdev), out_dev,
IFNAMSIZ)) {
+ struct xport *port;
+ HMAP_FOR_EACH (port, ofp_node, &xbridge->xports) {
+ if (!strncmp(netdev_get_name(port->netdev), out_dev, IFNAMSIZ)) {
+ if (!strcmp(netdev_get_type(port->netdev), "tap")) {
*out_port = port;
return 0;
+ } else {
+ return -ENOENT;
}
}
}
@@ -3165,8 +3167,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);
}
> -----Original Message-----
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan
> Scheurich
> Sent: Wednesday, 11 May, 2016 12:33
> To: dev@openvswitch.org
> Subject: [ovs-dev] User-space tunneling only on LOCAL port?
>
> 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?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
