Lustre discuss - Apr 2007 - Question regarding multi-homed clients

Hi all,

We''re running a few clients who have multiple IPs assigned to them
which are
not broadcast. These however are picked up by the Lustre client and the MDS
evicts the client in question after bringing it up.

A way around this is to ensure that only the primary interface is up when
Lustre is bought up on the client. Is there however any way to restrict the
client to only communicate via, say eth0?

Thanks,
-- 
Mustafa A. Hashmi
mahashmi@gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20070430/ac84f25e/attachment.html

options lnet networks="tcp0(eth0)"
 
...will make LNET always uses interface eth0 to construct a NID (i.e. <ip
address of eth0>@tcp0).
 
    Cheers, 
                   Eric 

________________________________

	From: lustre-discuss-bounces@clusterfs.com
[mailto:lustre-discuss-bounces@clusterfs.com] On Behalf Of Mustafa A. Hashmi
	Sent: 30 April 2007 10:48 AM
	To: lustre-discuss@clusterfs.com
	Subject: [Lustre-discuss] Question regarding multi-homed clients
	
	
	Hi all,
	
	We''re running a few clients who have multiple IPs assigned to them
which are not broadcast. These however are picked up by
the Lustre client and the MDS evicts the client in question after bringing it
up.
	
	A way around this is to ensure that only the primary interface is up when
Lustre is bought up on the client. Is there
however any way to restrict the client to only communicate via, say eth0?
	
	Thanks, 
	-- 
	Mustafa A. Hashmi
	mahashmi@gmail.com

add
options lnet networks="tcp0(<interface name e.g. eth0 eth1>)"
to your etc/modprobe.conf on client

On 4/30/07, Mustafa A. Hashmi <mahashmi@gmail.com>
wrote:
>
> Hi all,
>
> We''re running a few clients who have multiple IPs assigned to them
which
> are not broadcast. These however are picked up by the Lustre client and the
> MDS evicts the client in question after bringing it up.
>
> A way around this is to ensure that only the primary interface is up when
> Lustre is bought up on the client. Is there however any way to restrict the
> client to only communicate via, say eth0?
>
> Thanks,
> --
> Mustafa A. Hashmi
> mahashmi@gmail.com
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss@clusterfs.com
> https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
>
>

-- 
Regards--
Rishi Pathak
National PARAM Supercomputing Facility
Center for Development of Advanced Computing(C-DAC)
Pune University Campus,Ganesh Khind Road
Pune-Maharastra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20070430/2bfa73ef/attachment.html

Thanks very much Eric & Rishi.

On 4/30/07, rishi pathak <mailmaverick666@gmail.com>
wrote:
>
> add
> options lnet networks="tcp0(<interface name e.g. eth0
eth1>)"
> to your etc/modprobe.conf on client
>
> On 4/30/07, Mustafa A. Hashmi <mahashmi@gmail.com> wrote:
>
> > Hi all,
> >
> > We''re running a few clients who have multiple IPs assigned to
them which
> > are not broadcast. These however are picked up by the Lustre client
and the
> > MDS evicts the client in question after bringing it up.
> >
> > A way around this is to ensure that only the primary interface is up
> > when Lustre is bought up on the client. Is there however any way to
restrict
> > the client to only communicate via, say eth0?
> >
> > Thanks,
> > --
> > Mustafa A. Hashmi
> > mahashmi@gmail.com
> > _______________________________________________
> > Lustre-discuss mailing list
> > Lustre-discuss@clusterfs.com
> > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
> >
> >
>
>
> --
> Regards--
> Rishi Pathak
> National PARAM Supercomputing Facility
> Center for Development of Advanced Computing(C-DAC)
> Pune University Campus,Ganesh Khind Road
> Pune-Maharastra



-- 
Mustafa A. Hashmi
mahashmi@gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20070430/6cb1ef31/attachment.html