all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Stoyan Marinov <stoyan@marinov.us>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] BUG in vlan aware bridge
Date: Wed, 13 Oct 2021 01:45:48 +0300	[thread overview]
Message-ID: <1FAB115F-FD40-41E1-AC81-A781DA29B378@marinov.us> (raw)
In-Reply-To: <4F0DFA30-F1ED-4322-857A-4F4C24B463FE@marinov.us>

OK, I have just verified it has nothing to do with bonds. I get the same behavior with vlan aware bridge, bridge-nf-call-iptables=1 with regular eth0 being part of the bridge. Packets arrive fragmented on tap, reassembled by netfilter and then re-injected in bridge assembled (full size).

I did have limited success by setting net.bridge.bridge-nf-filter-vlan-tagged to 1. Now packets seem to get fragmented on the way out and back in, but there are still issues:

1. I'm testing with ping -s 2000 (1500 mtu everywhere) to an external box. I do see reply packets arrive on the vm nic, but ping doesn't see them. Haven't analyzed much further.
2. While watching with tcpdump (inside the vm) i notice "ip reassembly time exceeded" messages being generated from the vm.

I'll try to investigate a bit further tomorrow.

> On 12 Oct 2021, at 11:26 PM, Stoyan Marinov <stoyan@marinov.us> wrote:
> 
> That's an interesting observation. Now that I think about it, it could be caused by bonding and not the underlying device. When I tested this (about an year ago) I was using bonding on the mlx adapters and not using bonding on intel ones.
> 
>> On 12 Oct 2021, at 3:36 PM, VELARTIS Philipp Dürhammer <p.duerhammer@velartis.at> wrote:
>> 
>> HI,
>> 
>> we use HP Server with Intel Cards or the standard hp nic ( ithink also intel)
>> 
>> Also I see the I did a mistake:
>> 
>> Setup working:
>> tapX (UNtagged) <- -> vmbr0 <- - > bond0
>> 
>> is correct. (before I had also tagged) 
>> 
>> it should be :
>> 
>> Setup not working:
>> tapX (tagged) <- -> vmbr0 <- - > bond0
>> 
>> Setup working:
>> tapX (untagged) <- -> vmbr0 <- - > bond0
>> 
>> Setup also working:
>> tapX < - - > vmbr0v350 < -- > bond0.350 < -- > bond0
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: pve-devel <pve-devel-bounces@lists.proxmox.com> Im Auftrag von Stoyan Marinov
>> Gesendet: Dienstag, 12. Oktober 2021 13:16
>> An: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
>> Betreff: Re: [pve-devel] BUG in vlan aware bridge
>> 
>> I'm having the very same issue with Mellanox ethernet adapters. I don't see this behavior with Intel nics. What network cards do you have?
>> 
>>> On 12 Oct 2021, at 1:48 PM, VELARTIS Philipp Dürhammer <p.duerhammer@velartis.at> wrote:
>>> 
>>> HI,
>>> 
>>> i am playing around since days because we have strange packet losses.
>>> Finally I can report following (Linux 5.11.22-4-pve, Proxmox 7, all devices MTU 1500):
>>> 
>>> Packet with sizes > 1500 without VLAN working well but at the moment they are Tagged they are dropped by the bond device.
>>> Netfilter (set to 1) always reassembles the packets when they arrive a bridge. But they don't get fragmented again I they are VLAN tagged. So the bond device drops them. If the bridge is NOT Vlan aware they also get fragmented and it works well.
>>> 
>>> Setup not working:
>>> 
>>> tapX (tagged) <- -> vmbr0 <- - > bond0
>>> 
>>> Setup working:
>>> 
>>> tapX (tagged) <- -> vmbr0 <- - > bond0
>>> 
>>> Setup also working:
>>> 
>>> tapX < - - > vmbr0v350 < -- > bond0.350 < -- > bond0
>>> 
>>> Have you got any idea where to search? I don't understand who is in charge of fragmenting packages again if they get reassembled by netfilter. (and why it is not working with vlan aware bridges)
>>> 
>>> 
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel@lists.proxmox.com
>>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>> 
>> 
>> 
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel




  reply	other threads:[~2021-10-12 22:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12 10:48 VELARTIS Philipp Dürhammer
2021-10-12 11:16 ` Stoyan Marinov
2021-10-12 12:36   ` VELARTIS Philipp Dürhammer
2021-10-12 20:26     ` Stoyan Marinov
2021-10-12 22:45       ` Stoyan Marinov [this message]
2021-10-12 23:03         ` Stoyan Marinov
2021-10-13  9:22         ` VELARTIS Philipp Dürhammer
2021-10-13 11:36           ` Josef Johansson
2021-10-13 13:47             ` VELARTIS Philipp Dürhammer
2021-10-13 13:53               ` Josef Johansson
2021-10-13 13:53             ` VELARTIS Philipp Dürhammer
2021-10-13 14:19               ` Josef Johansson
2021-10-13 14:32                 ` VELARTIS Philipp Dürhammer
2021-10-14  5:14                   ` Josef Johansson
2021-10-14  5:40                     ` Josef Johansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1FAB115F-FD40-41E1-AC81-A781DA29B378@marinov.us \
    --to=stoyan@marinov.us \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal