Hi David,
Here's some information on how Retrospect communicates with client systems.
For more information on client discovery methods, please see pages 91-95 in
the Retrospect 5.0 User's Guide and pages 83-84 in the Retrospect 4.2 User's
Guide.
I hope this helps!
Eric Ullman
Dantz Development
--
RETROSPECT CLIENT DISCOVERY METHODS
Retrospect can "discover" client computers, providing they are in the same
local subnet as the Retrospect server, via its own internal name service.
This method, called Multicast, uses a UDP broadcast mechanism, to which
client computers respond with their IP address. The UDP broadcast packets
have a time-to-live of one, so they do not attempt to travel outside of the
local subnet. Once the client machine has been identified via UDP,
Retrospect handles any further communication with the client through
point-to-point TCP/IP (i.e., the client's IP address). DHCP poses no threat
to this method of local client discovery.
Retrospect Server Backup for Win32 (and Retrospect 4.2 Mac) can be
configured to discover Retrospect clients in any IP subnet defined by the
administrator. Retrospect accomplishes this with an extended version of its
internal name service called Subnet Broadcast. UDP broadcasts are sent in
turn to each defined subnet, thereby discovering all client computers, no
matter what their assigned IP address may be at the time.
This method of client discovery has one possible drawback. The routers,
through which Retrospect communicates with remote subnets need to support
UDP multicast packet forwarding. Often, in an effort to cut down on
cross-subnet chatter, many routers on large networks are configured to
*disallow* such UDP broadcasts. This defeats Retrospect's subnet broadcast
ability.
We have also seen extreme cases where switched hubs are configured to block
UDP broadcasts. This prevents any version of Retrospect from discovering
clients that aren't on exactly the same network segment.
If a DNS service is in place, DNS name is also a reliable means to track
Retrospect clients, since the DNS database will update the client computers'
IP addresses. There may be a lag of several hours, between IP leases
expiring and the DNS server updating its database, but Retrospect will
eventually be able to find such clients.
SOLUTIONS
If you're having trouble communicating with client computers outside of the
local Retrospect server's IP subnet, try these possible fixes/workarounds:
1. Configure routers (and switched hubs) to allow UDP broadcasts, on TCP/IP
port 497. Retrospect only broadcasts using IANA-registered socket 497, so
filtering other ports would not prevent it from discovering remote clients
in defined IP subnets.
2. Implement and use DNS naming procedures for all your desktop and notebook
computers. Then add in each client computer directly, by DNS name.
3. Put one Retrospect server in each and every IP subnet.
4. Use static IP addressing, and add clients directly by their IP address.
--
From: "Husk.David" [EMAIL PROTECTED]
Reply-To: "retro-talk" [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 15:08:38 -0500
To: "'retro-talk'" [EMAIL PROTECTED]
Subject: RE: PC clients
It turns out our problem was that a switch was filtering the multicast
retrospect packets. Is there a white paper that deals with how hand shaking
is accomplished between the Retrospect client and server?
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives:http://list.working-dogs.com/lists/retro-talk/
Problems?: [EMAIL PROTECTED]
