cDOT: ASUP mails sent over wrong IP (or how to configure sender LIF?)

[DOMINIC_WYSS]

Hi there

I have two cDOT clusters with the same behaviour:

cDOT tries to send the autosupport mails over the wrong LIF/IP address. as the relay on the SMTP server is not configured

for this IP, the ASUP mail failes.

in the documentation it states that the ASUP should go out trough the node vserver.

unfortunatelly the mailserver is on the same subnet as one of the LIFs of a data vserver.

and now cDOT just sends over this data LIF!

how can I prevent using the data LIFs for ASUPs and use the node mgmt LIFs?

thanks for any ideas!

[AGUMADAVALLI]

make sure that the transport(https) and mail hosts (email domain name) specified are correct.

use the autosupport modify and tab it, verify the options specified.

thank you

AK G

[DOMINIC_WYSS]

the settings are correct (transport is smtp), I checked that before asking here.

the mail relay is now open and it works. cDOT is really NOT using the mgmt LIFs if there is a data LIF on the same subnet as the SMTP host.

I found this KB:

https://kb.netapp.com/support/index?page=content&id=3012724&locale=en_US

Case 3 - The node-mgmt LIF and data LIFs on different subnets, destination is on the same subnet as the data LIFs.

The implicit subnet route of the data LIFs (which isn't seen in ngsh) will be the most specific route to the destination,

and will therefore be the selected route. A data LIF will be used.

[aborzenkov]

I wonder, whether it is possible to create host route for your E-Mail gateway. Normally host route should take precedent over implicit local network route.

[DOMINIC_WYSS]

unfortunately not, I already tried a host route.

[DAWSONSCALAR · Accepted solution]

I had this problem today.. you need to specify the priority of the route to the SMTP server on the admin SVM to 1. I tried as 10 and it didn't work.

network routing-groups route create -vserver node-mgmt-svm-name -routing-group nExistingSVMDefaultRoute/24 -destination smtp.server.subnet/24 -gateway ExistingSVMDefaultGW -metric 1

I found this out because the smtp server was bouncing the messages with a 421 error, which gave an error in "autosupport history show" that said "FTP: weird server reply". This is due to the way curl deals with the SMTP error message.