Clients not showing up across subnets

[tjyoung]

We are using Retrospect mulit-server 7.5. The server is located behind a firewall in a data center. Clients anywhere on the network can easily be backed up and restored through direct connect. Retrospect will not auto discover any clients across subnets using the subnets I have configured in Live Network. I have tried opening port 497 on the server firewall, although I do not think this is necessary. Any help would be appreciated. My eyes are going cross on this one!

[Lennart_T]

Did you open port 497 for both UDP as well as TCP? If not, you must.

[JohnJ]

ThomasY -

 

We fought with this same issue for weeks also. Our network is configured so that subnet broadcasting is not allowed. There are some posts in this forum that dismiss that policy but our network architects will not budge. Ours is also a DHCP environment so adding clients via the Direct option was not an option. Fortunately, the bulk of our target users are in 1 building with 4 floors and 1 subnet per floor. We added two dual port NIC's to the server and configured them to communicate with each of the subnets. This is a stop gap solution for us until there is a new Retrospect version that has the clients looking for the server rather than the server looking for the clients. Bottom line (at least from our experience), is that if you are in a DHCP environment and cannot get your network team to enable subnet broadcasting, you are out of luck.

[tjyoung]

I am finding out that a "Helper Address" can be configured into the switches to route the broadcast traffic from the clients to the backup server WITHOUT turning on subnet broadcasting. We have CISCO switches that can do this. I am looking into this now and can share what I find. Thanks for getting me pointed in the right direction.

[JohnJ]

We would be very interested in understanding this 'Helper Address' option if you can get it to work. Thanks

[rhwalker]

Quote:

---

Ours is also a DHCP environment so adding clients via the Direct option was not an option.

 

---

John,

 

Have you considered trying to convince your network people to do DHCP static maps by MAC address (rather than from a dynamic pool)? That way, each client would always get the same IP, even though they are using DHCP. Would not require any changes on the clients, only on the DHCP server, and you could then add the clients by IP.

 

Most network administrators prefer DHCP static maps by MAC address because it makes logging/investigation of problems easier (each client stays at the same IP), and still allows use of DHCP. You might also suggest to them that they could then put in reverse DNS on the LAN so that the machines could discover their own names from their DHCP-supplied IPs.

 

It's really rather straightforward, and even a rather junior network person can set it up.

 

Regards,

 

Russ

[wusean]

I keep on seeing this kind answer, "Have you considered trying to convince your network people to do DHCP static maps by MAC address ", I'm sure not every company allows you to do so, in my case we are just a very small department who using Macs, I have purchased this software for more then half year, and still not able to get it work right, I can only manually input the IP address, but everytime when IP changes I have to re-set up. the funny thing is when I restart the server, the very first time Restrospect server sees the clients, but I was not able to login, when login faild, the clients dispear, then I have to manually use IP.

[rhwalker]

Quote:

---

I keep on seeing this kind answer, "Have you considered trying to convince your network people to do DHCP static maps by MAC address ", I'm sure not every company allows you to do so, in my case we are just a very small department who using Macs, I have purchased this software for more then half year, and still not able to get it work right, I can only manually input the IP address, but everytime when IP changes I have to re-set up. the funny thing is when I restart the server, the very first time Restrospect server sees the clients, but I was not able to login, when login faild, the clients dispear, then I have to manually use IP.

 

---

Just trying to be helpful, and the solution I provided would solve your problem. Sorry that you don't want to use a solution that would solve your problem. Whatever. Good luck. It's not going to magically start working on its own.

 

Russ

[JohnJ]

Russ,

 

We did investigate using reserved IP addresses for the targeted machines. We decided against it primarily because the people who belong to the target machines move frequently between locations that are on different subnets so their IP addresses change when they move. Since they are not autodetected in this method, the support overhead goes up because we would need to keep track of machines as they move to change the reserved IP address and then get the client talking with the server again after the move. So while we wait for the re-architected product, we implemented the dual port NIC solution which is working for a reduced number of intended clients but we at least have it working. To be fair though, in some environments your suggestion would be feasible - the cons just out-weighed the pros in ours.

[rhwalker]

John,

 

Hmm... That's a new twist, machines moving between subnets. The real issue, then, seems to be that the client broadcasts don't pass across subnets as the clients move, as you originally stated (and which I didn't fully understand because of the missing information about moving clients). Would your network people permit a narrow firewall rule at the subnet boundaries to pass the client broadcasts only into the retrospect server's subnet (rather than into all subnets)? Or, since the only machine that needs to hear the broadcasts is the Retrospect server, perhaps a NAT translation rule to translate the broadcasts into a destination IP for the Retrospect server. Just some food for thought. My networks are static, so I haven't had to face this issue.

 

Russ