Erik Nordmark writes: > James Carlson wrote: > > dladm create-bridge [-t] [-R <root-dir>] [-p <priority>] > > [-m <max-age>] [-h <hello-time>] [-d <forward-delay>] > > [-f <force-protocol>] [-l <link>]... <bridge-name> > > Given that there might be some future project that does RSTP or MSTP,
The plan is to support RSTP in this project because that's what the code base I've got supports. ;-} Some future project may support MSTP. > wouldn't it make sense to have some notion of "bridge type" in the > create-bridge syntax? That would seem to make it easier to introduce new > types down the road. Then the initial type can be called "STP" and/or > "802.1D-1998". The intent here is to allow for upgrade via a "natural" path. In other words, when (and if) we support MSTP, an existing system that has bridges configured and is upgraded to that new software will automatically start running MSTP -- unless the user explicitly disables such an upgrade by way of the IEEE-specified "force protocol" feature. > If the create-bridge is supposed to be limited to the backwards > compatible set of IEEE 802.1D/802.1Q bridge protocols then you probably > don't need a type since '-f' can be used to control those. Do you intend > to limit it in that way? Create-bridge is supposed to be limited to a compatible set of bridging protocols, so a "type" shouldn't be needed. My current plan for the future RBridges/TRILL support (if that's what you're actually asking about here) is to add parameters that allow per-bridge disabling of RBridge behavior along with explicit administrative action (via SMF) to enable a TRILL instance of isisd. I could also be argued into a "bridge-created == isisd-enabled" position for ease-of-use, but that's not this case. The two protocols need to run side-by-side, at least by default. (If that's the other question here. ;-}) > > This command creates a bridge instance and optionally assigns > > network links to the new bridge. By default, no bridge > > instances are present, and OpenSolaris will not bridge between > > network links. See the "add-bridge" subcommand for details on > > link assignment. > > You say "assigns links". Does that mean that there can be multiple -l > options to specify multiple links? Or is this subcommand limited to at > most one link? The summary includes "[-l <link>]...", which means that (like the create-aggr command on which it's modeled) you can add multiple links at the time the bridge is created. You can also add and remove one or many links after the bridge has been created, using the add-bridge and remove-bridge subcommands, again just like the corresponding *-aggr subcommands. > > In this initial version, the links must also be Ethernet type. > > Do we have a well-define notion of "Ethernet" for dladm? > Typing various dladm show-* on my machine just seems to tell me that my > links are "non-vlan", which isn't sufficient to tell e.g., Ethernet and > 802.11 apart. The set of acceptable links is the same set that the *-aggr feature supports, plus aggregations themselves. Maybe I'm missing something important here, but I don't see a particular reason to distinguish between 802.11 and other kinds of interfaces. > > 1.2 New dladm Link Properties > > > > "stp" > > > > This is a boolean property. It defaults to "true." When set > > to "false," the link will not use Spanning Tree, and will be > > placed into forwarding mode at all times. The "false" setting > > is appropriate for point-to-point links connected to end > > nodes. Only non-VLAN type links have this property. > > I wonder if it would be better, since we might have rstp or mstp in the > future, to use Cisco type terminology for this (which I think is > "portfast" or something like that.) I'm very wary of and I don't want to step in any of their IPR. :-/ > > "stp-priority" > > "stp-cost" > > Could we/should we avoid "stp" in those names? The values are defined in terms that STP itself uses, and the IS-IS notion of cost and priority are rather different, so having some sort of reference to the domain in which the values are used makes sense to me. If we removed that term from those names, what would the units be? > > When the adminstrator knows that a particular port is not > > connected to another bridge (for example, a direct point-to-point > > connection to a host system), STP can be disabled administratively > > for that port. Even if all ports on a bridge have STP disabled, > > the STP daemon still runs; this is in case new ports are added, > > and because it is responsible for enabling and disabling > > forwarding on the ports. > > This is a design issue and not an architectural issue. (Thus I should > really have sent it as a separate email to the project team.): > For safety reasons, does the daemon watch for Bridge PDUs on the ports > that have STP disabled? (There shouldn't be any, thus there existence is > a red flag that the link probably isn't a point-to-point connection to a > host system.) That sounds like a reasonable thing to do. I'll add it to the list. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
