Skip to main content

Hi.. 

Setup:
- Two Client groups.
- One client group contains clients
- One client group contains Media Agents

A Backup Network using CIDR is configured according to: https://documentation.commvault.com/commvault/v11/article?p=107131.htm 

The Media Agents have multiple IP addresses in different networks ofc... 
They have an IP address for the frontend (to which the CS connects to) and one for the Backup Network. Both of these IP addresses are statically assigned.. 

Clients ofc have multiple IP addresses too... One for the frontend (to which the CS connects to) and one for the Backup Network. 
The frontend IP is static, but the one for the backup network is a DHCP one. 

Dumping such a client into the client group sets up the DIPs as expected according to the Network Summary seen on the MAs. Backup also works as expected using the DIP.

The issue is that when a client changes the IP address on its backup NIC, it doesn't seem to be updated on the CS or MAs. 
Backups stop working as the MAs try to contact the old IP address on the clients backup NIC... The old IP address is also still seen in the MAs Network Summary.

Going to each of the MAs and updating the FwConfig.txt file manually with the new IP address makes the backups work again as expected...
I'm no fan of having to do this as manually editing the FwConfig.txt is seen as a no- no, AFAIK.. Also doing it on 24 MAs is kind of tedious.. 
 
The change isn't reflected on the CS either.... When viewing the Network Summary on MAs, the old IP address is still listed..:-( 

I was hoping by defining a Backup Network, as an example, 10.10.10.0 /24 (Backup Network on MAs) <-> 192.168.1.0 /24 (Backup Network on clients), that changing the IP address on a client backup NIC from, let's say 192.168.1.11 to 192.168.1.12, wouldn't require any changes to be made anywhere as the new IP address is part of the existing network…

I was hoping that the new IP address would be picked up by the running IDA which then would make a request to the CS to update its DB when initiating a backup /restore..  This does not seem to be the case.

I this behavior expected?

CVLT v.11.20.60 (On CS, MAs and client)  


Thank you for any input you may be able to provide..   
I've got a ticket open for this question too.. 210831-281.

 

Best regards 

Kim Rubeck Solstar
 

Hi @RubeckDK !  Hope all is well!

I took a long look at this one (documentation, your well detailed post, and the incident number) and I definitely think this is either a) not working as expected or b) we are not understanding how it is supposed to work.

In my expectation, if the client is defined as the FQDN then name resolution happens via DNS (so if the IP changes, DNS knows and that is good enough).

Any backup from your defined Client Groups should limit themselves to the range you specified. 

However, why is it not seeing that there is a new IP address?  That’s the crux here.  If a DIP between groups exists, is there any caching of IP addresses involved?  How does it check what the client has (and compare it to the defined filter)?

I see you have Francis working on this case with you, and he’s very sharp.  I’m going to monitor the incident though hpoefully our other community members have thoughts to chime in as well!


Hi MIke.. 

 

Thank you for your input…  The thing that worries me the most is that the Commserve DB has no information about the updated IP. So doing any further DIP config on the client level, if ever needed, isn’t possible either… 

So the question is… How do I update the CS DB with the clients new IP information?

 

/Kim


I have the same thoughts.  I’m talking to Francis now and will follow his investigation closely.


Adding resolution via dev:

The issue corrected itself. We did engage Dev with some clarifications, and per Dev, the IPs are recorded by the commserve, and are updated within the hour during IP/hostname change.


Thanks @Mike Struening  ….  and thanks to your devs for clarifying how this is suppose to work. Very much appreciated. 

 

Have a great day… 

 

Best regards

Kim


Reply