Networker

Re: [Networker] How to understand this 7.4 behavior on multihomed Windows

2008-09-22 08:17:09
Subject: Re: [Networker] How to understand this 7.4 behavior on multihomed Windows
From: "Clark, Patti" <clarkp AT OSTI DOT GOV>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Mon, 22 Sep 2008 08:06:57 -0400
1.  Using the NMC, open the properties on your win client in question.  
2.  Select Apps&Modules tab. 
3.  In the Backup command: box enter: save -c <the name of your "A"
server>

This has saved much heartache from the multihomed Win environment.  I've
been
told that Windows does a lot of network caching which is a cause of this
issue.
I'm a *NIX person and I can't offer more than that as an explaination.

Patti Clark
DOE/OSTI

> -----Original Message-----
> From: EMC NetWorker discussion 
> [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of gharma
> Sent: Friday, September 19, 2008 6:14 PM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: [Networker] How to understand this 7.4 behavior on 
> multihomed Windows
> 
> A Windows Server 2k3 R2 with Networker 7.4 backup client has 
> two nics, is behind a firewall device, and uses IPsec to 
> filter all traffic to a strict allows list.  
> Nic 1 has DNS name A and allows all needed traffic with the 
> backup server and domain controllers.  Nic 2 has a DNS name B 
> not known to the W2k3R2 server (unless it decided to look up 
> the PTR DNS RR) and this nic only allows a couple specific 
> tcp ports (common services, not ports used by Legato) and 
> only with specific machines not including the backup server. 
> Backup has been successfully running for many months.  
> Last weekend the save set email report had lines of form:
> * DNS name A: C:\ 12345 save: SYSTEM error: client 'DNS name 
> B' is not properly configured on the Sun StorEdge(tm) 
> Enterprise Backup Server'
> The day before the backup worked, and no one was working on 
> machines over the weekend.
> How does this happen?  Or more to the point how does one prevent it?
> The server does not know the DNS name B, and it cannot 
> communicate with the backup server on the IP associated with name B.
> This happened once before and apparently corrected itself 
> after two days. This time, stopping/starting nsexecd, 
> cleaning out temp files, did not force a resolution.  
> However, the first backup after rebooting the W2k3R2 client 
> was successful.
> The only thing that seems plausible here is that the client 
> is sending a response to the server (on IP of name A) that 
> states the IP of name B (or perhaps the client did a DNS PTR 
> lookup and sent the name).
> Why in the world would it do that?
> I have reviewed what I can locate, here, via Google, etc. and 
> find issues that are close but not a match in this multihomes 
> situation.  Adding the DNS name B at the backup server seems 
> wrong as that IP cannot support the backup communication.
> So, question is, how can one prevent this from reoccurring?
> TIA,
> Roger
> 
> +-------------------------------------------------------------
> ---------
> |This was sent by abell AT asu DOT edu via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +-------------------------------------------------------------
> ---------
> 
> To sign off this list, send email to 
> listserv AT listserv.temple DOT edu and type "signoff networker" in 
> the body of the email. Please write to 
> networker-request AT listserv.temple DOT edu if you have any 
> problems with this list. You can access the archives at 
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
> 

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER