Al Hopper wrote:
> On Sun, 27 May 2007, Garrett D'Amore wrote:
>
>> Casper.Dik at Sun.COM wrote:
>>>> The question is whether that historical information is actually
>>>> useful. It _is_ useful to know that a link is up or not, but the
>>>> speed and duplex are, IMO, not often useful. (In fact, a number of
>>>> people were arguing against having _anything_ logged.)
>>>>
>>>
>>> I beg to differ; there have been occassions when network performance
>>> was very bad and then you can easily tell from the logs when the
>>> switch was misconfigured. Knowing when something changed can
>>> help a lot in finding who did it.
>>>
>>
>> Hmm.... maybe then I need to promote this track to a fast track. I
>> assumed that the case was non-controversial (nobody responded to my
>> earlier request for comments before I submitted the case), and that
>> the case didn't touch ARC'd interfaces (syslogs are "not-an-interface").
>>
>> Can a PSARC member let me know what is necessary to promote this to a
>> regular fasttrack? (Reopening the case in the process.)
>>
>> Now, on the note of changes that impact network performance, there
>> are a lot of other tunables (especially for non-ethernet links) where
>> misconfiguration of one end or the other can cause performance
>> problems. Its not clear that speed and duplex are sufficient to
>> debug all these problems.
>>
>> I also contend that this represents use of the syslogs to debug an
>> out-of-scope problem. (In this case, what you are talking about
>> doesn't help resolve the configuration problem directly, since you
>> can always view and change the _current_ configuration.) Use of
>> syslogs to help audit activity on _remote peers_ seems like a poor
>> excuse to me... if the site lacks proper auditing of configuration
>> changes in their network, then that problem should be tackled
>> directly, perhaps with local policy, or in combination with other
>> tools such as SNMP logging.
>
> You seem to be missing the point - syslogging the interface name with
> speed and duplicity is useful in a couple of very practical ways:
>
> a) you've got a white box with 2 ether interfaces marked "0" and "1"
> and you need to identify which is which. Easy - unplug one briefly
> and look at the console message.
>
> b) you're on a server (eg x2200M2) with 4 ethernet ports and you can't
> remember which pair of interfaces are the bge or nge pair. Easy -
> unplug one briefly and watch the console message.
>
> c) you've got an older SPARC box and you can't remember whether a
> particular rear panel ethernet port (in a PCI expansion slot) is a
> bge/e1000g etc. Same routine - unplug the cable briefly.
>
> All these examples are when you're working on the physical hardware.
> It's much faster to do this than search the product specific docs -
> and you don't have product specific docs if you've built the box and
> neglected to label the ethernet ports from a Solaris perspective.
In all of these cases, you _do not_ need to know the link speed/duplex,
the "up" and "down" messages that I've proposed will address this need.
To re-state:
* the link state change will be logged (going from down to up, or
vice versa), but the details of speed, duplex, channel, and other link
tunables will _not_ be part of the message that I've proposed.
Hope that answers this concern.
-- Garrett
