Hello Lemonnier,
I investigated something similar to this for our ServiceGuard
implementation of Samba that might shed some light on your
configuration.
But I'm not sure there is really anything you can do to
keep ALL traffic on the hme0 network; samba AND the pc's
depend very heavily on broadcast traffic to get their work
done, and since the broadcast address for both cards is the
same, I don't see any way to isolate it to a single card.
Anyway, here's what was going on in my case:
PROBLEM: When setting up Samba as a package in Service Guard, I have found
that the IP address that it is registering its Netbios Names on is NOT the
RELOCATABLE IP address configured in the package, but instead the LANIC ip
address assigned to the interface card. I can see this by making a
connection from my pc to this netbios name, and then checking the pc netbios
name cache from the pc command prompt using:
nbtstat -c
When I force a package failure, and Samba comes up on the alternate node, I
get the same behavior - ie, now samba is broadcasting it's netbios names on
the LANIC ip address of my alternate node, instead of the RELOCATABLE ip
address that I had in the package.
My configuration:
RELOCATABLE IP = 15.44.48.167/255.255.255.0
LANIC IP(primary node) = 15.44.48.74/255.255.255.0
LANIC IP(secondary node) = 15.44.48.73/255.255.255.0
CAUSE: Samba has code that checks to make sure that it DOESN'T
try to broadcast or claim it's NETBIOS names in the same subnet
with two different IP addresses. This is critical, since a Netbios
name claim will fail if that name has already been claimed on a
different IP address in the same subnet. So in our case, what is
happening is that when Samba builds its list of interfaces, the
LANIC interface with its 15.44.48.74 (or 73, depending on primary or
alternate node) is the first in the list, and the RELOCATABLE IP is the
second in the list. It processes them in order, and discards the second
RELOCATABLE ip address as being a 'duplicate' on that subnet.
Result - Samba broadcasts it's netbios names on the LANIC ip address only,
and when a package failover occurs, the ip address that the netbios names
are associated with CHANGE... This could cause unpredictable behavior with
clients who have cached the ip address in their local netbios name tables.
RESOLUTION: You can use the smb.conf parameters "interfaces=" and
"bind
only interfaces = yes" to force Samba to broadcast on the Relocatable IP
address rather than a LANIC ip address on the same subnet. For instance, in
our case, the smb.conf file would need to have the following lines on the
primary and alternate nodes:
interfaces = 15.44.48.167/255.255.255.0
bind only interfaces = yes
This would ensure that SAMBA registers it's netbios names to the relocatable
ip address 15.44.48.167 on the Primary OR Alternate
ServiceGuard node, and therefore would be consistent in a failover
situation.
NOTE: if you do this, and have OTHER LANIC ip interfaces on DIFFERENT
subnets, this will prevent SAMBA from servicing smb requests on those other
ip addresses. To cure this, make sure you add ALL the interfaces that you
want SAMBA to service requests from in the "interfaces = "
configuration
option. As an example, if our primary and alternate nodes had an ADDITIONAL
lan card on a different subnet:
Primary:
LANIC(1) = 15.44.48.74/255.255.255.0
LANIC(2) = 15.44.10.74/255.255.255.0
RELOCATABLE = 15.44.48.167/255.255.255.0
Alternate:
LANIC(1) = 15.44.48.73/255.255.255.0
LANIC(2) = 15.44.10.73/255.255.255.0
RELOCATABLE = 15.44.48.167/255.255.255.0
Then to ensure that SAMBA services requests from both the '15.44.48' and
the
'15.44.10' subnets on both machines, you would need to have the
following
entries in your smb.conf files on the Primary and Alternate nodes:
Primary:
interfaces = 15.44.48.167/255.255.255.0 15.44.10.74/255.255.255.0
bind only interfaces = yes
Alternate:
interfaces = 15.44.48.167/255.255.255.0 15.44.10.73/255.255.255.0
bind only interfaces = yes
More information about these smb.conf options can be found in the "Using
Samba" book in the section "Networking Options with Samba"
starting on page 101.
-----Original Message-----
From: Lemonnier Philippe [mailto:LEMONNIERP@thmulti.com]
Sent: Thursday, November 16, 2000 1:43 PM
To: 'samba@samba.org'
Subject: Trouble with SAMBA on Multihomed server
Importance: High
Hi all,
I experience some trouble trying to tune the Samba v2.0.7 configuration on a
SUN Enterprise450 server running Solaris 2.6.
This server is somewhat peculiar in that it has multiple network interfaces
on the SAME network:
----------------------------------------------------------------------------
----------------------------
{nestor}~>/sbin/ifconfig -au
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 141.11.171.3 netmask fffff800 broadcast 141.11.175.255
pf0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 141.11.175.238 netmask fffff800 broadcast 141.11.175.255
{nestor}~>netstat -r
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
141.11.168.0 nestor U 3 642678 pf0
141.11.168.0 nestor2 U 2 0 hme0
172.16.8.0 biche UG 0 22159
BASE-ADDRESS.MCAST.NET nestor U 3 0 pf0
default cisco-rennes UG 0 16873
localhost localhost UH 0 629974 lo0
----------------------------------------------------------------------------
-------------------------
The E450 acts mainly as a corporate NFS server to a bunch of workgroup
servers tied with an FDDI infrastructure.
The pf0 interface happens to be the main interface to the FDDI. The FDDI is
also connected to a corporate switch serving a few hundreds of Sun stations
& PCs.
The hme0 (fdx 100BT) is also tied to that switch.
You can notice both interfaces share the same network prefix & netmask
(multihomed server).
Running samba without any precaution works perfectly fine. SMB traffic flows
out from pf0 (primary interface & preferred route) thru FFDI to the switch
down to the PCs : perfect ;-)
However, for traffic handling , it would be far more efficient to force the
SMB traffic to hme0 so that NFS flows through the FDDI only, and SMB through
hme0 only.
Well, I have been playing around for some time with interfaces=hme0, bind
interfaces only=yes, socket address=... and so on, but could not force the
traffic to hme0 in any way.
I suspect interfaces=... and such certainly work perfectly when network
interfaces are on different subnets, but my case is different because these
are just two different paths to the same logical network.
Any guru out there to get me out of this trap ?
regards,
> Philippe Lemonnier -- Interactive Data Networking Lab Manager
> Thomson Broadcast Systems
Rue du Clos Courtel - 35517 Cesson Sevigne - FRANCE
Phone : 33 02 99 27 35 45 Fax : 33 02 99 27 31 06
Email : lemonnierp@thmulti.com