Clients frequently becoming unreachable.

[gadmin]

My proactive backup schedule attempts to back up users at least daily (set to every 3 hours under the advice of tech support). All of my users are on a DHCP network so their IP's change on a daily basis.

 

Even after adding users to the sources window using multicasting instead of typing in their current IP, i have clients becoming unreachable. It's happen through all different client versions and server versions. Currently everyone is on 6.028 Mac client and are all Macintosh platforms. The clients that become unreachable are random and can only be fixed by me monitoring the server daily to see who is no longer being backed up. I then delete the source, re-install the client on their mac (otherwise it won't show up in multicasting), then add them back to the proactive script.

 

Anyone else experience this type of behaviour?

[Maser]

Is there a reason you can't set *static* DHCP for your clients? That would probably solve a lot of these problems.

[gadmin]

Since the vast majority of our users are on laptops, we are trying to simplify the client network as much as possible. The way we have it setup, their network location will be functional whether they are in the office, offsite, or at home since DHCP is by far the more widely used IP config.

[rhwalker]

Yep, but most DHCP servers can serve DHCP leases based on the requester's MAC address (a so-called "static map"), such that each computer always gets the same IP address. That's what we do, and I've never seen this problem.

 

This also simplifies client management and logging, because you can set up a reverse DNS zone for the IP addresses, and log / reference each computer by its name.

 

Just make sure that the static map DHCP scope doesn't overlap any dynamic pool's DHCP scope, or grave disorder will result.

 

Russ

[Maser]

What Russ said goes double for me. ;-)

[gadmin]

Ok, that's good information, thanks guys! Didn't know that the multicast would be so problematic and didn't read anywhere to avoid dynamically changing IP addresses but I guess this is one of those tricks learned over using the solution.

[gadmin]

Fudge, it just came to me that I'm going to have to be vigilent with this mac address database, when somebody changes computers, new employees, etc.. I wonder if there is a way to do this with Single Sign On instead? Or is there another way using something other than a hardware address? Sounds like a lot of work with the amount of changes that go on in this network...

[CallMeDave]

I then delete the source, re-install the client on their mac (otherwise it won't show up in multicasting), then add them back to the proactive script

 

What happens if you simply kill/restart the [color:purple]retroclient[/color] unix daemon on the problem client(s)?

[Maser]

Fudge, it just came to me that I'm going to have to be vigilent with this mac address database, when somebody changes computers, new employees, etc.. I wonder if there is a way to do this with Single Sign On instead? Or is there another way using something other than a hardware address? Sounds like a lot of work with the amount of changes that go on in this network...

 

 

That really depends on your network. I used to manage a network (a University department) where there were about 1000 machines and new students coming in every year with probably a turn-over of 150 machines per year.

 

But *most* of those machines -- the majority -- were around for many years, so setting them up was a one-time issue.

 

Managing a static DHCP server system is not that hard. Sure, your initial setup will be, but in the long run, it'll give you a *lot* better information about your network and who is on it and what they are doing, etc...

[dskincaid]

I am plagued by this issue as well, though using fixed IPs on all my clients. I can initiate a 'manual' backup no problem. However clients identified by tags in proactive scripts are often ignored by the server.

 

Running the latest of everything Retrospect on Xserve 10.6.2.

[Pforne]

I think the term you're looking for here is a DHCP "reservation". You tell the DHCP server to reserve an IP for each machine based on its MAC address...

 

This reservation pool can be within the normal DHCP scope. It can also usually be set up using the client's current IP address so restarts are not necessary...

 

 

Yep, but most DHCP servers can serve DHCP leases based on the requester's MAC address (a so-called "static map"), such that each computer always gets the same IP address. That's what we do, and I've never seen this problem.

 

This also simplifies client management and logging, because you can set up a reverse DNS zone for the IP addresses, and log / reference each computer by its name.

 

Just make sure that the static map DHCP scope doesn't overlap any dynamic pool's DHCP scope, or grave disorder will result.

 

Russ

 

[rhwalker]

I think the term you're looking for here is a DHCP "reservation". You tell the DHCP server to reserve an IP for each machine based on its MAC address...

Nope, I used exactly the term I wanted to use. I was trying to help the posters solve their problem rather than debate semantics. I'm well aware of terms used in the RFCs, but those documents aren't typically used by Retrospect users when setting up their DHCP servers.

 

The term used by Apple's Server Admin DHCP setup pane and by many firewall/router UTMs, such as SonicWALL's GUI, is, can we guess, Static Map by MAC address.

 

That's what a Retrospect user would see when going to make the necessary changes.

 

Russ

[Marietta]

I'm having the same problems (as dskincald) with clients not being connected. We all have a fixed IP address. I am running Retrospect version 8.1 build 626 on an Imac OS10.6.3. Client version - 6.3.027 . Half the time, retrospect cannot connect to some of the clients, another day, it can't connect to others. If I do a test by address, the clients show up, but usually they don't when searching by multicast (sometimes they do if I restart the retrospect engine). I usually find out if they are connected properly after the backup (successful or not)

Is there an easy way to verify that the clients are connected properly? And how would I connect them, if they are not?

 

I am not very familiar with DHCP setups, and am hoping I do not have to become an expert with them. I think that everything should be set up properly for backups. They worked fine for a while, and we haven't changed anything. The firewall port is allowing retrospect through.