On Thu, 2006-12-10 at 14:32 -0700, Stephen Hemminger wrote: > > I am on the other extreme - this is problematic if you have a large > > table already learnt. Agrevate that with an unstable link and it gets a > > lot worse. Both of which dont sound unrealistic in say a wireless AP. > > We don't support bridging wireless, that requires some NDS stuff that > isn't supported, and requires more softmac than the stack has. >
I was more thinking of wireless-to-ethernet bridging; that should still work, no? i.e say eth1 on wireless with eth0 on the wired side? In any case, that may be a bad example (and a digression) of something that learns large tables. I have however seen 1K entries in bridging. > > A more sane policy i have seen is a timer that flushes the table after a > > programmed period; this way you counter a flipflop-ing link. > > That's already there. > ah, ok. So the patch is in an alternative to this then? > > IOW, the best place is to have this in some user space daemon. If it has > > to be in the kernel, can you add a systcl to disable it? > > > > When RSTP is in userspace, it will do the flushing. Cool. And that makes a lot of sense. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
