servers should talk to each other via the "main" interfaces, hopefully,
if your networks and routing are configured properly.
 
ie, if your STU specifies "backup2" as the media server, then the master
will talk to it via the interface named "media2"
How the master server decides which of its interfaces to talk out of is
more complicated if there are more than one interface on a given subnet,
and they're not trunked....could cause some "unexpected issues".
 
the clients will talk back to whatever interface a connection is
requested from.
 
f'rinstance.....backup1 has 4 interfaces....
 
for example:
 
backup1 (IP1)        -    192.168.1.10/24
backup1-neta (IP2)      192.168.2.10/24
backup1-netb (IP3)       192.168.3.10/24
backup1-netc (IP4)        192.168.4.10/24
 
A backup of a client is attempted, and that client has an IP of
192.168.3.16
 
The media server will select the interface connected to the proper
subnet which is "backup1-netb" and "talk out that interface to the
client.
 
The client will see an incoming connection from 192.168.3.10, perform a
reverse DNS lookup and determine the name to be "backup1-netb". It will
check it's bp.conf file for that name....if it doesn't find it, the job
will fail with a status 59, if it DOES find it, it will start to
transmit backup data back to 192.168.3.10.
 
 
Even if the media server has multiple interfaces on a subnet, it will
pick one to use, and talk to the client via that interface, the client
will still reply back to the interface that queried it.
 
couple questions for you.....what is the purpose of the extra
connections? to have a foot on multiple VLANs to keep backup traffic off
of routers? so each interface is a difference subnet? in which case you
really want to make sure you have routing disabled on the media
servers......or just for more bandwidth on a given subnet? in which case
you should probably be using some sort of trunking/multipathing/teaming,
etc.
 
Paul
 
-- 

        -----Original Message-----
        From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Martin,
Jonathan (Contractor)
        Sent: September 11, 2006 3:43 PM
        To: veritas-bu at mailman.eng.auburn.edu
        Subject: [Veritas-bu] Multiple-Nics
        
        
        Ok... so three new media servers with 4 nics each are headed my
way in the next few weeks.  That's 12 interfaces I've got to worry
about!  According to the NBU Performance Planning & Tuning Guide I
should create DNS entries for each interface, and add all interfaces to
each server's bp.conf (or registry in windows.)  I'm going to get all
these values setup and ready to go before the hardware even arrives.
         
        backup1 (IP1)
        
        backup1-neta (IP2)
        
        backup1-netb (IP3)
        
        backup1-netc (IP4)
        
        
        backup2 (IP1)
        
        backup2-neta (IP2)
        
        backup2-netb (IP3)
        
        backup2-netc (IP4)
        
        
        backup3 (IP1)
        
        backup3-neta (IP2)
        
        backup3-netb (IP3)
        
        backup3-netc (IP4)
         
        So the servers will all talk to each other across the various
nics (by looking up the server name) but how do clients know which IP to
use?  Many of those IPs are going to be on a non-routed "backend"
network, which several clients will not have access to.  How does the
Master / Media server know which nic to use to communicate with the
client?  Further, how do I tell my jobs which IP to use?!  For example,
if I have 6 nics on 3 servers in the "back end" will NBU automatically
local balance between them?  Perhaps I should enable teaming?  Any input
on how this done properly would be appreciated.  Unfortunately the HOSTS
file lookup method we use now is unacceptable (and dumb) so I'll have to
make this work properly.
         
        -Jonathan
        
         

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060911/9e3a987f/attachment.html
-------------- next part --------------
====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any distribution, use, or copying of 
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately 
from
your system and notify the sender promptly by email that you have done so. 

------------------------------------------------------------------------------------

Le pr?sent courriel peut contenir de l'information privil?gi?e ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite Si vous 
recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans 
d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de 
votre
ordinateur toute copie du courriel re?u.