On Tue, Mar 10, 2009 at 3:31 PM, James Carlson <[email protected]> wrote:
> Jason King writes:
>> I like the idea of putting the per-link stuff in with
>> {get,set}-linkprop I'll dig into this in a few days to make sure there
>> aren't any issues with doing this.
>
> OK.
>
>> Unfortunately, it still leaves the question of what to do about global
>> LLDP properties. Unless I misread the rbridge documentation you
>> pasted, it doesn't look like the rbridge model will map completely
>> (per link: yes, global: no) since there's only one daemon.
>
> If there's an LLP-related daemon, and that daemon is controlled by
> SMF, the global parameters can go with that instance, right?
>
> (Just because I have multiple bridging daemons doesn't mean you need
> to have multiple LLP daemons, right?)
>
> 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.
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.
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.
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).
>
>> Just thinking out loud, while the standard strongly implies that they
>> should be able to be manipulated, they are likely to be infrequently
>> touched (and generally uninteresting), would it be bad from an admin
>> point of view to just leave them in SMF with no corresponding method
>> to manipulate them in dladm?
>
> That'd probably be fine for most. I don't think it makes sense for
> any administrative names for the system, though.
>
>> Or as a variant, just use the standard recommended defaults in the
>> code, and only create the properties in SMF to override values as
>> needed?
>
> That's what I'm currently doing. It seems to work well enough.
>
> The important thing (for my use, at least) is that the configuration
> storage mechanism is hidden by the library, so that the rest of the
> system doesn't have to know how it's stored.
>
> --
> 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
