Hi Jeff,
I've just started using dnsmasq on Red Hat Linux which acts as a dns
forwarder but allows me to override certain IP addresses. It's easy to
configure and will get around this problem.
Other than that is it out of the question to use a slightly different
name for client interface that is in the backup network? (e.g.
servername-b) You would then put servername-b rather than servername in
the policy and the traffic would automatically route over the backup
network. I've used this for all clients in my backup network from day
one and it's been fine. The disadvantages that I can think of for you are
- The name of the client in reports and for searches is different from
the normal client name, and if it only applies to one or two servers
then it will be confusing.
- Backups taken before the change will be considered by the server to
be of a different client so there are a few extra steps to restore from
these.
Best regards,
Rosie.
Rosie Cleary
Computer Centre
National University of Ireland, Maynooth
Lightner, Jeff wrote [28/04/2011 20:53]:
> Sorry folks - NOT resolved.
>
> I thought this was resolved because the backup started but on checking I
> see it is using the primary LAN rather than the backup LAN. The addition
> of the FQDN on the client did get us past the 59 error but didn’t fix
> the issue I was asking about initially.
>
> The bpclntcmd is still showing the 10.x primary IP instead of the 172.x
> backup IP that I have in host file of the media server. We really need
> this backup to go across the backup LAN.
>
>
>
> *From:*veritas-bu-boun...@mailman.eng.auburn.edu
> [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] *On Behalf Of
> *Lightner, Jeff
> *Sent:* Thursday, April 28, 2011 3:11 PM
> *To:* veritas-bu@mailman.eng.auburn.edu
> *Subject:* Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf?
> -RESOLVED
>
> *Dan Otto had responded and based on what he wrote I resolved the issue.
> The below shows the thread between us and is reposted here with his
> permission.*
>
> **
>
> *From:*Lightner, Jeff [mailto:jlight...@water.com]
> *Sent:* Thursday, April 28, 2011 2:02 PM
> *To:* Daniel Otto
> *Subject:* RE: bpclntcmd and others ignoring nsswitch.conf?
>
> That was it.
>
> After checking bpcd log on the client we saw that it was complaining
> that the FQDN name wasn’t a media server. Our entry for the server was
> the short name for the media server. Adding the FQDN to the line that
> had the backup LAN IP and short name resolved the issue.
>
> It just didn’t occur to me to look at the client because I thought
> bpclntcmd was simply trying to resolve from the media server.
>
> I had actually tried adding FQDN of the client to the media server
> earlier because we have seen various issues regarding short name vs FQDN
> since implementing 7.1.
>
> Thanks for your help.
>
>
>
> *From:*Daniel Otto [mailto:dan_o...@symantec.com]
> *Sent:* Thursday, April 28, 2011 2:57 PM
> *To:* Lightner, Jeff
> *Subject:* RE: bpclntcmd and others ignoring nsswitch.conf?
>
> The 59 is thrown because whatever server hostname the client is
> resolving doesn’t exist in the client’s server list hence server access
> denied status 59 and should show up as a status 46 error in bpcd as a
> invalid server. If the media server couldn’t resolve the client at all
> or getting the wrong IP address you would be getting 58/25 or even 54’s
> type of errors.
>
>
>
> *From:*Lightner, Jeff [mailto:jlight...@water.com]
> *Sent:* Thursday, April 28, 2011 1:43 PM
> *To:* Daniel Otto
> *Subject:* RE: bpclntcmd and others ignoring nsswitch.conf?
>
> I did actually try removing dns from nsswitch.conf but it didn’t help.
>
> I haven’t looked at the client’s bpcd log – I did verify the media
> server is in the server list for the client. The only other one in the
> list is the master.
>
>
>
> *From:*Daniel Otto [mailto:dan_o...@symantec.com]
> *Sent:* Thursday, April 28, 2011 2:35 PM
> *To:* Lightner, Jeff
> *Subject:* RE: bpclntcmd and others ignoring nsswitch.conf?
>
> Easy fix would be to use the bpcd log on the client and whatever
> hostname is getting resolved simply add it to the SERVER = on the client
> and the 59 should go away. As to why it is not using the host
> file…that’s interesting.
>
> Perhaps for a quick test remove the DNS entry altogether from
> switch.conf to see if it then goes to the host file. Though I have only
>
