netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexis Bauvin <abauvin@scaleway.com>
To: dsa@cumulusnetworks.com, roopa@cumulusnetworks.com
Cc: netdev@vger.kernel.org, abauvin@scaleway.com, akherbouche@scaleway.com
Subject: [RFC v4 0/5] Add VRF support for VXLAN underlay
Date: Thu, 22 Nov 2018 02:07:08 +0100	[thread overview]
Message-ID: <20181122010713.3995-1-abauvin@scaleway.com> (raw)

v3 -> v4:
- rename vxlan_is_in_l3mdev_chain to netdev_is_upper master
- move it to net/core/dev.c
- make it return bool instead of int
- check if remote_ifindex is zero before resolving the l3mdev
- add testing script

v2 -> v3:
- fix build when CONFIG_NET_IPV6 is off
- fix build "unused l3mdev_master_upper_ifindex_by_index" build error with some
  configs

v1 -> v2:
- move vxlan_get_l3mdev from vxlan driver to l3mdev driver as
  l3mdev_master_upper_ifindex_by_index
- vxlan: rename variables named l3mdev_ifindex to ifindex

v0 -> v1:
- fix typos

We are trying to isolate the VXLAN traffic from different VMs with VRF as shown
in the schemas below:

+-------------------------+   +----------------------------+
| +----------+            |   |     +------------+         |
| |          |            |   |     |            |         |
| | tap-red  |            |   |     |  tap-blue  |         |
| |          |            |   |     |            |         |
| +----+-----+            |   |     +-----+------+         |
|      |                  |   |           |                |
|      |                  |   |           |                |
| +----+---+              |   |      +----+----+           |
| |        |              |   |      |         |           |
| | br-red |              |   |      | br-blue |           |
| |        |              |   |      |         |           |
| +----+---+              |   |      +----+----+           |
|      |                  |   |           |                |
|      |                  |   |           |                |
|      |                  |   |           |                |
| +----+--------+         |   |     +--------------+       |
| |             |         |   |     |              |       |
| |  vxlan-red  |         |   |     |  vxlan-blue  |       |
| |             |         |   |     |              |       |
| +------+------+         |   |     +-------+------+       |
|        |                |   |             |              |
|        |           VRF  |   |             |          VRF |
|        |           red  |   |             |         blue |
+-------------------------+   +----------------------------+
         |                                  |
         |                                  |
 +---------------------------------------------------------+
 |       |                                  |              |
 |       |                                  |              |
 |       |         +--------------+         |              |
 |       |         |              |         |              |
 |       +---------+  eth0.2030   +---------+              |
 |                 |  10.0.0.1/24 |                        |
 |                 +-----+--------+                    VRF |
 |                       |                            green|
 +---------------------------------------------------------+
                         |
                         |
                    +----+---+
                    |        |
                    |  eth0  |
                    |        |
                    +--------+


iproute2 commands to reproduce the setup:

ip link add green type vrf table 1
ip link set green up
ip link add eth0.2030 link eth0 type vlan id 2030
ip link set eth0.2030 master green
ip addr add 10.0.0.1/24 dev eth0.2030
ip link set eth0.2030 up

ip link add blue type vrf table 2
ip link set blue up
ip link add br-blue type bridge
ip link set br-blue master blue
ip link set br-blue up
ip link add vxlan-blue type vxlan id 2 local 10.0.0.1 dev eth0.2030 \
 port 4789
ip link set vxlan-blue master br-blue
ip link set vxlan-blue up
ip link set tap-blue master br-blue
ip link set tap-blue up

ip link add red type vrf table 3
ip link set red up
ip link add br-red type bridge
ip link set br-red master red
ip link set br-red up
ip link add vxlan-red type vxlan id 3 local 10.0.0.1 dev eth0.2030 \
 port 4789
ip link set vxlan-red master br-red
ip link set vxlan-red up
ip link set tap-red master br-red
ip link set tap-red up

We faced some issue in the datapath, here are the details:

* Egress traffic:
The vxlan packets are sent directly to the default VRF because it's where the
socket is bound, therefore the traffic has a default route via eth0. the
workarount is to force this traffic to VRF green with ip rules.

* Ingress traffic:
When receiving the traffic on eth0.2030 the vxlan socket is unreachable from
VRF green. The workaround is to enable *udp_l3mdev_accept* sysctl, but
this breaks isolation between overlay and underlay: packets sent from
blue or red by e.g. a guest VM will be accepted by the socket, allowing
injection of VXLAN packets from the overlay.

This patch serie fixes the issues describe above by allowing VXLAN socket to be
bound to a specific VRF device therefore looking up in the correct table.

Alexis Bauvin (5):
  udp_tunnel: add config option to bind to a device
  l3mdev: add function to retreive upper master
  vxlan: add support for underlay in non-default VRF
  netdev: add netdev_is_upper_master
  vxlan: handle underlay VRF changes

 drivers/net/vxlan.c                           | 114 ++++++++++++++++--
 include/linux/netdevice.h                     |   1 +
 include/net/l3mdev.h                          |  22 ++++
 include/net/udp_tunnel.h                      |   1 +
 net/core/dev.c                                |  17 +++
 net/ipv4/udp_tunnel.c                         |  10 ++
 net/ipv6/ip6_udp_tunnel.c                     |   9 ++
 net/l3mdev/l3mdev.c                           |  18 +++
 .../selftests/net/test_vxlan_under_vrf.sh     |  86 +++++++++++++
 9 files changed, 270 insertions(+), 8 deletions(-)
 create mode 100755 tools/testing/selftests/net/test_vxlan_under_vrf.sh

-- 

             reply	other threads:[~2018-11-22 11:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22  1:07 Alexis Bauvin [this message]
2018-11-22  1:07 ` [RFC v4 1/5] udp_tunnel: add config option to bind to a device Alexis Bauvin
2018-11-22 17:10   ` David Ahern
2018-11-22  1:07 ` [RFC v4 2/5] l3mdev: add function to retreive upper master Alexis Bauvin
2018-11-22 17:11   ` David Ahern
2018-11-22  1:07 ` [RFC v4 3/5] vxlan: add support for underlay in non-default VRF Alexis Bauvin
2018-11-22 17:19   ` David Ahern
2018-11-26 16:32     ` Alexis Bauvin
2018-11-26 17:54       ` David Ahern
2018-11-26 18:26         ` Roopa Prabhu
2018-11-26 19:06           ` Alexis Bauvin
2018-11-26 19:11             ` David Ahern
2018-11-27  0:41         ` Alexis Bauvin
2018-11-27  0:46           ` David Ahern
2018-11-27  0:57             ` Alexis Bauvin
2018-11-22  1:07 ` [RFC v4 4/5] netdev: add netdev_is_upper_master Alexis Bauvin
2018-11-22 17:14   ` David Ahern
2018-11-22 18:10     ` Alexis Bauvin
2018-11-22  1:07 ` [RFC v4 5/5] vxlan: handle underlay VRF changes Alexis Bauvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181122010713.3995-1-abauvin@scaleway.com \
    --to=abauvin@scaleway.com \
    --cc=akherbouche@scaleway.com \
    --cc=dsa@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).