netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Craig <philipc@snapgear.com>
To: Ferenc Wagner <wferi@niif.hu>
Cc: netdev@vger.kernel.org
Subject: Re: bridge forwarding delay without STP
Date: Wed, 12 Mar 2008 10:49:54 +1000	[thread overview]
Message-ID: <47D728B2.2090903@snapgear.com> (raw)
In-Reply-To: <87ejah2ole.fsf@tac.ki.iif.hu>

Ferenc Wagner wrote:
> why does a bridge without STP enabled respect its forward delay and
> not skip the learning state?  Forward delay is an STP parameter AFAIK
> (and according to the brctl manual), so I can't see why a bridge not
> doing STP should consider it at all.  Please enlighten me (and Cc: as
> I'm not subscribed).

It doesn't make sense to me either.  But since you can disable the
forward delay by setting it to 0, I don't think it's a problem to
leave this capability in, just in case someone wants it.

But a related problem I have seen is that when you set the forward
delay to 0, the bridge does not learn addresses for the first 20
seconds, and so it floods everything during this time.

Here's what I wrote about this back in July (I didn't get any
replies then):

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, the expiry isn't right for non-zero cases either.


      reply	other threads:[~2008-03-12  0:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-11 16:49 bridge forwarding delay without STP Ferenc Wagner
2008-03-12  0:49 ` Philip Craig [this message]

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=47D728B2.2090903@snapgear.com \
    --to=philipc@snapgear.com \
    --cc=netdev@vger.kernel.org \
    --cc=wferi@niif.hu \
    /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;
as well as URLs for NNTP newsgroup(s).