Seperate Network for Backukps not working

Either browse or \\servername gives me the same results.  Also, going to \\ip address gives me the same error.  Also, I need to mention that this is running in an AD environment.

Ok let me see if i can picture this
Server 1 on production 1 (NIC 1 IP 192.168.25.25  SN 255.255.255.0 GW 192.168.25.1) - (NIC 2 IP 192.168.13.10  SN 255.255.255.0 GW None)
Server 2 on production 1 (NIC 1 IP 192.168.25.35  SN 255.255.255.0 GW 192.168.25.1) - (NIC 2 IP 192.168.13.20  SN 255.255.255.0 GW None)

Backup Server (IP 192.168.13.30 SN 255.255.255.0 GW 192.168.13.?)

Without a DNS to resolve network addresses you would need to add the NetBEUI protocol to be able to route the traffic.

BTW, that solution is provided that your NIC card settings are as djohnson104 had specified, if they're on different subnets, that's the first problem.

Production network is 172.19.166.0 255.255.254.0
I have only mentioned two servers.  The NAS server and the Backup server.  Both servers are on both production network and backup network.

According to other solutions in the Expert Exchange, I should be able to use host files to bypass DNS juanfermin.

That's true, but I've found from Windows that you usually have to have a main plan and a backup plan for everything, because it doesn't always work as it's supposed to.  This is one of the reasons why I still use Wins Servers, because even though they're "supposed" to be obsolete, I've found that, especially in the larger networks, you need an alternate if for whatever reason the DNS isn't working as expected.

I think we you should drop the whole DNS thing for now. That is just another layer to troubleshoot. Use ip addresses and get your connection working then worry about name resolution.

So you have 2 servers both on 2 networks right? Are they directly connected to each other on the 192.168.13.0 network? or are their switches involved?

Whats with the wins and the dns? we have 2 servers and 4 network cards. we need two servers to communicate right now lets not make it harder than that.

The can talk to each other on the production network wich involves a CISCO 6513 core.   For the backup network, I have placed a small 5 port NetGear Gigabit switch (unmanaged)  to connect them together.

Ok and backup  connects to Nas and grabs the files it needs to back up?

Where I work they build simulators that have multiple computers with multiple nics.  The problem is on the back up network their is no gateway to send the data to. So it sends the unknown data out the production nic. What you need to add are static routes for your backup network on each machine.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_tcpip_pro_addstaticroute.mspx?mfr=true

This is the link i used, i am sure it will work for 2003 and 2000 as well. Make sure you add the -p flag to save the route after reboot.

Oh and that is one route for each machine, change the ip addresses to the proper ones.(i am sure you know that)

That sounds like a winner.  I have already changed everything to run on the production network for this weekend.  I will give this a test next week and let you know.  Also, I am assuming if this works, I will need to add it to the autoexec or something in order to save the settings?

The routes? as long as you add the -p flag it will save it in the registry.

First of all, for the backup network, use separate ip adresses, for instance if you use 192.168.13 use something else for the backup network. For instance 10.0.0.x then, if use use host files, name the backup nodes differently (one name for 192.168.0. address and one other name for the 10.0.0. address. (if you even need to use names for it, on your small network you can use ip addresses. Using this configuration you would ensure that the backup traffic goes on the backup nic and it will not interfere with your current setup

Quote "Production network is 172.19.166.0 255.255.254.0
"the backup network for 192.168.13.X

Sorry I didnt see that, but the rest of the info still applies.
pitroadhobo: In the backup policy, have you named the server you are trying to backup by name or IP? If you are using a name you should call it something else than the production name, that should fix so you dont have to add any routes. I must add that I provide backup for alot of hosts using a separate backup nic. As long as you either provide a unique name that is associated with the backup nic, or the ip of the backup nic you should be ok.

djohnson104

I get the error "route: bad argument 192.168.13.2" when I run the route add command as in your example.  I have tried some different variation and even tried running it with the clear all routes commands.   I am running "route add -p  192.168.13.0 255.255.255.0 192.168.13.3 metric 2" on the machine with the ip address of 192.168.13.3.  Any suggestions?

you need to add MASK between the first ip and the mask.
( route -p add 192.168.13.0 MASK 255.255.255.0 192.168.13.3 metric 2 )

I still cannot see why you need to add this route if you read my other post.

Ok
How should I specify the different host name for the interface? Do I just do that in the host file or is there another place?

So groetting, what you are saying if he adds his hostname to ip in the host file it will work? If so then he should be able to just use IP address right?

Again I am sorry, I missed the fact that he was unable to use the ip adress.

run a "route print"

Let me know what you get.

If you use multi-homed nics, you need to be really careful with DNS since DNS will resolve to *one* ip address.  Doesn't matter that your server has two IP's, the server's name only resolved to one IP as specified by DNS.

I setup backup-nic DNS entries, that is, dns wwwserver.mycompany.com is 10.2.2.4, but backup-wwwserver.mycompany.com is 192.168.2.4.  The server has two nics, one on IP 10.2.2.4 and the other on 192.168.2.4.  It has two DNS entries, one resolves to the application IP (10.2.2.4), the other resolves to the backup IP (192.168.2.4) used specifically for backup services.

As for your connectivity issue, I'd recommend using wireshark (i.e. ethereal) to analyze your network packets and figure out just where your data is being sent.  Windows may not be configured right, but it's not always easy to see what Windows is doing or why.  Running the network sniffer will show you what's actually going on.  Sometimes that helps you determine why the config isn't working since you can see the incorrect behavior.  Right now you can't see what's wrong, it's just not working.

Why do you need dns? Shouldn't you just worry about getting IP working without DNS. DNS is just adding another lable of troublshooting. Once you get it working VIA IP then you should worry about DNS. Networking WILL work with out DNS or WINS. Name Resolution is just something to make life easier. I say get it working by IP first then worry about DNS.

I have to use DNS on my production network for my client workstations.  I think the problem is that my backup sever is on both networks and it is difficult to tell it which network to talk across.  Obviously, DNS and Active Directory have a lot of control on my network so they may be dictating which subnet is used.  When I put the entries in the host file, routing and name resolution works correctly.  When I ping either server by name it resolves to the backup network.  But when I try to go to a UNC path, it fails, thus Backup Exec fails when trying to contact the server.  Something about authentication which may be an Active Directory hangup.  The additional DNS entry may be the trick but I  am very hestitant to try that on the production network.  Again, I say this seems to be such a simple concept but I can't explain why it doesn't work.

Well you problem starts before AD or DNS. Your trying to fix the whole system at once. You need to get the underlying network working first. Your IP does not work your DNS will not work, if your DNS does not work then your AD will not work. The whole purpose of the OSI model is to work in layers.

I will try an additional DNS entry for the backup network.

For DNS to work you need your underlying IP to work.