Autosupport cannot connect to host "SMTPHOST" (Network is unreachable)

[basisinfra]

Hello,

After upgrading our FAS2040 from Data ONTAP 8.0RC3 7-Mode to Data ONTAP 8.0.1 7-Mode, AutoSupport wil not work anymore.

We are receiving the following messages:

Fri not found.  Type '?' for a list of commands
NETAPPHOST> Fri Feb 11 10:49:19 CET [NETAPPHOST: asup.smtp.retry:info]: AutoSupport mail (HA Group Notification from NETAPPHOST (REBOOT (after giveback)) INFO) was not sent for host (0). The system will retry later to send the message
Fri not found.  Type '?' for a list of commands
NETAPPHOST> Fri Feb 11 10:53:19 CET [NETAPPHOST: asup.smtp.host:info]: AutoSupport cannot connect to host SMTPHOST1 (Network is unreachable) for message: HA Group Notification from NETAPPHOST (REBOOT (after giveback)) INFO
Fri not found.  Type '?' for a list of commands
NETAPPHOST> Fri Feb 11 10:53:19 CET [NETAPPHOST: asup.smtp.host:info]: AutoSupport cannot connect to host SMTPHOST2 (Network is unreachable) for message: HA Group Notification from NETAPPHOST (REBOOT (after giveback)) INFO
Fri not found.  Type '?' for a list of commands
NETAPPHOST> Fri Feb 11 10:53:19 CET [NETAPPHOST: asup.smtp.retry:info]: AutoSupport mail (HA Group Notification from NETAPPHOST (REBOOT (after giveback)) INFO) was not sent for host (0). The system will retry later to send the message
Fri not found.  Type '?' for a list of commands
NETAPPHOST>

Also after the upgrade I had to restore the IP address of the management adapter, cause it was gone.

1. I tried this kb article: https://kb.netapp.com/support/index?page=content&id=2011799 (smtphosts1 en 2 are pingable, all the interfaces are trusted)

2 Also the NetApp's IP addresses are trusted in the SMTPHOST relay list.

Anyone any idea how to fix this problem or how I can see which network interface SMTP uses for communication?

Thanks you in advance.

[daminimark]

Hmm...

Can you provide the output of these commands?

Locate mail host  in options:

autosupport.mailhost               mailgw

Example:

ssh netappfiler "priv set advanced; ping mailgw"

ssh netappfiler "priv set advanced; traceroute mailgw"

[basisinfra]

Thank you for your reply daminimark!

When I do a pingtest as you requested I am getting a response back.

NETAPPHOST> ping SMTPHOST1

SMTPHOST1 is alive

NETAPPHOST> ping SMTPHOST2

SMTPHOST2 is alive

The trace as requested ends with

26 * * *

27 * * *

28 * * *

29 * * *

30 * * *

But on the other NetApp filer it still works, I upgraded that filer also but didn't yet give it a reboot, when I reboot that filer I am sure the SMTP ERROR will appear....

[tulalipdataservices]

I had the same problem, but with an "Operation timed out" error message. Turned out that after the upgrade, the e0P interface is set to up with an IP address. This might cause local routing problems. After disabling that interface, my errors went away.

[chad_lake]

Did you ever find a solution to this?  I have two 3240s that are brand-new installs that I am seeing a similar problem with.  One head works fine, and the second head is giving me the "Network is unreachable" error.  Yet, I can ping/traceroute to it:

appnas-b> options autosupport

autosupport.mailhost         mailhost.my.domain (value might be overwritten in takeover)

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

appnas-b> ping mailhost.my.domain

mailhost.my.domain is alive

appnas-b> traceroute mailhost.my.domain

traceroute to mailhost.my.domain (1.2.3.4), 30 hops max, 40 byte packets

1  appmail.uen.org (1.2.3.4)  1.000 ms  1.000 ms  0.000 ms

appnas-b>

I don't have a host set up where I can snoop to see if the mail is trying to be sent out the wrong interface, but given that the autosupport and ifconfig on both boxes are identical....well, I'm confused.  Any help would be very much appreciated.

        -c

[basisinfra]

Yes we found a solution to this problem. When we ran the command "setup" again the SMTP AutoSupport function did his work again. But you really don't want to run that command because you have to put all the settings in again. So after a while we found out that if you ran the rc file manually it did the trick.

So run your rc file manually and pay close attention to the add route rules in your rc file if you have if they run correctly.

[chad_lake]

FYI, I was able to fix this problem without re-running setup.   What had happened, apparently, is that when the box was set up the default route had been pegged to the wrong interface (it was tied to an interface that didn't have that network on it). I removed the default route with "route delete default", and then added it back in "route add default <ip>", and it picked up the appropriate interface (without me having to specify it when running the route command).  And voila...autosupport is working now.

-c

[ZANDER_MEARS]

I've got the same issue with two 3140's running 7.3.4. I reconfigured their networking us use all NIC with various vifs and VLANs, both hav ethe same routing information in their rc files and both have been rebooted ok. The A controller is using the expected VLAN interface for the default route so Autosupport is working but B is using the e0M interface so getting blocked by our internal f/ws.

san2a> route -s

Routing tables

Internet:

Destination     Gateway     Flags     Refs     Use     Interface

default          <gateway>     UGS     17     7675390 san2a-svif0-33

san2b> route -s

Routing tables

Internet:

Destination     Gateway     Flags     Refs     Use     Interface

default          <gateway>    UGS     2          434     e0M

Both controllers' main VLAN interface and e0M interface are on the same subnet but have different IP address'. On the B controller I've removed and added the default route via the route command with no joy. I then removed the default route again and then ran source /etc/rc but it's still using the e0M interface.

Do I need to flush then entire routing table?

Can I specify which interface to use for the default route?

[ZANDER_MEARS]

I've been told having e0M and the main interface on the same subnet is my issue so will probably be disabling e0M

[NK]

I should admit, this post helped me to fix the issues with autosupport. Thanks heaps mates

[brassneck]

Anyone found a solution to this? I have the same issue on 8.0.1P5, clean new install - 2 heads clustered and a DR snap mirror host.

None can traceroute to the smtp host.

All can ping it.

I can traceroute from other servers in the subnet, and send mail to the relay from other servers.

One of the heads works OK, the others don't. The one that works has been rebooted recently .. can't do the others till tomorrow as I have to straighten out the mess of a networkng config I was left with and /etc/rc doesn't match the interfaces as configured or according to System Manager ^^

EDIT: the working one is one of the clustered heads .. as far as I can see there are no config differences between them.

[GREATERSUDBURY]

We upgraded to 8.0.1 from 7.3.3 and smtp stopped working

We got this from netapp tech support and it is now working

OnTap 8 autosupport requires https protocol.....

options autosupport.support.transport https

the system needs direct connection to the internet or use of a proxy

[brassneck]

Thanks for the reminder Peter, should have posted our solution:

Turned out the installation techs had given e0M and RLM the same IP address - I found a mysterious IP conflict in the logs.. arp'ing it out led to a MAC address suspiciously close too, but not shown by, ifconfig.

It was then I found out about the internal switch the two share ... supplying a separate IP to each cured the conflict (natch) but also appeared to fix the issue with mail - so I guess there was something screwy in the internal routing table.

Autosupport test are working fine, not yet had a real shout for a proper test <touch wood>.