Darren Reed writes: > James Carlson wrote: > > Note the lack of a "-R" option here. It is not possible to list > > bridge configuration information in an alternate root, in > > keeping with the rest of the dladm user interface. The reason > > for this restriction is to allow the data to be represented in > > SMF, where "writing" to an alternate root is supported by way of > > copying appropriate commands to $ROOT/var/svc/profile/upgrade, > > but "reading" is not feasible because the repository on the > > alternate root may be incompatible with the running system. > > If there is no separate command, how do we observe > the state of the bridging tables in use internally, > as we might routing information with "netstat -r"?
Good question. I think enhancing netstat is probably the best way to do this. BSD uses protocol 'bdg' to display bridging statistics, and given the prior art, we should do likewise. > > The observability node is intended for use with snoop and > > wireshark. It behaves as a standard Ethernet interface, but does > > not permit the transmission of packets. All transmitted packets > > are silently dropped. > > Was there any consideration given to there being > a kstat counter to record this drop events? No. Trying to transmit on one of the /dev/bridge/* nodes would be a fairly difficult blunder to wander into, so I don't see much point in doing that. It's certainly something that could be added later, though, if someone felt it was necessary. The kstat layout in section 1.3 would accomodate it. > Some other questions.... > What is the rights profile for bridging? No new rights profile or change to existing profiles is needed. The existing "Network Link Security" and "Network Management" rights profiles include dladm with sufficient privilege (as documented in this project) to allow administration of bridges. > Can I bridge interfaces with different MTUs? It's permitted per the standards, but a foolish thing to do. We should emit a warning in this case. A future project may implement LLDP to help prevent toxic mixed MTUs on a LAN. > If so, what happens to the larger packets? They're silently dropped, per 802.1Q-2005 section 6.3.8. (Yes, we can have a kstat for this.) > Is the assignment of a NIC to a bridge mutually > exclusive with other use, say with plumbing an > IP interface on it? No. To get more detail on that answer, we get into detailed design issues. For instance, on transmit of an IP packet through an interface attached to a bridge, we must do a bridge forwarding table look-up on the MAC destination address, and forward it as though it were received on that interface, except that if the forwarding entry points back to the interface, we transmit rather than drop. > Are there any interaction issues with bridging > and the default setting of the eeprom setting > "local-mac-address?"? (OOB setting is "false", > potentially giving all NICs the same MAC address.) That's not quite true. The out-of-the-box setting for "local-mac-address?" has been "true" for years -- see CRs 4473325, 4798630, and 6504375, among others. There are of course some hold-outs, as in CR 4868371. You're right that the "local-mac-address?=false" misfeature is a tremendous call generator, as it breaks at least IPMP, DHCP, and RARP and often breaks other things as well. Given how well-known the problem is, and the trend towards fixing this, I'm not positive that documentation is needed, but I'll add it anyway. -- 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
