Ethernet Bridge development
 help / color / mirror / Atom feed
From: Uli Luckas <u.luckas@road.de>
To: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] delay in bridge learning when forward delay is 0
Date: Wed, 24 Sep 2008 13:57:28 +0200	[thread overview]
Message-ID: <200809241357.28552.u.luckas@road.de> (raw)
In-Reply-To: <200809182133.59751.luckas@musoft.de>

Is any one willing to look into this problem? Or even aknowledege it's 
existence? 
If the description is not clear, please let me know.

Any response would be appreciated.

regards,
Uli

> Hi,
> In July 2007 Philip Craig reported the following issue with 'forward
> delay'=0 in great detail without receiving an answer. Has Philip's message
> got lost or was his analysis wrong?
> The problem becomes a real problem if you bridge a fast LAN to a slow port
> like a bluetooth pan for example.
>
>
> https://lists.linux-foundation.org/pipermail/bridge/2007-July/005476.html
> Philip Craig philipc at snapgear.com
>
> > Hi,
> >
> > If you set the bridge forward delay to 0 with:
> >         brctl setfd br0 0
> > then the bridge does not learn addresses for the first 20 seconds,
> > and so it floods everything during this time.
> >
> > The reason for this is that hold_time() returns 0 after a topology
> > change, br_fdb_update() is a no-op if hold_time() is 0 (so that
> > 'brctl setmaxage br0 0' can be used to disable learning), and the
> > topology change flag isn't cleared for max_age seconds, so nothing
> > is learnt during that time.
> >
> > It seems that the intent of hold_time() is to expire entries that are
> > older than forward_delay seconds at the time of the topology change,
> > which it does, but then it keeps on checking this expiry again for
> > max_age seconds, and bases these checks on the current time rather
> > than the time of the change.
> >
> > A quick fix for the forward delay 0 case would be to skip the
> > topology change check if stp is disabled, but if I understand things
> > correctly then the expiry isn't right for non-zero cases either.
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge

  reply	other threads:[~2008-09-24 11:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 19:33 [Bridge] delay in bridge learning when forward delay is 0 Uli Luckas
2008-09-24 11:57 ` Uli Luckas [this message]
2008-10-13 16:04   ` Uli Luckas
2008-10-13 18:10     ` Stephen Hemminger
2008-10-14  9:36       ` Uli Luckas
  -- strict thread matches above, loose matches on Subject: below --
2007-07-09  7:50 Philip Craig

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=200809241357.28552.u.luckas@road.de \
    --to=u.luckas@road.de \
    --cc=bridge@lists.linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox