netdev - Re: [RFC v3 0/3] Add VRF support for VXLAN underlay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3c4788fb-c71e-f626-138b-2a06a527b21a@cumulusnetworks.com>
Date:   Tue, 20 Nov 2018 14:45:56 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Alexis Bauvin <abauvin@...leway.com>, roopa@...ulusnetworks.com
Cc:     netdev@...r.kernel.org, akherbouche@...leway.com
Subject: Re: [RFC v3 0/3] Add VRF support for VXLAN underlay

On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> 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 |
> +-------------------------+   +----------------------------+

Roopa and I were discussing this setup and are puzzled by the VRF
association here. Does br-red and br-blue have an address? The commands
below do not show it and from our perspective seems odd for this
scenario. If it does not have an address, then there is no reason for
the VRF labeling.

Also, it would be good to have a unit test this case. Can you create a
shell script that creates the setup and runs a few tests verifying
connectivity? You can use network namespaces and veth pairs in place of
the VM with a tap device. From there the functionality is the same.
Tests can be initial VRF association for the vxlan lower device,
changing the VRF to another device, and then changing again back to
default VRF - checking proper connectivity for each.

Thanks