Autosupport: We cannot receive any notification

[SCOTT_V_RONTALE]

Hi everyone,

There's no output or we cannot receive any notifcations after doing the command options autosupport.doit. We've tried to change the transport to smtp or https but still no output.

version of the ONTAP is 8.2.2.RC1 7 mode.

Thanks for the help.

[DOMINIC_WYSS]

Can you ping the smtp server?

please paste the output of the following commands:

options autosupport

autosupport history show

[NetApp_SEAL]

- Are you using an HTTP proxy?

- Are the correct IPs set to allow SMTP relay?

Maybe attach output of /etc/rc and /etc/hosts as well to build off of the recommendation by DOMINIC.WYSS.

[SCOTT_V_RONTALE]

yes we can ping the smtp server.

Andoks-PROD1> ping 192.168.10.3

192.168.10.3 is alive

Andoks-PROD1> options autosupport

autosupport.content          minimal    (value might be overwritten in takeover)

autosupport.doit             MANAGEMENT_LOG

autosupport.enable           on         (value might be overwritten in takeover)

autosupport.from             Andoks-PROD1@andokscorp.com (value might be overwritten in takeover)

autosupport.local_collection on         (value might be overwritten in takeover)

autosupport.mailhost         192.168.10.3 (value might be overwritten in takeover)

autosupport.max_http_size    10485760   (value might be overwritten in takeover)

autosupport.max_smtp_size    5242880    (value might be overwritten in takeover)

autosupport.minimal.subject.id systemid   (value might be overwritten in takeover)

autosupport.nht_data.enable  on         (value might be overwritten in takeover)

autosupport.noteto           support@aisc.com.ph,cba.it@andokscorp.com (value might be overwritten in takeover)

autosupport.ondemand.polling_interval 60         (value might be overwritten in takeover)

autosupport.ondemand.remotediag.state on         (value might be overwritten in takeover)

autosupport.ondemand.server_url https://support.netapp.com/aods/asupmessage (value might be overwritten in takeover)

autosupport.ondemand.state   on         (value might be overwritten in takeover)

autosupport.partner.to       Andoks-PROD2@andokscorp.com (value might be overwritten in takeover)

autosupport.payload_format   7z         (value might be overwritten in takeover)

autosupport.performance_data.doit DONT

autosupport.performance_data.enable on         (value might be overwritten in takeover)

autosupport.periodic.tx_window 1h         (value might be overwritten in takeover)

autosupport.retry.count      15         (value might be overwritten in takeover)

autosupport.retry.interval   4m         (value might be overwritten in takeover)

autosupport.support.enable   on         (value might be overwritten in takeover)

autosupport.support.proxy               (value might be overwritten in takeover)

autosupport.support.put_url  support.netapp.com/put/AsupPut (value might be overwritten in takeover)

autosupport.support.reminder on         (value might be overwritten in takeover)

autosupport.support.to       autosupport@netapp.com (value might be overwritten in takeover)

autosupport.support.transport smtp       (value might be overwritten in takeover)

autosupport.support.url      support.netapp.com/asupprod/post/1.0/postAsup (value might be overwritten in takeover)

autosupport.throttle         on         (value might be overwritten in takeover)

autosupport.to               cba.it@andokscorp.com,support@aisc.com.ph (value might be overwritten in takeover)

autosupport.validate_digital_certificate on         (value might be overwritten)

Andoks-PROD1> autosupport history show

Seq                                    Attempt Last

Num   Destination Status               Count   Update

----- ----------- -------------------- ------- --------------------

79

      smtp        transmission-failed  15      8/21/2014 02:03:10

      http        ignore               1       8/21/2014 00:59:09

      noteto      ignore               1       8/21/2014 00:59:09

78

      smtp        transmission-failed  15      8/21/2014 01:03:09

      http        ignore               1       8/21/2014 00:08:16

      noteto      ignore               1       8/21/2014 00:08:16

77

      smtp        transmission-failed  15      8/20/2014 18:44:03

      http        ignore               1       8/20/2014 17:47:46

      noteto      transmission-failed  15      8/20/2014 18:44:02

9 entries were displayed.

[aborzenkov]

You have to ask E-Mail administrator to investigate why E-Mail server rejects mails from NetApp. There is very little that can be done from NetApp side here. I vaguely remember that some versions had problems with Exchange, but again - you need to gather information from mail server first.

[DOMINIC_WYSS]

the config looks ok to me.

I think the mailserver does not allow you to send mail (relaying). this has to be configured by the mailadmin.

aborzenkov is right, there was an Ontap version which had an issue with Exchange. this has been fixed about two years ago. I hope you don't have such an old Ontap version

[SCOTT_V_RONTALE]

Thanks for the reply.

Actually they have an old netapp in FAS2020 wherein the config for autosupport is the same with the new netapp FAS2552. We can recieve notification from the old netapp thats why we are confuse why is that the new netapp cannot send an autosupport notification.

[nigelg1965]

Hi

We had a similar issue a few months ago.

Assume you've checked the obvious, that your mail server has the filer whitelisted as an SMTP sender.

In our case, after a lot of faffing around, a reboot of the filer fixed it. The consensus seemed to be the email daemon within OnTap had died. One the few times when I've found NetApp support less than fantastic, no one I spoke to (and we a very premium support) was able to offer a definitive method to diagnose this was the issue at the time or suggest a remedy other than rebooting.

[NetApp_SEAL]

When you say an old 2020 and the 2250 has the same configuration, do you mean that the 2250 now has the same IPs as the previous 2020, or are both systems still up and running right now (each with different IPs)?

[SCOTT_V_RONTALE]

Systems are both up but with different IP's.  The client decided to still up the old netapp so that he can play around with it and check some configuration.

But the users are connected with the new netapp. Do you think that's a problem having the 2 netapp with same configuration but different IP's. Because they are experiencing a heavy traffic in the network also.

[NetApp_SEAL]

No, what I was getting at was that just because you have another NetApp array up and running - and pointing to the same SMTP relay server - doesn't automatically mean that ASUPs will work.

First place to start is the SMTP relay server itself (whether it's Exchange, a load balancer of some kind, etc...) to ensure that the new IPs of the FAS2552 are allowed to even relay via SMTP to begin with.

Additionally, that's why I mentioned posting the output of the /etc/rc and /etc/hosts files (if you could). Yes, you can ping the SMTP server IP, but that could just mean that there's a route somewhere on the controller that can reach it. It doesn't necessarily mean that you're reaching it via the correct IP - does that make sense? In this scenario, it's important to ensure that if you add an IP to the SMTP relay, that you add the correct originating IP. Most often times, it'll be the IP that's on the same subnet as the default gateway (at least on a 7-Mode system).

You can also run a traceroute to the SMTP server IP to see if there are any unusual hops in the data path.

Have you tried changing the autosupport.transport to https and kicking off a WEEKLY_LOG to see if it at least goes to NetApp and registers via the My AutoSupport site?

[SCOTT_V_RONTALE]

     We had place a new IP in the FAS2020 and still we can recieve a notification While the old IP of the old netapp was placed to the new netapp to test if it can recieve an asup but still no success.

             We've tried to change the transport to https to test also but still We cannot receive any asup.

[NetApp_SEAL]

Then you most likely have a routing or other network-related issue from the new FAS2552.

[wayne]

 I found a solution to a similar issue that recently came up in our environment. Our messaging team recently upgraded some mail relay servers. On many of our older filers the (autosupport.from) was set to only the host name (somefiler). After I changed the value to a valid email address (somefiler@yourplace.com) it once again worked fine.

[HenryUK]

have you tried ping dns name?

i had a problem the other day where the DNS server have been changed without my knowing and everything stopped

try pinging www.google.com or something and make sure it looks good

i was pinging 8.8.8.8 for ages wondering what was going on until i tried google and it failed

its worth a look if you have not already

Cheers