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.
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>.
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.
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 (184.108.40.206), 30 hops max, 40 byte packets
1 appmail.uen.org (220.127.116.11) 1.000 ms 1.000 ms 0.000 ms
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.
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.
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
Destination Gateway Flags Refs Use Interface
default <gateway> UGS 17 7675390 san2a-svif0-33
san2b> route -s
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?
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.
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.