this is really off-topic for bacula-users, I think this is purely
general networking.  here's my 2 cent, anyway:

Matthew Ife <Matthew.Ife AT ukfast.co DOT uk> writes:

> Both firewalled and none firewalled customer reside on the same
> layer 3 network but do not reside on the same layer 2 network and
> thus ARPING the backup server doesn’t always work if your client is
> on the wrong broadcast domain (the firewalled vlan). So even backup
> machines connected to the same switch on the same layer 3 network
> was running out of the gateway, through the firewall and back down
> the firewall to the backup server.

don't do that, then.  you could add static entries to the clients' ARP
tables, but *yuck*, how fragile.

> Our general configuration is as follows:
>
> bacula-dir and bacula-sd reside on the same server.
>
> client machines are generally all connected to the same switch.
>
> the backup server is trunked so that we avoid passing bacula traffic
> through the firewall. (well, that’s the intention!)

seriously -- get a firewall which can handle your traffic.  a garden
variety server can easily handle a gigabit of traffic, at least on
layer 3 (I don't have experience with bridge firewalls).

> The authentication error we have experienced - we suspect this is
> something to do with how bacula keeps authentication "tokens" of
> each client. If traffic suddenly comes through the wrong interface
> (i.e the interface it DIDN’T authenticate on) bacula requires
> re-authentication. This can be caused because there are two routing
> rules in the routing table for each vlan but a since both match it
> nearly always chooses the first. Sometimes it seems it chooses the
> second. Can you shed any light on this?

Bacula does not care about network interfaces, only the shared secret.
each new TCP connection goes through the handshake, but these
connections are long-lived and not restarted - if the connection dies,
the backup job fails.

there is one slight twist to how Bacula does things: the director will
generate a shared secret for the SD and the FD, tell the FD the secret
and what IP address it should connect to to reach the SD, and likewise
tell the SD the secret and which IP it should expect a connection
from.  these IP adresses are resolved on the director based on names
in the director's configuration file.  for a multihomed client, this
can cause some problems, see

  ip route get SD-IP-ADDRESS

(or the Windows equivalent -- if there is one) on the client to verify
that the source address matches the IP address returned by

  getent hosts FD-NAME

on the director (assuming bacula-dir.conf says "Address = FD-NAME" in
the relevant Client section).

> Does bacula handle multiple interfaces better where IP addresses are
> on different networks instead of the same?

Bacula is a simple network daemon, it listens to * by default, so
multiple interfaces (even dynamically changing) are not a problem.
this is standard Unix behaviour, no special magic.

-- 
regards,          | Redpill  _
Kjetil T. Homme   | Linpro  (_)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users