VXLAN driver
Subsystems (6)
cover VXLAN driver
This patchset implements the Virtual eXtensible Local Area Network tunnel. The code comes from GRE, Bridge, and the OVS Vxlan. The code has only been tested with the TAP based vxlan
https://github.com/upa/vxlan.git
Thanks to Chris for the idea.
PATCH 1/3 netlink: add attributes to fdb interface
Later changes need to be able to refer to neighbour attributes when doing fdb_add.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- drivers/net/macvlan.c | 2 +- include/linux/netdevice.h | 4 +++- net/bridge/br_fdb.c | 3 ++- net/bridge/br_private.h | 2 +- net/core/rtnetlink.c | 6 ++++-- 6 files changed, 12 insertions(+), 7 deletions(-)
drivers/net/macvlan.c +1 -1
@@ -546,7 +546,7 @@ static int macvlan_vlan_rx_kill_vid(strureturn 0 ; } -static int macvlan_fdb_add (struct ndmsg *ndm, +static int macvlan_fdb_add (struct ndmsg *ndm,struct nlattr *tb[],struct net_device *dev,const unsigned char *addr,u16 flags)
include/linux/netdevice.h +3 -1
@@ -906,7 +906,8 @@ struct netdev_fcoe_hbainfo {* feature set might be less than what was returned by ndo_fix_features()). * Must return >0 or -errno if it changed dev->features itself. * -* int (*ndo_fdb_add)(struct ndmsg *ndm, struct net_device *dev, +* int (*ndo_fdb_add)(struct ndmsg *ndm, struct nlattr *tb[], +* struct net_device *dev, * const unsigned char *addr, u16 flags) * Adds an FDB entry to dev for addr. * int (*ndo_fdb_del)(struct ndmsg *ndm, struct net_device *dev,
@@ -1016,6 +1017,7 @@ struct net_device_ops {void (*ndo_neigh_destroy)(struct neighbour *n);int (*ndo_fdb_add)(struct ndmsg *ndm, +struct nlattr *tb[],struct net_device *dev,const unsigned char *addr,u16 flags);
net/bridge/br_fdb.c +2 -1
@@ -608,7 +608,8 @@ static int fdb_add_entry(struct net_brid }/* Add new permanent fdb entry with RTM_NEWNEIGH */ -int br_fdb_add (struct ndmsg *ndm,struct net_device *dev, +int br_fdb_add (struct ndmsg *ndm,struct nlattr *tb[], +struct net_device *dev,const unsigned char *addr,u16 nlh_flags) {struct net_bridge_port *p;
net/bridge/br_private.h +1 -1
@@ -364,7 +364,7 @@ extern void br_fdb_update(struct net_briextern int br_fdb_delete (struct ndmsg *ndm,struct net_device *dev,const unsigned char *addr); -extern int br_fdb_add (struct ndmsg *nlh, +extern int br_fdb_add (struct ndmsg *nlh,struct nlattr *tb[],struct net_device *dev,const unsigned char *addr,u16 nlh_flags);
net/core/rtnetlink.c +4 -2
@@ -2090,7 +2090,8 @@ static int rtnl_fdb_add(struct sk_buff *if ((!ndm->ndm_flags || ndm->ndm_flags &NTF_MASTER ) && (dev->priv_flags &IFF_BRIDGE_PORT )) { master = dev->master; - err = master->netdev_ops->ndo_fdb_add (ndm, dev, addr, + err = master->netdev_ops->ndo_fdb_add (ndm, tb, + dev, addr, nlh->nlmsg_flags);if (err) goto out;
@@ -2100,7 +2101,8 @@ static int rtnl_fdb_add(struct sk_buff */* Embedded bridge, macvlan, and any other device support */ if ((ndm->ndm_flags &NTF_SELF ) && dev->netdev_ops->ndo_fdb_add) { - err = dev->netdev_ops->ndo_fdb_add (ndm, dev, addr, + err = dev->netdev_ops->ndo_fdb_add (ndm, tb, + dev, addr, nlh->nlmsg_flags);if (!err) {
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +1 -1
@@ -6888,7 +6888,7 @@ static int ixgbe_set_features(struct netreturn 0 ; } -static int ixgbe_ndo_fdb_add (struct ndmsg *ndm, +static int ixgbe_ndo_fdb_add (struct ndmsg *ndm,struct nlattr *tb[],struct net_device *dev,const unsigned char *addr,u16 flags)
PATCH 2/3 igmp: export symbol ip_mc_leave_group
In reply to Stephen HemmingerNeeded for VXLAN.
net/ipv4/igmp.c +1 -0
@@ -1904,6 +1904,7 @@ int ip_mc_leave_group(struct sock *sk, srtnl_unlock ();return ret; } +EXPORT_SYMBOL (ip_mc_leave_group);int ip_mc_source (int add,int omode,struct sock *sk,struct ip_mreq_source *mreqs,int ifindex)
PATCH 3/3 vxlan: virtual extensible lan
In reply to Stephen HemmingerThis is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
--- Documentation/networking/vxlan.txt | 36 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1180 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 14 5 files changed, 1244 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called macvlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1171 -0
1,171 lines not on this page · raw message
include/linux/if_link.h +14 -0
@@ -272,6 +272,20 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +36 -0
@@ -0,0 +1,36 @@ +Virtual eXtensible Local Area Networking documentation +====================================================== + +The VXLAN protocol is a tunnelling protocol that is designed to +solve the problem of limited number of available VLAN's (4096). +With VXLAN identifier is expanded to 24 bits. + +It is a draft RFC standard, that is implemented by Cisco Nexus, +Vmware and Brocade. The protocol runs over UDP using a single +destination port (still not standardized by IANA). +This document describes the Linux kernel tunnel device, +there is also an implantation of VXLAN for Openvswitch. + +Unlike most tunnels, a VXLAN is a 1 to N network, not just point +to point. A VXLAN device can either dynamically learn the IP address +of the other end, in a manner similar to a learning bridge, or the +forwarding entries can be configured statically. + +The management of vxlan is done in a similar fashion to it's +too closest neighbors GRE and VLAN. Configuring VXLAN requires +the version of iproute2 that matches the kernel release +where VXLAN was first merged upstream. + +1. Create vxlan device + # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device (vxlan0). The device uses the +the multicast group 239.1.1.1 over eth1 to handle packets where +no entry is in the forwarding table. + +2. Delete vxlan device + # ip link delete vxlan0 + +3. Show vxlan info + # ip -d show vxlan0 +
Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
Quoted 9 lines · Stephen Hemminger
drivers/net/Kconfig +3
-0@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL
drivers/net/Kconfig config MACVTAP · line 164
Quoted 10 lines
drivers/net/Kconfig +10
-0+ ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called macvlan. +
copy/paste error, this module wont be called macvlan ;)
Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
In reply to Stephen Hemmingerdrivers/net/vxlan.c line 489
Quoted 4 lines · Stephen Hemminger
drivers/net/vxlan.c new file +4
-0+/* Callback from net/ipv4/udp.c to receive packets */ +static int vxlan_udp_encap_recv (struct sock *sk,struct sk_buff *skb) +{ +struct iphdr *oip =ip_hdr (skb);
oip is set to ip_hdr(skb)
Quoted 5 lines
drivers/net/vxlan.c new file +5
-0+struct vxlanhdr *vxh; +struct vxlan_dev *vxlan; +struct vxlan_stats *stats; +__u32 vni; +__be32 saddr = oip->saddr;/* source address for learning */
drivers/net/vxlan.c line 504
Quoted 10 lines
drivers/net/vxlan.c new file +10
-0+__be32 daddr = oip->daddr;/* destination for checking */ + +/* pop off outer UDP header */ +__skb_pull (skb,sizeof (struct udphdr )); + +/* Need Vxlan and inner Ethernet header to be present */ +if (!pskb_may_pull (skb, +sizeof (struct vxlanhdr ) +sizeof (struct ethhdr ))) + goto error; +
here oip may points to a freed memory, if pskb_may_pull) has to reallocate skb->head
Quoted 41 lines
drivers/net/vxlan.c new file +41
-0+/* Drop packets with reserved bits set */ + vxh = (struct vxlanhdr *) skb->data; +if (vxh->vx_flags !=htonl (VXLAN_FLAGS ) || + (vxh->vx_vni &htonl (0xff ))) + goto error; + +__skb_pull (skb,sizeof (struct vxlanhdr )); + +/* Is this VNI defined? */ + vni =ntohl (vxh->vx_vni) >>8 ; + vxlan =vxlan_find_vni (sock_net (sk), vni); +if (!vxlan) + goto drop; + +/* Ignore packets if device is not up */ +if (!netif_running (vxlan->dev)) + goto drop; + +/* Re-examine inner Ethernet packet */ + skb->protocol =eth_type_trans (skb, vxlan->dev); + skb->ip_summed =CHECKSUM_NONE ; + +/* Ignore packet loops (and multicast echo) */ +if (compare_ether_addr (eth_hdr (skb)->h_source, + vxlan->dev->dev_addr) ==0 ) + goto drop; + +/* Check for multicast group configuration errors */ +if (IN_MULTICAST (ntohl (daddr)) && + daddr != vxlan->gaddr) { +if (net_ratelimit ()) +netdev_notice (vxlan->dev, +"group address %pI4 does not match\n" , + &daddr); + goto drop; + } + +if (vxlan->learn) +vxlan_snoop (skb->dev, saddr,eth_hdr (skb)->h_source); + + stats =this_cpu_ptr (vxlan->stats);
drivers/net/vxlan.c line 553
Quoted 10 lines
drivers/net/vxlan.c new file +8
-0+u64_stats_update_begin (&stats->syncp); + stats->rx_packets++; + stats->rx_bytes += skb->len; +u64_stats_update_end (&stats->syncp); + +__skb_tunnel_rx (skb, vxlan->dev); +skb_reset_network_header (skb); +vxlan_ecn_decap (oip, skb);
potential crash
PATCH v2 3/3 vxlan: virtual extensible lan
Subject: vxlan: virtual extensible lan
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
---
v2 - fix reference to possible freed memory in receive path
Documentation/networking/vxlan.txt | 36 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1180 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 14 5 files changed, 1244 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called vxlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1171 -0
1,171 lines not on this page · raw message
include/linux/if_link.h +14 -0
@@ -272,6 +272,20 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +36 -0
@@ -0,0 +1,36 @@ +Virtual eXtensible Local Area Networking documentation +====================================================== + +The VXLAN protocol is a tunnelling protocol that is designed to +solve the problem of limited number of available VLAN's (4096). +With VXLAN identifier is expanded to 24 bits. + +It is a draft RFC standard, that is implemented by Cisco Nexus, +Vmware and Brocade. The protocol runs over UDP using a single +destination port (still not standardized by IANA). +This document describes the Linux kernel tunnel device, +there is also an implantation of VXLAN for Openvswitch. + +Unlike most tunnels, a VXLAN is a 1 to N network, not just point +to point. A VXLAN device can either dynamically learn the IP address +of the other end, in a manner similar to a learning bridge, or the +forwarding entries can be configured statically. + +The management of vxlan is done in a similar fashion to it's +too closest neighbors GRE and VLAN. Configuring VXLAN requires +the version of iproute2 that matches the kernel release +where VXLAN was first merged upstream. + +1. Create vxlan device + # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device (vxlan0). The device uses the +the multicast group 239.1.1.1 over eth1 to handle packets where +no entry is in the forwarding table. + +2. Delete vxlan device + # ip link delete vxlan0 + +3. Show vxlan info + # ip -d show vxlan0 +
Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
drivers/net/vxlan.c line 393
Quoted 13 lines · Stephen Hemminger
drivers/net/vxlan.c new file +13
-0+ f =vxlan_find_mac (vxlan, src_mac); +if (likely (f)) { + f->used = jiffies; +if (likely (f->remote_ip == src_ip)) +return ; + + f->remote_ip = src_ip; + f->updated = jiffies; + +if (net_ratelimit ()) +netdev_info (dev, +"%pM migrated from %pI4 to %pI4\n" , + src_mac, &f->remote_ip, &src_ip);
This message is useless, as previous f_remote_ip content was already overwritten.
PATCH v3 3/3 vxlan: virtual extensible lan
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
---
v3 - fix ordering of change versus migration message v2 - fix use of ip header after pskb_may_pull
Documentation/networking/vxlan.txt | 36 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1180 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 14 5 files changed, 1244 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called vxlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1171 -0
1,171 lines not on this page · raw message
include/linux/if_link.h +14 -0
@@ -272,6 +272,20 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +36 -0
@@ -0,0 +1,36 @@ +Virtual eXtensible Local Area Networking documentation +====================================================== + +The VXLAN protocol is a tunnelling protocol that is designed to +solve the problem of limited number of available VLAN's (4096). +With VXLAN identifier is expanded to 24 bits. + +It is a draft RFC standard, that is implemented by Cisco Nexus, +Vmware and Brocade. The protocol runs over UDP using a single +destination port (still not standardized by IANA). +This document describes the Linux kernel tunnel device, +there is also an implantation of VXLAN for Openvswitch. + +Unlike most tunnels, a VXLAN is a 1 to N network, not just point +to point. A VXLAN device can either dynamically learn the IP address +of the other end, in a manner similar to a learning bridge, or the +forwarding entries can be configured statically. + +The management of vxlan is done in a similar fashion to it's +too closest neighbors GRE and VLAN. Configuring VXLAN requires +the version of iproute2 that matches the kernel release +where VXLAN was first merged upstream. + +1. Create vxlan device + # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device (vxlan0). The device uses the +the multicast group 239.1.1.1 over eth1 to handle packets where +no entry is in the forwarding table. + +2. Delete vxlan device + # ip link delete vxlan0 + +3. Show vxlan info + # ip -d show vxlan0 +
Re: [PATCHv3 net-next 3/3] vxlan: virtual extensible lan
[...]
Quoted 27 lines · Stephen Hemminger
drivers/net/vxlan.c new file +27
-0+ +/* Transmit local packets over Vxlan +* +* Outer IP header inherits ECN and DF from inner header. +* Outer UDP destination is the VXLAN assigned port. +* source port is based on hash of flow if available +* otherwise use a random value +*/ +static netdev_tx_t vxlan_xmit (struct sk_buff *skb,struct net_device *dev) +{ +struct vxlan_dev *vxlan =netdev_priv (dev); +struct rtable *rt; +const struct ethhdr *eth; +const struct iphdr *old_iph; +struct iphdr *iph; +struct vxlanhdr *vxh; +struct udphdr *uh; +struct flowi4 fl4; +struct vxlan_fdb *f; +unsigned int pkt_len = skb->len; +unsigned int mtu; +u32 hash; +__be32 dst; +__be16 df =0 ; +__u8 tos, ttl; +int err; +
[...]
drivers/net/vxlan.c line 721
Quoted 7 lines
drivers/net/vxlan.c new file +7
-0+ err =ip_local_out (skb); +if (likely (net_xmit_eval (err) ==0 )) { +struct vxlan_stats *stats =this_cpu_ptr (vxlan->stats); + +u64_stats_update_begin (&stats->syncp); + stats->tx_packets++; + stats->tx_bytes += pkt_len;
Should pkt_len include the outer headers?
Quoted 17 lines
drivers/net/vxlan.c new file +17
-0+u64_stats_update_end (&stats->syncp); + }else { + dev->stats.tx_errors++; + dev->stats.tx_aborted_errors++; + } +return NETDEV_TX_OK ; + +drop: + dev->stats.tx_dropped++; + goto tx_free; + +tx_error: + dev->stats.tx_errors++; +tx_free: +dev_kfree_skb (skb); +return NETDEV_TX_OK ; +}
Re: [PATCHv3 net-next 3/3] vxlan: virtual extensible lan
Quoted 33 lines · On Mon, 24 Sep 2012 13:24:41 -0700 John Fastabend <[email protected]>…
[...]
Quoted 27 lines · Stephen Hemminger
drivers/net/vxlan.c new file +27
-0+ +/* Transmit local packets over Vxlan +* +* Outer IP header inherits ECN and DF from inner header. +* Outer UDP destination is the VXLAN assigned port. +* source port is based on hash of flow if available +* otherwise use a random value +*/ +static netdev_tx_t vxlan_xmit (struct sk_buff *skb,struct net_device *dev) +{ +struct vxlan_dev *vxlan =netdev_priv (dev); +struct rtable *rt; +const struct ethhdr *eth; +const struct iphdr *old_iph; +struct iphdr *iph; +struct vxlanhdr *vxh; +struct udphdr *uh; +struct flowi4 fl4; +struct vxlan_fdb *f; +unsigned int pkt_len = skb->len; +unsigned int mtu; +u32 hash; +__be32 dst; +__be16 df =0 ; +__u8 tos, ttl; +int err; +[...]
Quoted 9 lines
drivers/net/vxlan.c line 721
Quoted 7 lines
drivers/net/vxlan.c new file +7
-0+ err =ip_local_out (skb); +if (likely (net_xmit_eval (err) ==0 )) { +struct vxlan_stats *stats =this_cpu_ptr (vxlan->stats); + +u64_stats_update_begin (&stats->syncp); + stats->tx_packets++; + stats->tx_bytes += pkt_len;Should
pkt_leninclude the outer headers?
It doesn't for GRE and related tunnels.
Re: [PATCHv3 net-next 3/3] vxlan: virtual extensible lan
Quoted 14 lines
Quoted 4 lines
[...]
Quoted 9 lines
drivers/net/vxlan.c line 721
Quoted 7 lines
drivers/net/vxlan.c new file +7
-0+ err =ip_local_out (skb); +if (likely (net_xmit_eval (err) ==0 )) { +struct vxlan_stats *stats =this_cpu_ptr (vxlan->stats); + +u64_stats_update_begin (&stats->syncp); + stats->tx_packets++; + stats->tx_bytes += pkt_len;Should
pkt_leninclude the outer headers?
Quoted 2 lines
It doesn't for GRE and related tunnels.
OK best to keep it the same as other tunnels.
Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
In reply to Stephen HemmingerQuoted 7 lines · Stephen Hemminger
drivers/net/vxlan.c new file +7
-0+/* Initialize the device structure. */ +static void vxlan_setup (struct net_device *dev) +{ +struct vxlan_dev *vxlan =netdev_priv (dev); +unsigned h; + +eth_hw_addr_random (dev);
drivers/net/vxlan.c line 921
Quoted 10 lines
drivers/net/vxlan.c new file +10
-0+ether_setup (dev); + + dev->netdev_ops = &vxlan_netdev_ops; + dev->destructor = vxlan_free; +SET_NETDEV_DEVTYPE (dev, &vxlan_type); + + dev->tx_queue_len =0 ; + dev->features |=NETIF_F_LLTX ; + dev->features |=NETIF_F_NETNS_LOCAL ; + dev->priv_flags &= ~IFF_XMIT_DST_RELEASE ;
I am not sure why you remove IFF_XMIT_DST_RELEASE here
Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
Quoted 13 lines · On Mon, 24 Sep 2012 22:09:50 +0200 Eric Dumazet <[email protected]> wrote:
Quoted 11 lines · Stephen Hemminger
drivers/net/vxlan.c new file +11
-0+/* Initialize the device structure. */ +static void vxlan_setup (struct net_device *dev) +{ +struct vxlan_dev *vxlan =netdev_priv (dev); +unsigned h; + +eth_hw_addr_random (dev); +ether_setup (dev); + + dev->netdev_ops = &vxlan_netdev_ops; + dev->destructor = vxlan_free;
Quoted 8 lines
drivers/net/vxlan.c line 921
Quoted 6 lines
drivers/net/vxlan.c new file +6
-0+SET_NETDEV_DEVTYPE (dev, &vxlan_type); + + dev->tx_queue_len =0 ; + dev->features |=NETIF_F_LLTX ; + dev->features |=NETIF_F_NETNS_LOCAL ; + dev->priv_flags &= ~IFF_XMIT_DST_RELEASE ;I am not sure why you remove
IFF_XMIT_DST_RELEASEhere
Copied from GRE. What is impact either way?
Re: [PATCHv2 net-next 3/3] vxlan: virtual extensible lan
Quoted 8 lines · Stephen Hemminger
Quoted 2 lines · On Mon, 24 Sep 2012 22:09:50 +0200 Eric Dumazet <[email protected]> wrote:
I am not sure why you remove
IFF_XMIT_DST_RELEASEhereCopied from GRE. What is impact either way?
GRE needs skb_dst(skb) to be non NULL if tiph->daddr == NULL
but I am not sure your code needs this.
This is a performance issue, for packets waiting in a Qdisc : we'll need to force a reference (and a cache line false sharing)
Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
In reply to Stephen HemmingerQuoted 9 lines · * Stephen Hemminger ([email protected]) wrote:
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
I'm working on doing some interop
Quoted 8 lines
drivers/net/Kconfig +2
-0@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)"
drivers/net/Kconfig config MACVTAP · line 163
Quoted 10 lines
drivers/net/Kconfig +10
-0+ depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called macvlan.
^^^^^^^
Cut 'n paste error, s/macvlan/vxlan/
Quoted 9 lines
drivers/net/Kconfig +9
-0+/* Add static entry (via netlink) */ +static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[], + struct net_device *dev, + const unsigned char *addr, u16 flags) +{ + struct vxlan_dev *vxlan = netdev_priv(dev); + __be32 ip; + int err; +
drivers/net/Kconfig config MACVTAP
Quoted 10 lines
drivers/net/Kconfig +10
-0+ if (tb[NDA_DST] == NULL) + return -EINVAL; + + if (nla_len(tb[NDA_DST]) != sizeof(__be32)) + return -EAFNOSUPPORT; + + ip = nla_get_be32(tb[NDA_DST]); + + spin_lock_bh(&vxlan->hash_lock); + err = vxlan_fdb_create(vxlan, addr, ip, VXLAN_FDB_PERM);
Any reason to force permanent when created from userspace?
drivers/net/Kconfig
Quoted 9 lines
drivers/net/Kconfig +9
-0+static bool vxlan_group_used(struct vxlan_net *vn, + const struct vxlan_dev *this) +{ + const struct vxlan_dev *vxlan; + struct hlist_node *node; + unsigned h; + + for (h = 0; h < VNI_HASH_SIZE; ++h) + hlist_for_each_entry(vxlan, node, &vn->vni_list[h], hlist) {
is walking this chain only protected with rtnl?
Quoted 10 lines
drivers/net/Kconfig +10
-0+/* Propogate ECN from outer IP header to tunneled packet */ +static inline void vxlan_ecn_decap(const struct iphdr *iph, struct sk_buff *skb) +{ + if (INET_ECN_is_ce(iph->tos)) { + if (skb->protocol == htons(ETH_P_IP)) + IP_ECN_set_ce(ip_hdr(skb)); + else if (skb->protocol == htons(ETH_P_IPV6)) + IP6_ECN_set_ce(ipv6_hdr(skb)); + } +}
<snip>
drivers/net/Kconfig
Quoted 9 lines
drivers/net/Kconfig +9
-0+/* Propogate ECN bits out */ +static inline u8 vxlan_ecn_encap(u8 tos, + const struct iphdr *iph, + const struct sk_buff *skb) +{ + u8 inner = vxlan_get_dsfield(iph, skb); + + return INET_ECN_encapsulate(tos, inner); +}
Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't met, for example, should drop on decap when inner is not supporting ECN and outer has set CE.
<snip>
drivers/net/Kconfig
Quoted 3 lines
drivers/net/Kconfig +3
-0+/* Callback from net/ipv4/udp.c to receive packets */ + /* Mark socket as an encapsulation socket. */ + udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
I don't think we need this particular encap_type value, just != 0
Quoted 2 lines
drivers/net/Kconfig +2
-0+ udp_sk(sk)->encap_rcv = vxlan_udp_encap_recv; + udp_encap_enable();
Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
Quoted 47 lines · On Mon, 24 Sep 2012 13:58:22 -0700 Chris Wright <[email protected]> wrote:
Quoted 9 lines · * Stephen Hemminger ([email protected]) wrote:
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
I'm working on doing some interop
Quoted 8 lines
drivers/net/Kconfig +2
-0@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)"drivers/net/Kconfig config MACVTAP · line 163
Quoted 10 lines
drivers/net/Kconfig +10
-0+ depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called macvlan.^^^^^^^Cut 'n paste error, s/macvlan/vxlan/
Quoted 13 lines
drivers/net/Kconfig +13
-0+/* Add static entry (via netlink) */ +static int vxlan_fdb_add(struct ndmsg *ndm, struct nlattr *tb[], + struct net_device *dev, + const unsigned char *addr, u16 flags) +{ + struct vxlan_dev *vxlan = netdev_priv(dev); + __be32 ip; + int err; + + if (tb[NDA_DST] == NULL) + return -EINVAL; + + if (nla_len(tb[NDA_DST]) != sizeof(__be32))
Quoted 8 lines
drivers/net/Kconfig
Quoted 6 lines
drivers/net/Kconfig +6
-0+ return -EAFNOSUPPORT; + + ip = nla_get_be32(tb[NDA_DST]); + + spin_lock_bh(&vxlan->hash_lock); + err = vxlan_fdb_create(vxlan, addr, ip, VXLAN_FDB_PERM);Any reason to force permanent when created from userspace?
Should use neighbour flag (NUD_PERMANENT) instead.
Quoted 12 lines
drivers/net/Kconfig
Quoted 10 lines
drivers/net/Kconfig +9
-0+static bool vxlan_group_used(struct vxlan_net *vn, + const struct vxlan_dev *this) +{ + const struct vxlan_dev *vxlan; + struct hlist_node *node; + unsigned h; + + for (h = 0; h < VNI_HASH_SIZE; ++h) + hlist_for_each_entry(vxlan, node, &vn->vni_list[h], hlist) {is walking this chain only protected with rtnl?
Yes. that should be enough, only used when creating new vxlan to avoid joining same group twice.
Quoted 12 lines
Quoted 11 lines
drivers/net/Kconfig +10
-0+/* Propogate ECN from outer IP header to tunneled packet */ +static inline void vxlan_ecn_decap(const struct iphdr *iph, struct sk_buff *skb) +{ + if (INET_ECN_is_ce(iph->tos)) { + if (skb->protocol == htons(ETH_P_IP)) + IP_ECN_set_ce(ip_hdr(skb)); + else if (skb->protocol == htons(ETH_P_IPV6)) + IP6_ECN_set_ce(ipv6_hdr(skb)); + } +}<snip>
Quoted 13 lines
drivers/net/Kconfig
Quoted 9 lines
drivers/net/Kconfig +9
-0+/* Propogate ECN bits out */ +static inline u8 vxlan_ecn_encap(u8 tos, + const struct iphdr *iph, + const struct sk_buff *skb) +{ + u8 inner = vxlan_get_dsfield(iph, skb); + + return INET_ECN_encapsulate(tos, inner); +}Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't met, for example, should drop on decap when inner is not supporting ECN and outer has set CE.
The code was taken from existing GRE in Linux. Looks like both VXLAN and GRE need to handle that.
Quoted 7 lines
<snip>
drivers/net/Kconfig
Quoted 3 lines
drivers/net/Kconfig +3
-0+/* Callback from net/ipv4/udp.c to receive packets */ + /* Mark socket as an encapsulation socket. */ + udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;I don't think we need this particular
encap_typevalue, just != 0
Is there any value in defining new value?
Quoted 3 lines
Quoted 3 lines
drivers/net/Kconfig +2
-0+ udp_sk(sk)->encap_rcv = vxlan_udp_encap_recv; + udp_encap_enable();
Re: [PATCH net-next 3/3] vxlan: virtual extensible lan
Quoted 15 lines · * Stephen Hemminger ([email protected]) wrote:
Quoted 5 lines · Chris Wright
Quoted 5 lines
drivers/net/vxlan.c new file +5
-0+/* Propogate ECN bits out */ +static inline u8 vxlan_ecn_encap (u8 tos, +const struct iphdr *iph, +const struct sk_buff *skb) +{Quoted 8 lines
drivers/net/vxlan.c line 589
Quoted 4 lines
drivers/net/vxlan.c new file +4
-0+u8 inner =vxlan_get_dsfield (iph, skb); + +return INET_ECN_encapsulate (tos, inner); +}Goal is to be RFC 6040 compliant, and it looks like some edge cases aren't met, for example, should drop on decap when inner is not supporting ECN and outer has set CE.
Quoted 2 lines
The code was taken from existing GRE in Linux. Looks like both VXLAN and GRE need to handle that.
Right.
Quoted 7 lines
Quoted 5 lines
drivers/net/vxlan.c line 1111
Quoted 3 lines
drivers/net/vxlan.c new file +3
-0+/* Callback from net/ipv4/udp.c to receive packets */ +/* Mark socket as an encapsulation socket. */ +udp_sk (sk)->encap_type =UDP_ENCAP_L2TPINUDP ;I don't think we need this particular
encap_typevalue, just != 0Is there any value in defining new value?
No, more the propagation of L2TP constant starts to look like cargo cult programming. IOW, no special meaning in this context.
RFC 1/1 gre: conform to RFC6040 ECN progogation
Linux GRE was likely written before this RFC and therefore does not conform to one of the rules in Section 4.2. Default Tunnel Egress Behaviour.
The new code addresses:
o If the inner ECN field is Not-ECT, the decapsulator MUST NOT propagate any other ECN codepoint onwards. This is because the inner Not-ECT marking is set by transports that rely on dropped packets as an indication of congestion and would not understand or respond to any other ECN codepoint [RFC4774]. Specifically:
* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
* If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT.
This was caught by Chris Wright while reviewing VXLAN. This code has not been tested with real ECN through tunnel.
net/ipv4/ip_gre.c +10 -8
@@ -567,15 +567,16 @@ out:rcu_read_unlock (); } -static inline void ipgre_ecn_decapsulate (const struct iphdr *iph,struct sk_buff *skb) +static int ipgre_ecn_decapsulate (const struct iphdr *iph,struct sk_buff *skb) {if (INET_ECN_is_ce (iph->tos)) {if (skb->protocol ==htons (ETH_P_IP )) { -IP_ECN_set_ce (ip_hdr (skb)); +return IP_ECN_set_ce (ip_hdr (skb)); }else if (skb->protocol ==htons (ETH_P_IPV6 )) { -IP6_ECN_set_ce (ipv6_hdr (skb)); +return IP6_ECN_set_ce (ipv6_hdr (skb)); } } +return 1 ; } static inline u8
@@ -703,17 +704,18 @@ static int ipgre_rcv(struct sk_buff *skbskb_postpull_rcsum (skb,eth_hdr (skb),ETH_HLEN ); } +__skb_tunnel_rx (skb, tunnel->dev); + +skb_reset_network_header (skb); +if (!ipgre_ecn_decapsulate (iph, skb)) + goto drop; + tstats =this_cpu_ptr (tunnel->dev->tstats);u64_stats_update_begin (&tstats->syncp); tstats->rx_packets++; tstats->rx_bytes += skb->len;u64_stats_update_end (&tstats->syncp); -__skb_tunnel_rx (skb, tunnel->dev); - -skb_reset_network_header (skb); -ipgre_ecn_decapsulate (iph, skb); -netif_rx (skb);rcu_read_unlock ();
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 13 lines · Stephen Hemminger
Linux GRE was likely written before this RFC and therefore does not conform to one of the rules in Section 4.2. Default Tunnel Egress Behaviour.
The new code addresses:
o If the inner ECN field is Not-ECT, the decapsulator MUST NOT propagate any other ECN codepoint onwards. This is because the inner Not-ECT marking is set by transports that rely on dropped packets as an indication of congestion and would not understand or respond to any other ECN codepoint [RFC4774]. Specifically:* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
Quoted 8 lines
* If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT.
This was caught by Chris Wright while reviewing VXLAN. This code has not been tested with real ECN through tunnel.
Signed-off-by Stephen Hemminger <[email protected]>
It seems dangerous to me without any logging ?
One could argue that the outer ECN field should not be CE if the inner was Not-ECT
It means :
1) the encapsulator set ECT(0), or ECT(1) and a congestioned hop set CE
2) the encapsulator set CE
1) or 2) while inner was not-ECT (!!!)
If a router does such a thing, we should log a message to help diagnostics.
By the way other tunnels probably have the same issues.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 32 lines · On Tue, 25 Sep 2012 00:25:36 +0200 Eric Dumazet <[email protected]> wrote:
Quoted 13 lines · Stephen Hemminger
Linux GRE was likely written before this RFC and therefore does not conform to one of the rules in Section 4.2. Default Tunnel Egress Behaviour.
The new code addresses:
o If the inner ECN field is Not-ECT, the decapsulator MUST NOT propagate any other ECN codepoint onwards. This is because the inner Not-ECT marking is set by transports that rely on dropped packets as an indication of congestion and would not understand or respond to any other ECN codepoint [RFC4774]. Specifically:* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
Quoted 8 lines
* If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT.
This was caught by Chris Wright while reviewing VXLAN. This code has not been tested with real ECN through tunnel.
Signed-off-by Stephen Hemminger <[email protected]>It seems dangerous to me without any logging ?
One could argue that the outer ECN field should not be CE if the inner was Not-ECT
It means :
1) the encapsulator set ECT(0), or ECT(1) and a congestioned hop set CE
2) the encapsulator set CE
Quoted 6 lines
1) or 2) while inner was not-ECT (!!!)
If a router does such a thing, we should log a message to help diagnostics.
By the way other tunnels probably have the same issues.
Logging is a bad idea in this case since the tunnel might be from a remote host/protocol and the log would be filled with crap.
The tunnels in general do need to have rx_dropped counter, but it looks like that isn't being done right either.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 6 lines · Stephen Hemminger
Logging is a bad idea in this case since the tunnel might be from a remote host/protocol and the log would be filled with crap.
The tunnels in general do need to have
rx_droppedcounter, but it looks like that isn't being done right either.
I never suggested to log _all_ messages.
Stephen, I personally was hit by some provider playing with TOS bits so wrong I had to patch linux to fix a minor problem. [1]
I would like to know why my tunnels are going to fail, and what should I do to get a fallback. Ie reverting your patches.
RFC 6040 states :
In these cases,
particularly the more dangerous ones, the decapsulator SHOULD log the event and MAY also raise an alarm.
Just because the highlighted combinations are currently unused, does not mean that all the other combinations are always valid. Some are only valid if they have arrived from a particular type of legacy ingress, and dangerous otherwise. Therefore, an implementation MAY allow an operator to configure logging and alarms for such additional header combinations known to be dangerous or CU for the particular configuration of tunnel endpoints deployed at run-time.
Alarms SHOULD be rate-limited so that the anomalous combinations will not amplify into a flood of alarm messages. It MUST be possible to suppress alarms or logging, e.g., if it becomes apparent that a combination that previously was not used has started to be used for legitimate purposes such as a new standards action.
[1]
commit 7a269ffad72f3604b8982fa09c387670e0d2ee14
Author: Eric Dumazet <[email protected]> Date: Thu Sep 22 20:02:19 2011 +0000
tcp: ECN blackhole should not force quickack mode
While playing with a new ADSL box at home, I discovered that ECN blackhole can trigger suboptimal quickack mode on linux : We send one ACK for each incoming data frame, without any delay and eventual piggyback.
This is because TCP_ECN_check_ce() considers that if no ECT is seen on a segment, this is because this segment was a retransmit.
Refine this heuristic and apply it only if we seen ECT in a previous segment, to detect ECN blackhole at IP level.
Re: [RFC] gre: conform to RFC6040 ECN progogation
In reply to Stephen HemmingerOn Mon, 2012-09-24 at 14:44 -0700, Stephen Hemminger wrote:
[...]
Quoted 2 lines
net/ipv4/ip_gre.c +0
-0
[...]
Quoted 5 lines
net/ipv4/ip_gre.c +1
-0@@ -703,17 +704,18 @@ static int ipgre_rcv(struct sk_buff *skbskb_postpull_rcsum (skb,eth_hdr (skb),ETH_HLEN ); } +__skb_tunnel_rx (skb, tunnel->dev);
net/ipv4/ip_gre.c static int ipgre_rcv(struct sk_buff *skb · line 717
Quoted 10 lines
net/ipv4/ip_gre.c +5
-0+ +skb_reset_network_header (skb); +if (!ipgre_ecn_decapsulate (iph, skb)) + goto drop; + tstats =this_cpu_ptr (tunnel->dev->tstats);u64_stats_update_begin (&tstats->syncp); tstats->rx_packets++; tstats->rx_bytes += skb->len;u64_stats_update_end (&tstats->syncp);
I don't know why you're moving this code above the stats update; rx_packets/rx_bytes should include dropped packets.
Ben.
Quoted 8 lines
net/ipv4/ip_gre.c +0
-5-__skb_tunnel_rx (skb, tunnel->dev); - -skb_reset_network_header (skb); -ipgre_ecn_decapsulate (iph, skb); -netif_rx (skb);rcu_read_unlock ();
Signature · 3 lines
Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 26 lines · On Mon, 1 Oct 2012 16:55:19 +0100 Ben Hutchings <[email protected]>…
On Mon, 2012-09-24 at 14:44 -0700, Stephen Hemminger wrote:
[...]Quoted 2 lines
net/ipv4/ip_gre.c +0
-0[...]
Quoted 5 lines
net/ipv4/ip_gre.c +1
-0@@ -703,17 +704,18 @@ static int ipgre_rcv(struct sk_buff *skbskb_postpull_rcsum (skb,eth_hdr (skb),ETH_HLEN ); } +__skb_tunnel_rx (skb, tunnel->dev);net/ipv4/ip_gre.c static int ipgre_rcv(struct sk_buff *skb · line 717
Quoted 10 lines
net/ipv4/ip_gre.c +5
-0+ +skb_reset_network_header (skb); +if (!ipgre_ecn_decapsulate (iph, skb)) + goto drop; + tstats =this_cpu_ptr (tunnel->dev->tstats);u64_stats_update_begin (&tstats->syncp); tstats->rx_packets++; tstats->rx_bytes += skb->len;u64_stats_update_end (&tstats->syncp);I don't know why you're moving this code above the stats update; rx_packets/rx_bytes should include dropped packets.
Ben.
Quoted 9 lines
net/ipv4/ip_gre.c static int ipgre_rcv(struct sk_buff *skb · line 721
Quoted 8 lines
net/ipv4/ip_gre.c +0
-5-__skb_tunnel_rx (skb, tunnel->dev); - -skb_reset_network_header (skb); -ipgre_ecn_decapsulate (iph, skb); -netif_rx (skb);rcu_read_unlock ();
Is that true? I thought they were accounted for by rx_dropped.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 36 lines · Stephen Hemminger
Quoted 33 lines · On Mon, 1 Oct 2012 16:55:19 +0100 Ben Hutchings <[email protected]>…
On Mon, 2012-09-24 at 14:44 -0700, Stephen Hemminger wrote:
[...]Quoted 2 lines
net/ipv4/ip_gre.c +0
-0[...]
Quoted 5 lines
net/ipv4/ip_gre.c +1
-0@@ -703,17 +704,18 @@ static int ipgre_rcv(struct sk_buff *skbskb_postpull_rcsum (skb,eth_hdr (skb),ETH_HLEN ); } +__skb_tunnel_rx (skb, tunnel->dev);net/ipv4/ip_gre.c static int ipgre_rcv(struct sk_buff *skb · line 717
Quoted 10 lines
net/ipv4/ip_gre.c +5
-0+ +skb_reset_network_header (skb); +if (!ipgre_ecn_decapsulate (iph, skb)) + goto drop; + tstats =this_cpu_ptr (tunnel->dev->tstats);u64_stats_update_begin (&tstats->syncp); tstats->rx_packets++; tstats->rx_bytes += skb->len;u64_stats_update_end (&tstats->syncp);I don't know why you're moving this code above the stats update; rx_packets/rx_bytes should include dropped packets.
Ben.
Quoted 7 lines
net/ipv4/ip_gre.c +0
-5-__skb_tunnel_rx (skb, tunnel->dev); - -skb_reset_network_header (skb); -ipgre_ecn_decapsulate (iph, skb); -netif_rx (skb);
Quoted 4 lines
Quoted 2 lines
net/ipv4/ip_gre.c static int ipgre_rcv(struct sk_buff *skb · line 720
Quoted 1 line
net/ipv4/ip_gre.c +0
-0rcu_read_unlock ();Is that true? I thought they were accounted for by
rx_dropped.
I don't think rx_dropped is appropriate for counting invalid packets, but maybe actual practice is already different.
As for whether packets counted in rx_dropped should also be counted in rx_packets/rx_bytes, I really don't know. The current comments on rtnl_link_stats (inherited from net_device_stats) are totally inadequate as a specification.
Ben.
Signature · 3 lines
Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 7 lines · Ben Hutchings
I don't think
rx_droppedis appropriate for counting invalid packets, but maybe actual practice is already different.As for whether packets counted in
rx_droppedshould also be counted in rx_packets/rx_bytes, I really don't know. The current comments onrtnl_link_stats(inherited fromnet_device_stats) are totally inadequate as a specification.
rx_dropped is used by core network stack, not the devices themselves.
So a packet is first accounted in rx_bytes/rx_packets by the driver, and if net/core/dev.c drops it, rx_dropped is incremented as well.
Re: [RFC] gre: conform to RFC6040 ECN progogation
Quoted 10 lines · On Mon, 01 Oct 2012 19:13:47 +0200 Eric Dumazet <[email protected]> wrote:
Quoted 7 lines · Ben Hutchings
I don't think
rx_droppedis appropriate for counting invalid packets, but maybe actual practice is already different.As for whether packets counted in
rx_droppedshould also be counted in rx_packets/rx_bytes, I really don't know. The current comments onrtnl_link_stats(inherited fromnet_device_stats) are totally inadequate as a specification.
Quoted 4 lines
rx_droppedis used by core network stack, not the devices themselves.So a packet is first accounted in rx_bytes/rx_packets by the driver, and if
net/core/dev.cdrops it,rx_droppedis incremented as well.
The tunnel drivers are consistent in putting any dropped packet because of protocol problem into a rx_XXX_error value and incrementing rx_errors.
I just made it treat ECN bit breakage like all the other protocol errors.
PATCH v4 1/1 vxlan: virtual extensible lan
In reply to Chris WrightThis is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment. Still needs more testing of static entry manipulation.
---
v4 - fix ecn and set state of fdb entries
v3 - fix ordering of change versus migration message v2 - fix use of ip header after pskb_may_pull
Documentation/networking/vxlan.txt | 36 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1180 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 14 5 files changed, 1244 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called vxlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1182 -0
1,182 lines not on this page · raw message
include/linux/if_link.h +14 -0
@@ -272,6 +272,20 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +36 -0
@@ -0,0 +1,36 @@ +Virtual eXtensible Local Area Networking documentation +====================================================== + +The VXLAN protocol is a tunnelling protocol that is designed to +solve the problem of limited number of available VLAN's (4096). +With VXLAN identifier is expanded to 24 bits. + +It is a draft RFC standard, that is implemented by Cisco Nexus, +Vmware and Brocade. The protocol runs over UDP using a single +destination port (still not standardized by IANA). +This document describes the Linux kernel tunnel device, +there is also an implantation of VXLAN for Openvswitch. + +Unlike most tunnels, a VXLAN is a 1 to N network, not just point +to point. A VXLAN device can either dynamically learn the IP address +of the other end, in a manner similar to a learning bridge, or the +forwarding entries can be configured statically. + +The management of vxlan is done in a similar fashion to it's +too closest neighbors GRE and VLAN. Configuring VXLAN requires +the version of iproute2 that matches the kernel release +where VXLAN was first merged upstream. + +1. Create vxlan device + # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device (vxlan0). The device uses the +the multicast group 239.1.1.1 over eth1 to handle packets where +no entry is in the forwarding table. + +2. Delete vxlan device + # ip link delete vxlan0 + +3. Show vxlan info + # ip -d show vxlan0 +
Re: [PATCHv4 net-next] vxlan: virtual extensible lan
Quoted 1 line · Stephen Hemminger
+static
netdev_tx_tvxlan_xmit(struct sk_buff *skb, struct net_device *dev)
[...]
Quoted 9 lines
drivers/net/vxlan.c new file +9
-0+/* Do PMTU */ +if (skb->protocol ==htons (ETH_P_IP )) { + df |= old_iph->frag_off &htons (IP_DF ); +if (df && mtu < pkt_len) { +icmp_send (skb,ICMP_DEST_UNREACH ,ICMP_FRAG_NEEDED , +htonl (mtu)); +ip_rt_put (rt); + goto tx_error; + }
drivers/net/vxlan.c line 687
Quoted 10 lines
drivers/net/vxlan.c new file +10
-0+ } +#if IS_ENABLED (CONFIG_IPV6 ) + else if (skb->protocol == htons(ETH_P_IPV6)) { +if (mtu >=IPV6_MIN_MTU && mtu < pkt_len) { +icmpv6_send (skb,ICMPV6_PKT_TOOBIG ,0 , mtu); +ip_rt_put (rt); + goto tx_error; + } + } +#endif
Won't this black hole packets if we need to generate ICMP messages? Since we're doing switching and not routing here icmp_send() doesn't necessarily have a route to the relevant endpoint. It looks like Ethernet over GRE has this issue as well.
Re: [PATCHv4 net-next] vxlan: virtual extensible lan
Quoted 20 lines · On Tue, 25 Sep 2012 14:55:13 -0700 Jesse Gross <[email protected]> wrote:
Quoted 1 line · Stephen Hemminger
+static
netdev_tx_tvxlan_xmit(struct sk_buff *skb, struct net_device *dev)[...]
Quoted 16 lines
drivers/net/vxlan.c new file +16
-0+/* Do PMTU */ +if (skb->protocol ==htons (ETH_P_IP )) { + df |= old_iph->frag_off &htons (IP_DF ); +if (df && mtu < pkt_len) { +icmp_send (skb,ICMP_DEST_UNREACH ,ICMP_FRAG_NEEDED , +htonl (mtu)); +ip_rt_put (rt); + goto tx_error; + } + } +#if IS_ENABLED (CONFIG_IPV6 ) + else if (skb->protocol == htons(ETH_P_IPV6)) { +if (mtu >=IPV6_MIN_MTU && mtu < pkt_len) { +icmpv6_send (skb,ICMPV6_PKT_TOOBIG ,0 , mtu); +ip_rt_put (rt); + goto tx_error;
Quoted 8 lines
drivers/net/vxlan.c line 687
Quoted 3 lines
drivers/net/vxlan.c new file +3
-0+ } + } +#endif Won't this black hole packets if we need to generate ICMP messages? Since we're doing switching and not routing here
icmp_send()doesn't necessarily have a route to the relevant endpoint. It looks like Ethernet over GRE has this issue as well.
Good catch. The IP network space of the tunneled network will likely be completely separate from the overlay network.
PATCH v5 1/1 vxlan: virtual extensible lan
In reply to Jesse GrossThis is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has not been tested for Interoperation with other equipment.
---
v5 - drop MTU discovery since network is overlaid
use common code to do ECN decapsulation
v4 - fix ecn and set state of fdb entries
v3 - fix ordering of change versus migration message v2 - fix use of ip header after pskb_may_pull
Documentation/networking/vxlan.txt | 36 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1164 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 14 5 files changed, 1228 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called vxlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1164 -0
1,164 lines not on this page · raw message
include/linux/if_link.h +14 -0
@@ -272,6 +272,20 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +36 -0
@@ -0,0 +1,36 @@ +Virtual eXtensible Local Area Networking documentation +====================================================== + +The VXLAN protocol is a tunnelling protocol that is designed to +solve the problem of limited number of available VLAN's (4096). +With VXLAN identifier is expanded to 24 bits. + +It is a draft RFC standard, that is implemented by Cisco Nexus, +Vmware and Brocade. The protocol runs over UDP using a single +destination port (still not standardized by IANA). +This document describes the Linux kernel tunnel device, +there is also an implantation of VXLAN for Openvswitch. + +Unlike most tunnels, a VXLAN is a 1 to N network, not just point +to point. A VXLAN device can either dynamically learn the IP address +of the other end, in a manner similar to a learning bridge, or the +forwarding entries can be configured statically. + +The management of vxlan is done in a similar fashion to it's +too closest neighbors GRE and VLAN. Configuring VXLAN requires +the version of iproute2 that matches the kernel release +where VXLAN was first merged upstream. + +1. Create vxlan device + # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 + +This creates a new device (vxlan0). The device uses the +the multicast group 239.1.1.1 over eth1 to handle packets where +no entry is in the forwarding table. + +2. Delete vxlan device + # ip link delete vxlan0 + +3. Show vxlan info + # ip -d show vxlan0 +
David Miller
maintainerRe: [PATCHv5 net-next] vxlan: virtual extensible lan
From: Stephen Hemminger <[email protected]>
Date: Tue, 25 Sep 2012 15:09:57 -0700
Quoted 6 lines
drivers/net/vxlan.c new file +6
-0+/* Hash Ethernet address */ +static u32 eth_hash (const unsigned char *addr) +{ +/* could be optimized for unaligned access */ +u32 a = addr[5 ] <<8 | addr[4 ]; +u32 b = addr[3 ] <<24 | addr[2 ] <<16 | addr[1 ] <<8 | addr[0 ];
drivers/net/vxlan.c line 235
Quoted 10 lines
drivers/net/vxlan.c new file +10
-0+ +return jhash_2words (a, b, vxlan_salt); +} + +/* Hash chain to use given mac address */ +static inline struct hlist_head *vxlan_fdb_head (struct vxlan_dev *vxlan, +const u8 *mac) +{ +return &vxlan->fdb_head[hash_32 (eth_hash (mac),FDB_HASH_BITS )]; +}
This hashing is way overkill, and in fact is a mis-use of Jenkins.
Jenkins can work fine with power-of-two hash sizes, so using hash_32() on the Jenkins hash result is nothing short of silly.
I would go one step further and change this to:
(a ^ b) * vxlan_salt
much like how we hash IP addresses in the ipv4 ARP tables. That function is a universal hash, and therefore provides whatever kind of protection you're trying to obtain using the salt.
But I wonder if this matters at all, the administrator controls the contents of this table, rather than external entitites.
Re: [PATCHv5 net-next] vxlan: virtual extensible lan
Quoted 22 lines · On Thu, 27 Sep 2012 18:47:40 -0400 (EDT) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Tue, 25 Sep 2012 15:09:57 -0700Quoted 6 lines
drivers/net/vxlan.c new file +6
-0+/* Hash Ethernet address */ +static u32 eth_hash (const unsigned char *addr) +{ +/* could be optimized for unaligned access */ +u32 a = addr[5 ] <<8 | addr[4 ]; +u32 b = addr[3 ] <<24 | addr[2 ] <<16 | addr[1 ] <<8 | addr[0 ];drivers/net/vxlan.c line 235
Quoted 10 lines
drivers/net/vxlan.c new file +10
-0+ +return jhash_2words (a, b, vxlan_salt); +} + +/* Hash chain to use given mac address */ +static inline struct hlist_head *vxlan_fdb_head (struct vxlan_dev *vxlan, +const u8 *mac) +{ +return &vxlan->fdb_head[hash_32 (eth_hash (mac),FDB_HASH_BITS )]; +}This hashing is way overkill, and in fact is a mis-use of Jenkins.
Quoted 6 lines
Jenkins can work fine with power-of-two hash sizes, so using
hash_32()on the Jenkins hash result is nothing short of silly.I would go one step further and change this to:
(a ^ b) *
vxlan_salt
Ok, but doubt that it makes much difference.
Quoted 7 lines
much like how we hash IP addresses in the ipv4 ARP tables. That function is a universal hash, and therefore provides whatever kind of protection you're trying to obtain using the salt.
But I wonder if this matters at all, the administrator controls the contents of this table, rather than external entitites.
The table includes values learned from packets received. Like a bridge, a malicious attacker who can forge MAC sourc addresses can overload one chain by swamping the table with bogus values. Probably needs a table limit.
David Miller
maintainerRe: [PATCHv5 net-next] vxlan: virtual extensible lan
From: Stephen Hemminger <[email protected]>
Date: Thu, 27 Sep 2012 16:00:54 -0700
Quoted 9 lines
Quoted 2 lines · On Thu, 27 Sep 2012 18:47:40 -0400 (EDT) David Miller <[email protected]>…
But I wonder if this matters at all, the administrator controls the contents of this table, rather than external entitites.
The table includes values learned from packets received. Like a bridge, a malicious attacker who can forge MAC sourc addresses can overload one chain by swamping the table with bogus values. Probably needs a table limit.
Ok.
PATCH v6 1/1 vxlan: virtual extensible lan
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has only been tested with the user-mode TAP based version for Linux, not against other vendors (yet).
---
v6 - simplify hash function
allow configuring forwarding table limit and ageing timer account for VLAN in header
adjust mtu based on lower device (if any)
fix fields in fdb_show
v5 - drop MTU discovery since network is overlaid
use common code to do ECN decapsulation
v4 - fix ecn and set state of fdb entries
v3 - fix ordering of change versus migration message v2 - fix use of ip header after pskb_may_pull
Documentation/networking/vxlan.txt | 47 + drivers/net/Kconfig | 13 drivers/net/Makefile | 1 drivers/net/vxlan.c | 1217 +++++++++++++++++++++++++++++++++++++ include/linux/if_link.h | 16 5 files changed, 1294 insertions(+)
drivers/net/Kconfig +13 -0
@@ -149,6 +149,19 @@ config MACVTAP To compile this driver as a module, choose M here: the module will be called macvtap. +config VXLAN + tristate "Virtual eXtensible Local Area Network (VXLAN)" + depends on EXPERIMENTAL + ---help--- + This allows one to create vxlan virtual interfaces that provide + Layer 2 Networks over Layer 3 Networks. VXLAN is often used + to tunnel virtual network infrastructure in virtualized environments. + For more information see: + http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 + + To compile this driver as a module, choose M here: the module + will be called vxlan. + config NETCONSOLE tristate "Network console logging support" ---help---
drivers/net/Makefile +1 -0
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_TEAM) += team/ obj-$(CONFIG_TUN) += tun.o obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_VIRTIO_NET) += virtio_net.o +obj-$(CONFIG_VXLAN) += vxlan.o # # Networking Drivers
drivers/net/vxlan.c new file +1217 -0
1,217 lines not on this page · raw message
include/linux/if_link.h +16 -0
@@ -272,6 +272,22 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , +IFLA_VXLAN_AGEING , +IFLA_VXLAN_LIMIT , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
Documentation/networking/vxlan.txt new file +47 -0
47 lines not on this page · raw message
David Miller
maintainerRe: [PATCHv6 net-next] vxlan: virtual extensible lan
From: Stephen Hemminger <[email protected]>
Date: Mon, 1 Oct 2012 13:57:19 -0700
Quoted 11 lines
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has only been tested with the user-mode TAP based version for Linux, not against other vendors (yet).
Signed-off-by Stephen Hemminger <[email protected]>
It doesn't build.
And I'm not telling you what the build error is, you'll have to do an allmodconfig build yourself to see it.
I want you to get into the habit of doing an allmodconfig build to validate your changes because that's the very first thing I'm going to do.
Re: [PATCHv6 net-next] vxlan: virtual extensible lan
Quoted 15 lines · On Mon, 01 Oct 2012 18:07:12 -0400 (EDT) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Mon, 1 Oct 2012 13:57:19 -0700Quoted 11 lines
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has only been tested with the user-mode TAP based version for Linux, not against other vendors (yet).
Signed-off-by Stephen Hemminger <[email protected]>
Quoted 8 lines
It doesn't build.
And I'm not telling you what the build error is, you'll have to do an allmodconfig build yourself to see it.
I want you to get into the habit of doing an allmodconfig build to validate your changes because that's the very first thing I'm going to do.
Thanks, still waiting for build to finish.
Re: [PATCHv6 net-next] vxlan: virtual extensible lan
In reply to David MillerQuoted 15 lines · On Mon, 01 Oct 2012 18:07:12 -0400 (EDT) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Mon, 1 Oct 2012 13:57:19 -0700Quoted 11 lines
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has only been tested with the user-mode TAP based version for Linux, not against other vendors (yet).
Signed-off-by Stephen Hemminger <[email protected]>
Quoted 8 lines
It doesn't build.
And I'm not telling you what the build error is, you'll have to do an allmodconfig build yourself to see it.
I want you to get into the habit of doing an allmodconfig build to validate your changes because that's the very first thing I'm going to do.
Dave did you remember to include the two pre-cursor patches.
Vxlan was originally submitted as a 3 part series and only the last one ever changed.
[PATCH net-next 1/3] netlink: add attributes to fdb interface [PATCH net-next 2/3] igmp: export symbol ip_mc_leave_group
Make allmodconfig works for me (x86-64).
David Miller
maintainerRe: [PATCHv6 net-next] vxlan: virtual extensible lan
From: Stephen Hemminger <[email protected]>
Date: Mon, 1 Oct 2012 15:30:14 -0700
Quoted 29 lines
Quoted 15 lines · On Mon, 01 Oct 2012 18:07:12 -0400 (EDT) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Mon, 1 Oct 2012 13:57:19 -0700Quoted 11 lines
This is an implementation of Virtual eXtensible Local Area Network as described in draft RFC:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02The driver integrates a Virtual Tunnel Endpoint (VTEP) functionality that learns MAC to IP address mapping.
This implementation has only been tested with the user-mode TAP based version for Linux, not against other vendors (yet).
Signed-off-by Stephen Hemminger <[email protected]>Quoted 8 lines
It doesn't build.
And I'm not telling you what the build error is, you'll have to do an allmodconfig build yourself to see it.
I want you to get into the habit of doing an allmodconfig build to validate your changes because that's the very first thing I'm going to do.
Dave did you remember to include the two pre-cursor patches.
Quoted 7 lines
Vxlan was originally submitted as a 3 part series and only the last one ever changed.
[PATCH net-next 1/3] netlink: add attributes to fdb interface [PATCH net-next 2/3] igmp: export symbol
ip_mc_leave_groupMake allmodconfig works for me (x86-64).
You MUST always resubmit the entire series when you resubmit one patch.
Furthermore you confused the situation even more by not including the patch number information in your Subject line.
PATCH 1/2 iproute2: vxlan support
In reply to David MillerSupport managing vxlan tunnels
--- include/linux/if_link.h | 27 ++++++ ip/Makefile | 3 +- ip/iplink_vxlan.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 259 insertions(+), 1 deletion(-) create mode 100644 ip/iplink_vxlan.c
include/linux/if_link.h +27 -0
@@ -270,6 +270,22 @@ enum macvlan_mode {#define MACVLAN_FLAG_NOPROMISC 1 +/* VXLAN section */ +enum { +IFLA_VXLAN_UNSPEC , +IFLA_VXLAN_ID , +IFLA_VXLAN_GROUP , +IFLA_VXLAN_LINK , +IFLA_VXLAN_LOCAL , +IFLA_VXLAN_TTL , +IFLA_VXLAN_TOS , +IFLA_VXLAN_LEARNING , +IFLA_VXLAN_AGEING , +IFLA_VXLAN_LIMIT , + __IFLA_VXLAN_MAX +}; +#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) +/* SR-IOV virtual function management section */ enum {
@@ -384,4 +400,15 @@ struct ifla_port_vsi { __u8 pad[3]; }; + +/* IPoIB section */ + +enum { +IFLA_IPOIB_UNSPEC , +IFLA_IPOIB_PKEY , + __IFLA_IPOIB_MAX +}; + +#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1) +#endif /* _LINUX_IF_LINK_H */
ip/Makefile +2 -1
@@ -3,7 +3,8 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \ ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o \ ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \ iplink_vlan.o link_veth.o link_gre.o iplink_can.o \ - iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o + iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o \ + iplink_vxlan.o RTMONOBJ=rtmon.o
ip/iplink_vxlan.c new file +230 -0
230 lines not on this page · raw message
Signature · 1 line
1.7.10.4
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 2/2 iproute2: manage VXLAN forwarding entries
Allow extending bridge forwarding table to handle VXLAN as well. Change format of output to be close to 'ip neighbour'
--- bridge/br_common.h | 1 + bridge/bridge.c | 18 ++++++++ bridge/fdb.c | 129 +++++++++++++++++++++++++++++++--------------------- 3 files changed, 97 insertions(+), 51 deletions(-)
bridge/br_common.h +1 -0
@@ -7,6 +7,7 @@ extern int print_fdb(const struct sockaddr_nl *who,extern int do_fdb (int argc,char **argv);extern int do_monitor (int argc,char **argv); +extern int preferred_family;extern int show_stats;extern int show_detail;extern int timestamp;
bridge/bridge.c +18 -0
@@ -15,6 +15,7 @@#include "br_common.h" struct rtnl_handle rth = { .fd =-1 }; +int preferred_family =AF_UNSPEC ;int resolve_hosts;int show_stats;int show_details;
@@ -86,6 +87,23 @@ main(int argc, char **argv) ++show_details; }else if (matches (opt,"-timestamp" ) ==0 ) { ++timestamp; + }else if (matches (opt,"-family" ) ==0 ) { + argc--; + argv++; +if (argc <=1 ) +usage (); +if (strcmp (argv[1 ],"inet" ) ==0 ) + preferred_family =AF_INET ; +else if (strcmp (argv[1 ],"inet6" ) ==0 ) + preferred_family =AF_INET6 ; +else if (strcmp (argv[1 ],"help" ) ==0 ) +usage (); +else +invarg ("invalid protocol family" , argv[1 ]); + }else if (strcmp (opt,"-4" ) ==0 ) { + preferred_family =AF_INET ; + }else if (strcmp (opt,"-6" ) ==0 ) { + preferred_family =AF_INET6 ; }else {fprintf (stderr,"Option \"%s\" is unknown, try \"bridge help\".\n" , opt);exit (-1 );
bridge/fdb.c +78 -51
232 lines not on this page · raw message
Signature · 1 line
1.7.10.4
Re: [PATCHv4 net-next] vxlan: virtual extensible lan
In reply to Jesse GrossQuoted 20 lines · On Tue, 25 Sep 2012 14:55:13 -0700 Jesse Gross <[email protected]> wrote:
Quoted 1 line · Stephen Hemminger
+static
netdev_tx_tvxlan_xmit(struct sk_buff *skb, struct net_device *dev)[...]
Quoted 16 lines
drivers/net/vxlan.c new file +16
-0+/* Do PMTU */ +if (skb->protocol ==htons (ETH_P_IP )) { + df |= old_iph->frag_off &htons (IP_DF ); +if (df && mtu < pkt_len) { +icmp_send (skb,ICMP_DEST_UNREACH ,ICMP_FRAG_NEEDED , +htonl (mtu)); +ip_rt_put (rt); + goto tx_error; + } + } +#if IS_ENABLED (CONFIG_IPV6 ) + else if (skb->protocol == htons(ETH_P_IPV6)) { +if (mtu >=IPV6_MIN_MTU && mtu < pkt_len) { +icmpv6_send (skb,ICMPV6_PKT_TOOBIG ,0 , mtu); +ip_rt_put (rt); + goto tx_error;
Quoted 8 lines
drivers/net/vxlan.c line 687
Quoted 3 lines
drivers/net/vxlan.c new file +3
-0+ } + } +#endif Won't this black hole packets if we need to generate ICMP messages? Since we're doing switching and not routing here
icmp_send()doesn't necessarily have a route to the relevant endpoint. It looks like Ethernet over GRE has this issue as well.
It is an interesting question about what is the correct way to handle packets where the inner header is IPv6 or IPv4 with Don't Fragment set. As you mention sending an ICMP response won't work because the tunnel endpoint is not part of that IP network.
The simple option is to fragment it in the tunnel and since the fragmentation is not visible to the overlay network, that is okay. But for PMTU discovery it might be better to just drop the packet and not send a fragmented payload.
Some backbone networks don't allow fragmentation at all (in a futile attempt to block DoS attacks and protect fragile Windows hosts). Fragmentation brings all sorts of evil problems like the potential of corrupted assembly because of sequence wrap; the checksum in the inner packet will defend against that but tunnels are not supposed to rely on inner protocol data protection.
Or you can just do what Cisco and Microsoft do and just tell everyone to set larger MTU on the backbone.
Re: [PATCHv4 net-next] vxlan: virtual extensible lan
Quoted 41 lines · Stephen Hemminger
Quoted 20 lines · On Tue, 25 Sep 2012 14:55:13 -0700 Jesse Gross <[email protected]> wrote:
Quoted 1 line · Stephen Hemminger
+static
netdev_tx_tvxlan_xmit(struct sk_buff *skb, struct net_device *dev)[...]
Quoted 16 lines
drivers/net/vxlan.c new file +16
-0+/* Do PMTU */ +if (skb->protocol ==htons (ETH_P_IP )) { + df |= old_iph->frag_off &htons (IP_DF ); +if (df && mtu < pkt_len) { +icmp_send (skb,ICMP_DEST_UNREACH ,ICMP_FRAG_NEEDED , +htonl (mtu)); +ip_rt_put (rt); + goto tx_error; + } + } +#if IS_ENABLED (CONFIG_IPV6 ) + else if (skb->protocol == htons(ETH_P_IPV6)) { +if (mtu >=IPV6_MIN_MTU && mtu < pkt_len) { +icmpv6_send (skb,ICMPV6_PKT_TOOBIG ,0 , mtu); +ip_rt_put (rt); + goto tx_error;Quoted 8 lines
drivers/net/vxlan.c line 687
Quoted 3 lines
drivers/net/vxlan.c new file +3
-0+ } + } +#endif Won't this black hole packets if we need to generate ICMP messages? Since we're doing switching and not routing here
icmp_send()doesn't necessarily have a route to the relevant endpoint. It looks like Ethernet over GRE has this issue as well.It is an interesting question about what is the correct way to handle packets where the inner header is IPv6 or IPv4 with Don't Fragment set. As you mention sending an ICMP response won't work because the tunnel endpoint is not part of that IP network.
The simple option is to fragment it in the tunnel and since the fragmentation is not visible to the overlay network, that is okay. But for PMTU discovery it might be better to just drop the packet and not send a fragmented payload.
Quoted 8 lines
Some backbone networks don't allow fragmentation at all (in a futile attempt to block DoS attacks and protect fragile Windows hosts). Fragmentation brings all sorts of evil problems like the potential of corrupted assembly because of sequence wrap; the checksum in the inner packet will defend against that but tunnels are not supposed to rely on inner protocol data protection.
Or you can just do what Cisco and Microsoft do and just tell everyone to set larger MTU on the backbone.
What I think people usually do in these situations are:
1. Insist people set the MTU to take into account the tunnel.
2. Use MSS clamping for TCP traffic.
3. Either drop or fragment the tunnel packet. In theory some IP
stacks will probe for a lower MTU if packets are dropping, in practice things seem to just break. If the backbone is going to drop fragmented packets then I guess it doesn't make a difference, modulo the potential for corruption that you mentioned. Always dropping seems worse (although it is the behavior of many hardware devices that can't do fragmentation at all).
So I think what you have currently is correct.
A couple of other options:
* In many cases it might be desirable to do fragmentation on the
inner rather than outer packet, especially if there are middleboxes looking inside the tunnel. This assumes that the inner packet is IP and doesn't have the DF bit set. In theory, you could do it even if the DF bit is set since we can't do path MTU discovery anyways.
* A few years ago I wrote an implementation of path MTU discovery in
OVS to handle this situation. It's pretty effective but it relies on guessing/faking some addresses. I think we're going to pull it out soon in favor of MSS clamping soon though.
I wouldn't implement either of these here, at least at this time though.