summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-02-03 23:21:23 +0300
committerDavid S. Miller <davem@davemloft.net>2017-02-03 23:21:23 +0300
commit3b19860c7f3d0c184385055cebded19bc537ff4a (patch)
tree48288a17219c037942267db3c6c469cf47bf7ecb /include
parent5a0fd98b7b5be8773c53c40c47451ec6cd11d1ff (diff)
parent11538d039ac6efcf4f1a6c536e1b87cd3668a9fd (diff)
downloadlinux-3b19860c7f3d0c184385055cebded19bc537ff4a.tar.xz
Merge branch 'bridge-per-vlan-dst_metadata-support'
Roopa Prabhu says: ==================== bridge: per vlan dst_metadata support 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 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include')
-rw-r--r--include/linux/if_bridge.h1
-rw-r--r--include/net/ip_tunnels.h1
-rw-r--r--include/uapi/linux/if_bridge.h11
-rw-r--r--include/uapi/linux/if_link.h1
-rw-r--r--include/uapi/linux/neighbour.h1
5 files changed, 15 insertions, 0 deletions
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index debc9d5904e5..c5847dc75a93 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -47,6 +47,7 @@ struct br_ip_list {
#define BR_PROXYARP_WIFI BIT(10)
#define BR_MCAST_FLOOD BIT(11)
#define BR_MULTICAST_TO_UNICAST BIT(12)
+#define BR_VLAN_TUNNEL BIT(13)
#define BR_DEFAULT_AGEING_TIME (300 * HZ)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 3d4ca4df1209..95056796657c 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -58,6 +58,7 @@ struct ip_tunnel_key {
/* Flags for ip_tunnel_info mode. */
#define IP_TUNNEL_INFO_TX 0x01 /* represents tx tunnel parameters */
#define IP_TUNNEL_INFO_IPV6 0x02 /* key contains IPv6 addresses */
+#define IP_TUNNEL_INFO_BRIDGE 0x04 /* represents a bridged tunnel id */
/* Maximum tunnel options length. */
#define IP_TUNNEL_OPTS_MAX \
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index ab92bca6d448..a9e6244ce438 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -118,6 +118,7 @@ enum {
IFLA_BRIDGE_FLAGS,
IFLA_BRIDGE_MODE,
IFLA_BRIDGE_VLAN_INFO,
+ IFLA_BRIDGE_VLAN_TUNNEL_INFO,
__IFLA_BRIDGE_MAX,
};
#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
@@ -134,6 +135,16 @@ struct bridge_vlan_info {
__u16 vid;
};
+enum {
+ IFLA_BRIDGE_VLAN_TUNNEL_UNSPEC,
+ IFLA_BRIDGE_VLAN_TUNNEL_ID,
+ IFLA_BRIDGE_VLAN_TUNNEL_VID,
+ IFLA_BRIDGE_VLAN_TUNNEL_FLAGS,
+ __IFLA_BRIDGE_VLAN_TUNNEL_MAX,
+};
+
+#define IFLA_BRIDGE_VLAN_TUNNEL_MAX (__IFLA_BRIDGE_VLAN_TUNNEL_MAX - 1)
+
struct bridge_vlan_xstats {
__u64 rx_bytes;
__u64 rx_packets;
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index b9aa5641ebe5..320fc1e747ee 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -322,6 +322,7 @@ enum {
IFLA_BRPORT_PAD,
IFLA_BRPORT_MCAST_FLOOD,
IFLA_BRPORT_MCAST_TO_UCAST,
+ IFLA_BRPORT_VLAN_TUNNEL,
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index bd99a8d80f36..f3d16dbe09d6 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -26,6 +26,7 @@ enum {
NDA_IFINDEX,
NDA_MASTER,
NDA_LINK_NETNSID,
+ NDA_SRC_VNI,
__NDA_MAX
};