This just got more difficult.  We have two media servers that data backups
up to.  They are E6500 will 4 gigabit cards in each.  We use Sun trunking to
effectively create two pipes for backups.  Our network group has set up two
backup vlans for the traffic and the majority of our servers are directly
connected to the backup vlans and have no problems.  Unfortunately, we have
a few satelite areas on campus that don't have a direct connection to the
backup vlans.  These are the boxes we are having problems with.  They route
through the production network and backup by the first interface to
respond.  I would simply get rid of this new interface, but HP Openview has
been throwing fits having to monitor on the backup vlans, so this was to fix
that problem.

<15 minutes later>

***** I think it will still work *****
Correct me if I am wrong, but the server will send a connection request
through the host interface specified in the file.  However, once the
connection request has been send it turns it back over to the OS to
determine the fastest route.  I just tested it and for the clients that
don't have a connect to the same subnet as the media servers is works just
like in the book...to them it is the fastest route since they don't know any
other.  They connect and send their traffic through that interface.  For the
clients that have a direct connect to the backup subnet, they will get the
initial connect request through the REQUIRED_INTERFACE  host and then switch
to the subnet with the direct connection since it is faster.  Does anyone
see gotcha's with this?

Larry, unfortunately fixing the routing issue would involve my network group
and they don't view it as a high enough priority to fix.  Unfortunately,
with all they are working right now I  would have to agree with them.  Does
my logic above make sense or am I completely messed up?

Thanks everyone so far for the input, it helps alot!
Chris



Larry Kingery wrote:

> When the REQUIRED_INTERFACE parameter is not used, NBU doesn't do
> routing at all, it just sends the data and leaves it up to the
> operating system.
>
> It sounds like for whatever reason the path chosen by the OS wants to
> route packets via the new hme.  You could use REQUIRED_INTERFACE if
> you have only one NIC that you'll ever want to use in the backup
> servers.
>
> I would suggest, though, that you fix the routing issue:
>
> 1) REQUIRED_INTERFACE only works when you only want to use ONE
>    interface.  Will this ALWAYS be the case?
>
> 2) Someday in the future, will the admin know why it was set up this
>    way?  Now's the time to fix the real problem, when you know exactly
>    what happened and why.
>
> 3) REQUIRED_INTERFACE only works for NetBackup.  See #2 for argument
>    why to fix the problem now, not later when you find out some other
>    application is broken by this also.
>
> HTH,
> L
>
> Chris Adolf writes:
> > Goodmorning,
> >     This weekend we added an additional NIC to our backup servers for
> > monitoring through HP Openview.  It is only an hme card and the other
> > interfaces intended for the backups are ge cards.  Over the weekend
> > several of our backups failed with an error of 56 because they were
> > trying to backup through the hme card  and that hostname is not in the
> >
> > bp.conf.  Is there a way to tell Netbackup to ignore a specific
> > interface, or can someone explain to me how it selects the interface
> > when backing up.  The majority of our clients have an interface on the
> >
> > same subnet as the backup servers and don't have a problem, the ones
> > that don't have a direct connect to the same subnet are the problem
> > children.
> >
> > Server info:
> >     Solaris 2.6
> >     NBU 3.4
> >
> > Any help would be appreciated, unfortunately, static routes are not an
> >
> > option.
> > Thanks,
> > Chris
> >
> > _______________________________________________
> > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> --
> Larry Kingery
>            Linux: Because rebooting is for adding hardware