From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: Sending undersized ARP packets with VXLAN L3 interface Date: Wed, 27 Aug 2014 16:23:56 -0400 Message-ID: <53FE3E5C.8020804@gmail.com> References: <53FE1AC3.5030409@gmail.com> <20140827114209.3a9d3761@urahara> <53FE2738.30702@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , Cong Wang , netdev To: Martin Rusko Return-path: Received: from mail-qc0-f174.google.com ([209.85.216.174]:37885 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935598AbaH0UYF (ORCPT ); Wed, 27 Aug 2014 16:24:05 -0400 Received: by mail-qc0-f174.google.com with SMTP id l6so918751qcy.19 for ; Wed, 27 Aug 2014 13:24:00 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 08/27/2014 04:01 PM, Martin Rusko wrote: > On Wed, Aug 27, 2014 at 8:45 PM, Vlad Yasevich wrote: >> On 08/27/2014 02:42 PM, Stephen Hemminger wrote: >>> On Wed, 27 Aug 2014 13:52:03 -0400 >>> Vlad Yasevich wrote: >>> >>>> On 08/27/2014 01:28 PM, Cong Wang wrote: >>>>> On Wed, Aug 27, 2014 at 10:06 AM, Martin Rusko wrote: >>>>>> >>>>>> I'm wondering, where is the proper place to fix this. Should >>>>>> arp_create() function allocate skb big enough to produce ethernet >>>>>> frame with at least minimum size? Or is it somewhere in NIC drivers >>>>>> where small packets are padded with zeros? >>>>> >>>>> Drivers do that, for example e1000: >>>>> >>>>> /* On PCI/PCI-X HW, if packet size is less than ETH_ZLEN, >>>>> * packets may get corrupted during padding by HW. >>>>> * To WA this issue, pad all small packets manually. >>>>> */ >>>>> if (skb->len < ETH_ZLEN) { >>>>> if (skb_pad(skb, ETH_ZLEN - skb->len)) >>>>> return NETDEV_TX_OK; >>>>> skb->len = ETH_ZLEN; >>>>> skb_set_tail_pointer(skb, ETH_ZLEN); >>>>> } >>>> >>>> >>>> I think vxlan needs something like this: >>>> >>>> From: Vladislav Yasevich >>>> Date: Wed, 27 Aug 2014 13:39:32 -0400 >>>> Subject: [PATCH] vxlan: Pad short ethernet frames. >>>> >>>> If sending short ethernet frames from the vxlan device, pad >>>> them to minimum size so they can be forwarded after decapsulation. >>>> >>>> Reported-by: Martin Rusko >>>> Signed-off-by: Vladislav Yasevich >>>> --- >>>> drivers/net/vxlan.c | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c >>>> index 1fb7b37..48267d4 100644 >>>> --- a/drivers/net/vxlan.c >>>> +++ b/drivers/net/vxlan.c >>>> @@ -1939,6 +1939,14 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct >>>> net_device *dev) >>>> #endif >>>> } >>>> >>>> + /* Pad short frames so they can be forwarded after decapsulation */ >>>> + if (skb->len < ETH_ZLEN) { >>>> + if (skb_pad(skb, ETH_ZLEN - skb->len)) >>>> + return NETDEV_TX_OK; >>>> + skb->len = ETH_ZLEN; >>>> + skb_set_tail_pointer(skb, ETH_ZLEN); >>>> + } >>>> + >>>> f = vxlan_find_mac(vxlan, eth->h_dest); >>>> did_rsc = false; >>>> >>> >>> No. The short frame is perfectly valid, over the VXLAN. >>> The system doing the decap and forwarding should be where any padding is added if necessary. >>> > > Well, RFC 7348 is not dealing with padding at all. Both deployment > scenarios listed in RFC, as well as most of the existing real life > deployments today (in my opinion) use VXLAN for bridged traffic. In > other words, frame encapsulated by VTEP is received first over some > ethernet interface (physical or virtual) which implies that the frame > is at least 64 bytes long already. > > Perhaps we're going to see more VXLAN interfaces in L3 mode, yet it > might be safer not to count on receiving VTEP doing the right thing > (pad small packets with zeros). > >> >> If that's the case, then Martin is most likely seeing a HW bug on the switch. >> I wonder how common such a bug might be? >> >> -vlad >> > > I see this on Vmware distributed virtual switch. Perhaps soon I will > be able to test it against HP 5930 switch. I'm going to try how Linux > bridge copes with it, now. Linux bridge will do just fine as it will pass the frame off to the hw driver which should pad things appropriately. -vlad > > Many thanks for the patch anyway! > > Regards, > Martin >