[Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[gilberto dos santos alves]

[-- Attachment #1: Type: text/plain, Size: 8520 bytes --]

Hi, imho is more stable using ubuntu 14.04 LTS, yes we need see dmesg,
syslog, network messages, you could put your txt files on pastebin.com and
especify url for us. if necessary we access these files. keep special
attention to syslog or network messages, and show how you start your qemu,
what windows, service pack etc you choose, ipv4 or ipv6. lets see first
infra-structure, networks, tap, bridge, memory, disk, hardware setup.

yes we can.




2016-02-02 2:48 GMT-02:00 <bridge-request@lists.linux-foundation.org>:

> Send Bridge mailing list submissions to
>         bridge@lists.linux-foundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bridge
> or, via email, send a message with subject or body 'help' to
>         bridge-request@lists.linux-foundation.org
>
> You can reach the person managing the list at
>         bridge-owner@lists.linux-foundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bridge digest..."
>
> Today's Topics:
>
>    1. Help with Ubuntu + bridge + tap + qemu + Windows (David Logan)
>    2. Re: Help with Ubuntu + bridge + tap + qemu + Windows (David Logan)
>    3. [PATCH RESEND] bridge:Fix concurrent access issue in the
>       function brnf_get_logical_dev (Nicholas Krause)
>    4. Re: Help with Ubuntu + bridge + tap + qemu + Windows
>       (Stephen Hemminger)
>    5. Re: Help with Ubuntu + bridge + tap + qemu + Windows (David Logan)
>
>
> ---------- Mensagem encaminhada ----------
> From: David Logan <djlogan2.dl@gmail.com>
> To: bridge@lists.linux-foundation.org
> Cc:
> Date: Mon, 1 Feb 2016 12:51:20 -0700
> Subject: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows
> Hi guys
>
> I have been researching this problem for weeks, and I have tried
> everything every web page has even remotely suggested, and nothing works. I
> am at my wits end, and I simply *must* get my issue resolved.
>
> Basically, when I bring up one or more VMs using tap# on a br# on an eth#,
> the network interface will work for a random amount of time, but inevitably
> something will die, and the “TX packets” stops incrementing, and the “TX
> packets dropped” takes over. At that point, I can shut down and start up my
> VM, and go through the cycle again with a different random time and packets
> transmitted.
>
> tap2      Link encap:Ethernet  HWaddr 8a:21:a8:cb:f5:98
>           inet6 addr: fe80::8821:a8ff:fecb:f598/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:51870 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:741595 errors:0 dropped:5702 overruns:0 carrier:0
>           collisions:0 txqueuelen:500
>           RX bytes:3220139 (3.2 MB)  TX bytes:1113177111 (1.1 GB)
>
> I could obviously post every shred of information I have, ethtool,
> iptables, netstat, brctl, etc. but I hate to create a 10K email with mostly
> unnecessary outputs. If anyone has a specific set of questions they need
> answered, I am more than happy to provide. I’m running the latest Ubuntu
> and get updates daily. The uname -a as of this morning is:
>
> Darwin Carolyns-MacBook-Air.local 15.3.0 Darwin Kernel Version 15.3.0: Thu
> Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
>
> What in the world am I doing wrong, or where is this failing, how do I
> find it, and most importantly, how do I fix it? :)
>
> Thank you,
> David Logan
>
>
>
> ---------- Mensagem encaminhada ----------
> From: David Logan <djlogan2.dl@gmail.com>
> To: bridge@lists.linux-foundation.org
> Cc:
> Date: Mon, 1 Feb 2016 13:04:48 -0700
> Subject: Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows
> oops. Wrong machine. The uname -a really is
>
> Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> David Logan
>
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Nicholas Krause <xerofoify@gmail.com>
> To: pablo@netfilter.org
> Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
> linux-kernel@vger.kernel.org, kaber@trash.net, coreteam@netfilter.org,
> netfilter-devel@vger.kernel.org, kadlec@blackhole.kfki.hu,
> davem@davemloft.net
> Date: Mon, 1 Feb 2016 22:19:33 -0500
> Subject: [Bridge] [PATCH RESEND] bridge:Fix concurrent access issue in the
> function brnf_get_logical_dev
> This fixes a concurrent access issue in the function brnf_get_logical_dev
> by properly locking with the function rcu_read_lock before calling the
> function vlan_find_dev_deep_rcu and unlocking after this function call
> as all callers of this function are required to do this in order to
> improve issues with concurrent access by other threads executing
> on this data structures simultaneously.
>
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
>  net/bridge/br_netfilter_hooks.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/br_netfilter_hooks.c
> b/net/bridge/br_netfilter_hooks.c
> index c8b9bcf..73c84a8 100644
> --- a/net/bridge/br_netfilter_hooks.c
> +++ b/net/bridge/br_netfilter_hooks.c
> @@ -428,9 +428,10 @@ static struct net_device *brnf_get_logical_dev(struct
> sk_buff *skb, const struct
>         if (brnf_pass_vlan_indev == 0 || !skb_vlan_tag_present(skb))
>                 return br;
>
> +       rcu_read_lock();
>         vlan = __vlan_find_dev_deep_rcu(br, skb->vlan_proto,
>                                     skb_vlan_tag_get(skb) & VLAN_VID_MASK);
> -
> +       rcu_read_unlock();
>         return vlan ? vlan : br;
>  }
>
> --
> 2.1.4
>
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Stephen Hemminger <stephen@networkplumber.org>
> To: David Logan <djlogan2.dl@gmail.com>
> Cc: bridge@lists.linux-foundation.org
> Date: Tue, 2 Feb 2016 14:27:08 +1100
> Subject: Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows
> On Mon, 1 Feb 2016 13:04:48 -0700
> David Logan <djlogan2.dl@gmail.com> wrote:
>
> > oops. Wrong machine. The uname -a really is
> >
> > Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18
> 15:41:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> >
> > David Logan
> >
> >
>
> I suspect you have a loop and STP is detecting that the STP packets being
> sent
> out one of the ports on the bridge are showing back up on another port on
> the bridge.
>
> The way bridging works you need to make each port on the bridge is a
> separate L2 domain;
> otherwise you create a loop.
>
>
>
> ---------- Mensagem encaminhada ----------
> From: David Logan <djlogan2.dl@gmail.com>
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: bridge@lists.linux-foundation.org
> Date: Mon, 1 Feb 2016 21:48:51 -0700
> Subject: Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows
> That was a bit above my head. Can you elaborate or point me towards a web
> site that explains the terminology? Sorry, I’m reasonable at networking, I
> know what levels are, I have an idea of what the various fields and stuff
> are, but I am no means an expert :)
>
> Also: While I have STP enabled at the moment as the recommendation of one
> web site, most of the time STP has been disabled in the bridge. I can turn
> it off and/or reboot and replicate the problem in minutes. Does that alter
> your suggestion?
>
> David Logan
>
>
> On Feb 1, 2016, at 8:27 PM, Stephen Hemminger <stephen@networkplumber.org>
> wrote:
>
> On Mon, 1 Feb 2016 13:04:48 -0700
> David Logan <djlogan2.dl@gmail.com> wrote:
>
> oops. Wrong machine. The uname -a really is
>
> Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> David Logan
>
>
>
> I suspect you have a loop and STP is detecting that the STP packets being
> sent
> out one of the ports on the bridge are showing back up on another port on
> the bridge.
>
> The way bridging works you need to make each port on the bridge is a
> separate L2 domain;
> otherwise you create a loop.
>
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

[-- Attachment #2: Type: text/html, Size: 13105 bytes --]

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[Stephen Hemminger]

Read Wikipedia on Spanning Tree to see how it detects bridging loops.
Look at dmesg to see when bridge STP disables a port when it detects loop

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[David Logan]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Hi guys
Thanks you all very much for you willingness to help. I had been struggling with this problem for weeks! It seems as though it really wasn’t a bridge problem as Srinivas pointed out. I was careful to reinstall the virtio drivers from the appropriate web site, and all of my VMs have been up all day long.

My main problem (aside from my overall lack of network knowledge) was simply not realizing that the bridge transmit queue meant transmitting from the tap interface to the virtio driver. I thought it was simply reflecting the numbers of the guest (meaning I thought the transmit count meant the number of packets transmitted from the virtio driver, and subsequently transmitted from the tap interface to the bridge.)

My humble apologies for making the network experts spend time on a very simple issue, but thank you all so much for your help. I was all but disabled due to this problem.

David Logan
http://www.linkedin.com/in/davidjlogan
303-818-8222


> On Feb 2, 2016, at 5:51 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> Read Wikipedia on Spanning Tree to see how it detects bridging loops.
> Look at dmesg to see when bridge STP disables a port when it detects loop


[-- Attachment #2: Type: text/html, Size: 2504 bytes --]

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[David Logan]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

No, not  yet, because I had no idea exactly who was responsible for what. I am using the virtio drivers and qemu. Let me look into that and see if I can find somebody to ask about it. That’s way more information that I had. I thought the “tx packets” were packets being transmitted from the vm to the bridge, not the other way around.

David Logan
http://www.linkedin.com/in/davidjlogan
303-818-8222


> On Feb 1, 2016, at 10:34 PM, Srinivas M.A. <srinivas.aji@gmail.com> wrote:
> 
> On Tue, Feb 2, 2016 at 1:21 AM, David Logan <djlogan2.dl@gmail.com> wrote:
>> 
>> tap2      Link encap:Ethernet  HWaddr 8a:21:a8:cb:f5:98
>>          inet6 addr: fe80::8821:a8ff:fecb:f598/64 Scope:Link
>>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>          RX packets:51870 errors:0 dropped:0 overruns:0 frame:0
>>          TX packets:741595 errors:0 dropped:5702 overruns:0 carrier:0
>>          collisions:0 txqueuelen:500
>>          RX bytes:3220139 (3.2 MB)  TX bytes:1113177111 (1.1 GB)
> 
> You are seeing TX packets dropped at the tap interface. So these are
> packets that are being sent from the bridge to the VM on the tap
> device, but getting dropped, probably because the tap device's queue
> is full. This would mean that the packets are not getting read by the
> VM fast enough, or may be not read at all after some point, since you
> see only the dropped increase after a while. So the issue is likely to
> be related to the virtualization software, rather than the bridge.
> Have you tried asking about this on forums related to the
> virtualization system you are using?


[-- Attachment #2: Type: text/html, Size: 3365 bytes --]

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[Srinivas M.A.]

On Tue, Feb 2, 2016 at 1:21 AM, David Logan <djlogan2.dl@gmail.com> wrote:
>
> tap2      Link encap:Ethernet  HWaddr 8a:21:a8:cb:f5:98
>           inet6 addr: fe80::8821:a8ff:fecb:f598/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:51870 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:741595 errors:0 dropped:5702 overruns:0 carrier:0
>           collisions:0 txqueuelen:500
>           RX bytes:3220139 (3.2 MB)  TX bytes:1113177111 (1.1 GB)

You are seeing TX packets dropped at the tap interface. So these are
packets that are being sent from the bridge to the VM on the tap
device, but getting dropped, probably because the tap device's queue
is full. This would mean that the packets are not getting read by the
VM fast enough, or may be not read at all after some point, since you
see only the dropped increase after a while. So the issue is likely to
be related to the virtualization software, rather than the bridge.
Have you tried asking about this on forums related to the
virtualization system you are using?

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[David Logan]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

That was a bit above my head. Can you elaborate or point me towards a web site that explains the terminology? Sorry, I’m reasonable at networking, I know what levels are, I have an idea of what the various fields and stuff are, but I am no means an expert :)

Also: While I have STP enabled at the moment as the recommendation of one web site, most of the time STP has been disabled in the bridge. I can turn it off and/or reboot and replicate the problem in minutes. Does that alter your suggestion?

David Logan


> On Feb 1, 2016, at 8:27 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> On Mon, 1 Feb 2016 13:04:48 -0700
> David Logan <djlogan2.dl@gmail.com> wrote:
> 
>> oops. Wrong machine. The uname -a really is
>> 
>> Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> David Logan
>> 
>> 
> 
> I suspect you have a loop and STP is detecting that the STP packets being sent
> out one of the ports on the bridge are showing back up on another port on the bridge.
> 
> The way bridging works you need to make each port on the bridge is a separate L2 domain;
> otherwise you create a loop.


[-- Attachment #2: Type: text/html, Size: 2561 bytes --]

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[Stephen Hemminger]

On Mon, 1 Feb 2016 13:04:48 -0700
David Logan <djlogan2.dl@gmail.com> wrote:

> oops. Wrong machine. The uname -a really is
> 
> Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> David Logan
> 
> 

I suspect you have a loop and STP is detecting that the STP packets being sent
out one of the ports on the bridge are showing back up on another port on the bridge.

The way bridging works you need to make each port on the bridge is a separate L2 domain;
otherwise you create a loop.

Re: [Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[David Logan]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

oops. Wrong machine. The uname -a really is

Linux server2 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

David Logan



[-- Attachment #2: Type: text/html, Size: 823 bytes --]

[Bridge] Help with Ubuntu + bridge + tap + qemu + Windows

[David Logan]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Hi guys

I have been researching this problem for weeks, and I have tried everything every web page has even remotely suggested, and nothing works. I am at my wits end, and I simply *must* get my issue resolved.

Basically, when I bring up one or more VMs using tap# on a br# on an eth#, the network interface will work for a random amount of time, but inevitably something will die, and the “TX packets” stops incrementing, and the “TX packets dropped” takes over. At that point, I can shut down and start up my VM, and go through the cycle again with a different random time and packets transmitted.

tap2      Link encap:Ethernet  HWaddr 8a:21:a8:cb:f5:98  
          inet6 addr: fe80::8821:a8ff:fecb:f598/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:51870 errors:0 dropped:0 overruns:0 frame:0
          TX packets:741595 errors:0 dropped:5702 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:3220139 (3.2 MB)  TX bytes:1113177111 (1.1 GB)

I could obviously post every shred of information I have, ethtool, iptables, netstat, brctl, etc. but I hate to create a 10K email with mostly unnecessary outputs. If anyone has a specific set of questions they need answered, I am more than happy to provide. I’m running the latest Ubuntu and get updates daily. The uname -a as of this morning is:

Darwin Carolyns-MacBook-Air.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

What in the world am I doing wrong, or where is this failing, how do I find it, and most importantly, how do I fix it? :)

Thank you,
David Logan


[-- Attachment #2: Type: text/html, Size: 3543 bytes --]