On Wed, May 18, 2016 at 9:41 AM, Jan Scheurich <jan.scheur...@web.de> wrote:
> 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;
> }
> }
> }
I agree current tunneling port check is bit arbitrary. It was designed
to handle most common tunneling setup. But I do not think we can allow
tunneling on any type of port. For example I doubt that it will work
on a tap port. It should be limited to subset of ports.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
