This is well-documented in the 8.1 System Administration Guide, as well as on-box man pages. https://library.netapp.com/ecmdocs/ECMP1136573/html/frameset.html Look in Monitoring the storage system --> Managing AutoSupport --> AutoSupport Options In short: autosupport.noteto sends a very short e-mail that just contains the AutoSupport subject line to the listed e-mail recipients. It is potentially filtered (see: autosupport triggers) autosupport.partner.to sends complete AutoSupport messages to the listed e-mail recipients. It is not filtered (same ASUP messages as one sent to NetApp Support) autosupport.performance_data.doit is a command to collect performance statistics and send as PERFORMANCE SNAPSHOT AutoSupport messages, on-demand. Similar in concept to the autosupport.doit command that sends USER_TRIGGERED AutoSupport messages. autosupport.performance_data.enable controls whether PERFORMANCE DATA is sent to NetApp Support and partner.to destinations (except there's a bug with partner.to).
... View more
When you speak of "viewing", are you referring to the NetApp Support site's page "My Support" -> "Systems", or are you referring to the My AutoSupport portal? In either case, the best recommendation for you and your customer is to open a ticket via the support site's "Feedback" page, and be ready to supply the serial numbers of the missing systems. https://support.netapp.com/eservice/assistant
... View more
Kevin, PERFORMANCE DATA and MANAGEMENT LOG is now sent daily, in order to smooth out the Sunday traffic and minimize the potential for information being truncated in the WEEKLY LOG. WEEKLY LOG no longer contains any log files. They are sent exclusively by MANAGEMENT LOG daily. MANAGEMENT LOG is very important for NetApp to receive for system diagnosis during technical cases, as well as for detection of system risks. PERFORMANCE DATA is required for performance trending and to provide the performance graphs in My AutoSupport. NetApp recommends that you allow both to be sent daily. MANAGEMENT LOG cannot be individually controlled for sending to NetApp. PERFORMANCE DATA can be controlled by the "options autosupport.performance_data.enable" command. Are you specifying e-mail addresses via "autosupport.partner.to"? If that is how you are seeing these AutoSupport e-mails, then see Bug 605902 http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=605902 This bug describes a regression where partner.to e-mail destinations always receive PERFORMANCE DATA, regardless of the options setting.
... View more
You're saying that you don't have a support contract, so you can't call NetApp Tech Support? Do you have access to the NetApp Support Site with a login ID? Our knowledgebase and documentation would be able to provide guidance. In any case, you picked the wrong community forum, unfortunately. I'd recommend you repost your message to this forum, instead. https://communities.netapp.com/community/products_and_solutions/data_ontap Regards, -Andris
... View more
7-mode? Try looking at the /etc/log/mlog/notifyd.log files to see more detailed information about the AutoSupport process. If you ask the support engineer to open a consult request in our internal AutoSupport knowledge exchange, folks like Rudy might be able to help out further.
... View more
I missed the My AutoSupport angle... sorry. There isn't a storage trending report in My AutoSupport, unfortunately. I'll pass on your request to the Product Manager.
... View more
This isn't the right forum for this question... nonetheless, assuming you have Field Portal login credentials, please go here for more information: https://fieldportal.netapp.com/search/?query=PartnerEdge
... View more
To comment on the daily transmissions of AutoSupport... management logs and performance data were changed to daily transmissions to smooth out the (potentially large) amount of information over the week. Previous to 8.1, this information was sent in one large message on Sunday. This occasionally created excessive mail message sizes for SMTP and HTTP servers and was also causing stress on the reception side at NetApp. We're still sending the same level of information as before, but we're now splitting it up into 7 daily "chunks". Another improvement with 8.1 log file collection for AutoSupport involves keeping track of the last collected log entries. They are not resent in subsequent messages, eliminating redundant information from being sent.
... View more
The "wrench" or management Ethernet port on the back of your system provides access to two internal interfaces 1. e0M: an interface you can use to manage your system via TCP/IP protocols (e.g. ssh, snmp, telnet, ONTAPI, etc.) 2. SP: an interface on your service processor - very handy for out-of-band management (remote access to your console port, power control, monitoring of your system) Since they're physically behind a common ethernet port, they need to be on the same IP subnet. In addition, as you saw from syslog, that subnet should be dedicated - not shared with your data-serving GigE interfaces. Based on your IP subnet descriptions, it looks like you've done that. Note: If all of your ethernet connections are going into single switch, you must use VLANs by assigning a VLAN per subnet (and placing the right switch ports for each subnet into the right VLAN). This is required to get true L2 Ethernet isolation between subnets. The #5 in the diagram port is called the "private management" port. The interface behind that port is e0P (P = private). This port is exclusively used for connecting the Alternate Control Path (ACP) Ethernet cables to external NetApp storage shelves (e.g. DS4243) for out-of-band recovery and management from the controller (via the e0P interface). Do you have external shelves? Then we recommend that you set up the ACP ethernet cabling and enable ACP. See: Universal SAS and ACP Cabling Guide
... View more
Please provide the source of this text (link, doc, etc.). The .to destinations will not receive all AutoSupport messages. They are filtered by default rules in Data ONTAP. In 8.0 and later, the customer can tweak those rules with CLI commands.
... View more
Ken, et al. Please report any additional issues via the Feedback link on the Support Site. http://support.netapp.com/eservice/assistant Thank you very much for your feedback. -Andris
... View more
Protocol services by default would be available on all interfaces (some specific limits are placed on the e0M interface, if you have one on your platform). Every tagged VLAN on the VIF would be an "interface", yes. Since you were bothering to separate different protocols with different interface, it sounded like a good idea. https://kb.netapp.com/support/index?page=content&id=3011652 This TR covers this topic: Best Practices for Secure Configuration of Data ONTAP 7G http://media.netapp.com/documents/tr-3649.pdf
... View more
1. AutoSupport information in the Data ONTAP 8.1 System Administration Guide has been updated with good information. 2. Try "man autosupport" from the CLI. 3. The AutoSupport page on the support site has a very nice FAQ. This topic is covered, I believe. http://support.netapp.com/NOW/knowledge/docs/olio/autosupport/
... View more
Kevin, et al. Is the ACP subnet issue being tracked with a bug#? Please provide the number. Or, did you open a technical case and ask for a bug to be opened? If not, please do so. Thanks.
... View more
The customer we built the "D" patch for is successfully sending SMTP via Exchange with it. Perhaps, for your situation, there are other factors at play? Please feel free to open a technical case to pursue this further. In any case, 8.1RC3 is a recommended update to anyone running 8.1RC2 at this time. I think we're spending way too much time talking about a D patch.
... View more
Thank you for clarifying the source of the declaration. I check the D6 fix notes and it is listed there. It should work with that D-Patch, as well.
... View more
Yes, to keep things consistent, I would use tagged VLAN's for all 3 subnets on the VIF and configure your network switch accordingly. You should use interface-specific control for your protocols, too. https://kb.netapp.com/support/index?page=content&id=3011652 Please don't forget to update your /etc/rc file with all of the interface changes. Yes, there's no problem with the filer being multi-homed to multiple IP subnets. 2 considerations to remember: - Your default route should point out the public subnet to that subnet's gateway. - The NFS and iSCSI subnets don't need the default route, as long as all of your hosts are local to those subnets. Correct. Bug 446493 is fixed in 7.3.5.1P1 or later. You are still at risk.
... View more