Linux Ethernet Bridging - Sep 2008 - [Bridge] delay in bridge learning when forward delay is 0

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.

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 at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge

> 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 at lists.linux-foundation.org
> > https://lists.linux-foundation.org/mailman/listinfo/bridge
>
> _______________________________________________
> Bridge mailing list
> Bridge at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
Hello Stephen,
you are mentioned in the MAINTAINERS file in the linux kernel tree for 
"ETHERNET BRIDGE". Could you at least, please acknowledge the
reception of
this mail? And maybe let us know what you think of the bug report?

regards,
Uli


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20081013/b65a5cc5/attachment.pgp