Active IQ and AutoSupport Discussions

Autosupport tries to use IPv6

GrahamNicoll
6,384 Views

I've got a 2 node cluster of 8020s running OnTap 8.3.1.  Both nodes were previously working fine but now the second node cannot send autosupport via https.  Below you can see the error being given, it looks like it's trying to use IPv6.  The network is not setup for IPv6 and the routing table does not have any ipv6 entries.  Anyone got any ideas where to look? 

 

AutoSupport Sequence Number: 833
Destination for This AutoSupport: http
Trigger Event: callhome.invoke
Time of Last Update: 12/15/2016 18:37:21
Status of Delivery: transmission-failed
Delivery Attempts: 15
AutoSupport Subject: USER_TRIGGERED (TEST:test asup)
Delivery URI: support.netapp.com/put/AsupPut
Last Error: Failed to connect to 2620:10a:4005:c000::a78:2d11: No route to host
Time of Generation: 12/15/2016 17:40:12
AutoSupport Compressed Size: 1.47MB
Percent Complete: -
Rate of Upload: -
Time Remaining for Upload: -
AutoSupport Decompressed Size: 25.38MB
Total Collection Time (ms): 57467

 

 

3 REPLIES 3

stonefr33
5,991 Views

Hi

 

Did you manage to find out what was happening on your system, I've got 1 of a 4 node cluster trying the same. Just opened a support ticket on the issue.

 

Thanks

GrahamNicoll
5,976 Views

The problem  for us had nothing to do with IPv6.  

 

We had 2 default routs with the same metric configured for the vserver.  Resolving the routing issue allowed autosupport to get out correctly.

 

Graham

stonefr33
5,930 Views

Glad to hear you got it fixed, one of our team managed to find the issue on our system today and it was down to routing as well but had to drop down to the systemshell to spot it (should de discoverable in the node shell as well). What was odd is that ping from the affected lif continued to work.

 

From the cluster shell the node management lif had the correct routes/costs/etc. assigned to it identical configuration to the other nodes (based on this I ignored that as being an issue) but a colleague took a closer look at the node in the systemshell and found there was no default route in the routing table, the output was compared to the other nodes to be sure and it was just this one node that it was missing on.

 

Resolution was just to delete the route in the routing group and recreate it and everything started working. I have requested that support create a KB on this as it is a bit obscure. 

 

Thanks

 

Public