Share this article
Anyone who has worked with Networker knows that a correctly configured DNS is a major component. More so, an incorrectly configured DNS environment can lead to numerous headaches that are often difficult to find. In a recent upgrade, it was the VMware Backup Appliance (VBA) proxies that provided some fun and games.
Due to compatibility requirements, upgrading Networker also requires upgrading VBA. If external VBA proxies are used, these get blown away and new ones are created. After some Networker upgrade issues (that’s a story for another day), the VBA upgrade went smoothly and new proxies were created. This is where the next lot of issues and relatively straight forward fixes come in.
When creating the VBA proxy from an OVA, there is the option to use DHCP. Even though DNS was configured, it wasn’t picked up by the proxy build which was shown when connecting to the proxy. The login prompt displayed localhost, and if not resolved, the VBA appliance itself will not be able to connect to Networker due to the DNS issues. This can also be seen with “localhost” entries in DNS.
By switching to a static IP address and ensuring that DNS was properly configured for both forward and reverse DNS, it started to look a lot better. The proxy recognised it’s name, but unfortunately the VBA was still having issues. Through some troubleshooting, We were able to identify that the name resolution wasn’t working properly. We could lookup & ping the FQDN, but solely using a hostname failed. Luckily the quick fix of adding a domain and search path to /etc/resolv.conf fixed the problem.
The final VBA goodness came when attempting a restore. As part of the upgrade phase, a small backup and restore had been tested with no issues. A little later, as part of EMC recommendations when using external proxies, the internal proxy was disabled. It turns out there is a bug with VBA 1.5.1.7 where restores fail when the internal proxy is disabled. Thankfully, there is an Alpha level hotfix that fixes this problem.
To summarise:
- Before registering a proxy with VBA, login to proxy and ensure it has a hostname and can resolve the VBA hostname both via FQDN and hostname
- If the proxy is not detecting its hostname, blow it away and remove any DNS entries to localhost with the IP of the proxy
- Check the DNS and ensure that both forward and reverse entries exist for the proxy.
- Start the proxy creation again, using static IP
- Login to proxy and again check its hostname and resolution of VBA hostname
- If there are name resolution issues, edit /etc/resolv.conf on the proxy and add domain and search entries
- If you use external proxies and have disabled the internal proxy (via NMC or CLI), then test a restore. If you have issues, apply the hotfix.
If you find yourself still experiencing issues, please do not hesitate to contact our team.
Contact us
Speak with a Tesserent
Security Specialist
Tesserent is a full-service cybersecurity and secure cloud services provider, partnering with clients from all industries and all levels of government. Let’s talk.
