From gd78059@sac.sfbay.sun.com Thu May 24 08:30:15 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4OFUF1q002610; Thu, 24 May 2007 08:30:15 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l4OFUF2o002606; Thu, 24 May 2007 08:30:15 -0700 (PDT) Date: Thu, 24 May 2007 08:30:15 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Message-Id: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> To: psarc-ext@sac.sfbay.sun.com Cc: Garrett.Damore@Sun.COM Subject: GLDv3 link status logging [PSARC/2007/298 Self Review] Status: RO Content-Length: 2479 I'm submitting the following automatic case on my own behalf. It seems non-controversial, and only impacts syslog contents, which doesn't even seem to be an ARC issue (logs are Not-an-interface). The change is significant enough that I want to give PSARC a heads up, though. Please let me know if there are any issues with it. Template Version: @(#)sac_nextcase 1.58 05/23/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GLDv3 link status logging 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 24 May, 2007 4. Technical Description Problem ------- Various network drivers are inconsistent in their handling of logging of link messages. One of the more annoying things that some drivers do is flood the logs with link down messages (usually once every 10sec or so) when trying to transmit packets out the link. Further, the detailed contents for link status changes are not consistent from one driver to another. Notably, the WIFI drivers generally do not do this. Solution -------- We propose to modify GLDv3 so that GLDv3 reports (on the behalf of the driver) when link state changes by logging a simple message to logs. This would only be done when the link _changes_, which could be either due to administrative action or an external event such as a cable disconnect or reboot or administrative action the link partner. The message will omit all details except the state as up or down, and will never go to the console. The message will have one of two forms: nge0 link up or nge0 link down Obviously "nge0" is for the Nvidia GigE driver. Other drivers, etc. will get their contents here as well. The message will appear to come from "mac", and will be prefixed by the normal syslog details (date, hostname, message ID, etc.) in the system logs. Note that side effect of this is that aggregations will also be reported to the logs: "aggr0 link up" or "aggr0 link down" The administrator that wants more detail about the link type, mode, etc. can use dladm to get this information. We will be modifying the full set of the current GLDv3 drivers to remove any driver-specific logging of link changes. We can do this now, while GLDv3 is still an ON-private API. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic From peter.tribble@gmail.com Sun May 27 03:31:22 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RAVMVk022425 for ; Sun, 27 May 2007 03:31:22 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4RAU5f7011449 for ; Sun, 27 May 2007 03:30:05 -0700 (PDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4RAOE1Z005679 for ; Sun, 27 May 2007 10:30:04 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay2.sun.com with ESMTP id BT-MMP-1984179 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:30:02 Z Received: from relay02i.sun.com (ip72.net150143-60.block3.us.syntegra.com [150.143.60.72]) by mms05es.sun.com with ESMTP id BT-MMP-1420928 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:30:02 Z Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by relay0i.sun.com with ESMTP id BT-MMP-2081758 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:30:02 Z Received: from py-out-1112.google.com ([64.233.166.180] [64.233.166.180]) by relay4i.sun.com with ESMTP id BT-MMP-1875329 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:30:01 Z Received: by py-out-1112.google.com with SMTP id b50so2252711pyh for ; Sun, 27 May 2007 03:30:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B45dNDws5eoK+SVmHrVy5t8AxxI0E7hB5f+AIGtzX8FNoyl2zSXki9IGg6eAg4fHtyEbh0HfDo6SHzus4CXaWP7XFmAhpBZB7LOK+C2hfH52R5dQAGoSAlFFVNV8IR0HD5VmhJqiSB4K+Ws7YYS3CR0o5pEaAN3nzma123aeSQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NJcNoZ4yotNtk+kJNe/ObWT1O4hjh9OqW2MZZj2b0JI1P6+eKltuRE/UkefFHjutiVHVK2ilqzLUCw49i9dMxf9VAsORXzu6gR2w9iEB6yOBAkFZMjiaw/EkHNLioM0SE8g5qV/uCmSF7XYEUN9jhvBscfkCJs/Lhvxym5tADlo= Received: by 10.64.241.3 with SMTP id o3mr7122467qbh.1180261801418; Sun, 27 May 2007 03:30:01 -0700 (PDT) Received: by 10.65.43.7 with HTTP; Sun, 27 May 2007 03:30:01 -0700 (PDT) Message-Id: Date: Sun, 27 May 2007 11:30:01 +0100 From: "Peter Tribble" To: Garrett.Damore@sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: psarc-ext@sac.sfbay.sun.com In-Reply-To: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> Status: RO Content-Length: 1536 On 5/24/07, Garrett D'Amore - sun microsystems wrote: > > I'm submitting the following automatic case on my own behalf. It seems > non-controversial, and only impacts syslog contents, which doesn't even seem > to be an ARC issue (logs are Not-an-interface). The change is significant > enough that I want to give PSARC a heads up, though. Please let me know if > there are any issues with it. ... > We propose to modify GLDv3 so that GLDv3 reports (on the behalf of the driver) > when link state changes by logging a simple message to logs. This would > only be done when the link _changes_, which could be either due to > administrative action or an external event such as a cable disconnect or > reboot or administrative action the link partner. > > The message will omit all details except the state as up or down, and will > never go to the console. > > The message will have one of two forms: > > nge0 link up > or > nge0 link down Are you saying that the message: May 27 10:29:08 voyager bge: [ID 801725 kern.info] NOTICE: bge0: link up 100Mbps Full-Duplex (initialized) will lose the speed and duplicity information? If so, I consider this to be a huge step backwards, as logging the speed and duplicity information is not only a simple and useful way of verifying that the link has come up correctly now, but is also a way (the only way?) of tracking historical changes to these properties. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Garrett.Damore@Sun.COM Sun May 27 09:09:17 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RG9HX2027242 for ; Sun, 27 May 2007 09:09:17 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4RG80im028093 for ; Sun, 27 May 2007 09:08:00 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4RG7sPv019999 for ; Sun, 27 May 2007 09:07:54 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIP00D01J93BF00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 09:07:54 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIP002F5JH6DIQN@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 09:07:54 -0700 (PDT) Date: Sun, 27 May 2007 09:06:28 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Peter Tribble Cc: psarc-ext@sac.sfbay.sun.com Message-id: <4659AC84.2080104@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2421 Peter Tribble wrote: > On 5/24/07, Garrett D'Amore - sun microsystems > wrote: >> >> I'm submitting the following automatic case on my own behalf. It seems >> non-controversial, and only impacts syslog contents, which doesn't >> even seem >> to be an ARC issue (logs are Not-an-interface). The change is >> significant >> enough that I want to give PSARC a heads up, though. Please let me >> know if >> there are any issues with it. > ... >> We propose to modify GLDv3 so that GLDv3 reports (on the behalf of >> the driver) >> when link state changes by logging a simple message to logs. This would >> only be done when the link _changes_, which could be either due to >> administrative action or an external event such as a cable disconnect or >> reboot or administrative action the link partner. >> >> The message will omit all details except the state as up or down, and >> will >> never go to the console. >> >> The message will have one of two forms: >> >> nge0 link up >> or >> nge0 link down > > Are you saying that the message: > > May 27 10:29:08 voyager bge: [ID 801725 kern.info] NOTICE: bge0: link > up 100Mbps Full-Duplex (initialized) > > will lose the speed and duplicity information? Yes. It will also lose the "why" (initialized in this case). Though not all NICs originally provided this information in the logs (and of those that did, most of them did not report them in exactly the same way.) > > If so, I consider this to be a huge step backwards, as logging the > speed and duplicity information is not only a simple and useful > way of verifying that the link has come up correctly now, but is > also a way (the only way?) of tracking historical changes to > these properties. 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.) For many links, the speed and duplex are not as trivial anyway. For example, what information should be logged for a wlan? What about for an aggregation? What about for a PPP link? IPoIB? Ad naseum. Of course, I suspect some sites were relying on this to provide not historical information, but rather _current_ link state. That's less of a problem now that we have dladm. -- Garrett From casper@holland.sun.com Sun May 27 09:35:29 2007 Received: from sr1-eaft06-01.holland.sun.com (sr1-eaft06-01.Holland.Sun.COM [129.159.237.36]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RGZSsc027349 for ; Sun, 27 May 2007 09:35:28 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l4RGY9q0047156; Sun, 27 May 2007 18:34:10 +0200 (MEST) Message-Id: <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> From: Casper.Dik@Sun.COM To: "Garrett D'Amore" cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <4659AC84.2080104@sun.com> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> Date: Sun, 27 May 2007 18:34:09 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 857 >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. >For many links, the speed and duplex are not as trivial anyway. For >example, what information should be logged for a wlan? What about for >an aggregation? What about for a PPP link? IPoIB? Ad naseum. Does an aggregation have a *link*? The underlying devices do have one; for WLAN too there is a link speed (but it's always half-duplex in a way) Casper From Garrett.Damore@Sun.COM Sun May 27 10:01:34 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RH1YQb027732 for ; Sun, 27 May 2007 10:01:34 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4RH0Hkr005046 for ; Sun, 27 May 2007 10:00:17 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4RH0CYE020560 for ; Sun, 27 May 2007 10:00:12 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIP00G01KTVL900@d1-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:00:11 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIP006E0LWBH827@d1-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 10:00:11 -0700 (PDT) Date: Sun, 27 May 2007 09:58:45 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> Sender: Garrett.Damore@Sun.COM To: Casper.Dik@Sun.COM Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <4659B8C5.5060607@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 3044 Casper.Dik@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. If the problem is audit of dladm changes (local changes), then dladm should record this either in an audit log, or in syslog itself. I consider that particular problem out-of-scope for this case, as well. On the other hand, for most networks, the only time link status will change after boot will be when the hardware (remote or local) boots, there is a change in the cable connectivity, or there is a configuration on one end or the other. > >> For many links, the speed and duplex are not as trivial anyway. For >> example, what information should be logged for a wlan? What about for >> an aggregation? What about for a PPP link? IPoIB? Ad naseum. >> > > Does an aggregation have a *link*? The underlying devices do have > one; for WLAN too there is a link speed (but it's always half-duplex > in a way) > The aggregation has information which may be useful (e.g. which underlying links are up, aggregate speed, etc.) For WLANs, maybe you care about SSID, channel, WPA/WEP, link quality, etc. It gets hard to know what is needed here. Right now _nothing_ is logged for these other link layers, whereas this case proposes to start logging at least the overall link state. -- Garrett From peter.tribble@gmail.com Sun May 27 11:46:06 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RIk6c8028352 for ; Sun, 27 May 2007 11:46:06 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4RIinij004723 for ; Sun, 27 May 2007 11:44:49 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4RGHEE6025945 for ; Sun, 27 May 2007 18:44:48 GMT Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay1.sun.com with ESMTP id BT-MMP-2018059 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 18:44:48 Z Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms02es.sun.com with ESMTP id BT-MMP-287973 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 18:44:48 Z Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by relay3.sun.com with ESMTP id BT-MMP-2284710 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 18:44:48 Z Received: from py-out-1112.google.com ([64.233.166.181] [64.233.166.181]) by relay4i.sun.com with ESMTP id BT-MMP-1548799 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 18:44:48 Z Received: by py-out-1112.google.com with SMTP id b50so2416961pyh for ; Sun, 27 May 2007 11:44:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fu/T22GrOKJ/4NatRKJ7fAI/81L9ZDYDsLa09bdxBnizi5F3Img3kqw3YEAcckDQnAwvKwzh4yPdVfTYcQkgFxd54gYah4ltveDCCj/Ab4fhXBM5ex1z6yKpv/w97SBC/UG4tBi8oGeAxHJb2QapGEI0h6TtqkdYR+KKF/te4LM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YYjJ05cTyKXwEIAXPE8Adn5e/jya2coeBANMnhp1rihFEOCHuTHvIdRL8ZxCh0Gp20dvd+40uy7KYW/wSL0Zb1rX9BI3nltxnHheaRF0ckVbwodEUH8mdqT8+RegWUyLza77nqm6JKp1zi3Z0LGwNSW5o9tJG80QtZWDDlKuX+U= Received: by 10.64.249.18 with SMTP id w18mr9154605qbh.1180291486850; Sun, 27 May 2007 11:44:46 -0700 (PDT) Received: by 10.65.43.7 with HTTP; Sun, 27 May 2007 11:44:46 -0700 (PDT) Message-Id: Date: Sun, 27 May 2007 19:44:46 +0100 From: "Peter Tribble" To: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: Casper.Dik@sun.com, psarc-ext@sac.sfbay.sun.com In-Reply-To: <4659B8C5.5060607@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> Status: RO Content-Length: 2718 On 5/27/07, Garrett D'Amore wrote: > Casper.Dik@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.) Experience shows that I really need all 3. I need to know when the link went down and came back up (so I know how long it was down); I need to know the speed and duplicity (particularly the latter) to detect misconfiguration when it occurs. > > 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. Indeed. Going to the network team to ask "have you changed anything this week?" is nowhere near as effective as "at 17:23:44 on Tuesday you broke the autonegotiation settings". Weaseling out of the latter is harder. > 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. Agreed, but for physical ethernet links speed and particularly duplex are key factors. > I also contend that this represents use of the syslogs to debug an > out-of-scope problem. My server's not functioning correctly - that's very much in-scope. What's needed are the tools to point the finger in the right direction. > (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. The snag is that losing this information reduces the ability to connect the problem with the change. In the presence of multiple changes, which one caused the problem? > On the other hand, for most networks, the only time link status will > change after boot will be when the hardware (remote or local) boots, > there is a change in the cable connectivity, or there is a configuration > on one end or the other. Precisely the changes I'm interesting in tracking. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From peter.tribble@gmail.com Sun May 27 12:05:42 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4RJ5gFG028760 for ; Sun, 27 May 2007 12:05:42 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4RJ4PgH003313 for ; Sun, 27 May 2007 12:04:25 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4RGW7UN002625 for ; Sun, 27 May 2007 19:04:25 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay1.sun.com with ESMTP id BT-MMP-2019238 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 19:04:25 Z Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms05es.sun.com with ESMTP id BT-MMP-2042495 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 19:04:24 Z Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by relay4.sun.com with ESMTP id BT-MMP-2212168 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 19:04:24 Z Received: from py-out-1112.google.com ([64.233.166.179] [64.233.166.179]) by relay4i.sun.com with ESMTP id BT-MMP-1553845 for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 19:04:24 Z Received: by py-out-1112.google.com with SMTP id b50so2423238pyh for ; Sun, 27 May 2007 12:04:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ijpncm8cXgcBby7+xGx5bIGbX5xoIYQ/eUsh7U22QBUGlC6VFuBbn2VcF4ZEuozruTPl17tf4O93+A2xN9AzpFL6TcJYp60vSaVIsDg6UnX9C9lIra9KPlJkMSsn4ZMaYZ0IkImVdjTYkZnEXeiZNusf8V/OE90RyJS9uvnJSMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jauM/v9nG74NBh2zRF5uB9alzsvBgggqO1CyFlpHJ+eJDFytVdyM4XHUqW3wlVV5GCR2Xn0d/i07D6hVSAhiRcYDLYFLZp9yliPpoxdAkzILKiYvS4hWW8nOgoV1JNY62GHWDs7osPkvQ1VU6ItgnCWUBzk577/GKuBl6fhrF4U= Received: by 10.65.116.10 with SMTP id t10mr9176423qbm.1180292664381; Sun, 27 May 2007 12:04:24 -0700 (PDT) Received: by 10.65.43.7 with HTTP; Sun, 27 May 2007 12:04:24 -0700 (PDT) Message-Id: Date: Sun, 27 May 2007 20:04:24 +0100 From: "Peter Tribble" To: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: psarc-ext@sac.sfbay.sun.com In-Reply-To: <4659AC84.2080104@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> Status: RO Content-Length: 553 On 5/27/07, Garrett D'Amore wrote: > Of course, I suspect some sites were relying on this to provide not > historical information, but rather _current_ link state. That's less of > a problem now that we have dladm. It *should* be, modulo bug 6321504 which requires significant privilege (far more than necessary) to view the current state. Certainly at the present time I can't regard dladm as an acceptable method of determining link status. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Tzongyu.Lee@Sun.COM Sun May 27 19:03:41 2007 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S23e82002383 for ; Sun, 27 May 2007 19:03:41 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S22HJC011174 for ; Mon, 28 May 2007 02:02:17 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00901AYXOG00@mail-apac.sun.com> (original mail from Tzongyu.Lee@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 10:02:17 +0800 (SGT) Received: from [129.158.218.85] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ002DAAZS94LC@mail-apac.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 10:02:17 +0800 (SGT) Date: Mon, 28 May 2007 10:01:42 +0800 From: Tzongyu Paul Lee Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <4659B8C5.5060607@sun.com> Sender: Tzongyu.Lee@Sun.COM To: "Garrett D'Amore" Cc: Casper.Dik@Sun.COM, Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465A3806.1090901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: zh-cn, en-us, en References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3786 Promoting this to a fast track might not be a bad idea. I like the idea that gldv3 picks up this gap to do link status logging instead of letting each driver come up with its own format and determine where to send/log to. The exact content of this link status message can be expounded within reason and let's nail this. If aggregated link status has nothing reported yet, this should be a bug or at least an RFE if none filed. This is another good reason to manage 'link status' at the gldv3 level. T. Paul --- Garrett D'Amore wrote: > Casper.Dik@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. > > If the problem is audit of dladm changes (local changes), then dladm > should record this either in an audit log, or in syslog itself. I > consider that particular problem out-of-scope for this case, as well. > > On the other hand, for most networks, the only time link status will > change after boot will be when the hardware (remote or local) boots, > there is a change in the cable connectivity, or there is a > configuration on one end or the other. > >> >> >>> For many links, the speed and duplex are not as trivial anyway. For >>> example, what information should be logged for a wlan? What about >>> for an aggregation? What about for a PPP link? IPoIB? Ad naseum. >>> >> >> >> Does an aggregation have a *link*? The underlying devices do have >> one; for WLAN too there is a link speed (but it's always half-duplex >> in a way) >> > > > The aggregation has information which may be useful (e.g. which > underlying links are up, aggregate speed, etc.) For WLANs, maybe you > care about SSID, channel, WPA/WEP, link quality, etc. It gets hard to > know what is needed here. Right now _nothing_ is logged for these > other link layers, whereas this case proposes to start logging at > least the overall link state. > > -- Garrett > -- Tzongyu Paul Lee, Tzongyu.Lee@Sun.Com or Paul.Lee@Sun.COM BJS05 7225, x84343 From John.Plocher@Sun.COM Sun May 27 20:28:21 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S3SLMd003422 for ; Sun, 27 May 2007 20:28:21 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4S3R3v5003410 for ; Sun, 27 May 2007 20:27:03 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S3QwNO009464 for ; Sun, 27 May 2007 20:26:58 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00G01ERD7D00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:26:58 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ0023XEWXDHAY@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:26:58 -0700 (PDT) Date: Sun, 27 May 2007 20:26:50 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <4659B8C5.5060607@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Casper.Dik@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <465A4BFA.1010603@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 242 Garrett D'Amore wrote: > Can a PSARC member let me know what is necessary to promote this to a > regular fasttrack? (Reopening the case in the process.) Simply change the IAM file's status line to waiting fast-track MM/DD/YYYY -John From Garrett.Damore@Sun.COM Sun May 27 20:31:11 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S3VBfA003436 for ; Sun, 27 May 2007 20:31:11 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4S3TrNa003667 for ; Sun, 27 May 2007 20:29:53 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S3TmlT009490 for ; Sun, 27 May 2007 20:29:48 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00G01ERD7D00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:29:48 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ0029RF1ODHAY@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:29:48 -0700 (PDT) Date: Sun, 27 May 2007 20:28:22 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Peter Tribble Cc: psarc-ext@sac.sfbay.sun.com Message-id: <465A4C56.2020302@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 905 Peter Tribble wrote: > On 5/27/07, Garrett D'Amore wrote: >> Of course, I suspect some sites were relying on this to provide not >> historical information, but rather _current_ link state. That's less of >> a problem now that we have dladm. > > It *should* be, modulo bug 6321504 which requires significant > privilege (far more than necessary) to view the current state. > Certainly at the present time I can't regard dladm as an acceptable > method of determining link status. > Huh? Is the problem that you need to have root privilege to determine link status? If we fixed _that_ problem, would you be happy? (I agree that root privilege should not be required to look at existing link state.) As far as your earlier arguments go, a lot of the argument seems to be based on pointing fingers and laying blame, rather than on _fixing_ the root problem. -- Garrett From Garrett.Damore@Sun.COM Sun May 27 20:34:43 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S3YhGX003504 for ; Sun, 27 May 2007 20:34:43 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4S3XPL4022287 for ; Sun, 27 May 2007 20:33:25 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S3XKZC026976 for ; Sun, 27 May 2007 20:33:20 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00I01F388R00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:33:20 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ002C9F7JDI4O@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:33:20 -0700 (PDT) Date: Sun, 27 May 2007 20:31:53 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465A4BFA.1010603@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Casper.Dik@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <465A4D29.8070606@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465A4BFA.1010603@Sun.Com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 545 John Plocher wrote: > Garrett D'Amore wrote: >> Can a PSARC member let me know what is necessary to promote this to a >> regular fasttrack? (Reopening the case in the process.) > > Simply change the IAM file's status line to > > waiting fast-track MM/DD/YYYY > > -John I've promoted this to a fast-track with timeout set for May 31, which is one week beyond the original submission date, and one day after the next PSARC meeting. If ARC members want more time, we can extend the timer at Wednesday's PSARC meeting. -- Garrett From John.Plocher@Sun.COM Sun May 27 20:46:49 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S3knQv003602 for ; Sun, 27 May 2007 20:46:49 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4S3jVNZ023414 for ; Sun, 27 May 2007 20:45:31 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S3jQmB009701 for ; Sun, 27 May 2007 20:45:26 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00L01FQWBG00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:45:26 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ002VIFRPDHAY@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 20:45:26 -0700 (PDT) Date: Sun, 27 May 2007 20:45:17 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465A4C56.2020302@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465A504D.3080900@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 845 Garrett D'Amore wrote: > ... historical information ... Does the GLDv3 framework know enough to gather and print additional context info in these messages? I agree that having only link up/down is a step backwards for drivers thattoday tell you speed, duplex, etc. Especially when you are dealing with auto negotiating interfaces, cable, switch and server interconnect problems and the like, having this level of detail contributes significantly to the adminability of a Solaris system. BTW, PSARC/1994/397, PSARC/1996/424, PSARC/1998/183 and PSARC/1998/399 all stabalize various parts of the syslog message content, so don't naively assume that you can make across the board changes without impact. In particular, SunMC, Explorer and other service/diagnostic tools contain embedded knowledge of (some of) the message formats... -John From Garrett.Damore@Sun.COM Sun May 27 21:01:39 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S41dbH003993 for ; Sun, 27 May 2007 21:01:39 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4S40LMS007809 for ; Sun, 27 May 2007 21:00:21 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S40GFJ009863 for ; Sun, 27 May 2007 21:00:16 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00001GDTIH00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 21:00:16 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ002JCGGGDHBY@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 21:00:16 -0700 (PDT) Date: Sun, 27 May 2007 20:58:50 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465A4C56.2020302@sun.com> Sender: Garrett.Damore@Sun.COM To: "Garrett D'Amore" Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465A537A.4020903@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1223 Garrett D'Amore wrote: > Peter Tribble wrote: >> On 5/27/07, Garrett D'Amore wrote: >>> Of course, I suspect some sites were relying on this to provide not >>> historical information, but rather _current_ link state. That's >>> less of >>> a problem now that we have dladm. >> >> It *should* be, modulo bug 6321504 which requires significant >> privilege (far more than necessary) to view the current state. >> Certainly at the present time I can't regard dladm as an acceptable >> method of determining link status. >> > > Huh? Is the problem that you need to have root privilege to determine > link status? If we fixed _that_ problem, would you be happy? Btw, all this information is available via kstat(1M) as well. But I agree that we should fix 6321504. I've taken a look at it... it looks like a simple bug to fix. Maybe I can fix it as part of this putback, or as a follow-on project. -- Garrett > > (I agree that root privilege should not be required to look at > existing link state.) > > As far as your earlier arguments go, a lot of the argument seems to be > based on pointing fingers and laying blame, rather than on _fixing_ > the root problem. > > -- Garrett From Garrett.Damore@Sun.COM Sun May 27 21:04:35 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S44Zlj004031 for ; Sun, 27 May 2007 21:04:35 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4S43Hk3026444 for ; Sun, 27 May 2007 21:03:17 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S43BZ1027315 for ; Sun, 27 May 2007 21:03:12 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIQ00001GDTIH00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 21:03:11 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIQ002R4GLBDHBY@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Sun, 27 May 2007 21:03:11 -0700 (PDT) Date: Sun, 27 May 2007 21:01:45 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465A504D.3080900@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465A5429.1040701@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2155 John Plocher wrote: > Garrett D'Amore wrote: >> ... historical information ... > > Does the GLDv3 framework know enough to gather and print > additional context info in these messages? It could go an inquire the information from the driver's kstats. (It has knowledge of how to do this, although the statistic details are not specifically present in the driver.) Part of the problem is figuring out what detail is relevant. For ethernet you'd think duplex and speed would be enough. But what about transceiver used, media type, and loopback state? Its not immediately obvious how much is sufficient, and how much is not. > > I agree that having only link up/down is a step backwards for drivers > thattoday tell you speed, duplex, etc. Especially when you are > dealing with auto negotiating interfaces, cable, switch and server > interconnect problems and the like, having this level of detail > contributes significantly to the adminability of a Solaris system. The details are available via dladm and kstats. The question is whether they _also_ belong in the syslogs. There is also the question about whether dladm should require root privilege (well, its not really root, but it is effectively so in most cases) to do this kind of thing. > > BTW, PSARC/1994/397, PSARC/1996/424, PSARC/1998/183 and > PSARC/1998/399 all stabalize various parts of the syslog > message content, so don't naively assume that you can make > across the board changes without impact. In particular, > SunMC, Explorer and other service/diagnostic tools contain > embedded knowledge of (some of) the message formats... Hmm... good point. I hope SunMC isn't using this information (kstat would be much better.) I can imagine that Explorer might. Again, I'd hope kstat to collect _current_ link state would be used in preference to grunging through the logs to get this info. The cases in question appear to address general formats of Syslog, and not the contents of specific messages (in particular nothing relating to link state notification.) Anyway, the case is promoted to a fasttrack, for further consideration by PSARC. -- Garrett From peter.tribble@gmail.com Mon May 28 11:27:22 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4SIRMTf013698 for ; Mon, 28 May 2007 11:27:22 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4SIQ3sP028309 for ; Mon, 28 May 2007 11:26:03 -0700 (PDT) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4SICWfK024527 for ; Mon, 28 May 2007 18:26:03 GMT Received: from mms03es.sun.com ([150.143.104.54] [150.143.104.54]) by relay3.sun.com with ESMTP id BT-MMP-545095 for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 18:25:56 Z Received: from relay01i.sun.com (ip70.net150143-60.block3.us.syntegra.com [150.143.60.70]) by mms03es.sun.com with ESMTP id BT-MMP-1543995 for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 18:25:55 Z Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by relay0i.sun.com with ESMTP id BT-MMP-2788932 for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 18:25:55 Z Received: from nz-out-0506.google.com ([64.233.162.233] [64.233.162.233]) by relay4i.sun.com with ESMTP id BT-MMP-2443485 for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 18:25:55 Z Received: by nz-out-0506.google.com with SMTP id s18so414213nze for ; Mon, 28 May 2007 11:25:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dpUd9NlBq+y+wu2Z6/eUvzW+3ng8KWwa34FVZTgHBVW9nrzkMsSGbdXIjU7ccwgNLbVirXu2tHHupOMXlBw89TI9Pp3EtTygUbiG/Yh2ME+6TjWx5ElYL8lSzIIY+ioqOvLeg00yzcBIg1tzNV5H7K7CGxgydnPRw/lt3n5qx2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y0cSNdOrL8QvzgFOHHrPYfyhti3UgqnvPcptx5HpyOa3hRfQLoNO1oXErA1BjLxB8V+VIVa0ZYQJVVGZFMQ4luPA6sWIoMS8NNhObpGR8XS4IMhrwxiBqSvAc4vr+GfxOGUr5cPPC09Xl3OVgeMf6PRaVk5REuK6IjoIUkNWRzE= Received: by 10.64.195.20 with SMTP id s20mr11173255qbf.1180376751465; Mon, 28 May 2007 11:25:51 -0700 (PDT) Received: by 10.65.43.7 with HTTP; Mon, 28 May 2007 11:25:51 -0700 (PDT) Message-Id: Date: Mon, 28 May 2007 19:25:51 +0100 From: "Peter Tribble" To: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: psarc-ext@sac.sfbay.sun.com In-Reply-To: <465A4C56.2020302@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> Status: RO Content-Length: 2012 On 5/28/07, Garrett D'Amore wrote: > Peter Tribble wrote: > > On 5/27/07, Garrett D'Amore wrote: > >> Of course, I suspect some sites were relying on this to provide not > >> historical information, but rather _current_ link state. That's less of > >> a problem now that we have dladm. > > > > It *should* be, modulo bug 6321504 which requires significant > > privilege (far more than necessary) to view the current state. > > Certainly at the present time I can't regard dladm as an acceptable > > method of determining link status. > > > > Huh? Is the problem that you need to have root privilege to determine > link status? If we fixed _that_ problem, would you be happy? I would be happy that dladm were useful, which is a good thing. It doesn't change my view that having speed and duplex in the link up message is essential. > (I agree that root privilege should not be required to look at existing > link state.) > > As far as your earlier arguments go, a lot of the argument seems to be > based on pointing fingers and laying blame, rather than on _fixing_ the > root problem. It's finger pointing only insofar as it allows you to easily root cause the problem. Removing information makes it much harder to administer systems - at present it's immediately obvious by visual inspection of the logs that the link has bounced and has come up correctly (or not...). With this change, the administrator then has to take additional manual steps to verify that the network parameters are correct. And it then becomes impossible to determine which out of a sequence of changes is the one that caused the problem, as you lose all the history. This isn't just of theoretical interest: I've had a couple of occasions when the speed/duplex notification in the log was key in quickly identifying and fixing a problem, and which would have been significantly harder without it. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From unixconsole@yahoo.com Mon May 28 21:08:59 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T48xOC018986 for ; Mon, 28 May 2007 21:08:59 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4T47g3Y009210 for ; Mon, 28 May 2007 21:07:42 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T2W9KA003366 for ; Tue, 29 May 2007 04:07:41 GMT Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay1.sun.com with ESMTP id BT-MMP-2182668 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 04:07:41 Z Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms02es.sun.com with ESMTP id BT-MMP-2315518 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 04:07:41 Z Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by relay1.sun.com with ESMTP id BT-MMP-3887033 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 04:07:41 Z Received: from web30805.mail.mud.yahoo.com ([68.142.200.148] [68.142.200.148]) by relay4i.sun.com id BT-MMP-2105508 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 04:07:41 Z Received: (qmail 44685 invoked by uid 60001); 29 May 2007 04:07:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oeXeLa8rF7ZZ4narQkv3r+ejN2XQ/EIxoNi/rJcvZsTvwwdhQhGuvytna1DdSk8SEudy3zTU8G6ja/n+qvuMLoxmCNluh64A5NM2s7k6m6T/JQC/NvNam5Z6H3io9Ly1jAHhOV7ffFIumqIfOQSRt1Srh/7CBTwWVaf5lsUNdc4=; X-YMail-OSG: W0az8jQVM1n3o5fU6yiVGQR_eSeknSUQqdcOTWaeicS0wqsZZ1YDs_OVHalSRbO62LaY90bqzfy.lrHIT2Y7hToQ3VtAtzoUfElOpCaM7sBtvRrgVxY- Received: from [71.2.179.191] by web30805.mail.mud.yahoo.com via HTTP; Mon, 28 May 2007 21:07:40 PDT Date: Mon, 28 May 2007 21:07:40 -0700 (PDT) From: Octave Orgeron Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] To: Peter Tribble , "Garrett D'Amore" Cc: psarc-ext@sac.sfbay.sun.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <543506.44650.qm@web30805.mail.mud.yahoo.com> Status: RO Content-Length: 3631 Hi Everyone, I'd like to point out that has a maintainer for the nicstatus script, having this information is critical for many systems administrators. It's important to be able to retrieve the following information: Auto-neg Link status Speed Duplex The most annoying problem today is that this information can not be obtained in a consistent manner. You have to use ndd or kstat to get this information. This has changed constantly with OS releases and patches. A recent example is how the auto-neg and link status info disappeared from kstat and went to ndd for the e1000g module in Solaris 10 Update 3. It's very challenging keeping up these this "flip-flop"ing of the interface information. I'd like to see dladm be the consistent and official interface for getting this critical information. Just thought, I'd put my $0.02 in on this:) Octave --- Peter Tribble wrote: > On 5/28/07, Garrett D'Amore wrote: > > Peter Tribble wrote: > > > On 5/27/07, Garrett D'Amore wrote: > > >> Of course, I suspect some sites were relying on this to provide > not > > >> historical information, but rather _current_ link state. That's > less of > > >> a problem now that we have dladm. > > > > > > It *should* be, modulo bug 6321504 which requires significant > > > privilege (far more than necessary) to view the current state. > > > Certainly at the present time I can't regard dladm as an > acceptable > > > method of determining link status. > > > > > > > Huh? Is the problem that you need to have root privilege to > determine > > link status? If we fixed _that_ problem, would you be happy? > > I would be happy that dladm were useful, which is a good thing. It > doesn't change my view that having speed and duplex in the > link up message is essential. > > > (I agree that root privilege should not be required to look at > existing > > link state.) > > > > As far as your earlier arguments go, a lot of the argument seems to > be > > based on pointing fingers and laying blame, rather than on _fixing_ > the > > root problem. > > It's finger pointing only insofar as it allows you to easily root > cause > the problem. Removing information makes it much harder to > administer systems - at present it's immediately obvious by visual > inspection of the logs that the link has bounced and has come up > correctly (or not...). With this change, the administrator then has > to > take additional manual steps to verify that the network parameters > are correct. And it then becomes impossible to determine which > out of a sequence of changes is the one that caused the problem, > as you lose all the history. > > This isn't just of theoretical interest: I've had a couple of > occasions > when the speed/duplex notification in the log was key in quickly > identifying and fixing a problem, and which would have been > significantly harder without it. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From jek3@sun.com Mon May 28 21:29:22 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T4TM9G019089 for ; Mon, 28 May 2007 21:29:22 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4T4S3wM794356; Mon, 28 May 2007 21:28:03 -0700 (PDT) Message-ID: <465BABC3.7000205@sun.com> Date: Mon, 28 May 2007 18:27:47 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Octave Orgeron CC: Peter Tribble , "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] References: <543506.44650.qm@web30805.mail.mud.yahoo.com> In-Reply-To: <543506.44650.qm@web30805.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 296 Octave Orgeron wrote: > A recent example is how the auto-neg and link status info > disappeared from kstat and went to ndd for the e1000g module in Solaris > 10 Update 3. Are you sure this disappearing act happened in Update 3 (or any update), I don't believe that should have happened. - jek3 From Garrett.Damore@Sun.COM Mon May 28 21:44:15 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T4iFMT019144 for ; Mon, 28 May 2007 21:44:15 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4T4gvEJ016398 for ; Mon, 28 May 2007 21:42:57 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T4gqg8029388 for ; Mon, 28 May 2007 21:42:52 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIS00001D22WW00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 21:42:52 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIS00FB5D3BK410@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 21:42:47 -0700 (PDT) Date: Mon, 28 May 2007 21:41:18 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <543506.44650.qm@web30805.mail.mud.yahoo.com> Sender: Garrett.Damore@Sun.COM To: Octave Orgeron Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465BAEEE.6080209@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <543506.44650.qm@web30805.mail.mud.yahoo.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4572 Octave Orgeron wrote: > Hi Everyone, > > I'd like to point out that has a maintainer for the nicstatus script, > having this information is critical for many systems administrators. > It's important to be able to retrieve the following information: > > Auto-neg > Link status > Speed > Duplex > > The most annoying problem today is that this information can not be > obtained in a consistent manner. You have to use ndd or kstat to get > this information. This has changed constantly with OS releases and > patches. A recent example is how the auto-neg and link status info > disappeared from kstat and went to ndd for the e1000g module in Solaris > 10 Update 3. It's very challenging keeping up these this "flip-flop"ing > of the interface information. I'd like to see dladm be the consistent > and official interface for getting this critical information. > Agreed wholeheartedly. For getting this information, a single, programmatic, reliable interface should be used. dladm (or libdladm()) should be that interface. (That said, I recently noticed that plans are afoot to obsolete dladm show-dev as part of clearview. I certainly hope they are going to provide a reasonable alternative, though I've not looked too closely.) For all GLDv3 drivers, the kstats are also a reasonably stable (PSARC covered, even, see ieee802.3(5)) interface. The fact that S10u3 busted this for e1000g seems like a bug to me. -- Garrett > Just thought, I'd put my $0.02 in on this:) > > Octave > > > --- Peter Tribble wrote: > > >> On 5/28/07, Garrett D'Amore wrote: >> >>> Peter Tribble wrote: >>> >>>> On 5/27/07, Garrett D'Amore wrote: >>>> >>>>> Of course, I suspect some sites were relying on this to provide >>>>> >> not >> >>>>> historical information, but rather _current_ link state. That's >>>>> >> less of >> >>>>> a problem now that we have dladm. >>>>> >>>> It *should* be, modulo bug 6321504 which requires significant >>>> privilege (far more than necessary) to view the current state. >>>> Certainly at the present time I can't regard dladm as an >>>> >> acceptable >> >>>> method of determining link status. >>>> >>>> >>> Huh? Is the problem that you need to have root privilege to >>> >> determine >> >>> link status? If we fixed _that_ problem, would you be happy? >>> >> I would be happy that dladm were useful, which is a good thing. It >> doesn't change my view that having speed and duplex in the >> link up message is essential. >> >> >>> (I agree that root privilege should not be required to look at >>> >> existing >> >>> link state.) >>> >>> As far as your earlier arguments go, a lot of the argument seems to >>> >> be >> >>> based on pointing fingers and laying blame, rather than on _fixing_ >>> >> the >> >>> root problem. >>> >> It's finger pointing only insofar as it allows you to easily root >> cause >> the problem. Removing information makes it much harder to >> administer systems - at present it's immediately obvious by visual >> inspection of the logs that the link has bounced and has come up >> correctly (or not...). With this change, the administrator then has >> to >> take additional manual steps to verify that the network parameters >> are correct. And it then becomes impossible to determine which >> out of a sequence of changes is the one that caused the problem, >> as you lose all the history. >> >> This isn't just of theoretical interest: I've had a couple of >> occasions >> when the speed/duplex notification in the log was key in quickly >> identifying and fixing a problem, and which would have been >> significantly harder without it. >> >> -- >> -Peter Tribble >> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> >> > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Octave J. Orgeron > Solaris Systems Engineer > http://www.opensolaris.org/os/community/sysadmin/ > http://unixconsole.blogspot.com > unixconsole@yahoo.com > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > ____________________________________________________________________________________Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > From John.Plocher@Sun.COM Mon May 28 21:53:33 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T4rXCp019281 for ; Mon, 28 May 2007 21:53:33 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4T4qG0j028330 for ; Mon, 28 May 2007 21:52:16 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T4qAQN029924 for ; Mon, 28 May 2007 21:52:11 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIS00301DH2W400@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 21:52:10 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIS00FHKDIYK510@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 21:52:10 -0700 (PDT) Date: Mon, 28 May 2007 21:52:01 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465A5429.1040701@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465BB171.8030102@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 693 Garrett D'Amore wrote: > Part of the problem is figuring out what detail is relevant. As you are the project lead for this proposal, I suggest that you take a stab at something - timestamp, link name, speed and duplex sure sounds like a great place to start - media type, tranceiver and loopback all seem less volatile, and thus less likely to be of interest when diagnosing faults.... > Hmm... good point. I hope SunMC isn't using this information (kstat The point is that syslog is an event notifier, while kstat is a polling mechanism. We certainly don't want a bunch of daemons in forever loops cycling thru long lists of kstats when watching syslog is sufficient... -John From Garrett.Damore@Sun.COM Mon May 28 22:02:06 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T526pF019640 for ; Mon, 28 May 2007 22:02:06 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4T50nZ4029657 for ; Mon, 28 May 2007 22:00:49 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T50hCl012852 for ; Mon, 28 May 2007 22:00:44 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIS00601DUH2400@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 22:00:43 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIS00FYFDX7K510@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 22:00:43 -0700 (PDT) Date: Mon, 28 May 2007 21:59:14 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Peter Tribble Cc: psarc-ext@sac.sfbay.sun.com Message-id: <465BB322.5030107@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4313 Peter Tribble wrote: > On 5/28/07, Garrett D'Amore wrote: >> Peter Tribble wrote: >> > On 5/27/07, Garrett D'Amore wrote: >> >> Of course, I suspect some sites were relying on this to provide not >> >> historical information, but rather _current_ link state. That's >> less of >> >> a problem now that we have dladm. >> > >> > It *should* be, modulo bug 6321504 which requires significant >> > privilege (far more than necessary) to view the current state. >> > Certainly at the present time I can't regard dladm as an acceptable >> > method of determining link status. >> > >> >> Huh? Is the problem that you need to have root privilege to determine >> link status? If we fixed _that_ problem, would you be happy? > > I would be happy that dladm were useful, which is a good thing. It > doesn't change my view that having speed and duplex in the > link up message is essential. > >> (I agree that root privilege should not be required to look at existing >> link state.) >> >> As far as your earlier arguments go, a lot of the argument seems to be >> based on pointing fingers and laying blame, rather than on _fixing_ the >> root problem. > > It's finger pointing only insofar as it allows you to easily root cause > the problem. Removing information makes it much harder to > administer systems - at present it's immediately obvious by visual > inspection of the logs that the link has bounced and has come up > correctly (or not...). "Immediately obvious" presupposes knowledge of the link partner. There is absolutely nothing wrong with running at half duplex if that is all the switch is capable, of, for example. > With this change, the administrator then has to > take additional manual steps to verify that the network parameters > are correct. And it then becomes impossible to determine which > out of a sequence of changes is the one that caused the problem, > as you lose all the history. > > This isn't just of theoretical interest: I've had a couple of occasions > when the speed/duplex notification in the log was key in quickly > identifying and fixing a problem, and which would have been > significantly harder without it. > I'm still not sure I buy this. If the link speed/duplex are wrong, there are _only_ two possibilities. Either the configuration the local system is incorrect, or the configuration on the switch is incorrect. I don't understand why you need historical information to make this determination. As far as I can tell, historical information is only useful to figure out which network admin you need to thwack for screwing up the configuration in the first place. Admittedly, I typically only deal with fairly simple link partners... i.e. I can usually readily tell what a switch is configured to be running at, as well as what it is currently running at ... usually this information is directly obvious via the management interfaces of the switch. I suppose if you have some very sophisticated equipment that has multiple configuration locations, any one of which could influence link settings, then it might be more tricky. I've no personal experience with such equipment, or even to suggest that such equipment exists. I also admit freely that historical information is not usually the _first_ place I look when trying to debug a problem... usually I look at the "direct observables"... in this it would be kstats or dladm, along with link lights and switch diagnostics, when debugging a problem. The other problem with relying on link historical data for this kind of debugging is that logs are inherently unreliable. (Was syslog running at the time the link status changed? Did the disk have enough room? Were network services working well enough to permit delivery of the message to any network log servers? Etc.) Particularly for historical data... most people rotate their logs (Solaris does this by default without administrative action to prevent it), such that on a reasonably busy system link status changes older than a week or two likely will be lost.) Anyway, its a fasttrack right now, and I'd encourage you to attend the PSARC meeting on Wednesday at 10am PDT, if you have any concerns that you feel aren't being fully considered here. -- Garrett From Garrett.Damore@Sun.COM Mon May 28 22:08:38 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T58cXp019825 for ; Mon, 28 May 2007 22:08:38 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4T57KVM021359 for ; Mon, 28 May 2007 22:07:20 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T57FwA013134 for ; Mon, 28 May 2007 22:07:15 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIS00801E57MN00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 22:07:15 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIS00FGYE83K220@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 28 May 2007 22:07:15 -0700 (PDT) Date: Mon, 28 May 2007 22:05:46 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465BB171.8030102@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465BB4AA.3040601@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1546 John Plocher wrote: > Garrett D'Amore wrote: >> Part of the problem is figuring out what detail is relevant. > > As you are the project lead for this proposal, I suggest that > you take a stab at something - timestamp, link name, speed and > duplex sure sounds like a great place to start - media type, > tranceiver and loopback all seem less volatile, and thus less > likely to be of interest when diagnosing faults.... I've actually suggested that all that is needed is the up/down status. Details on why, as well as link-specific properties, can be inquired via kstat or dladm. > >> Hmm... good point. I hope SunMC isn't using this information (kstat > > > The point is that syslog is an event notifier, while > kstat is a polling mechanism. We certainly don't want > a bunch of daemons in forever loops cycling thru long > lists of kstats when watching syslog is sufficient... Ah, but if asynchronous notification is needed from a program, then watching syslogs is most assuredly the _wrong_ way to do this. What you really want is an SNMP trap, or to arrange for receipt of the actual link status change message from the driver itself. I thought libdladm or libdlpi had support for this kind of asynchronous notification, but now I'm not so sure ... I can't seem to find any API for it. Another RFE? Also, right now, these applications will see the link up/down messages in the syslogs, and they can take whatever action they feel is appropriate when the syslogs indicate that such action is necessary. -- Garrett From al@logical-approach.com Tue May 29 03:38:34 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TAcYhO025551 for ; Tue, 29 May 2007 03:38:34 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TAbGee015024 for ; Tue, 29 May 2007 03:37:16 -0700 (PDT) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T9iOSi003031 for ; Tue, 29 May 2007 10:37:16 GMT Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay3.sun.com with ESMTP id BT-MMP-630417; Tue, 29 May 2007 10:36:57 Z Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms02es.sun.com with ESMTP id BT-MMP-81890; Tue, 29 May 2007 10:36:57 Z Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay4.sun.com with ESMTP id BT-MMP-4041413; Tue, 29 May 2007 10:36:57 Z Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l4TAau1O022254; Tue, 29 May 2007 05:36:56 -0500 (CDT) Date: Tue, 29 May 2007 05:36:56 -0500 (CDT) From: Al Hopper To: "Garrett D'Amore" cc: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <4659B8C5.5060607@sun.com> Message-Id: References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 4751 On Sun, 27 May 2007, Garrett D'Amore wrote: > Casper.Dik@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. > If the problem is audit of dladm changes (local changes), then dladm should > record this either in an audit log, or in syslog itself. I consider that > particular problem out-of-scope for this case, as well. This reads like you're giving someone a hammer and telling them it can only be used on nails. That may well have been the original designers intention. But everyone knows that a hammer has a 1000001 uses not involving nails! > On the other hand, for most networks, the only time link status will change > after boot will be when the hardware (remote or local) boots, there is a > change in the cable connectivity, or there is a configuration on one end or > the other. "only time"??? More likely an entirely different scenario that the original designers did'nt (and could not) anticipate! >> >>> For many links, the speed and duplex are not as trivial anyway. For >>> example, what information should be logged for a wlan? What about for an >>> aggregation? What about for a PPP link? IPoIB? Ad naseum. >>> >> >> Does an aggregation have a *link*? The underlying devices do have >> one; for WLAN too there is a link speed (but it's always half-duplex >> in a way) >> > > The aggregation has information which may be useful (e.g. which underlying > links are up, aggregate speed, etc.) For WLANs, maybe you care about SSID, > channel, WPA/WEP, link quality, etc. It gets hard to know what is needed > here. Right now _nothing_ is logged for these other link layers, whereas > this case proposes to start logging at least the overall link state. > > -- Garrett > Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From carlsonj@phorcys.east.sun.com Tue May 29 05:29:40 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TCTdPT026740 for ; Tue, 29 May 2007 05:29:40 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TCSLxk025297; Tue, 29 May 2007 08:28:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TCSLBC025294; Tue, 29 May 2007 08:28:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.7269.382049.584337@gargle.gargle.HOWL> Date: Tue, 29 May 2007 08:28:21 -0400 From: James Carlson To: "Garrett D'Amore" Cc: John Plocher , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465BB4AA.3040601@sun.com> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1765 Garrett D'Amore writes: > Ah, but if asynchronous notification is needed from a program, then > watching syslogs is most assuredly the _wrong_ way to do this. Indeed. The overall (common) format of syslog messages is fixed, but the program-driven content is _not_. There's no stability there at all, and we've historically treated syslog messages as even less than "not an interface." They've been treated as the equivalent of debugging printf messages -- as beneath architectural concern, and not even subject to L10N rules. In other words, it's possible to determine in a stable way that a given message came from some module at a particular time and contains some text string, but it's not possible to determine what the message actually means. Now, some might want to argue about whether that's a good thing (some other platforms may document and control messages; we don't), but it's long since been this way. Unless we're going to uproot 20+ years of Sun tradition here and write new rules about what things are "architectural," which I think is outside the scope of this case, I think the stability of syslog messages ought to be dropped as a discussion point. > What you > really want is an SNMP trap, or to arrange for receipt of the actual > link status change message from the driver itself. I thought libdladm > or libdlpi had support for this kind of asynchronous notification, but > now I'm not so sure ... I can't seem to find any API for it. Another RFE? Sysevents are designed for this purpose, not syslog. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Tue May 29 05:33:23 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TCXNtO026823 for ; Tue, 29 May 2007 05:33:23 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TCW472025351; Tue, 29 May 2007 08:32:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TCW49X025348; Tue, 29 May 2007 08:32:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.7492.850855.927545@gargle.gargle.HOWL> Date: Tue, 29 May 2007 08:32:04 -0400 From: James Carlson To: Al Hopper Cc: "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 598 Al Hopper writes: > 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. True, but quite lame. We need to find a better way of doing this. Though it's a fairly well understood usage, I think it'd look (at best) out of place in system documentation. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@eng.sun.com Tue May 29 07:55:27 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TEtRBr029420 for ; Tue, 29 May 2007 07:55:27 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TEs86X014346; Tue, 29 May 2007 07:54:08 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l4TEuLrT022884; Tue, 29 May 2007 07:56:21 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l4TEuKsR022883; Tue, 29 May 2007 07:56:20 -0700 (PDT) Date: Tue, 29 May 2007 07:56:20 -0700 (PDT) From: Gary Winiger Message-Id: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> To: Garrett.Damore@Sun.COM, John.Plocher@Sun.COM Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: peter.tribble@gmail.com, psarc-ext@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 520 John, > > Hmm... good point. I hope SunMC isn't using this information (kstat > > > The point is that syslog is an event notifier, while > kstat is a polling mechanism. We certainly don't want > a bunch of daemons in forever loops cycling thru long > lists of kstats when watching syslog is sufficient... I disagree with the implication that there's anything that can be relied on as syslog messages. They are all Non-An-Interface. If humans wish to consume syslog messages, that's up to the human. Gary.. From Darren.Moffat@Sun.COM Tue May 29 09:20:48 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TGKlvZ003694 for ; Tue, 29 May 2007 09:20:48 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TGJSbu025610 for ; Tue, 29 May 2007 09:19:29 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TGJMk6004259 for ; Tue, 29 May 2007 16:19:23 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00B0198K9R00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 17:19:22 +0100 (BST) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT005GL9CACF00@d1-emea-10.sun.com>; Tue, 29 May 2007 17:19:22 +0100 (BST) Date: Tue, 29 May 2007 17:19:22 +0100 From: Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: Garrett.Damore@Sun.COM, John.Plocher@Sun.COM, peter.tribble@gmail.com, psarc-ext@sac.sfbay.sun.com Message-id: <465C528A.6020804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 1563 Gary Winiger wrote: > John, > >>> Hmm... good point. I hope SunMC isn't using this information (kstat >> >> The point is that syslog is an event notifier, while >> kstat is a polling mechanism. We certainly don't want >> a bunch of daemons in forever loops cycling thru long >> lists of kstats when watching syslog is sufficient... > > I disagree with the implication that there's anything > that can be relied on as syslog messages. They are all > Non-An-Interface. If humans wish to consume syslog > messages, that's up to the human. We can argue this indefinitely but regardless of what some PSARC members think admins, developers on Solaris and other platforms act differently. While some may claim that syslog messages are not intended to be interfaces the fact of the matter is that they are because sometimes thats the only interface that gives that critical information in a timely manner. I'd go further and assert that some messages logged by certain parts of Solaris are so well known that they are effectively Committed interfaces. The messages that this case talks about are ones I'd put in this set. Unless this case intends to provide all of the same information for the drivers that will be changed then I believe this is an unacceptable regression regardless of what better tools are out there. As I read it the intent of this case is to centralise the logging not to deprecated it or reduce it, so it should provide identical information and as close as possible the exact same format of message. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Tue May 29 09:31:27 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TGVROG003942 for ; Tue, 29 May 2007 09:31:27 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TGU7H3001939; Tue, 29 May 2007 12:30:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TGU7qt001936; Tue, 29 May 2007 12:30:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.21775.45649.572535@gargle.gargle.HOWL> Date: Tue, 29 May 2007 12:30:07 -0400 From: James Carlson To: Darren J Moffat Cc: Gary Winiger , Garrett.Damore@Sun.COM, John.Plocher@Sun.COM, peter.tribble@gmail.com, psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C528A.6020804@Sun.COM> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1427 Darren J Moffat writes: > We can argue this indefinitely but regardless of what some PSARC members > think admins, developers on Solaris and other platforms act differently. Regardless of how they act, we don't apply any engineering towards making their actions supportable. Like debug printfs, nobody ever demands that changes in syslog messages be run past ARC. That's just life. They change all the time, including in patches. Unless we start doing the engineering necessary to make what those users are doing actually supportable in some way, it really doesn't matter what they're doing. The message contents are not documented, and what they're doing is clearly in the realm of hackery. > While some may claim that syslog messages are not intended to be > interfaces the fact of the matter is that they are because sometimes > thats the only interface that gives that critical information in a > timely manner. Sorry, no. I see no plausible way that we could get there, and I don't think making such an assertion should be part of this case. I completely agree that we've got huge holes in the system here, but nailing syslog messages to the wall isn't a reasonable way to fill them. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sebastien.Roy@Sun.COM Tue May 29 09:33:35 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TGXZF0003977 for ; Tue, 29 May 2007 09:33:35 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TGWG1r027842 for ; Tue, 29 May 2007 09:32:17 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TGWGtR026651 for ; Tue, 29 May 2007 16:32:16 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00H019WUPC00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 10:32:16 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT0069F9WRJ8MV@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 10:31:41 -0600 (MDT) Date: Tue, 29 May 2007 12:31:26 -0400 From: Sebastien Roy Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465BAEEE.6080209@sun.com> Sender: Sebastien.Roy@Sun.COM To: "Garrett D'Amore" Cc: Octave Orgeron , Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465C555E.3070003@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <543506.44650.qm@web30805.mail.mud.yahoo.com> <465BAEEE.6080209@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 734 Garrett D'Amore wrote: > (That said, I recently noticed that plans are afoot to obsolete dladm > show-dev as part of clearview. I certainly hope they are going to > provide a reasonable alternative, though I've not looked too closely.) You'll get a chance to look closely. That part of Clearview (2006/499) is scheduled for commitment review on June 20th. In any case (no pun intended), Clearview plans to obsolete show-dev (but keep it for now for backward compatibility), and replace it with show-phys which will have information such as media type, link state, link speed, duplex state, etc... This is part of 2006/499 and not this case, so any comments on this should be made as part of the review of 2006/499. -Seb From Darren.Moffat@Sun.COM Tue May 29 09:42:54 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TGgsJ1004091 for ; Tue, 29 May 2007 09:42:54 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TGfZOU007009 for ; Tue, 29 May 2007 09:41:35 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TGfTcm006031 for ; Tue, 29 May 2007 16:41:29 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00301A99PT00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 17:41:29 +0100 (BST) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT005I7AD5CF00@d1-emea-10.sun.com>; Tue, 29 May 2007 17:41:29 +0100 (BST) Date: Tue, 29 May 2007 17:41:29 +0100 From: Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <18012.21775.45649.572535@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Gary Winiger , Garrett.Damore@Sun.COM, John.Plocher@Sun.COM, peter.tribble@gmail.com, psarc-ext@sac.sfbay.sun.com Message-id: <465C57B9.9040004@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 916 James Carlson wrote: > Darren J Moffat writes: >> We can argue this indefinitely but regardless of what some PSARC members >> think admins, developers on Solaris and other platforms act differently. > > Regardless of how they act, we don't apply any engineering towards > making their actions supportable. and there in lies the problem, we are not meeting customer needs here. Customers and partners really just don't care about that, we know they build stuff on top of syslog. They expect to build stuff ontop of syslog on all platforms not just Solaris. IMO we need to take the fingers out of our ears and stop just saying "la la la la la la" everything this comes up and ignoring what the customers use and we know they use. What I'm saying for *this* case is that a reduction in the information presented is a problem and for me it means that this case doesn't meet its goals. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Tue May 29 10:03:09 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TH39VA005411 for ; Tue, 29 May 2007 10:03:09 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TH1otp002100; Tue, 29 May 2007 13:01:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TH1kgq002095; Tue, 29 May 2007 13:01:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.23674.549208.885858@gargle.gargle.HOWL> Date: Tue, 29 May 2007 13:01:46 -0400 From: James Carlson To: Darren J Moffat Cc: John.Plocher@Sun.COM, psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Gary Winiger Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C57B9.9040004@Sun.COM> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2434 Darren J Moffat writes: > James Carlson wrote: > > Darren J Moffat writes: > >> We can argue this indefinitely but regardless of what some PSARC members > >> think admins, developers on Solaris and other platforms act differently. > > > > Regardless of how they act, we don't apply any engineering towards > > making their actions supportable. > > and there in lies the problem, we are not meeting customer needs here. > Customers and partners really just don't care about that, we know they > build stuff on top of syslog. They expect to build stuff ontop of > syslog on all platforms not just Solaris. IMO we need to take the > fingers out of our ears and stop just saying "la la la la la la" > everything this comes up and ignoring what the customers use and we know > they use. ... and then what, exactly? Abandon all engineering sense and say, "sure, you can scrape strings out of files that were clearly intended for humans and depend on them?" I thought we were supposed to be setting system architecture here. That sure doesn't sound like any kind of supportable architecture. In any event, if you think that's the right thing to do because it appeals to our customer's needs, then I think we need to have a new policy written. The policy should inform future projects (and C-team members and the PAC) that henceforth _all_ changes to debug messages will be considered architectural matters, and that project teams are required to have these reviewed -- and likely forced to higher stability levels, in order to meet these "customer needs." I don't think that's the right way to go, but that's clearly a different case. > What I'm saying for *this* case is that a reduction in the information > presented is a problem and for me it means that this case doesn't meet > its goals. Given that they're merely debug messages, I don't really see the problem you see. I agree that we ought to have historical event information ("errpt" anyone?), and even that dladm would be a good way to present it. I'm not sure I agree that boiling away this particular ocean should be necessary to clean up what is (at best) a haphazard collection of semi-usable and mostly-harmful syslog messages. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Kais.Belgaied@Sun.COM Tue May 29 10:33:34 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4THXY9d006643; Tue, 29 May 2007 10:33:34 -0700 (PDT) Received: from [129.145.154.97] (sr1-umpk-47.SFBay.Sun.COM [129.145.154.97]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4THWGAM900332; Tue, 29 May 2007 10:32:16 -0700 (PDT) Message-ID: <465C63A0.4000805@Sun.COM> Date: Tue, 29 May 2007 10:32:16 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: "Garrett D'Amore - sun microsystems" CC: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> In-Reply-To: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1296 >Problem >------- > >Various network drivers are inconsistent in their handling of logging of >link messages. One of the more annoying things that some drivers do is >flood the logs with link down messages (usually once every 10sec or so) when >trying to transmit packets out the link. > > The root cause of the problem as you describe seems to be the fact that the stack above kept submitting the packets to a link that is known to be down, causing the flood of syslogs. Somehow the event of link-down was not generated, lost during the notification, or mishandled. That is a bug to be fixed between the stack and the specific drivers you observed the misbehavior on. The bug is probably below the radar screen for ARC. Now, back the the symptoms (scope of this case): Each futile submission of a packet to be transmitted on a link down indicates a problem worth paying attention to. It could be uncovering a bug such as the above, or it could be transient race. I don't believe it is a bad practice from driver writers to adopt a defensive approach and log an error on every occurrence of the offense. Kais >Further, the detailed contents for link status changes are not consistent >from one driver to another. > >Notably, the WIFI drivers generally do not do this. > > > From John.Plocher@Sun.COM Tue May 29 10:47:56 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4THluFE006962 for ; Tue, 29 May 2007 10:47:56 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4THkbOa022301 for ; Tue, 29 May 2007 10:46:37 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4THkW34018249 for ; Tue, 29 May 2007 10:46:32 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00E01DCGCF00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 10:46:32 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00F5CDDJK4J1@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 10:46:32 -0700 (PDT) Date: Tue, 29 May 2007 10:46:23 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465BB4AA.3040601@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465C66EF.2000805@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1821 Garrett D'Amore wrote: > Also, right now, these applications will see the link up/down messages > in the syslogs, and they can take whatever action they feel is > appropriate when the syslogs indicate that such action is necessary. I think you are missing the point. Sure, one could do all that extra work to figure out what is really happening after they see an obfuscated and truncated teaser message in syslog. But why should we go out of our way to make things harder for admins? Better that we ensure that we record useful and relevant info, especially when we have it at our fingertips at the time. What is syslog for? Why do we even log messages - heck, if a sysadmin really wanted to know about the state of the system, they could just use dladm, ifconfig, ping, traceroute, snoop, SNMP traps, dtrace and truss. After all, if you don't know how to use those tools, you should be banished to a Linux system where you are forced to use GNUtar with Bash :-) Have you ever used Splunk (www.splunk.com) to manage a system? If not, stop reading this and go get a free copy and play with it. It isn't the only or best way to admin complex systems, but it shows what can be done with simple logfile analysis. Combining web logs with syslog (with ...) lets me do the root cause analysis to find out WHY a problem is happening - even if the problem itself wasn't obvious at the time. Please find a way to keep this useful info in the network interface messages. The cost of putting it there will be significantly (IMHO several orders of magnitude) smaller than the time and effort saved at only one customer site by having it there. Yes, this implies that the network drivers will all need a similar set of kstats (or whatever) for this to work; also a small effort when compared to the benefits. -John From John.Plocher@Sun.COM Tue May 29 11:27:39 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TIRdbH008443 for ; Tue, 29 May 2007 11:27:39 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TIQLZc016166 for ; Tue, 29 May 2007 11:26:21 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TIQGpV023570 for ; Tue, 29 May 2007 11:26:16 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00G01F7Q8X00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 11:26:15 -0700 (PDT) Received: from [192.168.168.4] ([66.166.204.98]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT006JEF7QHAK7@d1-sfbay-10.sun.com>; Tue, 29 May 2007 11:26:15 -0700 (PDT) Date: Tue, 29 May 2007 11:26:06 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <18012.23674.549208.885858@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: Darren J Moffat , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Gary Winiger Message-id: <465C703E.2020104@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 2635 James Carlson wrote: > ... and then what, exactly? Abandon all engineering sense This sounds like an overreaction. We /know/ that people depend on the debugging messages found in syslog so that they can DEBUG their systems. Those messages are generated so that customers can debug problems on their systems. They are not in the same class as debugging printf()s in prototype code, although some coders use the facility for that purpose. It behooves US to consider how our customers use this resource so that we can ensure that it best meets their needs. We /know/ that sysadmins depend on this info. We /know/ that it is often used as a first step in diagnosing complex problems. We /know/ that having more information makes it easier to get a handle on the unknown. With all that knowledge, why is it that we want to make things harder for our customers by removing valuable clues from that repository? Oh, because it isn't an interface; humans don't matter and it isn't "pure architecture"? > In any event, if you think that's the right thing to do because it > appeals to our customer's needs, then I think we need to have a new > policy written. We already have such policies. One comes under the heading "make Solaris easier to use", another says, in effect, "don't violate customer's expectations". We tend to call the latter "being Netscape'd". It doesn't matter what we intended for an interface - if Netscape glommed onto it, we can not change it - it effectively is promoted to a Committed interface. I wouldn't go so far as to say every message in syslog was now a Committed API, but I do feel that the diagnostic payload for many of the messages is, as a human consumable interface, absolutely Committed. As such, removing significant info from the payload is a regression, and should be avoided when possible. And, in this case, it certainly seems to be easily possible. > Given that they're merely debug messages, I don't really see the > problem you see. I used to be able to debug problem, now I can no longer do so. No APIs, no script breakage, just a system that is not performing as expected, and an admin who is now less able to understand the context, pinpoint the problem and fix it. > I agree that we ought to have historical event information ("errpt" For better or for worse, ssylog is that medium for many of our customers. > clean up what is (at best) a haphazard collection of > semi-usable and mostly-harmful syslog messages. Mostly harmful? In the scope of this case, how is having link status, speed and duplex considered harmful - or even only semi-usable? -John From carlsonj@phorcys.east.sun.com Tue May 29 12:10:51 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TJAoGK010170 for ; Tue, 29 May 2007 12:10:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TJ9VBS002672; Tue, 29 May 2007 15:09:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TJ9Vje002669; Tue, 29 May 2007 15:09:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.31338.843884.679817@gargle.gargle.HOWL> Date: Tue, 29 May 2007 15:09:30 -0400 From: James Carlson To: John Plocher Cc: Gary Winiger , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C703E.2020104@Sun.Com> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3911 John Plocher writes: > James Carlson wrote: > > ... and then what, exactly? Abandon all engineering sense > > This sounds like an overreaction. So where in any of our documentation do we make the contents of those messages any sort of stable interface? > We /know/ that people depend on the debugging messages found in > syslog so that they can DEBUG their systems. Those messages are > generated so that customers can debug problems on their systems. Indeed. > They are not in the same class as debugging printf()s in prototype > code, although some coders use the facility for that purpose. > > It behooves US to consider how our customers use this resource > so that we can ensure that it best meets their needs. I agree with that. However, it doesn't mean that we need to enshrine hackery. > We /know/ that sysadmins depend on this info. We /know/ that > it is often used as a first step in diagnosing complex problems. > We /know/ that having more information makes it easier to get > a handle on the unknown. > > With all that knowledge, why is it that we want to make things > harder for our customers by removing valuable clues from that > repository? > > Oh, because it isn't an interface; humans don't matter and it > isn't "pure architecture"? How about "wrong tool for the job?" > > In any event, if you think that's the right thing to do because it > > appeals to our customer's needs, then I think we need to have a new > > policy written. > > We already have such policies. One comes under the heading "make > Solaris easier to use", another says, in effect, "don't violate > customer's expectations". The only policy we have regarding syslog messages (as far as I know) is that they're in the same class as other debugging messages -- plain old text, no need for L10N or other translation support, and changes aren't treated as worthy of architectural review. So, are all of the data structures touched by "lsof" also automatically Committed? I'd like to know how far this new policy might extend. > We tend to call the latter "being Netscape'd". It doesn't matter > what we intended for an interface - if Netscape glommed onto it, > we can not change it - it effectively is promoted to a Committed > interface. You'd argue that for syslog? If so, then we have a major disconnect here. The engineering work necessary to make that happen just isn't being done. > I wouldn't go so far as to say every message in syslog was now a > Committed API, but I do feel that the diagnostic payload for many > of the messages is, as a human consumable interface, absolutely > Committed. As such, removing significant info from the payload > is a regression, and should be avoided when possible. And, in this > case, it certainly seems to be easily possible. I can't easily parse that statement. I can't make sense out of "as a human consumable interface, absolutely Committed." "Committed" means that we will provide suitable reference documentation (such as man pages). We don't have that. It also means that other projects can consume it without restriction. We don't have that either so long as those "other projects" apparently have to run on top of humans rather than on computers. > Mostly harmful? In the scope of this case, how is having > link status, speed and duplex considered harmful - or even > only semi-usable? Links flapping in the breeze cause log files to fill and overflow with garbage, causing users to be unable to find any relevant messages, and sometimes causing file systems to fill up. Different drivers issue completely different messages in different contexts, and these cause customers to get annoyed or confused. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From daleg@elemental.org Tue May 29 12:38:52 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TJcqGA010427 for ; Tue, 29 May 2007 12:38:52 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TJbXtV024250 for ; Tue, 29 May 2007 12:37:33 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l4TJbTGP000401 for ; Tue, 29 May 2007 19:37:33 GMT Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay22.sun.com with ESMTP id BT-MMP-273257; Tue, 29 May 2007 19:37:28 Z Received: from mms23bas.mms.us.syntegra.com (relay23.mms.us.syntegra.com [192.12.251.50]) by mms25es.sun.com with ESMTP id BT-MMP-339609; Tue, 29 May 2007 19:37:28 Z Received: from lithium.elemental.org ([130.85.5.200] [130.85.5.200]) by relay23.sun.com with ESMTP id BT-MMP-3739342; Tue, 29 May 2007 19:37:28 Z Received: from [130.85.70.33] (deuterium.ucs.umbc.edu [130.85.70.33]) (authenticated bits=0) by lithium.elemental.org (8.13.8/8.13.8/ELEMENTAL-3.1) with ESMTP id l4TJbRk0001328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2007 15:37:27 -0400 (EDT) In-Reply-To: <18012.31338.843884.679817@gargle.gargle.HOWL> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: John Plocher , Darren J Moffat , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Gary Winiger Content-Transfer-Encoding: 7bit From: Dale Ghent Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Date: Tue, 29 May 2007 15:37:26 -0400 To: James Carlson X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (lithium.elemental.org [130.85.5.200]); Tue, 29 May 2007 15:37:27 -0400 (EDT) Status: RO Content-Length: 2005 On May 29, 2007, at 3:09 PM, James Carlson wrote: > John Plocher writes: >> James Carlson wrote: >>> ... and then what, exactly? Abandon all engineering sense >> >> This sounds like an overreaction. > > So where in any of our documentation do we make the contents of those > messages any sort of stable interface? It's *syslog* we're talking about here. If one feels the need to syslog something, they're unwittingly (or purposefully) committing themselves to a /de facto/ Public interface. There's nothing the kernel does with the text, and syslog isn't there to fill disk space. Just like the words you write in this PSARC thread, stuff in syslog is on the Public record, read by Joe Admin and scraped by Jane Developer. Moral of the story: be careful what you say (read: log) because it may come back to haunt you. Considering the intended audience of syslog's output, and how long these network status messages have been around in particular, it might be prudent to yield away from "pure architecture" (as someone put it) in this case and not try to close the barn door... not only because the horse has already left, but you'll be shutting it on a lot of users' feets. The best thing to do is to get a centralized logging framework implemented under GLD (so logging across disparate drivers is at least consistent) and live with what has been habit for so long in terms of the log content. There's a battle between architecture and consistency here. Each have their strengths and good points, but when the two come into conflict it's best to see things in the larger context of what the thingy is. In this particular case, I would vote for consistency over architecture, with a compromise favoring the latter. Keep the logged text consistent with history, and move logging into GLD. Hell, I'd say if there was a way to refuse to load a LAN driver that does anything above cmn_err(CE_PANIC,...) , we should. /dale From John.Plocher@Sun.COM Tue May 29 13:26:32 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKQW5n011521 for ; Tue, 29 May 2007 13:26:32 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TKPCQd020133 for ; Tue, 29 May 2007 13:25:12 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKP7OD024545 for ; Tue, 29 May 2007 13:25:07 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00501KP13Q00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:25:07 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FIKKPUK5E2@d1-sfbay-09.sun.com>; Tue, 29 May 2007 13:25:06 -0700 (PDT) Date: Tue, 29 May 2007 13:24:57 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <18012.31338.843884.679817@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: Gary Winiger , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Darren J Moffat Message-id: <465C8C19.1020707@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 1009 James Carlson wrote: > Links flapping in the breeze cause log files to fill and overflow with > garbage, causing users to be unable to find any relevant messages, and > sometimes causing file systems to fill up. As Kais said, links flapping in the wind sounds like a bug in that an upstream packer generator isn't being informed of a link-down event. Fix the bug. In addition, this proposal addresses the "fills log" symptom as well. If links are flapping in the wind because of some external misconfiguration, why wouldn't you want to tell someone? > Different drivers issue completely different messages in different > contexts, and these cause customers to get annoyed or confused. So, improve those drivers as well. This is an opportunity to improve the debugging of our systems at little to no cost - it should be a no brainer. And it should not preclude improving other parts of the system as well - having tools other than syslog is a Good Thing - they are not exclusive choices! -John From carlsonj@phorcys.east.sun.com Tue May 29 13:35:02 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKZ2lT011800 for ; Tue, 29 May 2007 13:35:02 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TKXg5v003084; Tue, 29 May 2007 16:33:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TKXggB003081; Tue, 29 May 2007 16:33:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.36390.449748.271114@gargle.gargle.HOWL> Date: Tue, 29 May 2007 16:33:42 -0400 From: James Carlson To: John Plocher Cc: Gary Winiger , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C8C19.1020707@Sun.Com> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <465C8C19.1020707@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1862 John Plocher writes: > James Carlson wrote: > > Links flapping in the breeze cause log files to fill and overflow with > > garbage, causing users to be unable to find any relevant messages, and > > sometimes causing file systems to fill up. > > > As Kais said, links flapping in the wind sounds like a bug in that > an upstream packer generator isn't being informed of a link-down > event. Fix the bug. In addition, this proposal addresses the "fills > log" symptom as well. No. That's a misunderstanding. I fully agree that persistent "link still down" messages are application bugs that need to be fixed. I'm talking about the case where a misconfigured link goes up and down rapidly over time, even with no traffic at all present. > If links are flapping in the wind because of some external > misconfiguration, why wouldn't you want to tell someone? Yes. Just not at the rate of dozens or hundreds of messages per second. > > Different drivers issue completely different messages in different > > contexts, and these cause customers to get annoyed or confused. > > So, improve those drivers as well. That's exactly what's going on here. We need commonality in order to improve at all. Trying to fix those drivers piecemeal to do something better is *exactly* the strategy that got us into the mess we're in. > This is an opportunity to > improve the debugging of our systems at little to no cost - it > should be a no brainer. And it should not preclude improving > other parts of the system as well - having tools other than > syslog is a Good Thing - they are not exclusive choices! Nor did I suggest otherwise. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@Sun.COM Tue May 29 13:40:16 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKeFVA011855 for ; Tue, 29 May 2007 13:40:15 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TKcvjX025689 for ; Tue, 29 May 2007 13:38:57 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKcqhR026168 for ; Tue, 29 May 2007 13:38:52 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00K01L7JLN00@d1-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:38:52 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00666LCRHCA5@d1-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:38:52 -0700 (PDT) Date: Tue, 29 May 2007 13:37:21 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Al Hopper Cc: psarc-ext@sac.sfbay.sun.com Message-id: <465C8F01.7070200@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 3389 Al Hopper wrote: > On Sun, 27 May 2007, Garrett D'Amore wrote: > >> Casper.Dik@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 From Nicolas.Williams@sun.com Tue May 29 13:40:41 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKeftp011894 for ; Tue, 29 May 2007 13:40:41 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TKbvZV029321; Tue, 29 May 2007 15:37:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TKbvPx029320; Tue, 29 May 2007 15:37:57 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 15:37:57 -0500 From: Nicolas Williams To: James Carlson Cc: John Plocher , Darren J Moffat , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@sun.com, Gary Winiger Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529203756.GW27420@Sun.COM> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18012.31338.843884.679817@gargle.gargle.HOWL> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3081 On Tue, May 29, 2007 at 03:09:30PM -0400, James Carlson wrote: > John Plocher writes: > > Mostly harmful? In the scope of this case, how is having > > link status, speed and duplex considered harmful - or even > > only semi-usable? > > Links flapping in the breeze cause log files to fill and overflow with > garbage, causing users to be unable to find any relevant messages, and > sometimes causing file systems to fill up. > > Different drivers issue completely different messages in different > contexts, and these cause customers to get annoyed or confused. Since this particular case merely removes items from log messages, rather than removing log messages, and given the strong opinions stated so far in favor of keeping the information that would be removed, what is the harm of keeping said information in said log messages? Whatever the interface status of log messages, if it's easy for us to keep the messages as they are/were then we should. If a case were to propose replacing one system component with a different implementation, particularly an implementation done outside Sun, then the effort to ensure that the new implementation has the same/ similar log messages as/to the old implementation would likely be prohibitive, and we could then invoke the "log messages are not an interface" dictum. As for whether the "log messages are not an interface" dictum applies here, they most certainly are at least intended for human consumption, and humans do consume these particular messages, so "log messages are not an interface" seems inappropriate to invoke here. Telling users to use some other tool to get additional information related to specific log messages seems more than OK to me, particularly for new messages or rarely used old messages. But in this case the messages in question are: a) old, b) very commnly relied-upon by users; this makes the proposed change more like a regression than like progress. Now, from the i-team's p.o.v., moving logging of link state changes from the driver to the framework may be simple, while similarly moving logging of speed/ duplicity change logging, and adding link state, speed and/or duplicity data to these log messages may be not so simple. This may be because the method by which the driver informs the framework of such changes does not allow the driver to provide all that information to the framework, so then the framework must go query the driver to get the remaining data so it can be logged -- logging the call from the driver and its arguments being easy while querying other device state from the driver not. But that's still a lot less effort than retrofitting a new implementation with log messages to match an old one. So don't break the customer's expectations -- it does not seem difficult to meet them in this case. Alternative: don't move the logging to the framework. If the motivation for the move was consistency across drivers then perhaps a common framework log routine for each media type would be better (e.g., ethernet would log link state, speed and duplicity). Nico -- From carlsonj@phorcys.east.sun.com Tue May 29 13:41:00 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKexvg011928 for ; Tue, 29 May 2007 13:41:00 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4TKdeLW003101; Tue, 29 May 2007 16:39:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4TKde9f003098; Tue, 29 May 2007 16:39:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18012.36748.60045.403116@gargle.gargle.HOWL> Date: Tue, 29 May 2007 16:39:40 -0400 From: James Carlson To: Dale Ghent Cc: John Plocher , Darren J Moffat , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Gary Winiger Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2560 Dale Ghent writes: > On May 29, 2007, at 3:09 PM, James Carlson wrote: > > > John Plocher writes: > >> James Carlson wrote: > >>> ... and then what, exactly? Abandon all engineering sense > >> > >> This sounds like an overreaction. > > > > So where in any of our documentation do we make the contents of those > > messages any sort of stable interface? > > It's *syslog* we're talking about here. If one feels the need to > syslog something, they're unwittingly (or purposefully) committing > themselves to a /de facto/ Public interface. There's nothing the > kernel does with the text, and syslog isn't there to fill disk space. > Just like the words you write in this PSARC thread, stuff in syslog > is on the Public record, read by Joe Admin and scraped by Jane > Developer. Moral of the story: be careful what you say (read: log) > because it may come back to haunt you. The whole point of having the ARC is essentially the opposite of what you're suggesting. Instead of "assuming" that someone meant to allow me to use something in my application merely because "it's out there," we require every project to declare _explicitly_ what things can be depended upon, and in what context they can be held to be reliable. Those explicit bits that are in fact "Public" must (in Solaris) have man pages. That's exactly the point. Nobody has promised to provide anything other than human (English only!) readable messages here. The contents of the messages are no kind of programming interface. They're not documented anywhere. They change arbitrarily all the time -- including in patches -- and they do so without any warning or even engineering review of any kind. Programs that depend on them are engaging in hackery. I admit that Sun has done a lousy job providing suitable interfaces here. That's clearly our fault. That still does not mean that debug messages are automatically nailed to the wall. > The best thing to do is to get a centralized logging framework > implemented under GLD (so logging across disparate drivers is at > least consistent) and live with what has been habit for so long in > terms of the log content. That's exactly what this case is attempting to accomplish. The first step is getting those logging messages into the framework where (if they exist at all) they belong. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@Sun.COM Tue May 29 13:49:34 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKnYFL011997 for ; Tue, 29 May 2007 13:49:34 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TKmFKh008152 for ; Tue, 29 May 2007 13:48:15 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKmAMl009474 for ; Tue, 29 May 2007 13:48:10 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00H01LS1Y400@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:48:10 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FORLS9K2Z2@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:48:10 -0700 (PDT) Date: Tue, 29 May 2007 13:46:39 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465C555E.3070003@sun.com> Sender: Garrett.Damore@Sun.COM To: Sebastien Roy Cc: Octave Orgeron , Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465C912F.8020308@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <543506.44650.qm@web30805.mail.mud.yahoo.com> <465BAEEE.6080209@sun.com> <465C555E.3070003@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 889 Sebastien Roy wrote: > Garrett D'Amore wrote: >> (That said, I recently noticed that plans are afoot to obsolete dladm >> show-dev as part of clearview. I certainly hope they are going to >> provide a reasonable alternative, though I've not looked too closely.) > > You'll get a chance to look closely. That part of Clearview > (2006/499) is scheduled for commitment review on June 20th. > > In any case (no pun intended), Clearview plans to obsolete show-dev > (but keep it for now for backward compatibility), and replace it with > show-phys which will have information such as media type, link state, > link speed, duplex state, etc... This is part of 2006/499 and not > this case, so any comments on this should be made as part of the > review of 2006/499. Thanks, and I've gone ahead and read the proposal there as well ... it all looks good to me. :-) -- Garrett From Nicolas.Williams@sun.com Tue May 29 13:52:16 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKqGmk012070 for ; Tue, 29 May 2007 13:52:16 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TKnWQt029334; Tue, 29 May 2007 15:49:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TKnW63029333; Tue, 29 May 2007 15:49:32 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 15:49:32 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Al Hopper , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529204931.GX27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C8F01.7070200@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1144 On Tue, May 29, 2007 at 01:37:21PM -0700, Garrett D'Amore wrote: > Al Hopper wrote: > >>Casper.Dik@Sun.COM wrote: > > > >You seem to be missing the point - syslogging the interface name with > >speed and duplicity is useful in a couple of very practical ways: > > > >[SNIPPED: three cases not needing speed and duplicity info] > > > >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. Yes, but others have given cases where speed and duplicity information is useful. > 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. It doesn't. Nico -- From Garrett.Damore@Sun.COM Tue May 29 13:54:37 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKsbCV012460 for ; Tue, 29 May 2007 13:54:37 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TKrJqH012119 for ; Tue, 29 May 2007 13:53:19 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKrE6g010033 for ; Tue, 29 May 2007 13:53:14 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00401LVIOL00@d1-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 13:53:14 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT006TDM0PH9L2@d1-sfbay-10.sun.com>; Tue, 29 May 2007 13:53:13 -0700 (PDT) Date: Tue, 29 May 2007 13:51:43 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465C57B9.9040004@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Darren J Moffat Cc: James Carlson , Gary Winiger , John.Plocher@Sun.COM, peter.tribble@gmail.com, psarc-ext@sac.sfbay.sun.com Message-id: <465C925F.8070205@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2367 Darren J Moffat wrote: > James Carlson wrote: >> Darren J Moffat writes: >>> We can argue this indefinitely but regardless of what some PSARC >>> members think admins, developers on Solaris and other platforms act >>> differently. >> >> Regardless of how they act, we don't apply any engineering towards >> making their actions supportable. > > and there in lies the problem, we are not meeting customer needs here. > Customers and partners really just don't care about that, we know they > build stuff on top of syslog. They expect to build stuff ontop of > syslog on all platforms not just Solaris. IMO we need to take the > fingers out of our ears and stop just saying "la la la la la la" > everything this comes up and ignoring what the customers use and we > know they use. > > What I'm saying for *this* case is that a reduction in the information > presented is a problem and for me it means that this case doesn't meet > its goals. > But for existing customers, the existing information was not provided in anything remotely resembling a consistent manner. Each driver did its own thing. For a customer/application to have depended on this kind of information would have been utterly insane, if they wanted the application to work with different NICs, etc. I have investigated, and I can provide this information without too much pain, but I still disagree with it in principle. The reason for this is that today the mac layer knows nothing about many of these link details, and it really doesn't need to. Furthermore, there are reasonable situations where the link speed can change without generating any kind of notification. (The typical example being link speed adjustments that are done on 802.11 links.) If folks really really want this information for 802.3 links, we can do it. I just don't think its reasonable. I also think, most tools just want an "up" or "down" notification (not details on speed or duplex), so very few are likely to be negatively impacted (other than they will have to adjust their scripts/tools to recognize the new "up" and "down" messages, but then one format will cover _all_ GLDv3 NIC drivers. Note that some NIC drivers don't even bother to log this at all. For example, 802.11 drivers do no link state logging whatsoever. My case would add this for those drivers. -- Garrett From Garrett.Damore@Sun.COM Tue May 29 13:56:47 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TKuktj012480; Tue, 29 May 2007 13:56:46 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TKtS8j013736; Tue, 29 May 2007 13:55:28 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKtNDc027969; Tue, 29 May 2007 13:55:23 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00201LZX3F00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Tue, 29 May 2007 13:55:23 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FQPM46K213@d1-sfbay-09.sun.com>; Tue, 29 May 2007 13:55:19 -0700 (PDT) Date: Tue, 29 May 2007 13:53:48 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465C63A0.4000805@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Kais Belgaied Cc: "Garrett D'Amore - sun microsystems" , psarc-ext@sac.sfbay.sun.com Message-id: <465C92DC.6060401@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <465C63A0.4000805@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1609 Kais Belgaied wrote: > >> Problem >> ------- >> >> Various network drivers are inconsistent in their handling of logging of >> link messages. One of the more annoying things that some drivers do is >> flood the logs with link down messages (usually once every 10sec or >> so) when >> trying to transmit packets out the link. >> >> > The root cause of the problem as you describe seems to be the fact > that the stack above kept > submitting the packets to a link that is known to be down, causing the > flood of syslogs. > Somehow the event of link-down was not generated, lost during the > notification, or mishandled. > That is a bug to be fixed between the stack and the specific drivers > you observed the misbehavior > on. The bug is probably below the radar screen for ARC. > > Now, back the the symptoms (scope of this case): Each futile > submission of a packet to be > transmitted on a link down indicates a problem worth paying attention > to. It could be > uncovering a bug such as the above, or it could be transient race. I > don't believe it > is a bad practice from driver writers to adopt a defensive approach > and log > an error on every occurrence of the offense. Yikes! That's a bad idea, if you mean doing it in syslog. Of course, we _do_ log (collect) this information in the carrier_errors kstats. Just like we do for all other network related errors. -- Garrett > > Kais > >> Further, the detailed contents for link status changes are not >> consistent >> from one driver to another. >> >> Notably, the WIFI drivers generally do not do this. >> >> >> > > From Nicolas.Williams@sun.com Tue May 29 14:05:19 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TL5JhO012737 for ; Tue, 29 May 2007 14:05:19 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TL2ZUg029345; Tue, 29 May 2007 16:02:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TL2ZJw029344; Tue, 29 May 2007 16:02:35 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 16:02:35 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Darren J Moffat , John.Plocher@sun.com, psarc-ext@sac.sfbay.sun.com, James Carlson , Gary Winiger Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529210235.GY27420@Sun.COM> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <465C925F.8070205@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C925F.8070205@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1230 On Tue, May 29, 2007 at 01:51:43PM -0700, Garrett D'Amore wrote: > Darren J Moffat wrote: > >What I'm saying for *this* case is that a reduction in the information > >presented is a problem and for me it means that this case doesn't meet > >its goals. > > But for existing customers, the existing information was not provided in > anything remotely resembling a consistent manner. Each driver did its > own thing. For a customer/application to have depended on this kind of > information would have been utterly insane, if they wanted the > application to work with different NICs, etc. So what? These messages are at least intended for human consumption, and the human may not even notice such inconsistencies. "Oh look, interface xyz0 flapped and now is at half-duplex, time to go kick some network staff a**!" > I have investigated, and I can provide this information without too much > pain, but I still disagree with it in principle. Then just do it. The principle behind all the outside and inside opinions stated in favor of including speed and duplicity info is quite reasonable: the stuff was there and it was useful, so why remove it (almost, if not exactly, the least astonishment principle). Nico -- From Garrett.Damore@Sun.COM Tue May 29 14:05:48 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TL5lu2012751 for ; Tue, 29 May 2007 14:05:47 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TL4TL8019765 for ; Tue, 29 May 2007 14:04:29 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TL4OGv029011 for ; Tue, 29 May 2007 14:04:24 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00E01ME2KC00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:04:24 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FCAMJBK243@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:04:23 -0700 (PDT) Date: Tue, 29 May 2007 14:02:50 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465C66EF.2000805@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Peter Tribble , psarc-ext@sac.sfbay.sun.com Message-id: <465C94FA.6070902@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> <465C66EF.2000805@Sun.Com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 3331 John Plocher wrote: > Garrett D'Amore wrote: >> Also, right now, these applications will see the link up/down >> messages in the syslogs, and they can take whatever action they feel >> is appropriate when the syslogs indicate that such action is necessary. > > > I think you are missing the point. > > Sure, one could do all that extra work to figure out > what is really happening after they see an obfuscated > and truncated teaser message in syslog. But why should > we go out of our way to make things harder for admins? > Better that we ensure that we record useful and relevant > info, especially when we have it at our fingertips at > the time. > > What is syslog for? Why do we even log messages - heck, > if a sysadmin really wanted to know about the state of > the system, they could just use dladm, ifconfig, ping, > traceroute, snoop, SNMP traps, dtrace and truss. After > all, if you don't know how to use those tools, you should > be banished to a Linux system where you are forced to > use GNUtar with Bash :-) There are very friendly tools built upon SNMP. Please don't place using DTrace and SNMP in the same bucket. In the Linux world, they have a dladm-like tool as well, its called ethtool. And the link status logging in the Linux world is even _more_ of a mess than it is here. Again, lets not go there. > > Have you ever used Splunk (www.splunk.com) to manage a > system? If not, stop reading this and go get a free > copy and play with it. It isn't the only or best way > to admin complex systems, but it shows what can be done > with simple logfile analysis. Combining web logs with > syslog (with ...) lets me do the root cause analysis to > find out WHY a problem is happening - even if the problem > itself wasn't obvious at the time. I've used tools like Splunk, though not Splunk itself. Yes, logfile analysis can be very very useful, but usually that is a last resort when the *up front* tools can't tell you what is going on, or for sites that don't use or don't want to use an architected solution based on SNMP. Basically, by not providing good tools up-front to solve these problems (via SNMP, CLI apps, or whatever), we have created the market for Splunk. Splunk fills a gap in our story, which I think we should fix by closing the gap, rather than continuing to build upon that gap. > > Please find a way to keep this useful info in the network > interface messages. The cost of putting it there will be > significantly (IMHO several orders of magnitude) smaller > than the time and effort saved at only one customer site > by having it there. I'm seriously, seriously skeptical of that. As I said, to fix even _one_ problem, you shouldn't need historical data. All you need is a snapshot of the current state to fix whatever the problem is. Unless you believe that link state changes are a root cause for other problems, and you want to point the finger at link state changes for those other problems.... I'm not sure what those would look like. > > Yes, this implies that the network drivers will all need > a similar set of kstats (or whatever) for this to work; > also a small effort when compared to the benefits. GLDv3 has that for network drivers of a common media type. Its less uniform for pre-GLDv3 and for non-802.3 media. -- Garrett From Nicolas.Williams@sun.com Tue May 29 14:08:50 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TL8orY012770; Tue, 29 May 2007 14:08:50 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TL670G029352; Tue, 29 May 2007 16:06:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TL67ng029351; Tue, 29 May 2007 16:06:07 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 16:06:07 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Kais Belgaied , psarc-ext@sac.sfbay.sun.com, "Garrett D'Amore - sun microsystems" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529210607.GZ27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <465C63A0.4000805@Sun.COM> <465C92DC.6060401@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C92DC.6060401@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 965 On Tue, May 29, 2007 at 01:53:48PM -0700, Garrett D'Amore wrote: > Kais Belgaied wrote: > >Now, back the the symptoms (scope of this case): Each futile > >submission of a packet to be transmitted on a link down indicates a > >problem worth paying attention to. It could be uncovering a bug such > >as the above, or it could be transient race. I don't believe it is a > >bad practice from driver writers to adopt a defensive approach and > >log an error on every occurrence of the offense. > > Yikes! That's a bad idea, if you mean doing it in syslog. Why? Because of the risk of filling logs? If an interface is expected to flap a _lot_ then a knob to turn off logging about it would be useful. But I expect that such situations are so rare that any concern about filling logs is unrealistic. > Of course, we _do_ log (collect) this information in the carrier_errors > kstats. Just like we do for all other network related errors. Statistics != logging. From John.Plocher@Sun.COM Tue May 29 14:20:34 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLKXKt013007 for ; Tue, 29 May 2007 14:20:33 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLIa9U017783 for ; Tue, 29 May 2007 14:19:08 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TLIVFH012830 for ; Tue, 29 May 2007 14:18:31 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00C01N51YG00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:18:31 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FG5N6TK273@d1-sfbay-09.sun.com>; Tue, 29 May 2007 14:18:30 -0700 (PDT) Date: Tue, 29 May 2007 14:18:21 -0700 From: John Plocher Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <18012.36748.60045.403116@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: Dale Ghent , Darren J Moffat , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Gary Winiger Message-id: <465C989D.7070806@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 3433 James Carlson wrote: > That's exactly the point. Nobody has promised to provide anything > other than human (English only!) readable messages here. The contents > of the messages are no kind of programming interface. They're not > documented anywhere. A quick search of docs.sun.com found several places where we document these kinds of messages. I'm sure that there are others on bigadmin as well... http://docs.sun.com/app/docs/doc/806-1075/6jacsnimr?a=view > ======================= > le0: No carrier-- cable disconnected or hub link test disabled? > Cause > > Stand-alone machines with no Ethernet port connection get this > error when the system tries to access the network. If the > Ethernet cable is connected, this message could result from > a mismatch between the machine's NVRAM settings and the > Ethernet hub settings. > Action > If this message is continuous, try to save any work to a > local disk. > When a machine is configured as a networked system, it must > be plugged into the Ethernet with a twisted pair J45 connector. > If the Ethernet cable is plugged in, find out whether or not > the Ethernet hub does a link integrity test. Then become > superuser to check and possibly set the machine's NVRAM. If > the hub's link integrity test is disabled, set this variable > to false. > # eeprom | grep tpe > tpe-link-test?=true > # eeprom 'tpe-link-test?=false' > The default setting is true. If for some reason tpe-link-test? > was set to false, and the hub's link integrity test is enabled, > reset this variable to true. > ======================= > le0: No carrier-- transceiver cable problem? > Cause > Stand-alone machines with no Ethernet port connection get > this error when the system tries to access the network. > Action > If this message is continuous, try to save any work to a > local disk. > When a machine is configured as a networked system, it must > be plugged into the Ethernet with either a twisted pair J45 > connector or thicknet 10Base-T connector (depending on the > building's Ethernet cable type). > ======================= > Programs that depend on them are engaging in hackery. I am not talking about programs that depend on these interfaces, but humans who need this information themselves. We have trained them over the years to look in syslog for this type of debugging information. >> The best thing to do is to get a centralized logging framework >> implemented under GLD (so logging across disparate drivers is at >> least consistent) and live with what has been habit for so long in >> terms of the log content. OK so far, but Garrett's proposal deletes specific items from the set of things that have been "habit for so long". > That's exactly what this case is attempting to accomplish. The first > step is getting those logging messages into the framework where (if > they exist at all) they belong. I'd agree with all you have said, with the addition of ... without losing the useful information already provided by some of the drivers. By all means, move this reporting into the GLD framework AND ensure that this framework emits messages that actually help admins diagnose and solve common problems. It doesn't help anyone to emit minimal content messages that force all users to look elsewhere for missing contextual data when it is relatively trivial for the framework to provide more context for all. -John From al@logical-approach.com Tue May 29 14:20:38 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLKcco013019 for ; Tue, 29 May 2007 14:20:38 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLIugH017971 for ; Tue, 29 May 2007 14:19:09 -0700 (PDT) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TLHiNB021542 for ; Tue, 29 May 2007 21:18:56 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay3.sun.com with ESMTP id BT-MMP-741728; Tue, 29 May 2007 21:18:31 Z Received: from relay03i.sun.com (ip74.net150143-60.block3.us.syntegra.com [150.143.60.74]) by mms05es.sun.com with ESMTP id BT-MMP-2526077; Tue, 29 May 2007 21:18:31 Z Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by relay0i.sun.com with ESMTP id BT-MMP-3264530; Tue, 29 May 2007 21:18:30 Z Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay4i.sun.com with ESMTP id BT-MMP-3606081; Tue, 29 May 2007 21:18:30 Z Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l4TLITcf016963; Tue, 29 May 2007 16:18:30 -0500 (CDT) Date: Tue, 29 May 2007 16:18:29 -0500 (CDT) From: Al Hopper To: "Garrett D'Amore" cc: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C8F01.7070200@sun.com> Message-Id: References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 2479 On Tue, 29 May 2007, Garrett D'Amore wrote: > Al Hopper wrote: ... snip .... >> 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. .... snip ... > 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. Every time I (personally) see the link up/down message, I *always* do a mental "sanity check" to determine if the speed/duplicity settings were "as expected". In our local environment that would almost always be "1000Mbps full duplex" for an interface that is gigabit capable. However, in a large client environment I am familiar with, it should always be 100Mbps/full duplex, because they have "hard coded" every bloody port in the entire datacenter[0]. Or at least, attempted to[1]. So the speed/duplicity is always sanity checked - and I know the sys admins I work closely with _always_ check it also. > Hope that answers this concern. I think the current info is very useful and should be retained, if at all possible. On a side note, as a developer, when I have my head in some code, I generally look at what is logged at the "info" level and see if there is some other data that is "close by" that might be useful and append it to the message. In this case, when I say "close by", I mean in a local data structure, or function arg, that is easy and inexpensively (from a system resource perspective) added. [0] your typical design by committee where the techies on the committee are out-numbered 10 to 1 by 100% Buzzword Compliant Management Types (BCMT). [1] Until they swap out a switch supervisor board, or upgrade the switch code - or some "new guy" comes along and "fixes" the current switch configs. Or they move the wires over to a new switch (during a maintenance window that we never received notification of). Regards, Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From Garrett.Damore@Sun.COM Tue May 29 14:21:31 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLLVtM013033 for ; Tue, 29 May 2007 14:21:31 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TLKCqh029222 for ; Tue, 29 May 2007 14:20:12 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TLK7pA000748 for ; Tue, 29 May 2007 14:20:07 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00H01N9GD600@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:20:07 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FZ2N9IK273@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:20:07 -0700 (PDT) Date: Tue, 29 May 2007 14:18:36 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <20070529204931.GX27420@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: Al Hopper , psarc-ext@sac.sfbay.sun.com Message-id: <465C98AC.6050404@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2678 Nicolas Williams wrote: > On Tue, May 29, 2007 at 01:37:21PM -0700, Garrett D'Amore wrote: > >> Al Hopper wrote: >> >>>> Casper.Dik@Sun.COM wrote: >>>> >>> You seem to be missing the point - syslogging the interface name with >>> speed and duplicity is useful in a couple of very practical ways: >>> >>> [SNIPPED: three cases not needing speed and duplicity info] >>> >>> 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. >> > > Yes, but others have given cases where speed and duplicity information > is useful. > Actually, as I've already indicated, apart from being able to lay blame on person who changed the settings, I don't understand why they are useful _in the logs_. I may just be dense. One problem I have is that assumption that Link speed and duplex are meaningful all the time works. For non-802.3 links, they aren't. Even the speed is not necessarily meaningful. (With 802.11 the speed can change dynamically, very frequently. You don't want to log that for certain!) For other devices, the fact that an external or internal transceiver is likely to be just as relevant as speed and duplex setting. (NICs that have an external transceiver, for example.) Or media, for nics that have both copper and fiber ports.) Again, trying to come up with something _in the logs_ that can be consistent across all drivers, in a way that doesn't worsen breakage, seems challenging. The one thing that seems to be universal is the link up/down state. Which is probably why that is what is what is record in the MAC layer rather than the device driver kstats. Anyway, if folks are dead convinced that we have to have link speed and duplex for 802.3, I have figured out how to add it without too much engineering effort or risk. Should we also be logging e.g. the SSID for 802.11 links? > >> 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. >> > > It doesn't. > It doesn't? Why not? Or are you saying it doesn't address the aforementioned "other cases" that people gave? -- Garrett From Garrett.Damore@Sun.COM Tue May 29 14:26:21 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLQL8Q013159; Tue, 29 May 2007 14:26:21 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TLP2q3002079; Tue, 29 May 2007 14:25:02 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TLOvcj013565; Tue, 29 May 2007 14:24:57 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00001NFQKK00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Tue, 29 May 2007 14:24:57 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FK4NHKK293@d1-sfbay-09.sun.com>; Tue, 29 May 2007 14:24:57 -0700 (PDT) Date: Tue, 29 May 2007 14:23:26 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <20070529210607.GZ27420@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: Kais Belgaied , psarc-ext@sac.sfbay.sun.com, "Garrett D'Amore - sun microsystems" Message-id: <465C99CE.9070208@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <465C63A0.4000805@Sun.COM> <465C92DC.6060401@sun.com> <20070529210607.GZ27420@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1561 Nicolas Williams wrote: > On Tue, May 29, 2007 at 01:53:48PM -0700, Garrett D'Amore wrote: > >> Kais Belgaied wrote: >> >>> Now, back the the symptoms (scope of this case): Each futile >>> submission of a packet to be transmitted on a link down indicates a >>> problem worth paying attention to. It could be uncovering a bug such >>> as the above, or it could be transient race. I don't believe it is a >>> bad practice from driver writers to adopt a defensive approach and >>> log an error on every occurrence of the offense. >>> >> Yikes! That's a bad idea, if you mean doing it in syslog. >> > > Why? Because of the risk of filling logs? If an interface is expected > to flap a _lot_ then a knob to turn off logging about it would be > useful. But I expect that such situations are so rare that any concern > about filling logs is unrealistic. > Quite the contrary! If you run dhcp on multiple interfaces, then it will periodically send probes out the network (or try at least). If you have an interface marked up, but the cable is disconnected, then it will flood the logs. We do _not_ log an error in syslog every time a packet is dropped due to collisions. Why should we do it for carrier_errors? > >> Of course, we _do_ log (collect) this information in the carrier_errors >> kstats. Just like we do for all other network related errors. >> > > Statistics != logging. > See above. Are carrier_errors somehow magical in that they get special handling that no other errors should get? -- Garrett From al@logical-approach.com Tue May 29 14:29:40 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLTe59013211 for ; Tue, 29 May 2007 14:29:40 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLSLRu023763 for ; Tue, 29 May 2007 14:28:21 -0700 (PDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TJGCBZ029954 for ; Tue, 29 May 2007 21:28:21 GMT Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay2.sun.com with ESMTP id BT-MMP-2336445; Tue, 29 May 2007 21:28:17 Z Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms02es.sun.com with ESMTP id BT-MMP-824192; Tue, 29 May 2007 21:28:16 Z Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by relay3.sun.com with ESMTP id BT-MMP-4694391; Tue, 29 May 2007 21:28:16 Z Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay4i.sun.com with ESMTP id BT-MMP-639205; Tue, 29 May 2007 21:28:16 Z Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l4TLSFmW022909; Tue, 29 May 2007 16:28:15 -0500 (CDT) Date: Tue, 29 May 2007 16:28:15 -0500 (CDT) From: Al Hopper To: "Garrett D'Amore" cc: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C925F.8070205@sun.com> Message-Id: References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <465C925F.8070205@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 3657 On Tue, 29 May 2007, Garrett D'Amore wrote: > Darren J Moffat wrote: >> James Carlson wrote: >>> Darren J Moffat writes: >>>> We can argue this indefinitely but regardless of what some PSARC members >>>> think admins, developers on Solaris and other platforms act differently. >>> >>> Regardless of how they act, we don't apply any engineering towards >>> making their actions supportable. >> >> and there in lies the problem, we are not meeting customer needs here. >> Customers and partners really just don't care about that, we know they >> build stuff on top of syslog. They expect to build stuff ontop of syslog >> on all platforms not just Solaris. IMO we need to take the fingers out of >> our ears and stop just saying "la la la la la la" everything this comes up >> and ignoring what the customers use and we know they use. >> >> What I'm saying for *this* case is that a reduction in the information >> presented is a problem and for me it means that this case doesn't meet its >> goals. >> > > But for existing customers, the existing information was not provided in > anything remotely resembling a consistent manner. Each driver did its own > thing. For a customer/application to have depended on this kind of > information would have been utterly insane, if they wanted the application to > work with different NICs, etc. But that is not the case in a large datacenter environment that I'm familiar with. The same one where all the ethernet ports are hard-coded. The good Sys Admins understand the limitations of hardcoding data in scripts. However, the environment tends to remain static over long periods of time (for various reasons, including the hassle of filling in endless electronic forms to make something simple happen and the implied threat of loosing your job if it does not work out as planned). A machine will be configured to run an application (they like one application per machine!) and it will stay on that machine for 3 to 5 years. Only after an app moves to a different/upgraded machine will the hard-coded scripts be re-evaluated. Oh ... and yes ... they are still running Solaris 8! > I have investigated, and I can provide this information without too much > pain, but I still disagree with it in principle. > > The reason for this is that today the mac layer knows nothing about many of > these link details, and it really doesn't need to. Furthermore, there are > reasonable situations where the link speed can change without generating any > kind of notification. (The typical example being link speed adjustments that > are done on 802.11 links.) > > If folks really really want this information for 802.3 links, we can do it. > I just don't think its reasonable. > > I also think, most tools just want an "up" or "down" notification (not > details on speed or duplex), so very few are likely to be negatively impacted > (other than they will have to adjust their scripts/tools to recognize the new > "up" and "down" messages, but then one format will cover _all_ GLDv3 NIC > drivers. > > Note that some NIC drivers don't even bother to log this at all. For > example, 802.11 drivers do no link state logging whatsoever. My case would > add this for those drivers. > > -- Garrett > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From Garrett.Damore@Sun.COM Tue May 29 14:35:03 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLZ3Y6013326 for ; Tue, 29 May 2007 14:35:03 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TLXirW007852 for ; Tue, 29 May 2007 14:33:44 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TLXdPf014514 for ; Tue, 29 May 2007 14:33:39 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00D01NU9DZ00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:33:39 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00F99NW0K5R2@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 14:33:36 -0700 (PDT) Date: Tue, 29 May 2007 14:32:06 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Al Hopper Cc: psarc-ext@sac.sfbay.sun.com Message-id: <465C9BD6.2030506@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <465C925F.8070205@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2436 Al Hopper wrote: > On Tue, 29 May 2007, Garrett D'Amore wrote: > >> Darren J Moffat wrote: >>> James Carlson wrote: >>>> Darren J Moffat writes: >>>>> We can argue this indefinitely but regardless of what some PSARC >>>>> members think admins, developers on Solaris and other platforms >>>>> act differently. >>>> >>>> Regardless of how they act, we don't apply any engineering towards >>>> making their actions supportable. >>> >>> and there in lies the problem, we are not meeting customer needs >>> here. Customers and partners really just don't care about that, we >>> know they build stuff on top of syslog. They expect to build stuff >>> ontop of syslog on all platforms not just Solaris. IMO we need to >>> take the fingers out of our ears and stop just saying "la la la la >>> la la" everything this comes up and ignoring what the customers use >>> and we know they use. >>> >>> What I'm saying for *this* case is that a reduction in the >>> information presented is a problem and for me it means that this >>> case doesn't meet its goals. >>> >> >> But for existing customers, the existing information was not provided >> in anything remotely resembling a consistent manner. Each driver did >> its own thing. For a customer/application to have depended on this >> kind of information would have been utterly insane, if they wanted >> the application to work with different NICs, etc. > > But that is not the case in a large datacenter environment that I'm > familiar with. The same one where all the ethernet ports are > hard-coded. The good Sys Admins understand the limitations of > hardcoding data in scripts. However, the environment tends to remain > static over long periods of time (for various reasons, including the > hassle of filling in endless electronic forms to make something simple > happen and the implied threat of loosing your job if it does not work > out as planned). A machine will be configured to run an application > (they like one application per machine!) and it will stay on that > machine for 3 to 5 years. Only after an app moves to a > different/upgraded machine will the hard-coded scripts be > re-evaluated. Oh ... and yes ... they are still running Solaris 8! Then they won't be impacted until they upgrade to Solaris 11. At which point most of their broken scripts will need to be fixed anyway for other reasons. So what's the problem? -- Garrett From al@logical-approach.com Tue May 29 14:38:43 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLchCb013369 for ; Tue, 29 May 2007 14:38:43 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLbPOx029297 for ; Tue, 29 May 2007 14:37:25 -0700 (PDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TJFPPG016694 for ; Tue, 29 May 2007 21:37:25 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay2.sun.com with ESMTP id BT-MMP-2337698; Tue, 29 May 2007 21:37:12 Z Received: from relay01i.sun.com (ip70.net150143-60.block3.us.syntegra.com [150.143.60.70]) by mms05es.sun.com with ESMTP id BT-MMP-2541846; Tue, 29 May 2007 21:37:11 Z Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by relay0i.sun.com with ESMTP id BT-MMP-3377343; Tue, 29 May 2007 21:37:11 Z Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay4i.sun.com with ESMTP id BT-MMP-2906094; Tue, 29 May 2007 21:37:11 Z Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l4TLbAxL027691; Tue, 29 May 2007 16:37:10 -0500 (CDT) Date: Tue, 29 May 2007 16:37:10 -0500 (CDT) From: Al Hopper To: "Garrett D'Amore" cc: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C9BD6.2030506@sun.com> Message-Id: References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <465C925F.8070205@sun.com> <465C9BD6.2030506@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 2867 On Tue, 29 May 2007, Garrett D'Amore wrote: > Al Hopper wrote: >> On Tue, 29 May 2007, Garrett D'Amore wrote: >> >>> Darren J Moffat wrote: >>>> James Carlson wrote: >>>>> Darren J Moffat writes: >>>>>> We can argue this indefinitely but regardless of what some PSARC >>>>>> members think admins, developers on Solaris and other platforms act >>>>>> differently. >>>>> >>>>> Regardless of how they act, we don't apply any engineering towards >>>>> making their actions supportable. >>>> >>>> and there in lies the problem, we are not meeting customer needs here. >>>> Customers and partners really just don't care about that, we know they >>>> build stuff on top of syslog. They expect to build stuff ontop of syslog >>>> on all platforms not just Solaris. IMO we need to take the fingers out >>>> of our ears and stop just saying "la la la la la la" everything this >>>> comes up and ignoring what the customers use and we know they use. >>>> >>>> What I'm saying for *this* case is that a reduction in the information >>>> presented is a problem and for me it means that this case doesn't meet >>>> its goals. >>>> >>> >>> But for existing customers, the existing information was not provided in >>> anything remotely resembling a consistent manner. Each driver did its own >>> thing. For a customer/application to have depended on this kind of >>> information would have been utterly insane, if they wanted the application >>> to work with different NICs, etc. >> >> But that is not the case in a large datacenter environment that I'm >> familiar with. The same one where all the ethernet ports are hard-coded. >> The good Sys Admins understand the limitations of hardcoding data in >> scripts. However, the environment tends to remain static over long periods >> of time (for various reasons, including the hassle of filling in endless >> electronic forms to make something simple happen and the implied threat of >> loosing your job if it does not work out as planned). A machine will be >> configured to run an application (they like one application per machine!) >> and it will stay on that machine for 3 to 5 years. Only after an app moves >> to a different/upgraded machine will the hard-coded scripts be >> re-evaluated. Oh ... and yes ... they are still running Solaris 8! > > Then they won't be impacted until they upgrade to Solaris 11. At which point > most of their broken scripts will need to be fixed anyway for other reasons. > So what's the problem? The only "problem" is trying to convince you to retain the existing behavior! :) Regards, Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From daleg@elemental.org Tue May 29 14:44:57 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLivDS013480 for ; Tue, 29 May 2007 14:44:57 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLhd9a002171 for ; Tue, 29 May 2007 14:43:39 -0700 (PDT) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TKhFuq028356 for ; Tue, 29 May 2007 21:43:38 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay3.sun.com with ESMTP id BT-MMP-745345 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 21:43:38 Z Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms05es.sun.com with ESMTP id BT-MMP-2547106 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 21:43:38 Z Received: from lithium.elemental.org ([130.85.5.200] [130.85.5.200]) by relay1.sun.com with ESMTP id BT-MMP-4780062 for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 21:43:37 Z Received: from [130.85.70.33] (deuterium.ucs.umbc.edu [130.85.70.33]) (authenticated bits=0) by lithium.elemental.org (8.13.8/8.13.8/ELEMENTAL-3.1) with ESMTP id l4TLhbj9004327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2007 17:43:37 -0400 (EDT) In-Reply-To: <465C94FA.6070902@sun.com> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> <465C66EF.2000805@Sun.Com> <465C94FA.6070902@sun.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E56BF6B-CB5A-4FF1-8156-B27D463AA3A8@elemental.org> Cc: John Plocher , psarc-ext@sac.sfbay.sun.com Content-Transfer-Encoding: 7bit From: Dale Ghent Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Date: Tue, 29 May 2007 17:43:36 -0400 To: "Garrett D'Amore" X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (lithium.elemental.org [130.85.5.200]); Tue, 29 May 2007 17:43:37 -0400 (EDT) Status: RO Content-Length: 602 On May 29, 2007, at 5:02 PM, Garrett D'Amore wrote: > Yes, logfile analysis can be very very useful, but usually that is > a last resort when the *up front* tools can't tell you what is > going on, or for sites that don't use or don't want to use an > architected solution based on SNMP. Just a quick question, and I don't think this three-letter acronym has been mentioned yet... But as far as purely link up/down status goes (irregardless of what speed, duplex, and so on), wouldn't this be the domain of FMA? It's plausible that link state changes could be considered "faulty". /dale From sommerfeld@sun.com Tue May 29 14:57:02 2007 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLv1DG013869 for ; Tue, 29 May 2007 14:57:02 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TLtfCc012263; Tue, 29 May 2007 17:55:41 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TLtetD025537; Tue, 29 May 2007 17:55:41 -0400 (EDT) Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] From: Bill Sommerfeld To: Dale Ghent Cc: "Garrett D'Amore" , John Plocher , psarc-ext@sac.sfbay.sun.com In-Reply-To: <9E56BF6B-CB5A-4FF1-8156-B27D463AA3A8@elemental.org> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> <465C66EF.2000805@Sun.Com> <465C94FA.6070902@sun.com> <9E56BF6B-CB5A-4FF1-8156-B27D463AA3A8@elemental.org> Content-Type: text/plain Date: Tue, 29 May 2007 17:55:39 -0400 Message-Id: <1180475739.23119.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1111 On Tue, 2007-05-29 at 17:43 -0400, Dale Ghent wrote: > Just a quick question, and I don't think this three-letter acronym > has been mentioned yet... > > But as far as purely link up/down status goes (irregardless of what > speed, duplex, and so on), wouldn't this be the domain of FMA? IMHO, it would. I haven't quite digested this entire case but it seems to me that the very notion of sending raw link state changes to syslog goes against the FMA architecture. > It's plausible that link state changes could be considered "faulty". As I understand FMA, link state changes would be error reports -- observations made by error detectors that aren't necessarily indications of faults, but rather as evidence to be considered by a diagnosis engine that may indicate an underlying fault somewhere in the system. For instance, I'd expect a DE to apply some amount of flap dampening based on recent history before declaring that a link had actually failed. IMHO, it is inconsistent with FMA to declare that syslogged link status notifications from a driver form any kind of interface. - Bill From Garrett.Damore@Sun.COM Tue May 29 15:08:07 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TM87l3014262 for ; Tue, 29 May 2007 15:08:07 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TM6mvK013975 for ; Tue, 29 May 2007 15:06:48 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TM6hnK006046 for ; Tue, 29 May 2007 15:06:43 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00K01PDIMU00@d1-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 15:06:43 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00605PF2HAR7@d1-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 15:06:43 -0700 (PDT) Date: Tue, 29 May 2007 15:05:08 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <9E56BF6B-CB5A-4FF1-8156-B27D463AA3A8@elemental.org> Sender: Garrett.Damore@Sun.COM To: Dale Ghent Cc: John Plocher , psarc-ext@sac.sfbay.sun.com Message-id: <465CA394.4090706@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <465A4C56.2020302@sun.com> <465A504D.3080900@Sun.Com> <465A5429.1040701@sun.com> <465BB171.8030102@Sun.Com> <465BB4AA.3040601@sun.com> <465C66EF.2000805@Sun.Com> <465C94FA.6070902@sun.com> <9E56BF6B-CB5A-4FF1-8156-B27D463AA3A8@elemental.org> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 963 Dale Ghent wrote: > On May 29, 2007, at 5:02 PM, Garrett D'Amore wrote: > >> Yes, logfile analysis can be very very useful, but usually that is a >> last resort when the *up front* tools can't tell you what is going >> on, or for sites that don't use or don't want to use an architected >> solution based on SNMP. > > Just a quick question, and I don't think this three-letter acronym has > been mentioned yet... > > But as far as purely link up/down status goes (irregardless of what > speed, duplex, and so on), wouldn't this be the domain of FMA? > > It's plausible that link state changes could be considered "faulty". You're not the first one to suggest this. And I agree with you. However, what I first want to do is get the logging centralized. Then conversion to FMA or whatever can be done at one shot, without touching a gazillion drivers. (What I don't want to happen is to spread the FMA knowledge into each driver....) -- Garrett From Garrett.Damore@Sun.COM Tue May 29 15:26:28 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TMQS0Z014384 for ; Tue, 29 May 2007 15:26:28 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TMP9v1022275 for ; Tue, 29 May 2007 15:25:09 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TMP8sB008054 for ; Tue, 29 May 2007 15:25:08 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00601Q84VA00@d1-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 15:25:08 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT006IHQ9WGY97@d1-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 15:25:08 -0700 (PDT) Date: Tue, 29 May 2007 15:23:38 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Al Hopper Cc: psarc-ext@sac.sfbay.sun.com Message-id: <465CA7EA.1090902@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4582 In order to address the concerns, questions about this, I'm thinking we can go ahead and log some additional details. It turns out not to be as painful as I thought, because the reference counting I need to recursively call into the the device driver to get the stats is basically already there. For 802.3 (mac_ether type devices), the logged link-up message could take the form of: bge0: link up, 1000Mbps, full duplex For 802.11 (mac_wifi type devices), its not entirely clear what is most desirable. We have SSID, security information (WEP/WPA, open/shared-key auth -- though nobody should ever use shared-key), 802.11 "mode" (802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel, current rate (though that can change at any time). Additionally, even the notion of associated/authenticated is a bit muddied by 802.11. What I'd like to do is leave the other non-802.3 messages as just "link up", with no further details. In any case, link down messages will still just be "link down". The main draw back of this approach is that the link notification messages will be different for ethernet than for any other link layer. Frankly, I find that kind of distasteful, and I'd rather not encourage the continued reliance of syslog to obtain details like link speed, duplex, etc. But I'm also finding it hard to continue to care about it passionately enough to argue with the few people who still seem to do care passionately enough. I guess this then becomes a request for PSARC to provide direction, which, I'm not sure I can do in a fasttrack. The options I present to PSARC are: * shall we take the case as originally proposed? * shall we amend the case to require link speed and duplex _only_ for ethernet links? * shall we reject the case altogether? (If the case were to be derailed, I'd just withdraw it because I don't have nearly enough interest in this case to run it as a full PSARC case.) Thanks. -- Garrett Al Hopper wrote: > On Tue, 29 May 2007, Garrett D'Amore wrote: > >> Al Hopper wrote: > ... snip .... >>> 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. > .... snip ... >> 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. > > Every time I (personally) see the link up/down message, I *always* do > a mental "sanity check" to determine if the speed/duplicity settings > were "as expected". In our local environment that would almost always > be "1000Mbps full duplex" for an interface that is gigabit capable. > > However, in a large client environment I am familiar with, it should > always be 100Mbps/full duplex, because they have "hard coded" every > bloody port in the entire datacenter[0]. Or at least, attempted > to[1]. So the speed/duplicity is always sanity checked - and I know > the sys admins I work closely with _always_ check it also. > >> Hope that answers this concern. > > I think the current info is very useful and should be retained, if at > all possible. > > On a side note, as a developer, when I have my head in some code, I > generally look at what is logged at the "info" level and see if there > is some other data that is "close by" that might be useful and append > it to the message. In this case, when I say "close by", I mean in a > local data structure, or function arg, that is easy and inexpensively > (from a system resource perspective) added. > > [0] your typical design by committee where the techies on the > committee are out-numbered 10 to 1 by 100% Buzzword Compliant > Management Types (BCMT). > > [1] Until they swap out a switch supervisor board, or upgrade the > switch code - or some "new guy" comes along and "fixes" the current > switch configs. Or they move the wires over to a new switch (during a > maintenance window that we never received notification of). > > Regards, > > Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com > Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT > OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 > http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From casper@holland.sun.com Tue May 29 15:32:09 2007 Received: from sr1-eaft06-01.holland.sun.com (sr1-eaft06-01.Holland.Sun.COM [129.159.237.36]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TMW88e014422 for ; Tue, 29 May 2007 15:32:08 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TMUlLp002243; Wed, 30 May 2007 00:30:48 +0200 (MEST) Message-Id: <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> From: Casper.Dik@Sun.COM To: "Garrett D'Amore" cc: Al Hopper , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465CA7EA.1090902@sun.com> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <465CA7EA.1090902@sun.com> Date: Wed, 30 May 2007 00:30:47 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 1057 >For 802.11 (mac_wifi type devices), its not entirely clear what is most >desirable. We have SSID, security information (WEP/WPA, open/shared-key >auth -- though nobody should ever use shared-key), 802.11 "mode" >(802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel, >current rate (though that can change at any time). Additionally, even >the notion of associated/authenticated is a bit muddied by 802.11. > >What I'd like to do is leave the other non-802.3 messages as just "link >up", with no further details. What I found usable when working on wifi drivers were message of the form: linkup, X% signal strange, ESSID="XXXX" each type of link has its own significant information. >The main draw back of this approach is that the link notification >messages will be different for ethernet than for any other link layer. Well, that is because each type of link has its own type of significant parameters. And "logging links status change with significands" seems like a way to define link dependent properties. Casper From Nicolas.Williams@sun.com Tue May 29 16:14:25 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNEP9k015536 for ; Tue, 29 May 2007 16:14:25 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TNBfjR029483; Tue, 29 May 2007 18:11:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TNBfp9029482; Tue, 29 May 2007 18:11:41 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 18:11:41 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Al Hopper , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529231141.GC27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> <465C98AC.6050404@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C98AC.6050404@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 509 On Tue, May 29, 2007 at 02:18:36PM -0700, Garrett D'Amore wrote: > Nicolas Williams wrote: > >Yes, but others have given cases where speed and duplicity information > >is useful. > > Actually, as I've already indicated, apart from being able to lay blame > on person who changed the settings, I don't understand why they are > useful _in the logs_. I may just be dense. That's what logs are useful for! For debugging, i.e., attributing fault, that is, blaming the source of the problem (and fixing it). From Nicolas.Williams@sun.com Tue May 29 16:20:28 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNKDVB015562 for ; Tue, 29 May 2007 16:20:28 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TNHSqx029490; Tue, 29 May 2007 18:17:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TNHSgR029489; Tue, 29 May 2007 18:17:28 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 18:17:28 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Al Hopper , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529231728.GD27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> <465C98AC.6050404@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C98AC.6050404@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2060 On Tue, May 29, 2007 at 02:18:36PM -0700, Garrett D'Amore wrote: > One problem I have is that assumption that Link speed and duplex are > meaningful all the time works. For non-802.3 links, they aren't. Even > the speed is not necessarily meaningful. (With 802.11 the speed can > change dynamically, very frequently. You don't want to log that for > certain!) Indeed. The log message in question may have to vary by media type. For 802.11 link up/down may not be so interesting either, rather, link speed ==/!= 0 would be. > For other devices, the fact that an external or internal transceiver is > likely to be just as relevant as speed and duplex setting. (NICs that > have an external transceiver, for example.) Or media, for nics that > have both copper and fiber ports.) Why? The transceiver is a physical attribute of the NIC -- if you need one and it's removed then you'll not have link. > Again, trying to come up with something _in the logs_ that can be > consistent across all drivers, in a way that doesn't worsen breakage, > seems challenging. The log message in question should be consistent across all drivers for the same media type. > The one thing that seems to be universal is the link up/down state. Not so. For wireless link state and speed both depend on signal strength. > Which is probably why that is what is what is record in the MAC layer > rather than the device driver kstats. I don't get this. > Anyway, if folks are dead convinced that we have to have link speed and > duplex for 802.3, I have figured out how to add it without too much > engineering effort or risk. Should we also be logging e.g. the SSID for > 802.11 links? Can it change without sysadmin intervention? No. Or did you mean the base station's ID? If so, then, maybe! (It'd be nice to see roaming reflected in the logs, no?) > >>Hope that answers this concern. > >> > > > >It doesn't. > > > > It doesn't? Why not? Or are you saying it doesn't address the > aforementioned "other cases" that people gave? I was. From Nicolas.Williams@sun.com Tue May 29 16:23:06 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNN5PI015595; Tue, 29 May 2007 16:23:05 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TNKMOm029499; Tue, 29 May 2007 18:20:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TNKMJa029498; Tue, 29 May 2007 18:20:22 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 18:20:22 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Kais Belgaied , psarc-ext@sac.sfbay.sun.com, "Garrett D'Amore - sun microsystems" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529232021.GE27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <465C63A0.4000805@Sun.COM> <465C92DC.6060401@sun.com> <20070529210607.GZ27420@Sun.COM> <465C99CE.9070208@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C99CE.9070208@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 907 On Tue, May 29, 2007 at 02:23:26PM -0700, Garrett D'Amore wrote: > Nicolas Williams wrote: > >On Tue, May 29, 2007 at 01:53:48PM -0700, Garrett D'Amore wrote: > >>Yikes! That's a bad idea, if you mean doing it in syslog. > > > >Why? Because of the risk of filling logs? If an interface is expected > >to flap a _lot_ then a knob to turn off logging about it would be > >useful. But I expect that such situations are so rare that any concern > >about filling logs is unrealistic. > > > > Quite the contrary! If you run dhcp on multiple interfaces, then it > will periodically send probes out the network (or try at least). If you > have an interface marked up, but the cable is disconnected, then it will > flood the logs. What?! Why should dhcpagent's sending a broadcast cause a link down message to be logged? Either the link status changed or it didn't; if it didn't change, don't log it. From Nicolas.Williams@sun.com Tue May 29 16:29:56 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNTunU015647 for ; Tue, 29 May 2007 16:29:56 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4TNRCrT029508; Tue, 29 May 2007 18:27:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TNRCft029507; Tue, 29 May 2007 18:27:12 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 29 May 2007 18:27:12 -0500 From: Nicolas Williams To: Casper.Dik@sun.com Cc: "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070529232712.GF27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <465CA7EA.1090902@sun.com> <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1717 On Wed, May 30, 2007 at 12:30:47AM +0200, Casper.Dik@Sun.COM wrote: > > >For 802.11 (mac_wifi type devices), its not entirely clear what is most > >desirable. We have SSID, security information (WEP/WPA, open/shared-key > >auth -- though nobody should ever use shared-key), 802.11 "mode" > >(802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel, > >current rate (though that can change at any time). Additionally, even > >the notion of associated/authenticated is a bit muddied by 802.11. > > > >What I'd like to do is leave the other non-802.3 messages as just "link > >up", with no further details. > > What I found usable when working on wifi drivers were message of > the form: > > linkup, X% signal strange, ESSID="XXXX" > > each type of link has its own significant information. Agreed. But presumably the log message for wireless NIC state change shouldn't be issued for every signal strength change! Just when signal strength goes aboe zero (link up) or down to zero (link down). And NWAM might not want to try to do things just because the link on a wireless interface went down -- I may be walking somewhere and be back within range of a base station soon. I agree that the base station ID is useful to have in these messages. OT: What about the little button that some systems (laptops, mostly?) have to enable/disable wireless? How should Solaris deal with that? Because if I turn off wireless then I definitely want NWAM to do something about that, but if signal strength temporarily falls to zero then I probably don't want NWAM to do anything about that. So mapping both, that button and signal strength to link up/down status is probably a bad idea. Nico -- From Garrett.Damore@Sun.COM Tue May 29 16:46:19 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNkJf0015818; Tue, 29 May 2007 16:46:19 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TNj0Wu004930; Tue, 29 May 2007 16:45:00 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TNitFH027803; Tue, 29 May 2007 16:44:55 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00101TXWAR00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Tue, 29 May 2007 16:44:55 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FWLTYUK2W3@d1-sfbay-09.sun.com>; Tue, 29 May 2007 16:44:55 -0700 (PDT) Date: Tue, 29 May 2007 16:43:23 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <20070529232021.GE27420@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: Kais Belgaied , psarc-ext@sac.sfbay.sun.com, "Garrett D'Amore - sun microsystems" Message-id: <465CBA9B.5090302@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <465C63A0.4000805@Sun.COM> <465C92DC.6060401@sun.com> <20070529210607.GZ27420@Sun.COM> <465C99CE.9070208@sun.com> <20070529232021.GE27420@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1375 Nicolas Williams wrote: > On Tue, May 29, 2007 at 02:23:26PM -0700, Garrett D'Amore wrote: > >> Nicolas Williams wrote: >> >>> On Tue, May 29, 2007 at 01:53:48PM -0700, Garrett D'Amore wrote: >>> >>>> Yikes! That's a bad idea, if you mean doing it in syslog. >>>> >>> Why? Because of the risk of filling logs? If an interface is expected >>> to flap a _lot_ then a knob to turn off logging about it would be >>> useful. But I expect that such situations are so rare that any concern >>> about filling logs is unrealistic. >>> >>> >> Quite the contrary! If you run dhcp on multiple interfaces, then it >> will periodically send probes out the network (or try at least). If you >> have an interface marked up, but the cable is disconnected, then it will >> flood the logs. >> > > What?! Why should dhcpagent's sending a broadcast cause a link down > message to be logged? Either the link status changed or it didn't; if > it didn't change, don't log it. > Agreed. But that's not what Kais originally said, and you agreed with (whether intentionally or not). A message should only be logged on a _change_ of state, not for each packet that can't get delivered because of link down. (To be fair, hme, et. al. don't log for each packet, but still quite frequently, like once each 10 or 30 secs or so.) -- Garrett From Garrett.Damore@Sun.COM Tue May 29 16:55:54 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TNtsgC016265 for ; Tue, 29 May 2007 16:55:54 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4TNsZH2029688 for ; Tue, 29 May 2007 16:54:35 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4TNsUUp016282 for ; Tue, 29 May 2007 16:54:30 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIT00B01UEUNY00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 16:54:30 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIT00FYPUEUK2Y3@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 29 May 2007 16:54:30 -0700 (PDT) Date: Tue, 29 May 2007 16:52:58 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <20070529232712.GF27420@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: Casper.Dik@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <465CBCDA.7040707@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <465CA7EA.1090902@sun.com> <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> <20070529232712.GF27420@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 3917 Nicolas Williams wrote: > On Wed, May 30, 2007 at 12:30:47AM +0200, Casper.Dik@Sun.COM wrote: > >>> For 802.11 (mac_wifi type devices), its not entirely clear what is most >>> desirable. We have SSID, security information (WEP/WPA, open/shared-key >>> auth -- though nobody should ever use shared-key), 802.11 "mode" >>> (802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel, >>> current rate (though that can change at any time). Additionally, even >>> the notion of associated/authenticated is a bit muddied by 802.11. >>> >>> What I'd like to do is leave the other non-802.3 messages as just "link >>> up", with no further details. >>> >> What I found usable when working on wifi drivers were message of >> the form: >> >> linkup, X% signal strange, ESSID="XXXX" >> >> each type of link has its own significant information. >> > > Agreed. But presumably the log message for wireless NIC state change > shouldn't be issued for every signal strength change! Just when signal > strength goes aboe zero (link up) or down to zero (link down). > > And NWAM might not want to try to do things just because the link on a > wireless interface went down -- I may be walking somewhere and be back > within range of a base station soon. > > I agree that the base station ID is useful to have in these messages. > > OT: > > What about the little button that some systems (laptops, mostly?) have > to enable/disable wireless? How should Solaris deal with that? Because > if I turn off wireless then I definitely want NWAM to do something about > that, but if signal strength temporarily falls to zero then I probably > don't want NWAM to do anything about that. So mapping both, that button > and signal strength to link up/down status is probably a bad idea. > OMG. This whole conversation degenerates into a rathole into which I never desired descend. Currently, in my gate, I _only_ log to syslog when a link state transitions as reported to the mac layer (and ultimately to the layers above it.) This means those transitions that _might_ trigger an upstream action (say, NWAM or IPMP actions) are logged. Change of speed/duplex settings, WEP keys, BSSIDs, etc. are all simply not interesting to most of those tools. And if they are, then they should darn well not be using syslog to get at it. I'm now wishing that I'd never ever undertaken to clean any of this up. As always, one cannot make everyone happy; and in this case I'm not even sure that I can make _anyone_ happy. One of these days I'll learn to quit tilting at windmills.... I wanted to clean up all the inconsistencies, wasteful logging, and simplify device drivers. Instead we've degenerated into conversations about politics at customer sites, commitment levels, and what is worthy of logging. The fact is that syslogs are HUMAN consumable. NOBODY should be depending upon their contents. Especially since we've had reasonable kstats and ndd for this stuff since at least Solaris 8. The very fact that a message is logged at all is just a courtesy, which is useful for the cases where someone plugs/unplugs a network, etc. I agree wholeheartedly with a link state change message. Anyway, I'm done arguing about this. Right now, the whole case was intended to be a volunteer effort to clean this crap up. Apparently some folks prefer to actually have the inconsistent crap, rather than use a real programmatic interface. I am going to flatly refuse to implement any of the 802.11 extended link information, or even consider anything except up/down in the logs for 802.11. If someone else wants to do it, they can take over the case and the effort ... its not worth my effort. I'll leave the PSARC case as it stands for now. If I get some kind of consensus from PSARC that it is worth doing then I'll commit what I have. Otherwise I give up. -- Garrett From casper@holland.sun.com Wed May 30 00:11:34 2007 Received: from sr1-eaft06-01.holland.sun.com (sr1-eaft06-01.Holland.Sun.COM [129.159.237.36]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U7BX2X022584 for ; Wed, 30 May 2007 00:11:33 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U7ADH4030324; Wed, 30 May 2007 09:10:13 +0200 (MEST) Message-Id: <200705300710.l4U7ADH4030324@sr1-eaft06-01.holland.sun.com> From: Casper.Dik@Sun.COM To: Nicolas Williams cc: "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <20070529232712.GF27420@Sun.COM> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <465CA7EA.1090902@sun.com> <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> <20070529232712.GF27420@Sun.COM> Date: Wed, 30 May 2007 09:10:13 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 815 >Agreed. But presumably the log message for wireless NIC state change >shouldn't be issued for every signal strength change! Just when signal >strength goes aboe zero (link up) or down to zero (link down). RIght. >What about the little button that some systems (laptops, mostly?) have >to enable/disable wireless? How should Solaris deal with that? Because >if I turn off wireless then I definitely want NWAM to do something about >that, but if signal strength temporarily falls to zero then I probably >don't want NWAM to do anything about that. So mapping both, that button >and signal strength to link up/down status is probably a bad idea. It may not be able to tell. (Even in Windows this generally seems to be done rather hackish as a rather large text is printed on top of everything else) Casper From Darren.Moffat@Sun.COM Wed May 30 01:01:34 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U81YE9023309 for ; Wed, 30 May 2007 01:01:34 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4U809bs006888 for ; Wed, 30 May 2007 01:00:10 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4U803wo024793 for ; Wed, 30 May 2007 08:00:04 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIU00L01GOOBM00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 09:00:03 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIU00FHFGVWPG20@d1-emea-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 08:59:57 +0100 (BST) Date: Wed, 30 May 2007 08:59:56 +0100 From: Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465C98AC.6050404@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Al Hopper , psarc-ext@sac.sfbay.sun.com Message-id: <465D2EFC.2060609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> <465C98AC.6050404@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 493 Garrett D'Amore wrote: > Actually, as I've already indicated, apart from being able to lay blame > on person who changed the settings, I don't understand why they are > useful _in the logs_. I may just be dense. Given that these are syslog logs one maybe viewing the log entry on a host other than the one that has that link (it might be an SMS message on your phone or an email), so it might not be trivial to run dladm to see what the current status actually is. -- Darren J Moffat From Garrett.Damore@Sun.COM Wed May 30 01:30:34 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U8UXtF023387 for ; Wed, 30 May 2007 01:30:33 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4U8TEXI014600 for ; Wed, 30 May 2007 01:29:14 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4U8T9Ga028268 for ; Wed, 30 May 2007 01:29:09 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIU00K01I7VN600@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 01:29:08 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIU00FUNI8KK2S5@d1-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 01:29:08 -0700 (PDT) Date: Wed, 30 May 2007 01:27:37 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465D2EFC.2060609@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Darren J Moffat Cc: Nicolas Williams , Al Hopper , psarc-ext@sac.sfbay.sun.com Message-id: <465D3579.5050902@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> <465C98AC.6050404@sun.com> <465D2EFC.2060609@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 5906 Darren J Moffat wrote: > Garrett D'Amore wrote: >> Actually, as I've already indicated, apart from being able to lay >> blame on person who changed the settings, I don't understand why they >> are useful _in the logs_. I may just be dense. > > Given that these are syslog logs one maybe viewing the log entry on a > host other than the one that has that link (it might be an SMS message > on your phone or an email), so it might not be trivial to run dladm to > see what the current status actually is. > SMS forwarding of your syslog contents... gak! if this is common practice nowadays, then I"m really glad I quit being a sysadmin about a decade ago. The typical syslog in a big network tends to have a lot of activity, more than I'd want to be sent to me via SMS or e-mail, unless it is filtered or consolidated somehow. The more I think about it, the more I realize that this whole mess really comes about because some geniuses insist on still forcing link speed and duplex instead of letting 802.3u autonegotiation do its job. I guess Sun contributed to the current mess at one time by shipping buggy 100Mbit implementations that didn't autonegotiate/NWay properly. I suspect that the problems that people are mostly concerned about are where the link duplex is incorrectly set. Again, probably because one side is trying to autonegotiate, but the other side is set to 100 full fuplex, forced, with 802.3u autonegotiation specifically disabled. The network engineers that insist on continuing to do this should probably be thwacked, but that's out-of-scope for this case. :-) I doubt the speed selection is nearly so much a problem. In any case, there is nothing inherently bad about half duplex (other than it may be performance limiting to a certain extent), as long as _both_ sides agree on the duplex setting. It is perfectly reasonable to have half duplex negotiated when a hub is inserted into the link, for example. The thing is, when you have it misconfigured, usually you'll be able to tell by, for example, getting collisions on a full-duplex link, or getting late collisions on a half duplex link. This situation can easily be correlated, and is a far better indication than just naively looking at the duplex state alone. And this is precisely the kind of analysis that FMA should be doing for the customer, rather than just leaving breadcrumbs in the syslogs. When FMA figures out that a misconfiguration likely exists, then _it_ can log the specific analysis rather than just this random clue "hey your link changed". (One could even try to be clever and have FMA self-repair this situation!) One other concern about logging link speed, is that as we move to greener systems, there is the idea that systems could auto-tune their link speed to save power. In low usage times, 10 or 100Mbit speeds consume a _lot_ less power than running a full 1G link. I suspect it is even more dramatic with 10G. The idea is to auto-tune based on cpu/network load. So one can imagine that even the link speeds might be altered without system administrator intervention. (Although that requires both link partners to properly support 802.3u autonegotiation!) So, here's the quick summary of pros/cons for logging extended details: Pro for logging extended link state data: * admins are used to it for most ethernet drivers * syslog is apparently more accessible for some administrators than the CLI tools for kstat/dladm * syslog allows historical data about link settings to be recorded Cons for logging extended link state data: * differences between link media/link types * probably not reasonable to log data for non-802.3 links * enables continued (ab)use of the syslog facility for programmatic notification * link data may be relatively volatile (e.g. power management changing speeds) * by itself, link duplex/state data is inadequate to properly diagnose faults * makes the framework aware of link media in ways that it is not already aware * duplicates (for non-historical uses) data already available via preferred kstat/dladm APIs I still really, really think continuing to log the link speed and duplex data is a bad idea. I'm starting to think logging _anything_ is questionable, but I understand that the cable connection events are interesting to watch in syslog. I'd really, really like to see folks agree to start with syslogging only link up/down (no speed/duplex), and follow it up with a proper FMA analysis of duplex related link errors... that we can actually perform a more meaningful analysis, and either offer or actually perform whatever corrective action is required. Ultimately, no matter _what_ we wind up doing, there are going to be a large number of people unhappy. Some vociferous users complain that we spam the logs, even as it is, and don't want more data there than absolutely necessary ... they'd be happiest with no syslog data at all for link events. Some vociferous users want even _more_ data in the logs, and complain about any reduction of the data that is there .... indeed some probably want more detail than we even provide today (such as 802.11 link details.) Some vociferous users/developers complain that the logged data is inconsistent, unparseable, if we do nothing to address it. Given that nobody (or at least very few) are going to be happy with anything we do (or do not do) in the short run, I'm inclined to follow the path that gives the greatest long term wins. I believe that the path suggested above (take the case as originally filed, and follow up with FMA analysis later) is architecturally the strongest, takes us in a direction we need to go, and carries a minimum of baggage with it. Ultimately at this point, the decision isn't mine though. But that's my recommendation. -- Garrett From casper@holland.sun.com Wed May 30 01:43:35 2007 Received: from sr1-eaft06-01.holland.sun.com (sr1-eaft06-01.Holland.Sun.COM [129.159.237.36]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U8hYGg023788 for ; Wed, 30 May 2007 01:43:35 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4U8gDk2014397; Wed, 30 May 2007 10:42:14 +0200 (MEST) Message-Id: <200705300842.l4U8gDk2014397@sr1-eaft06-01.holland.sun.com> From: Casper.Dik@Sun.COM To: "Garrett D'Amore" cc: Darren J Moffat , Nicolas Williams , Al Hopper , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465D3579.5050902@sun.com> References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <20070529204931.GX27420@Sun.COM> <465C98AC.6050404@sun.com> <465D2EFC.2060609@Sun.COM> <465D3579.5050902@sun.com> Date: Wed, 30 May 2007 10:42:13 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 2666 >The more I think about it, the more I realize that this whole mess >really comes about because some geniuses insist on still forcing link >speed and duplex instead of letting 802.3u autonegotiation do its job. >I guess Sun contributed to the current mess at one time by shipping >buggy 100Mbit implementations that didn't autonegotiate/NWay properly. As did many others; I remember we had tons of broken Cisco gear which needed firmware upgrades before it would work correctly. But even now I'm told Nortel recommends fixing the speed in their switches (which tells me that you should avoid their stuff at all cost) >I suspect that the problems that people are mostly concerned about are >where the link duplex is incorrectly set. Again, probably because one >side is trying to autonegotiate, but the other side is set to 100 full >fuplex, forced, with 802.3u autonegotiation specifically disabled. The >network engineers that insist on continuing to do this should probably >be thwacked, but that's out-of-scope for this case. :-) I doubt the >speed selection is nearly so much a problem. Perhaps dladm/ndd can print a message to the effect of "Disabling autonegotiation indicates that you have people working in your networking organization with an IQ under 80". >In any case, there is nothing inherently bad about half duplex (other >than it may be performance limiting to a certain extent), as long as >_both_ sides agree on the duplex setting. It is perfectly reasonable to >have half duplex negotiated when a hub is inserted into the link, for >example. > >The thing is, when you have it misconfigured, usually you'll be able to >tell by, for example, getting collisions on a full-duplex link, or >getting late collisions on a half duplex link. This situation can >easily be correlated, and is a far better indication than just naively >looking at the duplex state alone. Collission on a full duplex link? Wouldn't this be CRC errors (because as soon as you start sending the other side will stop and you will happily send your packet but the other packet will be short; how is this detected. >And this is precisely the kind of analysis that FMA should be doing for >the customer, rather than just leaving breadcrumbs in the syslogs. When >FMA figures out that a misconfiguration likely exists, then _it_ can log >the specific analysis rather than just this random clue "hey your link >changed". (One could even try to be clever and have FMA self-repair >this situation!) Absolutely; FMA could say "detected late collissions on half-duplex link, forcing full-duplex". Not sure how to go down to half-duplex. Casper From carlsonj@phorcys.east.sun.com Wed May 30 07:19:37 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UEJaZm028701 for ; Wed, 30 May 2007 07:19:37 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4UEIGPG006783; Wed, 30 May 2007 10:18:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4UEIFrA006780; Wed, 30 May 2007 10:18:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18013.34727.766821.24101@gargle.gargle.HOWL> Date: Wed, 30 May 2007 10:18:15 -0400 From: James Carlson To: John Plocher Cc: Gary Winiger , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@Sun.COM, Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: <465C989D.7070806@Sun.Com> References: <200705291456.l4TEuKsR022883@marduk.eng.sun.com> <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2356 John Plocher writes: > James Carlson wrote: > > That's exactly the point. Nobody has promised to provide anything > > other than human (English only!) readable messages here. The contents > > of the messages are no kind of programming interface. They're not > > documented anywhere. > > A quick search of docs.sun.com found several places where we > document these kinds of messages. I'm sure that there are others > on bigadmin as well... I was somehow led to believe that man pages define the stable interfaces on Solaris -- not admin guides, not bigadmin entries, and not blogs. > > If the Ethernet cable is plugged in, find out whether or not > > the Ethernet hub does a link integrity test. Then become > > superuser to check and possibly set the machine's NVRAM. If > > the hub's link integrity test is disabled, set this variable TPE? Is that the Solaris name for SQE? What a blast from the past. In any event, this part: > > # eeprom | grep tpe > > tpe-link-test?=true ... is wholly irrelevant. Doesn't exist on modern platforms. The newest one I can find that has this is an old Ultra 2. Good luck to anyone trying to rely on that. > > Programs that depend on them are engaging in hackery. > > I am not talking about programs that depend on these interfaces, > but humans who need this information themselves. We have trained > them over the years to look in syslog for this type of debugging > information. That part I agree with. But you were bringing up log-grovelling applications as a reason for keeping this data intact and for asserting that it's some sort of stable interface. > > That's exactly what this case is attempting to accomplish. The first > > step is getting those logging messages into the framework where (if > > they exist at all) they belong. > > I'd agree with all you have said, with the addition of > ... without losing the useful information already provided by > some of the drivers. Garrett's latest offer appears to do that. I'm not at all comfortable with it (I'd rather see the messages just plain torched), but it seems like a decent compromise. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Wed May 30 08:14:12 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UFEBxT000240 for ; Wed, 30 May 2007 08:14:11 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4UFBO0O000064; Wed, 30 May 2007 10:11:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4UFBODs000063; Wed, 30 May 2007 10:11:24 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 30 May 2007 10:11:24 -0500 From: Nicolas Williams To: James Carlson Cc: John Plocher , Gary Winiger , psarc-ext@sac.sfbay.sun.com, Garrett.Damore@sun.com, Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070530151123.GT27420@Sun.COM> References: <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18013.34727.766821.24101@gargle.gargle.HOWL> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 435 On Wed, May 30, 2007 at 10:18:15AM -0400, James Carlson wrote: > Garrett's latest offer appears to do that. I'm not at all comfortable > with it (I'd rather see the messages just plain torched), but it seems > like a decent compromise. The FMA idea is certainly appealing, and replacing this log message altogether would be good (as with SMF, sysadmins would just have to learn the new thing). But that sounds like a small project. From Garrett.Damore@Sun.COM Wed May 30 10:34:21 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UHYLXX007202 for ; Wed, 30 May 2007 10:34:21 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4UHX2m2008574 for ; Wed, 30 May 2007 10:33:02 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UHWu1D025567 for ; Wed, 30 May 2007 10:32:56 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIV001017EMAU00@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 10:32:56 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIV00F3A7EWK207@d1-sfbay-09.sun.com>; Wed, 30 May 2007 10:32:56 -0700 (PDT) Date: Wed, 30 May 2007 10:31:24 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <20070530151123.GT27420@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: James Carlson , John Plocher , Gary Winiger , psarc-ext@sac.sfbay.sun.com, Darren J Moffat Message-id: <465DB4EC.3060109@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 858 This case had its timeout extended another week, pending a final specification. The final specification I'm offering up is the original spec, with the following modifications: For 802.3 (ethernet links), link up messages will take the form: * bge0 link up, 100Mbps, full duplex (Adjusting speed and duplex type appropriately.) For all other media types, the link up message will only be: * ath0: link up (no speed, duplex, etc.) For all media, the message "link down" will be used upon loss of link. The interface stability of these messages is Not-An-Interface. They should not be consumed by any applications. It is expected that these logged messages will be removed altogether in the future, to be replaced by functionality to be provided by FMA. However, we are leaving that to be done in a future PSARC case. -- Garrett From Darren.Moffat@Sun.COM Wed May 30 10:49:20 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UHnKeB007583 for ; Wed, 30 May 2007 10:49:20 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4UHlxT3018575 for ; Wed, 30 May 2007 10:48:00 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UHlrYH017336 for ; Wed, 30 May 2007 17:47:54 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIV00C017ZOA600@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 18:47:53 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIV00L9083TRK10@d1-emea-09.sun.com>; Wed, 30 May 2007 18:47:53 +0100 (BST) Date: Wed, 30 May 2007 18:47:53 +0100 From: Darren J Moffat Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465DB4EC.3060109@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , James Carlson , John Plocher , Gary Winiger , psarc-ext@sac.sfbay.sun.com Message-id: <465DB8C9.5080309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <465C528A.6020804@Sun.COM> <18012.21775.45649.572535@gargle.gargle.HOWL> <465C57B9.9040004@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 276 Garrett D'Amore wrote: > This case had its timeout extended another week, pending a final > specification. > > The final specification I'm offering up is the original spec, with the > following modifications: I'm happy with the updated spec, thanks. -- Darren J Moffat From peter.tribble@gmail.com Wed May 30 10:57:04 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UHv3Hs008253 for ; Wed, 30 May 2007 10:57:04 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4UHthvf023562 for ; Wed, 30 May 2007 10:55:44 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UGAei1008994 for ; Wed, 30 May 2007 17:55:43 GMT Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay1.sun.com with ESMTP id BT-MMP-2507843 for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 17:55:43 Z Received: from relay03i.sun.com (ip74.net150143-60.block3.us.syntegra.com [150.143.60.74]) by mms05es.sun.com with ESMTP id BT-MMP-1110722 for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 17:55:42 Z Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by relay0i.sun.com with ESMTP id BT-MMP-3643759 for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 17:55:42 Z Received: from py-out-1112.google.com ([64.233.166.177] [64.233.166.177]) by relay4i.sun.com with ESMTP id BT-MMP-930453 for psarc-ext@sac.sfbay.sun.com; Wed, 30 May 2007 17:55:42 Z Received: by py-out-1112.google.com with SMTP id b50so3984771pyh for ; Wed, 30 May 2007 10:55:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l71wix06ARTd+DqA6wtJdm5D1CKqoQK89M3OeH+ba4TjQyCM+F4/1q+3q+0XjhpeWX9WKKLeJWRfiXU72p1kHjxs1OaDtPOsWX8rZexoe3eDbgrGRDhEv9H6sfGmSehFp/iO/5h5gYdXvB1xL8LWFHb9Tu2Lx1zCrSkhXH6nmic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PQz3/03QWHnAsJSROw4xWb0tUmwWlGhHpPH9unBkanICsJVnES9txnbjw2z9JCTnfy5tX3q/CS3GcgM2wiZldA3GbnIxrbZS+SBXUA+kDNYExAjMhB1RjDI++jY1MaC43LzkCMhFhQDOjQ4yPr53RQZT2WQSPUE+KJFz8Ymchw4= Received: by 10.65.97.18 with SMTP id z18mr15858360qbl.1180547741638; Wed, 30 May 2007 10:55:41 -0700 (PDT) Received: by 10.65.43.7 with HTTP; Wed, 30 May 2007 10:55:41 -0700 (PDT) Message-Id: Date: Wed, 30 May 2007 18:55:41 +0100 From: "Peter Tribble" To: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Cc: psarc-ext@sac.sfbay.sun.com In-Reply-To: <465DB4EC.3060109@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465C528A.6020804@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> Status: RO Content-Length: 544 On 5/30/07, Garrett D'Amore wrote: > This case had its timeout extended another week, pending a final > specification. > > The final specification I'm offering up is the original spec, with the > following modifications: > > For 802.3 (ethernet links), link up messages will take the form: > > * bge0 link up, 100Mbps, full duplex > > (Adjusting speed and duplex type appropriately.) Thanks! I'm happy with the proposal like this. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Nicolas.Williams@sun.com Wed May 30 11:04:15 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UI4Fiu008355 for ; Wed, 30 May 2007 11:04:15 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4UI1UiM000236; Wed, 30 May 2007 13:01:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4UI1UDb000235; Wed, 30 May 2007 13:01:30 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 30 May 2007 13:01:30 -0500 From: Nicolas Williams To: Peter Tribble Cc: "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Message-ID: <20070530180129.GA27420@Sun.COM> References: <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Status: RO Content-Length: 347 On Wed, May 30, 2007 at 06:55:41PM +0100, Peter Tribble wrote: > Thanks! I'm happy with the proposal like this. Me three. Anyone wanting the ESSID logged in the wireless media case will probably have to take it upon themselves to do it, and then because it would be adding something new, may run into arguments about better ways to handle that. From al@logical-approach.com Wed May 30 11:04:46 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UI4kDI008371 for ; Wed, 30 May 2007 11:04:46 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4UI3Qxa029055 for ; Wed, 30 May 2007 11:03:26 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UGAfOu006944 for ; Wed, 30 May 2007 18:03:26 GMT Received: from mms04es.sun.com ([150.143.104.74] [150.143.104.74]) by relay1.sun.com with ESMTP id BT-MMP-2509216; Wed, 30 May 2007 18:03:25 Z Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms04es.sun.com with ESMTP id BT-MMP-1090892; Wed, 30 May 2007 18:03:25 Z Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay3.sun.com with ESMTP id BT-MMP-5587664; Wed, 30 May 2007 18:03:24 Z Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l4UI3OK4006629; Wed, 30 May 2007 13:03:24 -0500 (CDT) Date: Wed, 30 May 2007 13:03:24 -0500 (CDT) From: Al Hopper To: "Garrett D'Amore" cc: psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: Message-Id: References: <465C528A.6020804@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 915 On Wed, 30 May 2007, Peter Tribble wrote: > On 5/30/07, Garrett D'Amore wrote: >> This case had its timeout extended another week, pending a final >> specification. >> >> The final specification I'm offering up is the original spec, with the >> following modifications: >> >> For 802.3 (ethernet links), link up messages will take the form: >> >> * bge0 link up, 100Mbps, full duplex >> >> (Adjusting speed and duplex type appropriately.) > > Thanks! I'm happy with the proposal like this. +1 Excellent - Thanks a bunch Garrett for all the time and effort you've put into this case. I admire your tenacity! Regards, Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ From daleg@elemental.org Wed May 30 11:09:43 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UI9hgZ008573 for ; Wed, 30 May 2007 11:09:43 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4UI8NXK002329 for ; Wed, 30 May 2007 11:08:23 -0700 (PDT) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4UFaI7o008520 for ; Wed, 30 May 2007 18:08:23 GMT Received: from mms03es.sun.com ([150.143.104.54] [150.143.104.54]) by relay3.sun.com with ESMTP id BT-MMP-916062; Wed, 30 May 2007 18:08:22 Z Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms03es.sun.com with ESMTP id BT-MMP-1829923; Wed, 30 May 2007 18:08:22 Z Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by relay4.sun.com with ESMTP id BT-MMP-5485904; Wed, 30 May 2007 18:08:22 Z Received: from lithium.elemental.org ([130.85.5.200] [130.85.5.200]) by relay4i.sun.com with ESMTP id BT-MMP-933869; Wed, 30 May 2007 18:08:22 Z Received: from [130.85.70.33] (deuterium.ucs.umbc.edu [130.85.70.33]) (authenticated bits=0) by lithium.elemental.org (8.13.8/8.13.8/ELEMENTAL-3.1) with ESMTP id l4UI8LWb027113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2007 14:08:21 -0400 (EDT) In-Reply-To: <20070530180129.GA27420@Sun.COM> References: <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> <20070530180129.GA27420@Sun.COM> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B96C705-06BF-4F28-8EAB-0FAFBB23E408@elemental.org> Cc: psarc-ext@sac.sfbay.sun.com Content-Transfer-Encoding: 7bit From: Dale Ghent Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] Date: Wed, 30 May 2007 14:08:20 -0400 To: "Garrett D'Amore" X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (lithium.elemental.org [130.85.5.200]); Wed, 30 May 2007 14:08:21 -0400 (EDT) Status: RO Content-Length: 455 On May 30, 2007, at 2:01 PM, Nicolas Williams wrote: > On Wed, May 30, 2007 at 06:55:41PM +0100, Peter Tribble wrote: >> Thanks! I'm happy with the proposal like this. > > Me three. I like it, too. > Anyone wanting the ESSID logged in the wireless media case will > probably > have to take it upon themselves to do it, and then because it would be > adding something new, may run into arguments about better ways to > handle > that. Ditto. /dale From carlsonj@phorcys.east.sun.com Wed May 30 11:11:51 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4UIBoEb008653 for ; Wed, 30 May 2007 11:11:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4UIAUae008211; Wed, 30 May 2007 14:10:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l4UIAUxY008208; Wed, 30 May 2007 14:10:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18013.48662.187022.382206@gargle.gargle.HOWL> Date: Wed, 30 May 2007 14:10:30 -0400 From: James Carlson To: Al Hopper Cc: "Garrett D'Amore" , psarc-ext@sac.sfbay.sun.com Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-Reply-To: References: <465C528A.6020804@Sun.COM> <18012.23674.549208.885858@gargle.gargle.HOWL> <465C703E.2020104@Sun.Com> <18012.31338.843884.679817@gargle.gargle.HOWL> <18012.36748.60045.403116@gargle.gargle.HOWL> <465C989D.7070806@Sun.Com> <18013.34727.766821.24101@gargle.gargle.HOWL> <20070530151123.GT27420@Sun.COM> <465DB4EC.3060109@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 472 Al Hopper writes: > Excellent - Thanks a bunch Garrett for all the time and effort you've > put into this case. I admire your tenacity! I generally don't do this on the PSARC list, but "+1". This seems like the best solution available for now. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@Sun.COM Fri Jun 1 19:59:01 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l522x1qf028523; Fri, 1 Jun 2007 19:59:01 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l522vdWa023525; Fri, 1 Jun 2007 19:57:39 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l522vYQd014946; Fri, 1 Jun 2007 19:57:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JIZ00D01MTKVX00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Fri, 01 Jun 2007 19:57:34 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JIZ00ISRMVYHL80@fe-sfbay-09.sun.com>; Fri, 01 Jun 2007 19:57:34 -0700 (PDT) Date: Fri, 01 Jun 2007 19:55:57 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> Sender: Garrett.Damore@Sun.COM To: "Garrett D'Amore - sun microsystems" Cc: psarc-ext@sac.sfbay.sun.com Message-id: <4660DC3D.107@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 669 FYI, in addition to updating the spec to log the link details for ethernet, I had to add a new mac plugin operation to facilitate this. This is an extension to the Consolidation Private interface specified by PSARC 2006/248. A revised spec for the nemo plugin API is provided in the case materials directory, along with a diff file for the changes. I've also supplied an edited "spec" in the materials directory, which captures the final state at which we have arrived. Hopefully this is non-controversial enough at this point, that the case can be approved and I can commit the changes. (Codereview and testing are complete at this stage.) -- Garrett From Garrett.Damore@Sun.COM Wed Jun 6 10:57:29 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l56HvTrC016210 for ; Wed, 6 Jun 2007 10:57:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l56Hu451024179 for ; Wed, 6 Jun 2007 10:56:04 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l56HtxV9007921 for ; Wed, 6 Jun 2007 10:55:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJ8006016G6UO00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 06 Jun 2007 10:55:59 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJ800GCQ7534740@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 06 Jun 2007 10:55:52 -0700 (PDT) Date: Wed, 06 Jun 2007 10:54:05 -0700 From: "Garrett D'Amore" Subject: Re: GLDv3 link status logging [PSARC/2007/298 Self Review] In-reply-to: <465CBCDA.7040707@sun.com> Sender: Garrett.Damore@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Casper.Dik@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <4666F4BD.20906@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200705241530.l4OFUF2o002606@sac.sfbay.sun.com> <4659AC84.2080104@sun.com> <200705271634.l4RGY9q0047156@sr1-eaft06-01.holland.sun.com> <4659B8C5.5060607@sun.com> <465C8F01.7070200@sun.com> <465CA7EA.1090902@sun.com> <200705292230.l4TMUlLp002243@sr1-eaft06-01.holland.sun.com> <20070529232712.GF27420@Sun.COM> <465CBCDA.7040707@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 60 FYI, this case was approved at PSARC today. -- Garrett