We've got a FAS2020 here and i'm trying to configure the Autosupport facility. It is accepting the settings OK but it cannot find the mail server on the internal network I think because it's trying to communicate over the 2 lan ports, but these are connected to dedicated iSCSI traffic only, and the BMC port is connected to the LAN.
But the documentation states it is possible to use Autosupport over the BMC port.
Thanks for the replies. In response to mayumbarob, this is what is not working. I cannot ping the mailhost as the FAS2020 LAN ports are not connected to the same switch fabric as the mailhost; my iSCSI traffic is on dedicated switches completely isolated from the main LAN. I use both LAN ports on each controller (we have a 2 controller model) to connect to independent SAN switches (we have 2 SAN switches) for optimal resiliency. This is why I was hoping to use the BMC port for autosupport as this is connected to our main LAN, along with the mail host.
The only thing I can see in the documentation is that the BMC will work for autosupport if the LAN ports fail.
I could enable some sort of SMTP relay on the hosts but this would just add processing power to the hosts. Granted it won't be much but this would be the very last resort.
I'm surprised that the 'best practice' is to have the SAN connectivity isolated from the main LAN for performance reasons, yet don't seem to allow for this unless you use one of the LAN ports connected to the main LAN leaving the other port for SAN stuff, which i'm not doing as it leaves us no redundancy! Maybe the argument is that the 2020 is for smaller environments that don't have a dedicated SAN switching fabric but that would be a stupid argument to make.
The syslogs show that it simply cannot connect to the mailhost.
Well FAS2020 has limited no of ports. Hence, if you wish to have the Best Practices implemented you can simply have a logical separation instead of physical separation. By logically separating and placing the iSCSI traffic in separate VLAN. you can still afford to send the AutoSupport over the main IP.
As stated earlier, the quickest way to fix this is to VLAN in your administrative subnet via one of your Ethernet interfaces - this not only provides you the interface you need to reach your SMTP gateway for AutoSupport, it will also give you a fully functional management interface for Telnet/SSH, FilerView, etc.
I also wanted to clarify what the BMC does w.r.t. AutoSupport transmissions. The BMC sends a very small subset of AutoSupport message events - they are ones that are considered severe in nature (system is down, abnormally rebooted). The BMC does NOT act as any kind of proxy for AutoSupport messages originating from the system itself.
As stated earlier, the BMC reads the AutoSupport configuration information (options) from its host system. Therefore, as you have things configured right now, the BMC is capable of sending that subset of severe AutoSupport messages. You can test that via the BMC CLI, if you like.
However, if you'd like to get full automation from AutoSupport and corresponding usage of the My AutoSupport portal, you'll need to provide that IP path via an administrative interfaces (VLAN'ed, if you like).
I was a fighting with the same issue, only the way working was to create VLAN on SAN. This is a one thing I really hate on Netapp. On the HP storage I can do everything over the management port and don't need to touch SAN........