Jason King writes:
> On Tue, Mar 10, 2009 at 3:31 PM, James Carlson <[email protected]>
> wrote:
> > Or do you have a single LLP daemon that supports multiple instances?
> > If that's the case, then you might want to look into making each of
> > the instances be a separate SMF instance anyway: it makes for simpler
> > administrative control.
>
>
> It's a single-instance daemon that sends/receives on multiple links.
OK; that's actually quite similar to bridging.
> It sounds like this could be simplified down to one added subcommand for
> dladm:
>
> Putting the per-link data under {get,set}-linkprop (with interfaces in
> libdladm to manipulate) -- actual data resides in a per link property
> group in SMF, global data only in SMF in a separate property group.
> The 'show-discovery-config' subcommand can be eliminated.
Actually, I found it much simpler just to use the regular link
property storage mechanism rather than to try to force per-link data
into SMF.
The only things I have in SMF are the things you're implementing as
globals.
> The {start,stop}-discovery subcommands could be eliminated -- enabling
> LLDP tx or rx on any interface implicitly enables the service (I
> believe share(1m) does something like this). It can still be turned
> on/off via svcadm {enable,disable} of course.
That makes sense to me.
> Per link stats can be viewed via the show-link -s (or if dlstat
> integrates, can be moved to that), removing 'show-discovery-stats'.
>
> That would leave the actual LLDP data ('show-discovery' -- though I'm
> really thinking 'show-neighbo[u]rs' might be better -- seems to better
> match switch nomenclature).
It seems we're going to get "dlstat" soonish to take over these
functions. (Unfortunately, it looks like this proposal, though it's a
good idea, was discussed somewhere off-list, and hasn't been ARC'd
yet, so it's a bit of a surprise ...)
--
James Carlson, Solaris Networking <[email protected]>
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
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
