i thought this only set the delivery method directly to netapp? i have autosupport.support.transport https set but i also have mailhost, to/from set and i get all the normal autosupport mails in addition to the https post sent directly to netapp.

-- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404

310-309-4999 desk 310-430-0536 cell

-----Original Message----- From: owner-toasters@mathworks.com on behalf of Geissler, Norbert Sent: Tue 2/12/2008 10:05 AM To: Daniel Keisling; toasters@mathworks.com Subject: AW: Autosupport failing to mailhost

Hi,

does Exchange 2003 support https connection ?

autosupport.support.transport https

if not, try changing to

option autosupport.support.transport smtp

Good luck, Norbert Geissler

Siemens AG Siemens IT Solutions and Services Global Operations SIS GO GIO DS G SU1 Otto-Hahn-Ring 6 81739 München Tel.: +49 (89) 636-48132 Fax: +49 (89) 636-28889 Mobil: +49 (170) 9157829 mailto:norbert.geissler@siemens.com mailto:norbert.geissler@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Erich R. Reinhardt, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Sitz der Gesellschaft: Berlin und München; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

________________________________

Von: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] Im Auftrag von Daniel Keisling Gesendet: Dienstag, 12. Februar 2008 17:23 An: toasters@mathworks.com Betreff: Autosupport failing to mailhost

Hello,

From what seems out of the blue, Autosupport emails are no longer able to be sent to my mailhost (Exchange 2003 on the same subnet):

"Autosupport cannot connect to host rtpmail01.americas.ppdi.local (Network comm problem) for message: USER_TRIGGERED (TEST)"

This message will be thrown until the message is eventually dropped. My Exchange administrator does not see any connections coming from the filer to send this email. I can ping the mailhost with no problem:

rtpstore2b> ping rtpmail01.americas.ppdi.local rtpmail01.americas.ppdi.local is alive

My routing table:

Destination Gateway Flags Refs Use Interface default 172.20.63.254 UGS 4 222239 e0a 127 localhost UGS 0 22236 lo localhost localhost UH 3 145 lo 172.20.62/23 link#4 UC 0 0 e0a rtpmail01.americ 0:8:2:28:ee:86 UHL 0 11 e0a rtpexchbe01.amer 0:8:2:28:ee:86 UHL 0 0 e0a rtpstore2b 0:a0:98:9:66:53 UHL 0 18112 lo

My autosupport options:

rtpstore2b> options autosupport autosupport.cifs.verbose off autosupport.content complete autosupport.doit DONT autosupport.enable on autosupport.from rtpstore2b at rtp.ppdi.com mailto:rtpstore2b@rtp.ppdi.com autosupport.local.nht_data.enable off autosupport.local.performance_data.enable off autosupport.mailhost rtpmail01.americas.ppdi.local autosupport.minimal.subject.id hostname autosupport.nht_data.enable on autosupport.noteto autosupport.performance_data.enable on autosupport.retry.count 15 (value might be overwritten in takeover) autosupport.retry.interval 4m (value might be overwritten in takeover) autosupport.support.enable on autosupport.support.proxy autosupport.support.to autosupport at netapp.com mailto:autosupport@netapp.com autosupport.support.transport https autosupport.support.url support.netapp.com/asupprod/post/1.0/postAsup autosupport.throttle on autosupport.to storage at wilm.ppdi.com mailto:storage@wilm.ppdi.com

(I've replaced the @'s with 'at')

I have no problems with my SSH session, so I don't know how this could be a network cable/connection problem. Are there any debugging steps I can do? Has anyone seen this before? It has definitely worked in the past. This is DOT 7.2.2 on a FAS3040.

TIA,

Daniel

______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.

Hi DanielVery good point. I have done a bit more digging and find this article on the NOW site:https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb13968 So it does indeed look like that this autosupport.support.transport setting only applies to mail for netapp and that addresses in your autosupport.to should indeed always be sent via smtp. I think this must have changed sometime around 7.0.Looking at the error you see, Autosupport cannot connect to host rtpmail01.americas.ppdi.local (Network comm problem) for message: USER_TRIGGERED (TEST) it does sound like some device is blocking a connection between the filer and exchange server.At this stage I would make a packet trace on the filer as follows:pktt start all -d / -i rtpmail01.americas.ppdi.localoptions autosupport.doit TESTWait for the error message thenpktt stop allI don't know how well you know TCP; If you send me the trace I would be happy to look at it; what you will be interested in seeing isa) whether any attempt at all is made to connect to the exchange serverb) if so is it to port 80 (http), port 443 (https) or smtp (25)c) If you see a bunch of SYN's with no replies or a reply of a RST ACK then there is most likely a firewall blocking the path.SMTP is plain text so if there is a SMTP connection which goes wrong somewhere you are quite likely to see an error telling you what's wrong which you could then share with your Exchange admin.Hope this helps -- let us know your findings,cheers,KennethSubject: RE: Autosupport failing to mailhostDate: Tue, 12 Feb 2008 13:07:52 -0600From: daniel.keisling@austin.ppdi.comTo: kheal@hotmail.com; toasters@mathworks.com

Does the autosupport.support.transport option only use smtp or https when delivering to NetApp? In this case (https), it works fine. NetApp is receiving my autosupports.

What's not working is local mail to me. I tried this on another filer at another site (except for the mailhost (another Exchange 2003 server), all the autosupport settings are the same) and the email to my local account came immediately, as well as a notification from NetApp. The log even said:

Feb 12 14:11:57 EST [wilstore2a: asup.smtp.sent:notice]: Cluster Notification mail sent: Cluster Notification from wilstore2a (USER_TRIGGERED (testing_from_wilstore)) INFO

This was definitely sent via smtp, yet the autosupport.support.transport is set to https. Daniel

From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Kenneth HealSent: Tuesday, February 12, 2008 12:33 PMTo: Daniel Keisling; toasters@mathworks.comSubject: RE: Autosupport failing to mailhost

Hi DanielI see a line which saysautosupport.support.transport httpsWhich means the filer will use https to send autosupports, and not smtp.Can you tryoptions autosupport.support.transport smtpAnd see if the mails go through?cheersKennethKenneth HealDatabasement BVThe Netherlands

Subject: Autosupport failing to mailhostDate: Tue, 12 Feb 2008 10:22:51 -0600From: daniel.keisling@austin.ppdi.comTo: toasters@mathworks.com

Hello,

From what seems out of the blue, Autosupport emails are no longer able to be sent to my mailhost (Exchange 2003 on the same subnet):

"Autosupport cannot connect to host rtpmail01.americas.ppdi.local (Network comm problem) for message: USER_TRIGGERED (TEST)"

This message will be thrown until the message is eventually dropped. My Exchange administrator does not see any connections coming from the filer to send this email. I can ping the mailhost with no problem:

rtpstore2b> ping rtpmail01.americas.ppdi.localrtpmail01.americas.ppdi.local is alive My routing table:

Destination Gateway Flags Refs Use Interfacedefault 172.20.63.254 UGS 4 222239 e0a127 localhost UGS 0 22236 lolocalhost localhost UH 3 145 lo172.20.62/23 link#4 UC 0 0 e0artpmail01.americ 0:8:2:28:ee:86 UHL 0 11 e0artpexchbe01.amer 0:8:2:28:ee:86 UHL 0 0 e0artpstore2b 0:a0:98:9:66:53 UHL 0 18112 lo My autosupport options:

rtpstore2b> options autosupportautosupport.cifs.verbose offautosupport.content completeautosupport.doit DONTautosupport.enable onautosupport.from rtpstore2b at rtp.ppdi.comautosupport.local.nht_data.enable offautosupport.local.performance_data.enable offautosupport.mailhost rtpmail01.americas.ppdi.localautosupport.minimal.subject.id hostnameautosupport.nht_data.enable onautosupport.notetoautosupport.performance_data.enable onautosupport.retry.count 15 (value might be overwritten in takeover)autosupport.retry.interval 4m (value might be overwritten in takeover)autosupport.support.enable onautosupport.support.proxyautosupport.support.to autosupport at netapp.comautosupport.support.transport httpsautosupport.support.url support.netapp.com/asupprod/post/1.0/postAsupautosupport.throttle onautosupport.to storage at wilm.ppdi.com (I've replaced the @'s with 'at')

I have no problems with my SSH session, so I don't know how this could be a network cable/connection problem. Are there any debugging steps I can do? Has anyone seen this before? It has definitely worked in the past. This is DOT 7.2.2 on a FAS3040.

TIA,

Daniel

______________________________________________________________________This email transmission and any documents, files or previous emailmessages attached to it may contain information that is confidential orlegally privileged. If you are not the intended recipient or a personresponsible for delivering this transmission to the intended recipient,you are hereby notified that you must not read this transmission andthat any disclosure, copying, printing, distribution or use of thistransmission is strictly prohibited. If you have received this transmissionin error, please immediately notify the sender by telephone or return emailand delete the original transmission and its attachments without readingor saving in any manner.

Express yourself instantly with MSN Messenger! MSN Messenger ______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.

_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

I'm still at a loss for this issue. Beginning last Wednesday, the Exchange administrator failed the cluster over to another node and all subsequent autosupport tests started working perfectly. I assumed that the other node was the problem, so we again made it the active node on Friday to do more tests. Surprisingly, all autosupport tests and my weekly log email have worked fine (as well as a test today). I don't know if the act of failing the cluster to the other node fixed something, but it's back to working again. It seems this issue only pops up once a month, lasts 3-4 days, then disappears again.

We're having some nasty autosupport issues too. The symptoms are somewhat different from what you described. We were pointed at this:

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=263066

The bug report is typically lacking in real information. The bottom line is that once a filer is affected by this bug, the only way out is to change the autosupport.transport to http or smtp, and _REBOOT_. So much for high availability. The scheduled release for a fix is 7.2.5.

Ok...I've read the rest of this thread and I see your filer is generating autosupports and they're getting to NetApp, but not to you. We've been bitten by this in the past, too. First of all, get rid of the Exchange Server. ;) Ok, if you can, point to a Sendmail or other SMTP relay. And check the logs, if they're available to you (gotta love the logs on Exchange...). We found that ours were getting rejected on our MTA because of our self-imposed message-size limit (10MB), which was readily discovered in Sendmail logs. Some of these autosupports are huge. Try setting the autosupport.content option to "minimal" ('options autosupport.content minimal), and generating another test. If you get it, you've found the culprit.

-Kevin

*------------------------------------------*-----------------------* | Kevin Davis (UNIX/Storage Sysadmin) | Natick, Massachusetts | | 508.647.7660 | 01760-2098 | | mailto:kevin.davis@mathworks.com *-----------------------* | http://www.mathworks.com | | *------------------------------------------*-----------------------*

Try the following from another machine on the same subnet of the filer

telnet $MAILHOST 25 Helo itsme

250 OK <--- SERVER RESPONSE

MAIL FROM: $AUTOSUPPORT_FROM address (The address you've configured for options autosupport.from)

250 OK <--- SERVER RESPONSE

RCPT TO: $YOUR_EMAIL_ADDRESS

250 OK <--- SERVER RESPONSE

DATA test test test test . <---- final dot and \r\n

250 ok <--- SERVER RESPONSE.

If you can't connect at all, or the exchange server says something other than 250 OK then you've either got a network or name resolution problem (can't connect at all) or the Exchange server is not allowing you to relay (Probably some error message like 550 Relaying Denied.)

If the mailserver gives you a 250, then it's accepted responsibility for delivering the email.

~Max

On Feb 12, 2008, at 11:43 AM, Clark, Andre wrote:

Exchange is set up not to be an open relay. You need to add your system’s IP address to the Exchange server you are using to allow the SMTP messages to go through.

AC

From: owner-toasters@mathworks.com [mailto:owner- toasters@mathworks.com] On Behalf Of Daniel Keisling Sent: Tuesday, February 12, 2008 14:08 To: Kenneth Heal; toasters@mathworks.com Subject: RE: Autosupport failing to mailhost

Does the autosupport.support.transport option only use smtp or https when delivering to NetApp? In this case (https), it works fine. NetApp is receiving my autosupports.

What's not working is local mail to me. I tried this on another filer at another site (except for the mailhost (another Exchange 2003 server), all the autosupport settings are the same) and the email to my local account came immediately, as well as a notification from NetApp. The log even said:

Feb 12 14:11:57 EST [wilstore2a: asup.smtp.sent:notice]: Cluster Notification mail sent: Cluster Notification from wilstore2a (USER_TRIGGERED (testing_from_wilstore)) INFO

This was definitely sent via smtp, yet the autosupport.support.transport is set to https.

Daniel

From: owner-toasters@mathworks.com [mailto:owner- toasters@mathworks.com] On Behalf Of Kenneth Heal Sent: Tuesday, February 12, 2008 12:33 PM To: Daniel Keisling; toasters@mathworks.com Subject: RE: Autosupport failing to mailhost Hi Daniel

I see a line which says autosupport.support.transport https

Which means the filer will use https to send autosupports, and not smtp.

Can you try options autosupport.support.transport smtp

And see if the mails go through?

cheers Kenneth

Kenneth Heal Databasement BV The Netherlands Subject: Autosupport failing to mailhost Date: Tue, 12 Feb 2008 10:22:51 -0600 From: daniel.keisling@austin.ppdi.com To: toasters@mathworks.com Hello,

From what seems out of the blue, Autosupport emails are no longer able to be sent to my mailhost (Exchange 2003 on the same subnet):

"Autosupport cannot connect to host rtpmail01.americas.ppdi.local (Network comm problem) for message: USER_TRIGGERED (TEST)"

This message will be thrown until the message is eventually dropped. My Exchange administrator does not see any connections coming from the filer to send this email. I can ping the mailhost with no problem:

rtpstore2b> ping rtpmail01.americas.ppdi.local rtpmail01.americas.ppdi.local is alive My routing table:

Destination Gateway Flags Refs Use Interface default 172.20.63.254 UGS 4 222239 e0a 127 localhost UGS 0 22236 lo localhost localhost UH 3 145 lo 172.20.62/23 link#4 UC 0 0 e0a rtpmail01.americ 0:8:2:28:ee:86 UHL 0 11 e0a rtpexchbe01.amer 0:8:2:28:ee:86 UHL 0 0 e0a rtpstore2b 0:a0:98:9:66:53 UHL 0 18112 lo My autosupport options:

rtpstore2b> options autosupport autosupport.cifs.verbose off autosupport.content complete autosupport.doit DONT autosupport.enable on autosupport.from rtpstore2b at rtp.ppdi.com autosupport.local.nht_data.enable off autosupport.local.performance_data.enable off autosupport.mailhost rtpmail01.americas.ppdi.local autosupport.minimal.subject.id hostname autosupport.nht_data.enable on autosupport.noteto autosupport.performance_data.enable on autosupport.retry.count 15 (value might be overwritten in takeover) autosupport.retry.interval 4m (value might be overwritten in takeover) autosupport.support.enable on autosupport.support.proxy autosupport.support.to autosupport at netapp.com autosupport.support.transport https autosupport.support.url support.netapp.com/asupprod/post/1.0/ postAsup autosupport.throttle on autosupport.to storage at wilm.ppdi.com (I've replaced the @'s with 'at')

I have no problems with my SSH session, so I don't know how this could be a network cable/connection problem. Are there any debugging steps I can do? Has anyone seen this before? It has definitely worked in the past. This is DOT 7.2.2 on a FAS3040.

TIA,

Daniel

---

This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.

Express yourself instantly with MSN Messenger! MSN Messenger

---

This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.

CONFIDENTIALITY NOTICE

This communication, including any attachment, is confidential. It is intended for the exclusive use of the addressee. If the reader of this message is not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us by telephone or facsimile and immediately delete the communication.