netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next 0/5] bridge: per vlan dst_metadata support
@ 2017-01-31  5:57 Roopa Prabhu
  2017-01-31  5:57 ` [PATCH net-next 1/5] ip_tunnels: new IP_TUNNEL_INFO_BRIDGE flag for ip_tunnel_info mode Roopa Prabhu
                   ` (5 more replies)
  0 siblings, 6 replies; 16+ messages in thread
From: Roopa Prabhu @ 2017-01-31  5:57 UTC (permalink / raw)
  To: netdev; +Cc: davem, stephen, nikolay, tgraf, hannes, jbenc, pshelar, dsa, hadi

From: Roopa Prabhu <roopa@cumulusnetworks.com>

High level summary:
lwt and dst_metadata have enabled vxlan l3 deployments
to use a single vxlan netdev for multiple vnis eliminating the scalability
problem with using a single vxlan netdev per vni. This series tries to
do the same for vxlan netdevs in pure l2 bridged networks.
Use-case/deployment and details are below.

Deployment scerario details:
As we know VXLAN is used to build layer 2 virtual networks across the
underlay layer3 infrastructure. A VXLAN tunnel endpoint (VTEP)
originates and terminates VXLAN tunnels. And a VTEP can be a TOR switch
or a vswitch in the hypervisor. This patch series mainly
focuses on the TOR switch configured as a Vtep. Vxlan segment ID (vni)
along with vlan id is used to identify layer 2 segments in a vxlan
overlay network. Vxlan bridging is the function provided by Vteps to terminate
vxlan tunnels and map the vxlan vni to traditional end host vlan. This is
covered in the "VXLAN Deployment Scenarios" in sections 6 and 6.1 in RFC 7348.
To provide vxlan bridging function, a vtep has to map vlan to a vni. The rfc
says that the ingress VTEP device shall remove the IEEE 802.1Q VLAN tag in
the original Layer 2 packet if there is one before encapsulating the packet
into the VXLAN format to transmit it through the underlay network. The remote
VTEP devices have information about the VLAN in which the packet will be
placed based on their own VLAN-to-VXLAN VNI mapping configurations.

Existing solution:
Without this patch series one can deploy such a vtep configuration by
adding the local ports and vxlan netdevs into a vlan filtering bridge.
The local ports are configured as trunk ports carrying all vlans.
A vxlan netdev per vni is added to the bridge. Vlan mapping to vni is
achieved by configuring the vlan as pvid on the corresponding vxlan netdev.
The vxlan netdev only receives traffic corresponding to the vlan it is mapped
to. This configuration maps traffic belonging to a vlan to the corresponding
vxlan segment.

          -----------------------------------
         |              bridge               |
         |                                   |
          -----------------------------------
            |100,200       |100 (pvid)    |200 (pvid)
            |              |              |
           swp1          vxlan1000      vxlan2000
                    
This provides the required vxlan bridging function but poses a
scalability problem with using a separate vxlan netdev for each vni.

Solution in this patch series:
The Goal is to use a single vxlan device to carry all vnis similar
to the vxlan collect metadata mode but additionally allowing the bridge
and vxlan driver to carry all the forwarding information and also learn.
This implementation uses the existing dst_metadata infrastructure to map
vlan to a tunnel id.
- vxlan driver changes:
    - enable collect metadata mode to be used with learning,
      replication and fdb
    - A single fdb table hashed by (mac, vni)
    - rx path already has the vni
    - tx path expects a vni in the packet with dst_metadata and relies
      on learnt or static forwarding information table to forward the packet

- Bridge driver changes: per vlan dst_metadata support:
    - Our use case is vxlan and 1-1 mapping between vlan and vni, but I have
      kept the api generic for any tunnel info
    - Uapi to configure/unconfigure/dump per vlan tunnel data
    - new bridge port flag to turn this feature on/off. off by default
    - ingress hook:
        - if port is a tunnel port, use tunnel info in
          attached dst_metadata to map it to a local vlan
    - egress hook:
        - if port is a tunnel port, use tunnel info attached to vlan
          to set dst_metadata on the skb

Other approaches tried and vetoed:
- tc vlan push/pop and tunnel metadata dst:
    - though tc can be used to do part of this, these patches address a deployment
      case where bridge driver vlan filtering and forwarding information
      database along with vxlan driver forwarding information table and learning
      are required.
- making vxlan driver understand vlan-vni mapping:
    - I had a series almost ready with this one but soon realized
      it duplicated a lot of vlan handling code in the vxlan driver

Roopa Prabhu (5):
  ip_tunnels: new IP_TUNNEL_INFO_BRIDGE flag for ip_tunnel_info mode
  vxlan: support fdb and learning in COLLECT_METADATA mode
  bridge: uapi: add per vlan tunnel info
  bridge: per vlan dst_metadata netlink support
  bridge: vlan dst_metadata hooks in ingress and egress paths

 drivers/net/vxlan.c            |  211 +++++++++++++++++-----------
 include/linux/if_bridge.h      |    1 +
 include/net/ip_tunnels.h       |    1 +
 include/uapi/linux/if_bridge.h |   11 ++
 include/uapi/linux/if_link.h   |    1 +
 include/uapi/linux/neighbour.h |    1 +
 net/bridge/Makefile            |    5 +-
 net/bridge/br_forward.c        |    2 +-
 net/bridge/br_input.c          |    8 +-
 net/bridge/br_netlink.c        |  140 +++++++++++++------
 net/bridge/br_netlink_tunnel.c |  296 ++++++++++++++++++++++++++++++++++++++++
 net/bridge/br_private.h        |   12 ++
 net/bridge/br_private_tunnel.h |   47 +++++++
 net/bridge/br_vlan.c           |   24 +++-
 net/bridge/br_vlan_tunnel.c    |  203 +++++++++++++++++++++++++++
 15 files changed, 837 insertions(+), 126 deletions(-)
 create mode 100644 net/bridge/br_netlink_tunnel.c
 create mode 100644 net/bridge/br_private_tunnel.h
 create mode 100644 net/bridge/br_vlan_tunnel.c

-- 
1.7.10.4

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-02-01 19:12 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-31  5:57 [PATCH net-next 0/5] bridge: per vlan dst_metadata support Roopa Prabhu
2017-01-31  5:57 ` [PATCH net-next 1/5] ip_tunnels: new IP_TUNNEL_INFO_BRIDGE flag for ip_tunnel_info mode Roopa Prabhu
2017-01-31  5:57 ` [PATCH net-next 2/5] vxlan: support fdb and learning in COLLECT_METADATA mode Roopa Prabhu
2017-01-31 23:37   ` Jonathan Toppins
2017-02-01  3:38     ` Roopa Prabhu
2017-01-31  5:57 ` [PATCH net-next 3/5] bridge: uapi: add per vlan tunnel info Roopa Prabhu
2017-01-31  5:57 ` [PATCH net-next 4/5] bridge: per vlan dst_metadata netlink support Roopa Prabhu
2017-01-31  7:12   ` kbuild test robot
2017-01-31  9:34   ` kbuild test robot
2017-01-31  5:57 ` [PATCH net-next 5/5] bridge: vlan dst_metadata hooks in ingress and egress paths Roopa Prabhu
2017-01-31 12:52   ` kbuild test robot
2017-01-31 15:38     ` Roopa Prabhu
2017-01-31 16:41 ` [PATCH net-next 0/5] bridge: per vlan dst_metadata support Stephen Hemminger
2017-01-31 20:43   ` Roopa Prabhu
2017-02-01 16:35     ` Stephen Hemminger
2017-02-01 19:12       ` Roopa Prabhu

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).