Create a virtual interface for failover.
This veth should be assigned the dns configured IP then add this veth and the rest of the interfaces to the IFGroup.
That should give you redundancy.
Sent from my iPhone
You probably unplugged the one interface that is used to resolve the DD hostname by your backup application.
There are basically 2 options for you;
1: As said above, resolve to the DD hostname as your backup target device onto a failover or LACP interface.
This IF doesn't need to be part of the ifgroup membership, it will just be the initial communication and then appropriate DDBoost ifgroup IP will be handed back to the host for backup use and the hostname is no longer required for the backup.
This allows both resilience for the initial connection and incase one of your ifgroup interfaces goes down, also load balancing. The ifgroups do not need to resolve, they just need an IP.
If you cannot create a resilient interface with failover or LACP then you can add a hosts file entry at the client for the DD "hostname" on one IP/NIC and a second IP/NIC with the DD "hostname-failover" hostname, if the first hostname/IP is down, it will connect to the "hostname-failover" IP/interface and then discuss which ifgroup IP to use for the backup (as said above).
It's discussed in here -->
Hope that helps.
DDBoost provides you with Advance Load balancing as well as failover. It also depends on what IP was used in the backup application to register the Device. Do not use LACP for DDBoost Interfaces, as that would have performance impact. Ifgroup is the way to go for DDBoost. For redundancy you can use 2*1G interfaces and put them into a failover configuration and use that IP to register in the Backup Software. All communication will happen over the Failover/LACP interface and data transfer over the ifgroup interfaces.
if you have only 10Gb interfaces available. Creating a veth0 failover pair providing redundancy for communication would be a waste of bandwidth.Would it be a good practice adding the virtual port into the ifgroup?
There is no reason why you can't add the resilient interface/IP to the ifgroup too.
It's allocated to ifgroup membership as a "designated" interface/IP not a "dedicated" interface/IP.
If you wanted to create a failover virtual port of your 10gbe interfaces, you could also create an alias (or VLAN tagged interface) IP on veth0.
That way you could keep the management/resolved IP and the 'data' IP (for ifgroup) separate but still using the same resilient underlying 10Gbe ports. I would expect that this is needed in most environments with different subnet/LAN config/criteria for management vs replication vs data etc...
ifgroup members don't need to resolve to DNS, they're just IP's.
This would then use bandwidth optimally and still give the redundancy required to assure proper communication all the time. My understanding is that if the communication link is gone, boost management / control is gone.
Data Protection Solutions (DPS)
Exactly correct but don't forget about the "option 2" I posted earlier with -failover hostname to an alternate interface/IP to keep connectivity resilience without a redundant/virtual NIC config in play.
how does -failover hostname option work ? Let's say i cannot use LACP/Failover for my "entry point" interface. So on my host i create two entries in /etc/hosts
1) Does it work with DDboost capable applications only ?
2) Is DDboost capable app looks in the hosts file to determine the next working interface ?
3) Does it work with Avamar ? Would i configure the host file on the utility node only or storage nodes as well ?
4) Does it work with DDboost for RMAN ?
This is all great information and the partner guide is very helpful, but i was wondering if I could get a sanity check on what I am thinking about doing as a way to satisfy my failover requirements while still maintaining optimal bandwidth and access to the Data Domain:
This way data access is maintained over 6 interfaces (1/2 the DD) at all times while dns is maintained through either Sw1 on the veth1 interfaces in normal mode, or Sw2 on the veth2 interfaces in failover mode.