How to supress "No redundancy in the failover configuration for 2 LIFs" mail.

[Overz]

First off, let me aplogise. As english is not a mother tongue for me, I have trouble reading the mail, and think i am missing something (obvious). It seems excessisve to ask here as this should be a simple isue.

I get the mail as stated in the bottom of this message regularly. But i think this should not be a problem for us. You see, the LIFS they talk about as far as i can see contain the E0M (management port) and the snapmirror-sync port e0a (traffic between te netapps to snampirror-sync data between them)

So if as in the message stated the "home port or home node" would go offline, a failover is not possible right? I mean, if the management port goes down, i cannot manage it anymore, there is no possibility of failover. Same seems to go for the snapmirror port. It's alway one toaster to a other toaster. So this message is nothing to worry about right?

If this annalysis is correct, how do i get rid of this mail message? I cant seem to find it anywhere, and the netapp-jargon confuses me to a great extend. If i am wrong, i would love to have a direction to search in order to fix the non-redundant LIF.

*************** Failover config ******************

delft-bn-cluster-1::> net int show -failover -lif Delft-netapp2554-b_node_mgmt
  (network interface show)
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- ---------------
delft-bn-cluster-1
         Delft-netapp2554-b_node_mgmt Delft-netapp2554-b:e0M
                                               local-only      Default Network
                         Failover Targets: Delft-netapp2554-b:e0M

delft-bn-cluster-1::> net int show -failover -lif sk-delft-backupB
  (network interface show)
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- ---------------
BNAlgemeen
         sk-delft-backupB Delft-netapp2554-b:e0a
                                               local-only      VLAN 3
                         Failover Targets: Delft-netapp2554-b:e0a

********The mail: ********

Filer: Delft-netapp2554-b
Time: Sun, Oct 23 00:15:05 2016 +0200
Severity: LOG_ALERT

Message: vifmgr.lifs.noredundancy: No redundancy in the failover configuration for 2 LIFs
assigned to node "Delft-netapp2554-b". LIFs:
delft-bn-cluster-1:Delft-netapp2554-b_node_mgmt,
bnAlgemeen:sk-delft-backupB

Description: This message occurs when one or more logical interfaces (LIFs) are configured
to use a failover policy that implies failover to one or more ports but have no failover
targets beyond their home ports. If any affected home port or home node is offline or
unavailable, the corresponding LIFs will be operationally down and unable to serve data.

Action: Add additional ports to the broadcast domains or failover groups used by the
affected LIFs, or modify each LIF's failover policy to include one or more nodes with
available failover targets. For example, the "broadcast-domain-wide"
failover policy will consider all failover targets in a LIF's failover group.
Use the "network interface show -failover" command to review the currently assigned
failover targets for each LIF.

Source: vifmgr
Index: 162566

[aborzenkov · Accepted solution]

---

@Overz wrote:

So if as in the message stated the "home port or home node" would go offline, a failover is not possible right?

---

No. The message simply tells you that those LIFs do not have redundant ports, so if connection to the single port fails, those LIFs are not accessible. For intercluster LIF you should actually consider adding redundant port, because if your only port fails, no snapmirror traffic from/to this node is possible. Having redundant ports for node management does not hurt as well.

[Overz]

---

@aborzenkov wrote:

---

so if connection to the single port fails, those LIFs are not accessible.

---

The Toaster has 2 heads. Named Delft-netapp2554-a & Delft-netapp2554-b

So if one port goes down, the other should already automatically take over right? Or is this only with a head fail? It seems excessive to have 4 cables for a management port.

It's a bit confusing as the interfaces list the same port name 2 times (on other heads)

[aborzenkov]

---

@Overz wrote:

So if one port goes down, the other [filer] should already automatically take over right?

---

This depends on failover policy. Some LIF types never failover to another node. This includes node management and intercluster LIFs.

[Overz]

ah, ok i think i got it. What i call head is a node. So the policy local-only acording to netapp documentation will only failover on the same node (head).

so i have 2 options, either choose a failover policy wich will failover to a other head (sorry for using my wording, but it makes it more clear for me) or like you initially sad, plug extra cables into the heads and get a redundancy that way.

For example, i move the 2 lifs to the policy sfo-partner-only. Is this correct? It intresting how easy it starts to look if you start calling a head a node 🙂

[aborzenkov]

---

@Overz wrote:

choose a failover policy wich will failover to a other head

---

You can't. Those LIF types cannot failover to another node.

[Overz]

And i cannot choose a new LIF type for these 2 connections either?

So than as you initially suggested the only way to solve this isue is to add cables. Thanks for the replys. I will mark your initial awnser as solving awnser. I would love to have confirmation of this last statement tho.

[aborzenkov]

---

@Overz wrote:

And i cannot choose a new LIF type for these 2 connections either?

---

No. It has to be node management for node management and intercluster LIF for intercluster traffic.

[Darkstar]

---

@Overz wrote:

So than as you initially suggested the only way to solve this isue is to add cables.  

---

There is another option: You can set the failover policy of that lif to "disabled". That will signal the system that you do not intend this interface to failover and it shuts up the warning message.

[sam_wozniak]

I have this same annoyance with a few recent installs myself.  What I don't understand is why one of the two ports in my intercluster failover group can't be e0M.  In my case I have one ifgrp VLAN port for traffic on a server network which is used for replication - a0a-12 and the only other option is e0M.  I could create another VLAN and provide that for failover target, but really...  

DOT allows me to have both ports in the failover group and assign that FG to my intercluster LIF, but 'net int show -failover' tells otherwise and reflects what the email error message is saying.  We opened up a support case and they said it could be ignored.  I can understand that e0M can't be used for data traffic and thus intercluster traffic, but there seems to be missing a check.  That or just a message somewhere that says e0M won't be available for that type of traffic.

cluster02::> net int failover-groups show
(network interface failover-groups show)
Failover
Vserver Group Targets
---------------- ---------------- --------------------------------------------

...

n01_ic
cluster02-01:a0a-12, cluster02-01:e0M

cluster02::> net interface show -failover
(network interface show)
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- --------------------- --------------- ---------------

...

n01_ic cluster02-01:a0a-12 local-only n01_ic
Failover Targets: cluster02-01:a0a-12

And yes, n01_ic is both the LIF and the FG name used above.

[andris]

There's technical and philosophical arguments for not using e0M for anything but management roles.

Technically, e0M has been a lower-speed port (100Mb/s, 1Gb/s) in various platforms, sharing a link with remote management (the service processor). It also is restricted to a 1500 byte MTU limit.   Philosophically, management traffic (i.e. the control plane) should remain as isolated as possible from the data traffic.