We've got a situation where our company (Loudcloud, Inc.) has a filer reporting the same SYSTEM_ID as a filer from another company (Toshiba). Recently, Toshiba's filer threw a disk and sent in an autosupport mail. Netapp was kind enough to open a ticket, and assign it to Loudcloud, Inc. Oops. Apparently, whatever parses the autosupport mail at NetApp uses the SYSTEM_ID to map the NetApp to an account (service contract).
So, my questions are:
- Where does DOT grab the SYSTEM_ID from? The NVRAM card? The motherboard?
- Is the SYSTEM_ID burned electronically into the system at NetApp, or can it be reset in the field?
- Are the duplicate SYSTEM_ID's an accident?
Thanks.
j. -- Jay Soffian System Administrator 408 744 7584 Loudcloud, Inc.
On Fri, Mar 08, 2002 at 02:46:25PM -0800, Jay Soffian wrote:
We've got a situation where our company (Loudcloud, Inc.) has a filer reporting the same SYSTEM_ID as a filer from another company (Toshiba). Recently, Toshiba's filer threw a disk and sent in an autosupport mail. Netapp was kind enough to open a ticket, and assign it to Loudcloud, Inc. Oops. Apparently, whatever parses the autosupport mail at NetApp uses the SYSTEM_ID to map the NetApp to an account (service contract).
I've seen similar things happen to us twice recently.
So, my questions are:
- Where does DOT grab the SYSTEM_ID from? The NVRAM card? The motherboard?
It depends on the system (some do not have NVRAM cards), but I think it's always from the NVRAM card, if it's present. If you ever swap an NVRAM card, a form is included that you're to return with the old card, which NetApp is supposed to use to update their database. In our case, this did not happen. We noticed the problem when the system was listed one they were not getting autosupport from, via the NOW site, so we opened another case to get them to update their database.
- Is the SYSTEM_ID burned electronically into the system at NetApp, or can it be reset in the field?
I don't believe it can be reset, but they can update their database to reflect the correct assignment.
- Are the duplicate SYSTEM_ID's an accident?
My guess is that it isn't really duplicate, but that NetApp has the incorrect System ID in their database for the filer at Toshiba. This problem happened to us with one of our NetCaches after another RMA. They claimed it was assigned to AT&T, but once we provided "sysconfig -v" output from our system to show them otherwise, they were able to clear it up within a couple of weeks. I suggest you open a case and try the same.
Karl Larson Tellme Networks
"KL" == Karl Larson karl@tellme.com writes:
- Are the duplicate SYSTEM_ID's an accident?
KL> My guess is that it isn't really duplicate, but that NetApp has KL> the incorrect System ID in their database for the filer at KL> Toshiba.
Nope, it's a duplicate. I got NetApp to forward me the autosupport message from the Toshiba filer and compared it to the autosupport from our filer.
In any case, I did get a call from NetApp. As it was explained to me, the SYSTEM_ID is a computed value based upon the NVRAM serial number and a serial number that is embedded on the filer backplane (backplane is probably a misnomer; there is a PCB at the front of the filer that the motherboard plugs in to). At least, this is how it works for the F700 series.
It turns out the easiest solution in this case is to swap the NVRAM card in our filer.
j. -- Jay Soffian System Administrator 408 744 7584 Loudcloud, Inc.
On Fri, Mar 08, 2002 at 02:46:25PM -0800, Jay Soffian wrote:
- Where does DOT grab the SYSTEM_ID from? The NVRAM card? The motherboard?
There are, for various historical reasons, several different system identification numbers for NetApp systems.
I will give details on all of them, but will assume that by "SYSTEM_ID" you mean what is reported as "SYSTEM_ID=XXX" in autosupport mail; that comes from the NVRAM card.
The original one, which is what is reported as "SYSTEM_ID=XXX" in autosupport mail, comes, on any NetApp system with an NVRAM card, *purely* from the NVRAM card - *none* of it comes from the motherboard or the chassis.
On NetApp systems *without* NVRAM cards - i.e., C1100 and C1105 NetCache appliances - the "SYSTEM_ID" value is generated from the system serial number. That is not the case on any other platforms.
That serial number, obviously, is not guaranteed to remain the same throughout the life of the system, as the NVRAM card can be replaced if it fails.
With the F7xx/C7xx series, a serial number was put on the motherboard. Unfortunately, that's subject to change over the life of the system as well, as the motherboard is also replaceable.
The C1100 and C1105 also have a serial "number" on the motherboard (I put "number" in quotes as it's not numeric - it includes letters); however, as the only replaceable unit on a C1100 or C1105 is the entire system, that number won't change for a system. (That's the number used to generate the "SYSTEM_ID" value.)
I don't know whether the F85 and F87 provide a motherboard serial number.
The motherboard serial number shows up in "sysconfig -v" output under "slot 0: System Board" as "Serial Number" on those platforms, at least in ONTAP 6.0/6.1 and NetCache 5.0/5.1/5.2 (I haven't checked what earlier releases do).
With the F8xx/C3xxx/C6xxx series, a serial number was also put on the chassis. If you replace the chassis, you've replaced the system, so that number doesn't change over the life of the system. (Those machines also have a motherboard serial number.)
On the C1100/C1105, I no longer remember whether separate motherboard and system serial numbers exist (not that it matters in the grander scheme of things, given that the motherboard isn't replaceable).
I don't *think* the F85 and F87 have chassis serial numbers.
At least in ONTAP 6.1 and NetCache 5.0/5.1/5.2, if a system has a chassis (system) serial number, it'll be reported by "sysconfig" (with or without "-v") as "System Serial Number".
In autosupport mail in ONTAP 6.0/6.1 and NetCache 5.0/5.1/5.2:
on systems with a chassis serial number, that number will be reported after the
===== SYSTEM SERIAL NUMBER =====
line as
system serial number = XXX
on systems *without* a chassis serial number, but with an "/etc/serialnum" file, the text in the first line of that file will be reported after the
===== SYSTEM SERIAL NUMBER =====
line as
system serial number = XXX
on systems with neither a chassis serial number nor an "/etc/serialnum" file, there will be no
===== SYSTEM SERIAL NUMBER =====
or
system serial number = XXX
line in the autosupport mail.
("/etc/serialnum" will *not* override the chassis serial number.)
- Is the SYSTEM_ID burned electronically into the system at NetApp, or can it be reset in the field?
The NVRAM serial number is burned electronically into the NVRAM card, and isn't reset in the field.
- Are the duplicate SYSTEM_ID's an accident?
Yes. It's not supposed to happen.
-
Guy Harris -
Jay Soffian -
Karl Larson