Jump to content

Retrospect client on multihomd host


dantzspam

Recommended Posts

 

Ladies & Gentlemen,

 

short form

..........

Want to run the Retrospect client on a dual-homed Mac whose

TCP control panel is configured for one interface while the

Retrospect backup server is on the segment connected to the

other interface.

 

Please advise.

 

=========================================================

 

longer form

...........

 

Performa 6400/180 running MacOS 8.1 and IPNetRouter.

 

Primary (A) interface attaches to cable modem and

is configured through TCP/IP Control Panel.

 

Secondary (B) interface attaches to internal segment

for which Performa/IPNetRouter then serves as DHCP

server, including for Retrospect Desktop system running

as Backup Server (a fully tricked out iMac at 10.2.5).

 

Both Retrospect Client and Server software are the

latest available from your web site.

 

Because you have chosen to disable Add-By-Address,

I can only configure Clients via multicast, therefore

your multicast must reach the secondary interface of

the Performa. As near as I can tell the Retrospect

Client is unable to cope with the fact that the

interface it should use to respond to the multicast

is not the interface specified in the TCP/IP control

panel.

 

None of this was a problem running earlier versions

of Retrospect with the Performa as the server and

Remotes scattered about on the segment attached to the

secondary interface. It only now becomes a problem

when attempting to upgrade to your more modern versions

of Retrospect which, in fact, require an OS rev level

that cannot be supported on the Performa hardware.

Therefore the Performa must become a Client to another

Server elsewhere on the internal segment. This is,

however, precisely what does not work.

 

Note that doing a TCP port scan of the Performa from

the internal segment shows that all the expected ports

are listening with one glaring and notable exception

which is, of course, port 497 = Retrospect. This

fact demostrates that all TCP services are indeed

running on the internal segment with the exception

of Retrospect. This is an effect limited to TCP;

a UDP port scan does turn up a response from UDP

port 497 = Retrospect, further narrowing the probable

cause to the Retrospect Client itself.

 

I would be happy to run further tests. You may assume

that I am a power user, as they seem to be called,

and that I have a serious amount of UNIX-based test

gear.

 

END

 

Link to comment
Share on other sites

Retrospect Client for Macintosh OS 9.x and earlier does not support any type of Mutli-homing. Retrospect Client looks at the "connect via" settings in the TCP/IP control panel and uses the setting that is configured.

 

If you require multiple TCP/IP settings, some users have created AppleScripts to change TCP/IP configurations as needed.

Link to comment
Share on other sites

 

> If you require multiple TCP/IP settings, some users have created AppleScripts

> to change TCP/IP configurations as needed.

 

OK, let's try again.

 

This is a *router* -- it routes. The last thing it needs is unstable,

AppleScript-adjusted TCP/IP settings which derail its routing service

at intervals its users cannot otherwise predict.

 

It is also a Performa 6400 running 8.x. Because "modern" Retrospect

servers won't run on 8.x, it cannot be the Retrospect server anymore --

which it has been since version 3.0 of Retrospect, which is a good

long time. It must therefore be a Retrospect client while the Retrospect

server runs on the internal segment that the router protects.

 

If it is both a Retrospect client and a locally critical infrastructure

service, then it is *the Retrospect client* that ought to be responding

on the interface and to the address on which the multicast is arriving.

That is precisely what it will not do for TCP/IP and precisely what it

does already do for UDP. It is, in short, a volitional design decision

that the client is behaving as it does (and thus does not work) just

as much as it is a volitional design decision to not allow the server

to run on 8.x platforms. Need we remember that OpenTransport

as found on 8.x is actually very much more configurable and

malleable than the BSD-stack that supplants it on OS X?

 

Tell me, if I pay the tax of buying "Add by address" will I be any

better off? Will the client become aware that I have paid additional

$$$ so that I can reach it by address and not by multicast? Since

this is a *router* it does -- unlike every single other machine on

this local network -- actually have a fixed and predictable address

which could be "added by address" since there actually is an

address to add.

 

Let's go farther afield. Suppose I do decide to croak routing by

whipping routing around in a circle while I temporarily make the

TCP/IP interface that is control-panel-configured the one that is

on the internal segment on which the Retrospect server lives.

Once the multicast discovery of the now newly visible client has

been announced to the Retrospect scheduler can I then whip it

back, i.e., are you really making TCP/IP virtual circuits or does

backup run just by UDP? Is TCP used for anything other than

discovery? If backup is a UDP service, which arguably is the

right thing to do under at least one reading of a backup system's

design constraints, then is the requirement for TCP only the

enforcement mechanism for the "Add by address" being a

separately priced option? Certainly none of this hooha was

an issue for good old Retrospect 3.0 so we've gone backwards

in that sense. Fact is, I'd have stayed with that -- it wasn't

broke -- were OS X compatible clients (remotes) available

which, as presumably a business decision, they have yet to

appear.

 

BTW, multihomed is the wave of the future -- I'm running

several multihomed hosts in support of a burgeoning wireless

plant and anyone with critical needs will want to backup not

just the single-adddress/single-interface leaf nodes of the

networking structure but the core framework as well. In fact,

backing up leaf nodes is getting less and less relevant as

reliability requirements, free-seating, and regulation pressure

force the desktop to be every day more dataless than it was

the day before. Dataless nodes don't need backup.

 

Film at 11.

 

 

 

 

Link to comment
Share on other sites

Retrospect Client does not know about the networking method used by the Retrospect Server.

 

If you use "add by address", Retrospect and Retrospect Client will use the network interface specified in the "connect via" option in the TCP/IP control panel. If you need Mutihoming, you need to use Retrospect under Mac OS X on the client and server

 

The following Tech Memo was writing several years ago, but may still answer some of your questions.

 

 

Description: Single Link Multi-homing and how it affects Dantz products (It doesn’t)

 

Author: Walt Hays

Date: 1/28/98

 

Subject:

 

Before Open Transport 1.3, the Macintosh did not support Multi-homing. Unfortunately, the multi-homing that OT 1.3 supports does not help users of Dantz products.

 

Background:

 

Windows 95 and NT systems allow multi-homing that helps our customers. The most typical scenario is a customer who has dial-up Internet access and a local Ethernet TCP/IP address. Our Windows client uses Ethernet all the time, and the customer uses the Internet whenever they like. On the Macintosh you cannot have a dial-up Internet connection and active local Ethernet TCP/IP access at the same time; you must switch between configurations in the TCP/IP control panel.

 

Mac OS 8.1 ships with OT 1.3, which supports "Single Link Multi-homing". Single Link Multi-homing allows you to assign more than one TCP/IP address to a single physical network adapter. Unfortunately this doesn’t help our customers, as it only applies to local network adapters, not PPP connections.

 

Testing:

 

I set up my Macintosh to use Single Link Multi-homing as detailed in the "OT 1.3 Technical Info" read me. Basically, I created a text file that I put in my Preferences folder that set a second IP address to be associated with my Ethernet card. I could ping this new address and my old address from another computer. When I tried to Add by Address, the secondary address gave me a 541 error (correctly), and my main address worked fine. The client was not affected.

 

I created a PPP configuration, and switched to it. Immediately my secondary address stopped responding to pings. In other words, the PPP interface does not support Single Link Multi-homing.

 

Conclusion:

 

Apple’s Single Link Multi-homing, part of Mac OS 8.1’s Open Transport 1.3, has no effect on our products.

 

Reference:

 

The following page is straight from Apple’s read me "OT 1.3 Technical Info" installed by Mac OS 8.1.

 

Single Link Multi-homing System Setup

 

Open Transport 1.3 introduces Single Link Multi-homing, a mechanism by which Open Transport can support multiple IP addresses on the same hardware interface. Synonyms for this feature include IP Aliasing, Secondary IP address Support, IP Masquerading, "Multihoming", IP Multinode support. This is useful for sites like Internet Service Providers (ISPs), that want to give each of their clients a distinct IP address, without requiring separate computers for each address. Web server software packages, or server plug-ins that utilize this feature can offer virtual domain support that supports all web browsers. You will need to contact your application developer to see if they are supporting this new feature of Open Transport. This feature is only available with Open Transport 1.3 and later.

 

You configure a system to use multiple IP addresses as follows:

 

1. The TCP/IP Control Panel must be set for manual addressing.

 

2. You create a text file with the required name "IP Secondary Addresses" and put it into the Preferences folder in the System Folder.

 

Each line of the IP Secondary Addresses file contains a secondary IP address to be used by the system, and an optional subnet mask and router address for the secondary IP address. If there is no subnet mask entry, then a default subnet mask for the IP address class will be used. If there is no router address entry, then the default router associated with the primary address will be used.

 

Each secondary address entry must be prefixed by "ip=". Each subnet mask entry must be prefixed by "sm=". Each router address entry must be prefixed by "rt=". Lines proceeded by a ; are ignored. An example of the contents of the IP Secondary Addresses file follows.

 

; 'ip=' for ip address, 'sm=' subnet mask, 'rt=' router address

; Note: no space in 'ip=192.168.22.200'

;

; IP address Subnet Mask router addresses

;----------- ----------- ----------------

ip=192.168.22.200 sm=255.255.255.0 rt=192.168.20.1

ip=192.168.22.201 rt=192.168.20.1

ip=192.168.22.202

 

The order of the entries is important. The "rt=" entry must follow the "sm=" entry if used.

 

When Open Transport activates TCP/IP, the primary address will be obtained from the TCP/IP Control Panel setting. Open Transport then looks for the IP Secondary Addresses file in the Preferences folder to determine if additional addresses should also be configured. If there are duplicate IP address entries in the IP Secondary Addresses file, the duplicate addresses will be ignored. When Open Transport binds a TCP/IP connection, if there is an address conflict with either the primary or any secondary addresses with another host, Open Transport will present an error message using a dialog box and unload Open Transport/TCP from memory. The error dialog will display the conflicting IP address, the hardware address of the conflicting machine and note that your TCP/IP network interface has been shut down.

 

To resolve the conflict, quit all of the TCP/IP applications on both conflicting machines, reconfigure TCP/IP on one of the machines so there is no longer an address conflict, then relaunch your TCP/IP applications.

 

Link to comment
Share on other sites

Quote:

This is a *router* -- it routes. The last thing it needs is unstable,

AppleScript-adjusted TCP/IP settings which derail its routing service

at intervals its users cannot otherwise predict.

 


 

Maybe you should consider getting a hardware router. These can be had for as little as $30. This little device solved a LOT of my problems.

Link to comment
Share on other sites

>Tell me, if I pay the tax of buying "Add by address" will I be any

>better off? Will the client become aware that I have paid additional

>$$$ so that I can reach it by address and not by multicast?

 

That's a good question. You should test it and see.

 

Use your old copy of Retrospect 4.3 on a machine on the private LAN. Attempt to connect to the IPNetRouter machine (you may need to regress to the 4.3 control panel on that machine; I don't know if Retrospect 4.3 can connect to a 5.0.140 client, although it appears that the "Classic" control panel hasn't changed for this "modern" release). If it works, I'd be pretty sure it will work under Retrospect 5.0 too.

 

>...re you really making TCP/IP virtual circuits or does

>backup run just by UDP...

 

Backups are via TCP; UDP is used for discovery only.

 

>...I'm running

>several multihomed hosts in support of a burgeoning wireless

>plant and anyone with critical needs will want to backup not

>just the single-adddress/single-interface leaf nodes of the

>networking structure but the core framework as well.

 

Anyone backing up a critical needs networks should be willing to invest in a version of software that will do the job. Dantz broke out the needs of desktop users from the needs of users such as you. If your test with 4.3 reveals that Add by Address allows you to connect to your old Performa (and I'm not so sure that I agree that IPNetRouter on 8.1 is the wave of the future) then paying for a Server version of Retrospect seems like a reasonable choice.

 

I was a huge fan of IPNetRouter back before SOHO routers could be had for about a hundred bucks. Current routers have most of the capability that Peter's software does (although having had the opportunity to listen to him speak I recognize that there are a dizzying number of features available); unless you need some particular functionality that LinkSys or NetGear don't provide you're probably better served by upgrading your networking hardware to something firmware based.

 

Dave

 

 

Link to comment
Share on other sites

FWIW, the reason I use a software router is (1) it ain't broke so why fix it,

and (2) it is very (very) much more configurable and queryable than your

run of the mill hardware router built for a Windows world.

 

As to investing in software, I do that in spades. What I have is a situation

where the software in which I invested (various Retrospect versions) will

not run as a server or as a client on this platform which is infrastructure

critical and, as the last poster suggested, used to work in various

configurations on various previous versions of Retrospect. Progress, in

this case, does rather resemble "paved Paradise and put up a parking

lot."

 

As to the core technical issue: while Open Transport (Mentat/TCP) supports

multi-link multihoming just fine (as proven by IPNetRouter), Apple never

provided a public API to examine the full network configuration of the

machine. Thus products like Retrospect would need to use an "unofficial"

API (available through Apple DTS) to find the list of IP interfaces available

and allow the user to select one, or alternatively bind to address 0 so they

could listen on all interfaces.

 

As I said, this is all volitional design decisions.

 

 

-oo-

 

Link to comment
Share on other sites

>FWIW, the reason I use a software router is (1) it ain't broke so why fix it,

>and (2) it is very (very) much more configurable and queryable than your

>run of the mill hardware router built for a Windows world.

 

When it wasn't broke there was no reason to fix it.

 

But your situation is of your own making. You added machines to your network that didn't exist when your old solution was released. That a new solution is available is good; that it requires more modern hardware/software is fair.

 

That you want to avoid touching your software router is understandable, but it may not be reasonable.

 

- You could put IPNetRouter on a more modern Macintosh, one that runs 9.1

- While IPNetRouter is certainly more configurable and queryable then a SOHO router, if you don't _need_ that configuration and querying the trade offs might be worth it.

 

 

>What I have is a situation

>where the software in which I invested (various Retrospect versions) will

>not run as a server or as a client on this platform which is infrastructure

>critical and, as the last poster suggested, used to work in various

>configurations on various previous versions of Retrospect.

 

If earlier versions of Retrospect will support your multi-homed machine with the client control panel, this current version will too.

 

Perhaps I've missed some part of the discussion, but the only other previous poster in _this_ thread suggested you use a hardware router. I do not see as part of this discussion someone who has tried to use Retrospect to connect to a multi-homed classic client using "Add by address" or "Configure subnet broadcast."

 

Did you try the test I suggested? You already have all the software you need to do it, and the answer you get from that test will tell you whether you simply need the more powerful version of Retrospect 5.

 

Dave

Link to comment
Share on other sites

  • 3 weeks later...

Quote:

FWIW, the reason I use a software router is (1) it ain't broke so why fix it,

and (2) it is very (very) much more configurable and queryable than your

run of the mill hardware router built for a Windows world.

 


To a previous poster's comments, I would add that the Performa uses a great deal more electrical energy than the hardware router. With the hardware router, most of the power goes to the waste heat from the wall wart. crazy.gif It's wasteful.

 

I'd also note that Power Macs capable of running Mac OS 9.1 were selling for well under $100 on eBay the last time I looked.

 

As for your argument that "it ain't broke so why fix it", I'd ask when the last time was that you changed the oil in your car. You did? Why? What was "broke"?

 

Edward

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...