Jump to content

Subnet Broadcasting


Nigel Smith

Recommended Posts

All,

Trying to get subnet broadcasting working.

We have 2 subnets, both on the same interface of a Fortigate IPS -- for sake of argument, 192.168.45.0/24 and 192.168.183.0/25. Unicast is fine in both directions. Server sits on the 45-subnet and can broadcast-detect all clients on that subnet but no clients on the 183.

We've set the second subnet definition on the server's default interface to be 192.168.183.12/30, giving a broadcast address of 192.168.183.15. We've set up a static ARP entry and policy on the Fortigate so that anything from the server to 192.168.183.15 goes to FF:FF:FF:FF:FF:FF, and the policy is showing traffic so it looks like the server's "shout" is at least getting that far.

But I know nothing about the client's response. Does the server's "shout" include its IP address (if so, will the above hide that?) and is the client's response unicast? Does the client even respond to Layer 2 broadcast traffic, or does it require Layer 3?

TIA to anyone with any answers,

Nige

Edited by Nigel Smith
spelink
Link to comment
Share on other sites

Nigel Smith,

Your post doesn't say what version of Retrospect you are using, and whether it is Retrospect Windows or Retrospect Mac.  Rather than waste my time by making an inquiry, I'll just assume it is some version of Retrospect Mac—as most of your past posts seem to indicate.

Everything I know about setting subnet addresses in Retrospect, which isn't much, is contained in the posts I made in this thread last year.  I suggest you read all those post, and view the video by the head of Retrospect Tech Support I linked to in one of them.  I also suggest you read this section of the relevant Wikipedia article.

I don't know anything about setting server interfaces, so someone else will have to comment on that.

Link to comment
Share on other sites

My bad -- we're actually using Multi Server Premium v15.1.2.100 on Windows Server 2016 for this. Clients are Mac and Windows of various vintages.

But, as I far as I know, that shouldn't matter. The underlying mechanism for RS's subnet broadcasts has been the same for years (though it is handled differently at the OS level by Macs and PCs) and it is that which I am trying to get more info on.

Server interface doesn't need adjusting, just "Default" with the 45 and 183 subnets defined -- and it has to be that way since each client can get either a 45- or 183-based DHCP provided address when they connect to our network (using different interfaces for each subnet works for client discovery, but clients are then only backed up when they are on the same subnet they were discovered on ? ).

If it sounds a horrible mess -- it is! But it is like that for historic reasons, which we had no control over. We used to be OK because our network ran under a 255.255.0.0 net mask and so RS broadcasts from a 45 covered that and the 183 (we have a third, unrelated, subnet but any client there is static IPed and so reachable directly), but a gateway "upgrade" last year resulted in both physical and logical topology changes which included tightening the mask -- a good thing in general, but not for this specific...

Central Network's guys are suggesting Layer 2 broadcast forwarding (rather than Layer 3 as described in that Wikipedia article), but I'll be chasing my tail if RS client doesn't respond to Layer 2 ?

(Oh, and thanks David -- nice to recognise a name from the past!)

Nige

Link to comment
Share on other sites

Nigel Smith,

As I've said elsewhere, I run Retrospect Mac 14 on a small home network with no subnetting.  IIRC, when I Add a Removed and re-installed Client from my "backup server", the Client software stores  the server address of the "backup server" that Added it—which cannot then be changed (I just checked in a System Preferences—>Retrospect).  If you install a bunch of clients from the 192.168.183.15 "backup server" address , it sounds to me as if those clients will communicate over the .address ff.ff.ff.ff.ff.ff (is that an IPV6 address?—it's 48 instead of 64 bits) because that's how your Fortigate is set up.

If that doesn't work I will fearlessly offer some suggestions, probably based on a misunderstanding of your problem and certainly with no knowledge of the Fortigate IPS.

First, have you considered establishing a fixed IP address for each client machine, based on its MAC address (upper-case "MAC" stands for "media access control", and has nothing to do with "Mac" as an abbreviation for Macintosh—though many people think it does)?  I was advised by the now-departed assistant to the head of Retrospect Technical Support to do this through my router when I installed Retrospect Mac 12 in 2015; it had not been necessary through Retrospect Mac 6.  I don't know how you would do this in conjunction with Fortigate.  You would then Remove, re-install, and re-Add each Client on your "backup server"—specifying that fixed IP address.

Second, have you considered "Using Public/Private Key Authentication with Retrospect Clients", which is described starting on page 59 of the Retrospect Mac 15 User's Guide (you can find the equivalent section in the Retrospect Windows 15 UG; I'm not going to bother)?

Third, you should try using the technique described in this Knowledge Base article.  If testing with the ip command works, you would obviously want to switch to using the ipsave command.

Fourth, you may still be entitled to free Tech Support because you have purchased Retrospect 15.  Based on the experience of another administrator, it seems that Retrospect Inc.'s European TS is contracted out to people who are not very knowledgeable.  I would instead submit a Support Request to Walnut Creek CA via this form.

P.S.: Added new first paragraph.

 

Link to comment
Share on other sites

On 10/5/2018 at 5:19 AM, Nigel Smith said:

....

....

Server interface doesn't need adjusting, just "Default" with the 45 and 183 subnets defined -- and it has to be that way since each client can get either a 45- or 183-based DHCP provided address when they connect to our network (using different interfaces for each subnet works for client discovery, but clients are then only backed up when they are on the same subnet they were discovered on ? ).

If it sounds a horrible mess -- it is! But it is like that for historic reasons, which we had no control over. We used to be OK because our network ran under a 255.255.0.0 net mask and so RS broadcasts from a 45 covered that and the 183 (we have a third, unrelated, subnet but any client there is static IPed and so reachable directly), but a gateway "upgrade" last year resulted in both physical and logical topology changes which included tightening the mask -- a good thing in general, but not for this specific...

Central Network's guys are suggesting Layer 2 broadcast forwarding (rather than Layer 3 as described in that Wikipedia article), but I'll be chasing my tail if RS client doesn't respond to Layer 2 ?

....

Nige

Nigel Smith,

Thinking further, it occurred to me that "each client can get either a 45- or 183-based DHCP provided address when they connect to our network" means the clients on those two subnets transiently connect to your network.  That sounds to me as if you are likely to be using Proactive scripts to back them up. 

If so, it seems that Retrospect 15.1 might be able to handle those clients with its new Remote Backup feature. That, to the extent I understand it, would mean that each client machine would have to have an IP address on whichever subnet it connects to.  You might have to set these up (I don't know how with Fortigate involved) with two static IPs for each client machine's MAC address, one for each subnet it might connect to.  Your "backup server" would have to have port 497 open—and port 22024 if you want to allow on-demand requests, and would have to have the "Remote Backup Clients" item defined on Volumes and the "Remote Backup Clients" tag defined under Sources; it would also have to be set up with a public/private keypair per "Installing Windows Clients for Multiple Log In" starting on page 275 of the Retrospect Windows 15 User's Guide.  You would then have to give each installed client the public key, apparently according to this post.  Thus a particular client machine would get Proactively backed up on whichever subnet it connected to.

P.S.: Revised second paragraph, because my first version would have required duplicate Proactive scripts using different names for the same client (because it would be set up with two static IPs for the client machine's MAC address, one for each subnet) depending on which subnet it was connected to—which I'm sure you would consider undesirable.  Basically I'm pretty sure (but you should ask Retrospect T. S.) that a Client doesn't even respond to Layer 2 broadcast traffic; it requires Layer 3 (my only exposure to networking layers was in one lecture of a course I took in 1990; I'm a retired applications programmer).  I suspect your topology involves client computers that move around between connections, which would have been unusual in 1990 because Wi-Fi didn't yet exist.  Public/private keypairs were invented for situations where Natasha Fatale might be able to spoof the IP address and password of enterprise-employee Carmen Sandiego's computer; it was Retrospect Inc.'s recent insight that Carmen might be connecting from another network anywhere in the world and would need the Remote Backup facility.  In that case Carmen wouldn't need to have an IP address assigned, which is why I changed to "might" in the third sentence of the second paragraph.

Edited by DavidHertzberg
Replaced third-from-last and second-from-last sentences in second paragraph, revised third sentences in second paragraph, added P.S.
Link to comment
Share on other sites

On 10/5/2018 at 5:05 PM, DavidHertzberg said:

If you install a bunch of clients from the 192.168.183.15 "backup server" address , it sounds to me as if those clients will communicate over the .address ff.ff.ff.ff.ff.ff (is that an IPV6 address?—it's 48 instead of 64 bits) because that's how your Fortigate is set up.

ff.ff.ff.ff.ff.ff.ff is a MAC address, the Layer 2 analog of Layer 3's 192.168.183.255 -- it's an "ethernet broadcast" while the second is an IPv4 broadcast. That's the crux of the question -- will RS client respond to that in the same way as the normal IPv4 broadcast? Wireshark shows that the forwarded packets retain their IPv4 headers, originating from the server (192.168.45.31) and using UDP port 497 -- however their destination is 192.168.183.15, which may mess with the client (i.e. it's receiving a broadcast but not from the expected IPv4 broadcast address.

Server to Fortigate looks good, Fortigate to subnet looks OK, I now need to Wireshark a client to see what it is getting.

Quote

First, have you considered establishing a fixed IP address for each client machine, based on its MAC address (upper-case "MAC" stands for "media access control", and has nothing to do with "Mac" as an abbreviation for Macintosh—though many people think it does)?

I'd do this at home. But here we have 450+ non-static devices and ~350 addresses in the IP pool. So, quite aside from the work involved, we simply won't fit.

Quote

Second, have you considered "Using Public/Private Key Authentication with Retrospect Clients"

As I understand it, P/PKA merely obviates the need to provide a backup password during client install. It still requires the server to poll for the new client as usual (though that process can be automatic) and so will have the same problem. But I'll have another look in case the server address can be included so the client can notify it of its presence.

Quote

Third, you should try using the technique described in this Knowledge Base article.  If testing with the ip command works, you would obviously want to switch to using the ipsave command.

This is Plan B (or probably F or G by now ? ). Install the client normally, temporarily re-bind to a 45 address if necessary, add client to server. It appears that our sticking point is the initial add -- once the client is registered the server can detect it on either subnet. But I can't see why the mechanisms are different, I may be seeing an IP-caching artefact rather than a true detection, and this will need a lot of testing before I'm happy with it.

From your follow-up:

Quote

If so, it seems that Retrospect 15.1 might be able to handle those clients with its new Remote Backup feature

This might work. I had a quick look at Remote Backup for another problem, but it didn't help (no control over the other [private] network's settings) so didn't delve too deep. If I can create sub-folders in the Remote Backup Clients folder and assign those to different Proactive scripts -- to maintain concurrent operations and allow different clients to use different backup sets -- it might be a work-round if we can't get things working "properly". Thanks for the idea!

And finally...

Quote

Fourth, you may still be entitled to free Tech Support because you have purchased Retrospect 15...  I would instead submit a Support Request to Walnut Creek CA via this form.

I'm kinda hoping Mayoff will stumble across this thread. Having been helped by Robin before when trying (and succeeding!) to subvert Internet Backups to do things they weren't meant to, I know he's The Man and isn't averse to handling weird situations like this.

Thanks David, this has been a great help. I'm desperately trying to solve this without a complete network re-do because, at that stage, we'd also be looking at things like client network login -- and that would make Retrospect's USP of Proactive backups redundant and almost certainly push us to changing to Netvault or similar. And we don't want to do that!

Nige

Link to comment
Share on other sites

On 10/8/2018 at 5:25 AM, Nigel Smith said:

...

....

I'd do this at home. But here we have 450+ non-static devices and ~350 addresses in the IP pool. So, quite aside from the work involved, we simply won't fit.

As I understand it, P/PKA merely obviates the need to provide a backup password during client install. It still requires the server to poll for the new client as usual (though that process can be automatic) and so will have the same problem. But I'll have another look in case the server address can be included so the client can notify it of its presence.

....

From your follow-up:

This might work. I had a quick look at Remote Backup for another problem, but it didn't help (no control over the other [private] network's settings) so didn't delve too deep. If I can create sub-folders in the Remote Backup Clients folder and assign those to different Proactive scripts -- to maintain concurrent operations and allow different clients to use different backup sets -- it might be a work-round if we can't get things working "properly". Thanks for the idea!

And finally...

I'm kinda hoping Mayoff will stumble across this thread. Having been helped by Robin before when trying (and succeeding!) to subvert Internet Backups to do things they weren't meant to, I know he's The Man and isn't averse to handling weird situations like this.

Thanks David, this has been a great help. I'm desperately trying to solve this without a complete network re-do because, at that stage, we'd also be looking at things like client network login -- and that would make Retrospect's USP of Proactive backups redundant and almost certainly push us to changing to Netvault or similar. And we don't want to do that!

Nige

Nigel Smith,

It appears that you have two intra-organizational foul-ups.  One is that you have more non-static devices than addresses in the IP pool, which sounds to me like a merger foul-up—possibly compounded by the IPV4 address shortage and associated money problems.  The other is that "the gateway 'upgrade' last year" means "server sits on the 45-subnet and can broadcast-detect all clients on that subnet but no clients on the 183", which sounds to me like some sort of security-motivated foul-up—since you say "each client can get either a 45- or 183-based DHCP provided address when they connect to our network".  I don't expect you to explain those foul-ups on this forum, but I suspect switching to any client-server other than Retrospect will result in your organization's spending much more money and you spending much more time than would be palatable.

One alternative is to simply set up a second Retrospect "backup server" on a machine that has full access to the 183-based subnet.  Since you are willing to "maintain concurrent operations and allow different clients to use different backup sets", I suspect that Retrospect 16's full Retrospect Management Console—expected to be available in March 2019—will allow you to meet these needs by monitoring and controlling both "backup servers" from one Console.  An extra "backup server" machine would be trivial for an organization of your size, and I'm sure you can negotiate with Retrospect Inc. for no additional license fee in a situation that could be viewed as being the fault of a deficiency in their product.

Another alternative is Remote Backup, as I have mentioned above.  This KB article says you have to use public/private keypairs for he facility.  However, the top of page 60 in the Retrospect Mac 15 UG says "Distribute or copy this public_key folder containing the pubkey.dat file along with the Retrospect Client installer. As long as the public_key folder is located at the same level with the Client installer when the installer is run, the proper encryption keys (pubkey.dat, pubkey1.dat, pubkey2.dat, ..., pubkey9.dat) will be installed on each client".  Unless the use of multiple encryption keys is a facility peculiar to the Mac Client, IMHO the lack of this same paragraph in the Retrospect Windows 15 UG is simply another example of the accumulated inconsistencies between the Mac and Windows UGs for which I have justifiably criticized (see the second sentence in the next paragraph) Retrospect Inc..

Either way I agree that you should discuss your problem with the head of Retrospect Technical Support.  I am not mentioning his name, as you have done, because it is my impression that he does a daily search of the Forums for posts by me containing his name—resulting in his coming down on me like a ton of bricks for any thoroughly justified or joking criticism of Retrospect Inc. or its customers contained in them.  Other than that, he has apparently been too busy for the past year or so—since he lost his assistant—to look at the Forums.  That is why I suggested that you create a Support Case, because I suspect he will automatically refer any phone call  from you—likely a Brit—to European Support.

P.S.: If your Support Case does not receive prompt attention, I suggest that you phone Retrospect Sales—who have on one occasion "goosed" Tech Support for me.  The head of Sales is Werner Walter; his U.S. phone number is (925) 476-1030 extension 814, his e-mail is Werner.Walter@Retrospect.com.  If you have to do this, be sure to mention the specific other client-server backup application that you are considering switching to; the thought of a current customer—especially one who has just purchased the latest version as you have—having inquired about the competition tends to energize salespeople.  Also please be aware that the "description of your issue" in the Support Case form is IME limited to about 2000 characters by the Support Case software.  If you go over that limit your "description" will be broken up into a "description" plus one or more "additional notes".  The same is true for any additional notes you may later post yourself.  I suggest that, to avoid the appearance of choppiness in your Support Case, you create your case from your posts in this thread and then copy it paragraph-by-paragraph to your Support Case.  Finally please be aware that the Support Case software does not support any text formatting; to underline something I suggest putting the underscore character in front of the first and behind the last word you would like to underline.

P.P.S.: Removed mention of Storage Groups from 2nd paragraph; a Backup Set is supposed to be simultaneously updateable by more than one activity if it's a Storage Group, but no doubt the Backup Set itself (as opposed to its Members) must be defined on only one disk drive—which couldn't be simultaneously updated by activities running on two different "backup servers".

Edited by DavidHertzberg
Added P.S. about writing an effective Support Case and getting attention paid to it; P.P.S. saying Storage Groups not applicable
Link to comment
Share on other sites

As you are using private IP address space anyway, would it be possible for your organisation to transition from the two Class C 192.168.45.m and 192.168.183.m networks to a single Class B 172.n.m.m. network? This would give you more than enough IP addresses for the 450 machines. (Would probably make network administration simpler too.)

EDIT: Unless there is something really weird going on in your network the change from Class C to Class B can be achieved by changing the scope of the DHCP server.

Edited by Scillonian
Link to comment
Share on other sites

12 hours ago, Scillonian said:

As you are using private IP address space anyway...

Actually public space -- the IPs given above are just examples.

While it wouldn't take too much work to find what the ranges really are, a little obfuscation on a public forum isn't a bad thing. But I apologise for not making that clear and so wasting your time.

However, moving to completely private behind our NATing Fortigate is certainly an option. As is moving to IPv6, for which we are getting increasing pressure from central Networking. Both would be long-term projects and neither comes under the heading of "fun" for me, so I'll do what I can with what we've currently got.

Thanks anyway,

Nige

Link to comment
Share on other sites

On 10/8/2018 at 4:51 PM, DavidHertzberg said:

Nigel Smith,

It appears that you have two intra-organizational foul-ups.

Aargh -- board ate my post (anyone else have to reset their password every time they want to log in?). Abbreviated version follows...

Hardly foul-ups. Many places run with less IPs than potentially connected devices -- think of your local coffee shop. In our case we've many staff with multiple devices, most of which are seldom connected. Rotation students who are only here one day a week, one week a month, or one month a quarter. Early starters/finishers who hardly overlap with the night owls. And so on. So we rarely go above 80% usage our DHCP pool and many devices have the same IP day to day -- but potentially they could be on either subnet when RS comes a-knockin'.

The gateway upgrade is vast improvement for 99% of our use-case. The only thing we've had a problem with is Retrospect, an unforeseen consequence that's only come to light since a change in backup policy -- we're returning to our old-style centralised backups for all machines after a flirtation with end-user backups to external HDs.

All of which is moot.

It seems that Retrospect uses different methods for initial "client detection" and subsequent "availability discovery". Clients can be added to the server only if they are on the 45 subnet but, once added, they can be seen/managed/backed up when attached to the 183. I'm three from three (so far) with the following work flow:

  1. Static client machine to a 45 address
  2. Install RS client via subnet broadcast discovery
  3. Register client on server, set volumes, etc
  4. Static client to 183 address
  5. Restart client machine
  6. Backup successfully
  7. Static client to 45 address
  8. Restart
  9. Backup successfully

Even the restarts between subnet changes are unnecessary, at least on Macs -- although you initially get "Multicast port unavailable" in the client it can still be seen by the server, and that message clears after a few seconds anyway as IP bindings are sorted out.

I'm keeping Remote Backups in reserve, running tests just in case, but the above should be good enough for our needs.

Thanks again for all the help,

Nige

Link to comment
Share on other sites

On 10/4/2018 at 10:30 AM, Nigel Smith said:

All,

Trying to get subnet broadcasting working.

We have 2 subnets, both on the same interface of a Fortigate IPS -- for sake of argument, 192.168.45.0/24 and 192.168.183.0/25. Unicast is fine in both directions. Server sits on the 45-subnet and can broadcast-detect all clients on that subnet but no clients on the 183.

....

....

Nige

 

On 10/10/2018 at 8:16 AM, Nigel Smith said:

....

.... So we rarely go above 80% usage our DHCP pool and many devices have the same IP day to day -- but potentially they could be on either subnet when RS comes a-knockin'.

....

....

It seems that Retrospect uses different methods for initial "client detection" and subsequent "availability discovery". Clients can be added to the server only if they are on the 45 subnet but, once added, they can be seen/managed/backed up when attached to the 183. I'm three from three (so far) with the following work flow:

  1. Static client machine to a 45 address
  2. Install RS client via subnet broadcast discovery
  3. Register client on server, set volumes, etc
  4. Static client to 183 address
  5. Restart client machine
  6. Backup successfully
  7. Static client to 45 address
  8. Restart
  9. Backup successfully

Even the restarts between subnet changes are unnecessary, at least on Macs -- although you initially get "Multicast port unavailable" in the client it can still be seen by the server, and that message clears after a few seconds anyway as IP bindings are sorted out.

....

....

Nige

Nigel Smith,

Hold on a friggin' minute, there.:huh:  If your "[backup] server sits on the 45 subnet", how can it setup a  a static client to a 183 address?  And how can it then setup a  a static client for the same machine to a 45 address? is the setting up of static clients done through the Fortigate IPS?

You owe us a decent explanation of what I've quoted from your last post, and IMHO you can provide one without violating the secrets of your installation's security—or expecting us to be experts in the capabilities of networking hardware/software..:angry:

P.S.: Furthermore, does the setting of a client to a static address have to be done each time a client logs on to one subnet or the other, or just once for each client on each subnet?  If it's the former, who does the setting—the Backup Administrator (i.e., you) or someone from IT?  What does "three for three (so far)" mean, individual backups handled or clients permanently set up on both subnets?

Edited by DavidHertzberg
Because Nigel had already read this post, added P.S. and additional clause at end of only sentence of second paragraph
Link to comment
Share on other sites

I obviously didn't explain this as clearly as I hoped. The 9-step list was purely to demonstrate that:

If I set the client machine to be on the same subnet as the server and register it on the default interface via subnet discovery (steps 1, 2 and 3) then it doesn't matter if the client subsequently changes internal subnets (steps 4 and 5, 7 and 8 ) -- the server can still find it using subnet discovery and back it up (steps 6 and 9). But the client must be on the same subnet as the server for that initial discovery to happen.

I.E. there is a subtle difference between the discovery process used to initially register a client and that used to see if a previously registered client is available for backup. I don't know what it is, but it is enough to allow the Fortigate to route the traffic between subnets -- this was a routing-of-broadcast-packets issue, and nothing to do with any security policies.

We only have have to set a static IP on the client machine for initial registration, and then only if the client happened to pull a 183 address from the DHCP server. I can then set the client machine back to using DHCP and there's no more intervention required. A couple of extra steps in our usual setup process, so no biggie compared to wholesale network changes or "might work but not really recommended" routing kluges.

I was at three successes from three attempts at the time of writing that, different machines with different Mac OSs. I've now used the routine successfully on a dozen different machines, though no PCs as yet, so I'm reasonably confident this is a good work-around for our specific problem. And I'm going to test Remote Backups thoroughly, ready for when the work-around stops working...

I don't know why this works, and while my inner nerd would love to delve deeper my outer pragmatist is happy to shrug and move on to other issues.

Hopefully that explains it with a bit more clarity.

Nige

Link to comment
Share on other sites

Nigel Smith,

Thanks for the enhanced explanation. 

What I understand from it is that, to Add the Retrospect Client on a client machine client via subnet broadcast discovery , you must—presumably via Fortigate IPS—set it up with a static address on the 45 subnet.  After you've done the Add, you must also set the client machine up with a static address on the 183 subnet.  Obviously the static address you set up on the 183 subnet is not used when the client machine shows up on the 45 subnet; I guess this is due to the magic of Fortigate IPS.  I'm as surprised as you are to learn that the Retrospect "backup server" recognizes an already-Added client no matter which subnet it is connected to; my undoubtedly-ignorant guess is that the recognition is by Computer Name (System Preferences—>Sharing on Macs).

We'd probably all love to hear an explanation of why your organization won't let the "backup server" directly see the 183 subnet.  Can you give a security-sanitized one?  Does it have to do with different levels of trust?

Edited by DavidHertzberg
Replaced first two sentences in the first paragraph with three sentences, because my understanding has changed; made subject of first sentence of second paragraph "we" instead of "I"
Link to comment
Share on other sites

Almost. Static IP is applied in client's Network pane of System Prefs (or equivalent for Windows) and, after registering, it is reset to "Using DHCP" after which it might appear on either subnet via the magic of DHCP offers and acks. So just a brief, temporary, static allocation while sitting at the client machine and installing the RS client.

Again, this isn't a security issue. Our core switches have aggregated connections to the Fortigate, which is our router and gateway to the outside. This gives us huge bandwidth along with redundancy and automatic fail-over if one of the core switches fails. The "unforeseen consequence" is that, like most routers, the Fortigate will not send a subnet broadcast out of the same interface it arrived in on (broadcast storm prevention) -- and since all our subnets are on that same aggregated interface, a shout from the 45-server can be routed to every interface except the aggregated one containing it and the 183-client.

Direct IP is fine, Bonjour etc works (apparently the "network control" portion of the multicast subnet is treated differently to RS's multicast address, which threw us for a while) -- it's only this one use-case that has caused problems.

There are ways round it, but they create more complication and/or other problems. For example, we could put each of the subnets onto their own VLAN because each of the subnets would then be a virtual interface on the aggregated interface and the RS packets could be routed because the incoming and outgoing virtual interfaces would be different. But that could screw up building-wide printer and share discovery without introducing another layer of fixes, etc, etc.

But understand that I am not a formal network guy ? The above is gleaned from my testing and discussion with the central networking team (which usually includes them saying "Of course, if this was a Cisco...") and a hasty read of the Fortigate manual and Cookbook, so some of my terminology may be off although I hope the principles are understandable. Time for a proper course, I guess.

So the TL;DR for the thread appears to be: "If you are ever in a situation where you have multiple subnets on a network and RS Server isn't seeing new clients outside of its own subnet, try registering the clients while they are on the server's subnet. They may then be available for backing up whichever subnet they subsequently find themselves on -- but monitor things closely!"

Nige

Link to comment
Share on other sites

Nigel Smith,

Your latest post has enabled me to realize that I had forgotten that there's more than one way to set up a static IP address. 

When I switched my apartment LAN from LocalTalk to Ethernet in 1998,  I needed to re-enable my wife's Mac to print on my HP LaserJet 5MP printer—which is in a different room.   That printer is so old (but so sturdy that it still works fine for my limited needs) that I had to buy an HP JetDirect EX Plus to interface between its parallel port and my Ethernet LAN.  When I bought a MacBook Pro in 2015, a poster (who shortly thereafter turned out to be Retrospect-hating, BTW) on the Ars Technica Mac Forums suggested I give the EX Plus a static IP address via the router (as opposed to doing it by Telnetting into the EX Plus, which I had been doing).  Then Andy—the now-departed Tech Support phone-answerer—told me shortly thereafter that I needed to give my client machines static IP addresses so that Retrospect Mac 12 could connect with them,  so I did that via my router also.  Over the intervening years, I had forgotten that  you can also assign a computer itself a static IP address via System Preferences—>Network (or the equivalent on other OSes). 

Because giving computers static IP addresses on a network's router is done by equating an IPV4 address to the computer's MAC address, I couldn't understand how the Fortigate IPS would let you permanently assign two static IP addresses for a client—one on the 45 subnet and one on the 183 subnet.  I now understand that that's not what you needed to do.

Sorry. 

Link to comment
Share on other sites

Nigel Smith,

There may be a faster way of doing what you are slowly accomplishing.  Look at this Tutorial for Retrospect Windows, and also at this Tutorial for Retrospect Mac.  You would probably have to buy an additional network adapter for your "backup server" machine, but I think your installation can handle that from a financial and security point of view.

This approach may be covered already in the User's Guides.  However over the last few years the august Documentation Committee has left it to the head of Retrospect Support to document in Tutorial videos things that they were reluctant :rolleyes: to document in the UGs or even in Knowledge Base articles.  A consequent problem is that the head of Retrospect Tech Support seems compelled to keep his videos under 3 minutes, and preferably not much more than 2 minutes, because he fears losing those viewers with a short attention span.

Link to comment
Share on other sites

19 hours ago, DavidHertzberg said:

Nigel Smith,

There may be a faster way of doing what you are slowly accomplishing.  Look at this Tutorial for Retrospect Windows, and also at this Tutorial for Retrospect Mac.  You would probably have to buy an additional network adapter for your "backup server" machine, but I think your installation can handle that from a financial and security point of view.

No, this is what doesn't work for our situation. I had hopes, a few weeks ago, but it wasn't to be...

RS Server knows which interface a client was added via, and only ever looks for the client on that interface. So a client registered when on the 183 address would only be backed up when it is the 183 subnet, never when on the 45.

Brilliant in many situations, like departmentally-segregated subnets/VLANs where clients don't move around, but no good for us.

Nige

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...