Bug 4096 - Removal of secondary ip on the server does not update wins database causes high utilization by nmbd
Summary: Removal of secondary ip on the server does not update wins database causes hi...
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: nmbd (show other bugs)
Version: 3.0.23b
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-12 13:28 UTC by Chait Errande
Modified: 2010-10-10 09:02 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Chait Errande 2006-09-12 13:28:37 UTC 
Our samba server was configured to be the wins server.
This server had 2 ip addresses on the same subnet. When I
removed the secondary ip address.And restarted samba the wins database
did not recognize this update.
# nmblookup -U smbsrvr.xyzllc.com -R 'xyz#1B'
querying xyz on 10.x.x.15
10.x.x.135 xyz<1b>
10.x.x.15 xyz<1b>
In the above case 10.x.x.135 was the secondary ip address
The result was:
1) High utilzation of CPU by nmbd.
2) When I used the IP for another samba server users had browsing problems.

Resolution was I stopped nmbd, deleted the wins.tlb, modified the wins.dat removed all secondary ip addresses for the server and restarted nmbd.
The result was:
1) nmbd high utilization went away.
2) the browsing problems stopped.
# nmblookup -U smbsrvr.xyzllc.com -R 'xyz#1B'
WARNING: The "printer admin" option is deprecated
querying xyz on 10.x.x.15
10.x.x.15 xyz<1b>
Comment 1 Martin von Wittich 2010-10-10 09:02:24 UTC 
This is a rather serious bug that we recently began to encounter on our samba servers too.

We had several servers with multiple virtual interfaces and IPs like 192.168.0.1/24, 192.168.1.1/24, ... and changed those servers to a single IP 192.168.0.1/16. All their respective networks started to have issues like timing out when trying to contact the server via \\servername, because due to the faulty cache they tried to contact the wrong IP.