Hello
Sorry for the (I guess) simple question, but:
I have 7 computers under one 8-port router (D-Link DIR-100, firmware v1.13EU) in my network (actually in a sub-network) and they do not see each other's host names.
The router has the 'DNS relay' option enabled, and all 7 computers use the router as the DNS server, which in turn will forward DNS requests to the ISP DNS server. That way I can understand that simple, plain, default DNS is not enough for my boxes to see each-other's names.
Windows has a nice (or not) way to resolve the problem: CIFS (Samba) server names are automatically included in the name resolving procedure. I know I can do the same with my CentOS boxes if I install samba on each of them and add 'wins' to the 'hosts: ' line in /etc/nsswitch.conf, but somehow I think installing cifs on every node just to get my local machine names to resolve properly to the IP addresses is not the right way to solve my problem ...
What is the way to have all computers in my simple network know each other by name ?
Is it possible to have the name resolving procedure used by the system automatically recognize a new machine added to my network, when I try to access it with right host name, like WINS can ?
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing. Why should the default be set so that I contact the ISP DNS server for each and every web page I hit ?
Is there an easy way to install a caching name server on my each machine, and make sure my system is using /that server/ to resolve names ?
Thank you, Timothy Madden
On Tuesday, November 29, 2011 11:14:16 AM Timothy Madden wrote:
The router has the 'DNS relay' option enabled, and all 7 computers use the router as the DNS server, which in turn will forward DNS requests to the ISP DNS server. That way I can understand that simple, plain, default DNS is not enough for my boxes to see each-other's names.
Can this router have DNS entries added for local hosts? Some SOHO type routers can do this, but I'm not that familiar with your particular router.
somehow I think installing cifs on every node just to get my local machine names to resolve properly to the IP addresses is not the right way to solve my problem ...
Indeed.
What is the way to have all computers in my simple network know each other by name ?
There is no one correct way. But here are a few possibilities for you: 1.) DNS entries in the D-Link router; 2.) static hostnames in /etc/hosts (you'll need to set the router up to always hand out the same IP address for each machine; most SOHO routers can do this, but it may not be obvious how to make it work) 3.) Run a separate DHCP and DNS server on the LAN and not use the router (for a larger installation this would be the preferred way to do things, but for a small number it's not ideal).
Is it possible to have the name resolving procedure used by the system automatically recognize a new machine added to my network, when I try to access it with right host name, like WINS can ?
Dynamic DNS; your router may be able to do this for you.
Is there an easy way to install a caching name server on my each machine, and make sure my system is using /that server/ to resolve names ?
Yes. More than one option exists for this; for CentOS 5 at least you can just 'yum install caching-nameserver' and 'chkconfig named on' (and then 'service named start') and it should come up; I haven't used that setup in some time, though, so not sure how nice that plays with DHCP. There are other options, but that is the main one that is in the CentOS distribution's main repo.
Hope that helps.
From: Timothy Madden terminatorul@gmail.com
The router has the 'DNS relay' option enabled, and all 7 computers use the router as the DNS server, which in turn will forward DNS requests to the ISP DNS server. That way I can understand that simple, plain, default DNS is not enough for my boxes to see each-other's names.
Can't you add local entries to the router...?
What is the way to have all computers in my simple network know each other by name ?
Setup a local DNS (if your router cannot do it). Or simply add them to each /etc/hosts For 7 computers, I would just use /etc/hosts... Unless you plan to rename them every 5 minutes.
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing.
Do not be sad! At least with CentOS 5, you can install the 'caching-nameserver' package.
JD
On Tue, Nov 29, 2011 at 10:58 AM, John Doe jdmls@yahoo.com wrote:
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing.
Do not be sad! At least with CentOS 5, you can install the 'caching-nameserver' package.
Your router is probably giving out its own IP as the nameserver and caching locally anyway.
Vreme: 11/29/2011 05:58 PM, John Doe piše:
From: Timothy Maddenterminatorul@gmail.com
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing.
Do not be sad! At least with CentOS 5, you can install the 'caching-nameserver' package.
What about Avahi (http://en.wikipedia.org/wiki/Avahi_%28software%29)? Doesn't it do that?I thought it does.
On Nov 29, 2011, at 9:14 AM, Timothy Madden wrote:
Hello
Sorry for the (I guess) simple question, but:
I have 7 computers under one 8-port router (D-Link DIR-100, firmware v1.13EU) in my network (actually in a sub-network) and they do not see each other's host names.
The router has the 'DNS relay' option enabled, and all 7 computers use the router as the DNS server, which in turn will forward DNS requests to the ISP DNS server. That way I can understand that simple, plain, default DNS is not enough for my boxes to see each-other's names.
Windows has a nice (or not) way to resolve the problem: CIFS (Samba) server names are automatically included in the name resolving procedure. I know I can do the same with my CentOS boxes if I install samba on each of them and add 'wins' to the 'hosts: ' line in /etc/nsswitch.conf, but somehow I think installing cifs on every node just to get my local machine names to resolve properly to the IP addresses is not the right way to solve my problem ...
What is the way to have all computers in my simple network know each other by name ?
Is it possible to have the name resolving procedure used by the system automatically recognize a new machine added to my network, when I try to access it with right host name, like WINS can ?
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing. Why should the default be set so that I contact the ISP DNS server for each and every web page I hit ?
Is there an easy way to install a caching name server on my each machine, and make sure my system is using /that server/ to resolve names ?
---- just to clarify some things...
NETBIOS is a rather chatty (ie, noisy/traffic generating) for a local subnet. Yes, this can be a convenient way of being able to refer to a computer by its name and the price you pay for that convenience is a fair amount of broadcast traffic by all computers that support this protocol (Windows, Macintosh or Linux using NMBD).
NETBIOS does not in any way provide DNS services. It is relegated to the local subnet only and almost always what is designated as non-routed IP space (10.x.x.x, 172.16.x.x, 192.168.x.x)
UNIX/Linux has a reasonably simple method for maintaining DNS names in /etc/hosts where you can simply set them, ie 192.168.1.1 srv1 srv1.mydomain 192.168.1.2 srv2 srv2.mydomain etc. You can also do this on Windows systems - edit C:\Windows\System32\drivers\etc\hosts
If you want Dynamic DNS on your LAN, you are going to find that the typical home/SOHO routers are insufficient with short lease times, no memory storage for previously registered DHCP addresses and no ability to actually provide real DNS (other than forwarding to some other DNS server) and thus, no DDNS. Thus if you really want to have dynamic DNS on your local LAN, you would want to install bind and dhcp packages and configure them (not the easiest thing to do but not entirely difficult either).
Craig
On 11/29/11 10:00 AM, Craig White wrote:
If you want Dynamic DNS on your LAN, you are going to find that the typical home/SOHO routers are insufficient with short lease times, no memory storage for previously registered DHCP addresses and no ability to actually provide real DNS (other than forwarding to some other DNS server) and thus, no DDNS.
many SOHO firewall/routers incorporate DNSmasq, which is a combination DHCP/DNS service that both acts as a caching forwarder for external lookups, and provides the local clients with DNS names based on their current DHCP registrations. This works quite nicely for the use case of the OP.
On 29.11.2011 20:00, Craig White wrote:
On Nov 29, 2011, at 9:14 AM, Timothy Madden wrote:
Hello
Sorry for the (I guess) simple question, but:
I have 7 computers under one 8-port router (D-Link DIR-100, firmware v1.13EU) in my network (actually in a sub-network) and they do not see each other's host names.
The router has the 'DNS relay' option enabled, and all 7 computers use the router as the DNS server, which in turn will forward DNS requests to the ISP DNS server. That way I can understand that simple, plain, default DNS is not enough for my boxes to see each-other's names.
Windows has a nice (or not) way to resolve the problem: CIFS (Samba) server names are automatically included in the name resolving procedure. I know I can do the same with my CentOS boxes if I install samba on each of them and add 'wins' to the 'hosts: ' line in /etc/nsswitch.conf, but somehow I think installing cifs on every node just to get my local machine names to resolve properly to the IP addresses is not the right way to solve my problem ...
What is the way to have all computers in my simple network know each other by name ?
Is it possible to have the name resolving procedure used by the system automatically recognize a new machine added to my network, when I try to access it with right host name, like WINS can ?
Also, I hear Linux does not have, by default, a cache of resolved names (like Windows does), and I find that to be a sad thing. Why should the default be set so that I contact the ISP DNS server for each and every web page I hit ?
Is there an easy way to install a caching name server on my each machine, and make sure my system is using /that server/ to resolve names ?
just to clarify some things...
NETBIOS is a rather chatty (ie, noisy/traffic generating) for a local subnet. Yes, this can be a convenient way of being able to refer to a computer by its name and the price you pay for that convenience is a fair amount of broadcast traffic by all computers that support this protocol (Windows, Macintosh or Linux using NMBD).
NETBIOS does not in any way provide DNS services. It is relegated to the local subnet only and almost always what is designated as non-routed IP space (10.x.x.x, 172.16.x.x, 192.168.x.x)
UNIX/Linux has a reasonably simple method for maintaining DNS names in /etc/hosts where you can simply set them, ie 192.168.1.1 srv1 srv1.mydomain 192.168.1.2 srv2 srv2.mydomain etc. You can also do this on Windows systems - edit C:\Windows\System32\drivers\etc\hosts
If you want Dynamic DNS on your LAN, you are going to find that the typical home/SOHO routers are insufficient with short lease times, no memory storage for previously registered DHCP addresses and no ability to actually provide real DNS (other than forwarding to some other DNS server) and thus, no DDNS. Thus if you really want to have dynamic DNS on your local LAN, you would want to install bind and dhcp packages and configure them (not the easiest thing to do but not entirely difficult either).
Thank you all for your answers.
Indeed, my router (D-Link DIR-100) only does DNS relay and nothing more.
It looks like I have to stick to CIFS for now. Editing hosts file manually looks too outdated for me, and I have to edit each hosts file on all my computers when a new computer is added (which just happened a few days ago). A dnsmasq server looks like a better way to handle my problem, but it already requires one of the machines to assume a server role: it needs a static IP and can not benefit from (its own) configuration services, and it must be running for all other machines to be running and see each other.
My subnet is Gigabit anyway, so I guess I think I will live with the extra traffic from NetBIOS.
I still have one problem, though: somehow my trick to include 'wins' in the 'hosts: ' line in /etc/nsswitch.conf only works when my box uses a static IP ! :( I guess `dhclient´ updates the DNS server lists and the 'resolver' in a way that interferes with the name service switch mechanism (configured from /etc/nsswitch.conf).
Is there a way to get the name service switch to use wins, while the DNS configuration is handled by DHCP client ?
Thank you, Timothy Madden
On Wednesday, November 30, 2011 08:54:04 AM Timothy Madden wrote:
Is there a way to get the name service switch to use wins, while the DNS configuration is handled by DHCP client ?
Yes, there is (or at least should be). While I know some will object strongly to doing it this way, here's how you might be able to do it:
1.) Follow http://bensbits.com/blog/2006/02/02/wins_name_resolution_for_linux/ 2.) If not using NetworkManager, set PEERDNS=no in the appropriate /etc/sysconfig/network-scripts/ifcfg-ethX file 3.) If using NetworkManager, or using the GUI config tools, make sure the 'Automatically Obtain DNS Information from provider' is *not* checked 4.) Set up /etc/resolv.conf to point DNS to your router (since that will not happen automatically) or set up the DNS servers in the GUI.
Now, I say 'might' simply because I've not personally tried it, since I have a local DNS server set up here and that would not match your particular setup, so even if I got it working you might not, since I do have a DNS server on the LAN.
Since you're using these systems as desktops, and since you didn't specify (at least not in this thread; if you did in another thread I apologize) which CentOS you are using, do note that CentOS 5 and CentOS 6 do things quite a bit differently. So YMMV.
And please let us know how it turns out, especially for the benefit of those who might be searching this thread a year or two from now with your exact question.... the second most annoying thing about typical e-mail list threads is that the OP often doesn't come back with what the solution was.... and to those OP's who do come back with a 'SOLVED' tag in the subject line (or just in the body of the e-mail) and describe what actually fixed their problem, I thank you. (I've already in another thread told my opinion on what the most annoying thing about typical e-mail list threads is, so I'll not repeat that here).
On 30.11.2011 17:00, Lamar Owen wrote:
On Wednesday, November 30, 2011 08:54:04 AM Timothy Madden wrote:
Is there a way to get the name service switch to use wins, while the DNS configuration is handled by DHCP client ?
Yes, there is (or at least should be). While I know some will object strongly to doing it this way, here's how you might be able to do it:
1.) Follow http://bensbits.com/blog/2006/02/02/wins_name_resolution_for_linux/ 2.) If not using NetworkManager, set PEERDNS=no in the appropriate /etc/sysconfig/network-scripts/ifcfg-ethX file 3.) If using NetworkManager, or using the GUI config tools, make sure the 'Automatically Obtain DNS Information from provider' is *not* checked 4.) Set up /etc/resolv.conf to point DNS to your router (since that will not happen automatically) or set up the DNS servers in the GUI.
Now, I say 'might' simply because I've not personally tried it [...]
Since you're using these systems as desktops, and since you didn't specify ([...]) which CentOS you are using [...]
And please let us know how it turns out, [ ... ]
Sorry to say the instructions did not work for me.
I have CentOS release 5.7 (Final), kernel 2.6.18-274.12.1.el5 on x86_64 (yum reports no updates available).
I added 'wins' and 'winbind' to the nsswitch.conf lines indicated in the above link. I tried with or without NetworkManager, I used the GUI to disable 'Obtain DNS information from provider', than I checked the ifcfg-eth0 file for the 'PEERDNS=no' line. I have manually added the DNS servers in my network to /etc/resolv.conf.
Still, no success in ping-ing other (samba) machines in my network. But I could ping the same machines from a Windows workstation...
I the end, I had to revert to static IP instead of DHCP.
Thank you, Timothy Madden
On Friday, December 02, 2011 06:36:25 AM Timothy Madden wrote:
Sorry to say the instructions did not work for me.
...
Still, no success in ping-ing other (samba) machines in my network. But I could ping the same machines from a Windows workstation...
...
I the end, I had to revert to static IP instead of DHCP.
Ok, sorry to hear those possibilities didn't work out for you. There may yet be a way to make it work, but it is definitely a case of swimming upstream against the current to do Linux name resolution with WINS rather than DNS.
If you should find out how to actually make it work, I for one would be interested in seeing it.
In the meantime, statically configured DHCP is a reasonable alternative, and, honestly, I may be going that way here for other security-related things (in terms of being able to better determine which box is flagged as being a participant of a botnet or such since some of my DHCP 'servers' don't keep logs of who got what address (cisco router based DHCP in a few areas), but they can have static configurations. All that is a stopgap until I can get packetfence running properly, but that's involving quite a bit of work to support our switching environment.
On 02.12.2011 17:01, Lamar Owen wrote:
On Friday, December 02, 2011 06:36:25 AM Timothy Madden wrote:
Sorry to say the instructions did not work for me.
...
Still, no success in ping-ing other (samba) machines in my network. But I could ping the same machines from a Windows workstation...
...
I the end, I had to revert to static IP instead of DHCP.
Ok, sorry to hear those possibilities didn't work out for you. [...]
If you should find out how to actually make it work, I for one would be interested in seeing it. [...]
Actually, as I was saying, I have a sub-net of 8 computers and 1 router (and also one switch if you want).
The router is stubborn enough to make sure that no incoming connections or outside traffic get to the sub-net (except on the forwarded ports), even if I would actually like to be able to route traffic from the company LAN (where my work computer resides) to the machines in the sub-net.
In this sub-net I *could* get DHCP for IP allocation and WINS for name resolution work together. There was nothing special to do than: - start smb and winbind (no NetworkManager...) - include 'wins' in the 'hosts: ' line in /etc/nssswitch.conf - maybe add a DHCP_HOSTNAME=`hostname` line to /etc/sysconfig/network-scripts/ifcfg-eth0 script, for my router to see the computer names.
There was no need to prevent DHCP client from retrieving DNS information.
In this way, I need no dedicated machine for DNS, DHCP or WINS, and I can use all 8 machines for testing our product. Our test procedure specifies that the machines involved should be restarted just before tests begin. I believe that would be a problem if want to pick one of them as the DHCP/DNS/WINS server ...
So I want to repeat the procedure for two other machines in the (outside) company LAN, where I had the same name resolving problems in the past, on a different project, and which where still in use. Much to my surprise, the same configuration did not work there, in a larger and different network (the company LAN), with or without the enabling DHCP to also retrieve the DNS information. It is here on these two machines where I reverted to stati IP instead of DHCP.
I do not know any special difference between the two computers (I run yum update on both), or what causes my configuration to work in one network, but not in the other ... Any suggestions are welcome !
Thank you, Timothy Madden
On Fri, Dec 2, 2011 at 12:18 PM, Timothy Madden terminatorul@gmail.com wrote:
Actually, as I was saying, I have a sub-net of 8 computers and 1 router (and also one switch if you want).
The router is stubborn enough to make sure that no incoming connections or outside traffic get to the sub-net (except on the forwarded ports), even if I would actually like to be able to route traffic from the company LAN (where my work computer resides) to the machines in the sub-net.
It is fairly trivial to route among different private LANs with OpenVPN as long as the IP ranges are unique and one of the tunnel endpoints can be reached at a known public address - NAT, port-forwarding, etc., are OK. Of course your company policies may dictate whether that is permitted or not.
My Ubuntu desktop at home seems to show up to windows boxes on the home lan and vice-versa, without me having to do anything to configure it.
Something I've done in the past in small office situations is set up a DNS server that knows the names of all the local machines and then proxies off to a real DNS server for anything else. Works really well actually and does not have to have a "real" domain to manage. YOu just have to make sure all the boxes on the LAN use it as a DNS server.
On Wed, Nov 30, 2011 at 7:54 AM, Timothy Madden terminatorul@gmail.com wrote:
Thank you all for your answers.
Indeed, my router (D-Link DIR-100) only does DNS relay and nothing more.
Errr, unless I'm looking at the wrong online manual, DNS relay does _exactly_ what you want. You just have to give it a local domain name and fill in the dhcp reservation table with the related name/ip/mac sets. The fact that it wants a name in this table should have been a hint.
After you've set that up, test it with 'dig @192.168.0.1 name.localdomain'.
It looks like I have to stick to CIFS for now. Editing hosts file manually looks too outdated for me, and I have to edit each hosts file on all my computers when a new computer is added (which just happened a few days ago). A dnsmasq server looks like a better way to handle my problem, but it already requires one of the machines to assume a server role: it needs a static IP and can not benefit from (its own) configuration services, and it must be running for all other machines to be running and see each other.
The router should do the same thing. Some d-links have bugs, though, so test it and if it doesn't work, check if there is a firmware update for your model.
My subnet is Gigabit anyway, so I guess I think I will live with the extra traffic from NetBIOS.
The DIR-100 isn't gigabit, so the things connected to its ports are going to 100M. But, that's fast enough for a small net anyway.
On Wed, Nov 30, 2011 at 7:54 AM, Timothy Madden terminatorul@gmail.com
Indeed, my router (D-Link DIR-100) only does DNS relay and nothing more.
What about in "Network Setting / DHCP Client list & reservation"? It lists "Host Name" entries... http://www.scribd.com/doc/10073475/DIR100-Manual-En Page 26
JD
On 30.11.2011 17:39, Les Mikesell wrote:
On Wed, Nov 30, 2011 at 7:54 AM, Timothy Maddenterminatorul@gmail.com wrote:
Thank you all for your answers.
Indeed, my router (D-Link DIR-100) only does DNS relay and nothing more.
Errr, unless I'm looking at the wrong online manual, DNS relay does _exactly_ what you want. You just have to give it a local domain name and fill in the dhcp reservation table with the related name/ip/mac sets. The fact that it wants a name in this table should have been a hint.
After you've set that up, test it with 'dig @192.168.0.1 name.localdomain'.
Well ... yes, you are right, the router has that reservation table in its DHCP settings. But if I have to include *all* my machines on the DHCP reservations list, with hostname, IP address and MAC address, than it is not really dynamic configuration, it is all manual and static again.
I still think CIFS is the way to do the job right. With it you just add a new machine into the switch or router, make sure it has CIFS (and has the name service switch configured to use it), and everything works.
Sorry if my opinion looks too ignorant, I do appreciate your answers. Compared to other newsgroups, this list is very helpful (and Gmane rocks!).
Maybe I got used too much to the way this thing "just works" on a Windows network. But I really expected a modern Linux OS to have some better decentralized name resolving support off-the-box for a small, router-based home network. I still think the wins support is there, only it is not started by default and as I can now see, it is also too difficult for me to set up.
DIR-100 is not Gigabit, but 7 of the 8 machines that use it are all connected in a gigabit switch (D-Link DGS-1008D), so (most of) the subnet is internally gigabit. There was no port left in the switch for machine no. 8, so that goes into the DIR-100 directly (as does the switch) and is going to 100M. :)
Thank you, Timothy Madden
On Fri, Dec 2, 2011 at 6:10 AM, Timothy Madden terminatorul@gmail.com wrote:
After you've set that up, test it with 'dig @192.168.0.1 name.localdomain'.
Well ... yes, you are right, the router has that reservation table in its DHCP settings. But if I have to include *all* my machines on the DHCP reservations list, with hostname, IP address and MAC address, than it is not really dynamic configuration, it is all manual and static again.
As it should be. Naming things should be done with a hierarchical delegation, not by chance if you want it to work in a larger context. And naming needs to work world-wide.
I still think CIFS is the way to do the job right. With it you just add a new machine into the switch or router, make sure it has CIFS (and has the name service switch configured to use it), and everything works.
Sorry if my opinion looks too ignorant, I do appreciate your answers.
I think of netbios naming as something that just happens to work sometimes in a tiny context. If that's what you think of as doing the job right, fine. It's like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates. I think your network deserves better.
Maybe I got used too much to the way this thing "just works" on a Windows network.
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
But I really expected a modern Linux OS to have some better decentralized name resolving support off-the-box for a small, router-based home network.
No, it is designed to work in a larger context, and home routers are supposed to provide the support to integrate your network with the world's conventions if you don't want to manage your own server for that. Also, consider how you would handle inbound connections through your router if you ever wanted to do that. If the machines are identified by a local broadcast and have a dynamic private IP, how will you access the correct one?
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
On 12/02/2011 08:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
I agree with Lamar ... I use WINS on a routed VPN network that has a dozen offices that uses Samba on Linux (and OpenLDAP) as the Domain Controller. Samba has an option called:
remote announce http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
and another called:
remote broswer sync http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
These two options keep all my WINS/SMB networks synced all across the US.
On Dec 2, 2011, at 8:15 AM, Johnny Hughes wrote:
On 12/02/2011 08:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
I agree with Lamar ... I use WINS on a routed VPN network that has a dozen offices that uses Samba on Linux (and OpenLDAP) as the Domain Controller. Samba has an option called:
remote announce http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
and another called:
remote broswer sync http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
These two options keep all my WINS/SMB networks synced all across the US.
---- indeed but to continue Les's fairly adept analogy, this is akin to running wires & a PA system to another office so the yelling happens not just in one room but in several rooms.
WINS itself is not routed but a workstation or a server is more than capable of announcing itself or participating in WINS activity on many subnets.
Craig
On Friday, December 02, 2011 10:38:11 AM Craig White wrote:
indeed but to continue Les's fairly adept analogy, this is akin to running wires & a PA system to another office so the yelling happens not just in one room but in several rooms.
Uh, no. With properly configured WINS (both server and on all workstations; for DHCP deployments make sure the DHCP server supports giving out the WINS server address(es)) there is no broadcast name resolution traffic when there is a WINS server and all workstations are configured to use it. It's more akin to replacing a PA system in an office with speakers in the ceiling with a PBX or key system that allows station to station intercom.
The traffic load is very similar to DNS (at least it is here, where I implemented WINS a number of years ago on CentOS 4 to enable routed networking; the broadcast traffic went way down and the network browser (using the CIFS term there) stability went way up).
WINS itself is not routed but a workstation or a server is more than capable of announcing itself or participating in WINS activity on many subnets.
This is quite an interesting statement on a number of levels..... as communication across subnets implies routing is in use.
On Dec 2, 2011, at 8:52 AM, Lamar Owen wrote:
On Friday, December 02, 2011 10:38:11 AM Craig White wrote:
indeed but to continue Les's fairly adept analogy, this is akin to running wires & a PA system to another office so the yelling happens not just in one room but in several rooms.
Uh, no. With properly configured WINS (both server and on all workstations; for DHCP deployments make sure the DHCP server supports giving out the WINS server address(es)) there is no broadcast name resolution traffic when there is a WINS server and all workstations are configured to use it. It's more akin to replacing a PA system in an office with speakers in the ceiling with a PBX or key system that allows station to station intercom.
---- ummm... there are WINS master browser elections on every subnet at least every 15 minutes unless a new computer is introduced or a master browser is unresponsive and thus likely more frequent than that. These elections are by nature done via broadcast. ----
The traffic load is very similar to DNS (at least it is here, where I implemented WINS a number of years ago on CentOS 4 to enable routed networking; the broadcast traffic went way down and the network browser (using the CIFS term there) stability went way up).
WINS itself is not routed but a workstation or a server is more than capable of announcing itself or participating in WINS activity on many subnets.
This is quite an interesting statement on a number of levels..... as communication across subnets implies routing is in use.
---- I am going to assume that you don't configure routers to repeat broadcast traffic from one subnet to another subnet...
Thus the only way you can accomplish cross subnet WINS is via individual servers & workstations specifically configured to participate on the remote subnet individually and for that, yes routing is in use.
Craig
On Friday, December 02, 2011 11:06:51 AM Craig White wrote:
ummm... there are WINS master browser elections on every subnet ...
'Master browser election broadcasts' != 'broadcast-based name resolution.'
I have measured significant broadcast traffic reduction when migrating from non-WINS to WINS SMB/CIFS name resolution.
But this is straying quite far from the OP's question (he doesn't appear to be on a routed network, for one) and from the topic of the list.
On Dec 2, 2011, at 9:17 AM, Lamar Owen wrote:
On Friday, December 02, 2011 11:06:51 AM Craig White wrote:
ummm... there are WINS master browser elections on every subnet ...
'Master browser election broadcasts' != 'broadcast-based name resolution.'
I have measured significant broadcast traffic reduction when migrating from non-WINS to WINS SMB/CIFS name resolution.
But this is straying quite far from the OP's question (he doesn't appear to be on a routed network, for one) and from the topic of the list.
---- Just having 1 Windows system on a network would automatically cause broadcast of it being the master browser (assuming of course, no AD). The election of a 'master browser' does indicate to all others to poll the master browser directly but this is automatic (with or without a WINS server). In general, a subnet doesn't really need a WINS server at all but yes, via some clever DHCP or individual configuration of all the workstations and usage of a designated fixed WINS server can really cut down on broadcast traffic.
While it is true that specifically, this is not CentOS - it is related to the usage of samba on CentOS (and was the OP original query) and is probably a very common topic for CentOS people.
As for how much broadcast occurs... A very detailed page is here...
http://technet.microsoft.com/en-us/library/cc767893.aspx
Craig
On Friday, December 02, 2011 11:40:39 AM Craig White wrote:
On Dec 2, 2011, at 9:17 AM, Lamar Owen wrote:
I have measured significant broadcast traffic reduction when migrating from non-WINS to WINS SMB/CIFS name resolution.
...
As for how much broadcast occurs... A very detailed page is here... http://technet.microsoft.com/en-us/library/cc767893.aspx
For my LAN I measured the traffic before and after using ethereal (as Wireshark was called back then) hooked to a SPAN port on our core switch.
A 'properly configured network with WINS' would mean all nodes on the LAN become, and stay, P-nodes (using Microsoft's terminology). This causes a reduction in broadcast traffic, and helps in circumstances where you really care about broadcast traffic (L2TPv3 tunnels over the WAN to implement VMware vMotion is one case; bridged GRE tunnels are another, and I've run both).
Once we nailed all the non-P-nodes down to being P-nodes, I noted the reduction in broadcast traffic (again, to facilitate efficiency improvement on some layer 2 tunnelling that was necessary at the time, when the tunnels were over the then OC3 WAN link that was a layer-3 routed Packet over SONET link without EoMPLS or similar capabilities).
Since there were remote fileshares on the other end of that OC3, and since even at 150Mb/s payload rates the latency wasn't trivial, keeping broadcasts off of it was important. And since P-nodes use unicast traffic for name resolution, latency wasn't an issue.
And on NBMA networks (I ran an ATM core for a while) broadcast name resolution is a big problem; eliminating traffic on the broadcast and unknown server (BUS) in a LAN emulation (LANE) environment can be a significant improvement, especially with slow BUS implementations.
But an 8 node LAN isn't going to notice the difference, even if all the nodes are H-nodes (the default WINS setup).
The somewhat on-topic question becomes 'how do I control node behavior in Samba on the various CentOS versions?'
That is, how do I configure Samba to be a B, P, M, or H-node (and with WINS you want it to be a P-node if broadcasts are considered harmful)?
Here's one link to a HOWTO that, while a tad old, is still relevant: http://www.linuxtopia.org/online_books/network_administration_guides/samba_r...
On 02.12.2011 18:17, Lamar Owen wrote:
On Friday, December 02, 2011 11:06:51 AM Craig White wrote:
ummm... there are WINS master browser elections on every subnet ...
'Master browser election broadcasts' != 'broadcast-based name resolution.'
I have measured significant broadcast traffic reduction when migrating from non-WINS to WINS SMB/CIFS name resolution.
But this is straying quite far from the OP's question (he doesn't appear to be on a routed network, for one) and from the topic of the list.
To make a long story short, here's what I see by now:
WINS can work in both: - a decentralized, continuous-broadcast mode, that requires no configuration and is the default - a centralized, WINS-server based mode, that can minimize traffic down to the DNS values. This requires WINS/DHCP server configuration and can be used to have WINS work over routed networks, but still does not scale properly if the networks are too large.
DNS can work with: - only centralized, server-based configuration that requires some amount of configuration - no broadcasts or extra traffic whatsoever - can scale with no problem to any networks, routed or not, up to the entire internet.
It seems to me that they even complement each other (on the opposite ends).
It is worth mentioning that Samba also comes with some examples in wich a WINS server can update a DNS server when a new machine registers on un-registers with the server with WINS.
On Fri, Dec 2, 2011 at 9:15 AM, Johnny Hughes johnny@centos.org wrote:
On 12/02/2011 08:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
I agree with Lamar ... I use WINS on a routed VPN network that has a dozen offices that uses Samba on Linux (and OpenLDAP) as the Domain Controller. Samba has an option called:
remote announce http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
and another called:
remote broswer sync http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
These two options keep all my WINS/SMB networks synced all across the US.
Yes, but to make it work, the wins server has to have a static IP, which is what the discussion was about avoiding.... And it still doesn't handle duplicate names or provide a way to delegate naming rights to avoid them. So it can work, but only under some limited circumstances, and only for things using the matching protocols. But, if you have a registered DNS domain or a private one and constrain your lookups to start there, you could use a DNS server that accepts dynamic updates.
On 12/02/2011 09:46 AM, Les Mikesell wrote:
On Fri, Dec 2, 2011 at 9:15 AM, Johnny Hughes johnny@centos.org wrote:
On 12/02/2011 08:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
I agree with Lamar ... I use WINS on a routed VPN network that has a dozen offices that uses Samba on Linux (and OpenLDAP) as the Domain Controller. Samba has an option called:
remote announce http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
and another called:
remote broswer sync http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
These two options keep all my WINS/SMB networks synced all across the US.
Yes, but to make it work, the wins server has to have a static IP, which is what the discussion was about avoiding.... And it still doesn't handle duplicate names or provide a way to delegate naming rights to avoid them. So it can work, but only under some limited circumstances, and only for things using the matching protocols. But, if you have a registered DNS domain or a private one and constrain your lookups to start there, you could use a DNS server that accepts dynamic updates.
There is also certainly nothing wrong with doing dynamic dns if you have a linux box giving out dhcp addresses. You can run ddns and wins on the same box. I have both.
Johnny Hughes wrote: <snip>
There is also certainly nothing wrong with doing dynamic dns if you have a linux box giving out dhcp addresses. You can run ddns and wins on the same box. I have both.
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
mark
On Fri, Dec 2, 2011 at 10:40 AM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools just normally make this difficult. SME server made it handy long ago by combining the user entries into the same screen and building the separate configs under the covers. Maybe there is something even better now.
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 10:40 AM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools just normally make this difficult. SME server made it handy long ago by combining the user entries into the same screen and building the separate configs under the covers. Maybe there is something even better now.
Um, no can do: we don't run the DNS here on campus (a US gov't federal agency), we have blocks of IPs assigned to us. Within our division, we control the horizontal, we control the vertical.... <g>
mark
On Friday, December 02, 2011 01:17:19 PM m.roth@5-cent.us wrote:
Within our division, we control the horizontal, we control the vertical.... <g>
And now we have reached the outer limits of topicality.....
/me <ducks>
On Fri, Dec 2, 2011 at 12:17 PM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools just normally make this difficult. SME server made it handy long ago by combining the user entries into the same screen and building the separate configs under the covers. Maybe there is something even better now.
Um, no can do: we don't run the DNS here on campus (a US gov't federal agency), we have blocks of IPs assigned to us. Within our division, we control the horizontal, we control the vertical.... <g>
If you are giving out DHCP addresses, you are almost certainly giving out DNS server addresses, and you can point that to one or more that you control (probably on the same box(es) as the dhcp service). And that DNS server can answer for your local registered or private domain names as well as the rest of the world. And it will work by actually following network standards instead of relying on ancient proprietary broadcast schemes.
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 12:17 PM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools
<snip>
Um, no can do: we don't run the DNS here on campus (a US gov't federal agency), we have blocks of IPs assigned to us. Within our division, we control the horizontal, we control the vertical.... <g>
If you are giving out DHCP addresses, you are almost certainly giving out DNS server addresses, and you can point that to one or more that you control (probably on the same box(es) as the dhcp service). And
Les, you're missing the point: we are not *supposed* to be running a DNS server. There's another division that does that, the same one that assigns us the blocks of IP addresses. Please don't confuse me with the OP.
mark
On Fri, Dec 2, 2011 at 12:45 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 12:17 PM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools
<snip> >> Um, no can do: we don't run the DNS here on campus (a US gov't federal >> agency), we have blocks of IPs assigned to us. Within our division, we >> control the horizontal, we control the vertical.... <g> > > If you are giving out DHCP addresses, you are almost certainly giving > out DNS server addresses, and you can point that to one or more that > you control (probably on the same box(es) as the dhcp service). And
Les, you're missing the point: we are not *supposed* to be running a DNS server. There's another division that does that, the same one that assigns us the blocks of IP addresses. Please don't confuse me with the OP.
I don't even understand what that means. Is there a mandate to do things wrong? Would someone fire you if you used windows for your DHCP service and it was a version that had AD running as a DNS service too?
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 12:45 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 12:17 PM, m.roth@5-cent.us wrote:
And we have our DHCP give out IP by MAC addresses, so they're effectively static.
If you've done that, you might as well put them in DNS. Linux tools
<snip> >> Um, no can do: we don't run the DNS here on campus (a US gov't federal >> agency), we have blocks of IPs assigned to us. Within our division, we >> control the horizontal, we control the vertical.... <g> > > If you are giving out DHCP addresses, you are almost certainly giving > out DNS server addresses, and you can point that to one or more that > you control (probably on the same box(es) as the dhcp service). And
Les, you're missing the point: we are not *supposed* to be running a DNS server. There's another division that does that, the same one that assigns us the blocks of IP addresses. Please don't confuse me with the OP.
I don't even understand what that means. Is there a mandate to do things wrong? Would someone fire you if you used windows for your DHCP service and it was a version that had AD running as a DNS service too?
Ok, you *have* confused me with the OP. We run almost *no* Windows here, at least on the servers or workstations we support in this division. They do actual science here, and Windows...rotfl! running scientific compute clusters? To do what, figure out the first 100 decimal places of pi in a month?
And running another DHCP server on the network is *not* a Good Thing, and I feel as though we'd get a lot of grief if we did. Rules and regulations, forget "corporate" rules.
mark
On Fri, Dec 2, 2011 at 12:59 PM, m.roth@5-cent.us wrote:
> And we have our DHCP give out IP by MAC addresses, so they're > effectively static.
If you've done that, you might as well put them in DNS. Linux tools
<snip> >> Um, no can do: we don't run the DNS here on campus (a US gov't federal >> agency), we have blocks of IPs assigned to us. Within our division, we >> control the horizontal, we control the vertical.... <g> > > If you are giving out DHCP addresses, you are almost certainly giving > out DNS server addresses, and you can point that to one or more that > you control (probably on the same box(es) as the dhcp service). And
Les, you're missing the point: we are not *supposed* to be running a DNS server. There's another division that does that, the same one that assigns us the blocks of IP addresses. Please don't confuse me with the OP.
I don't even understand what that means. Is there a mandate to do things wrong? Would someone fire you if you used windows for your DHCP service and it was a version that had AD running as a DNS service too?
Ok, you *have* confused me with the OP. We run almost *no* Windows here, at least on the servers or workstations we support in this division. They do actual science here, and Windows...rotfl! running scientific compute clusters? To do what, figure out the first 100 decimal places of pi in a month?
So nobody ever needs a name/ip mapping to the nodes anyway?
And running another DHCP server on the network is *not* a Good Thing, and I feel as though we'd get a lot of grief if we did. Rules and regulations, forget "corporate" rules.
I thought you said you _were_ running a DHCP server. And the part that confuses me is why anyone would split the addressing and naming authority into something that doesn't match the topology. That is, if you are working together with whoever runs the DNS I'd expect the name/IP mapping to be coordinated, probably with a central DHCP as well, or if your network management is delegated to you, then you'd do both independently. But if you are running something unusual that doesn't care about names or DNS then it doesn't matter...
Les Mikesell wrote:
On Fri, Dec 2, 2011 at 12:59 PM, m.roth@5-cent.us wrote:
>> And we have our DHCP give out IP by MAC addresses, so they're >> effectively static. > > If you've done that, you might as well put them in DNS. Linux > tools
<snip> >> Um, no can do: we don't run the DNS here on campus (a US gov't >> federal agency), we have blocks of IPs assigned to us. Within >> our division, we control the horizontal, we control the
vertical.... <g>
If you are giving out DHCP addresses, you are almost certainly giving out DNS server addresses, and you can point that to one or more that you control (probably on the same box(es) as the dhcp service). And
Les, you're missing the point: we are not *supposed* to be running a DNS server. There's another division that does that, the same one that assigns us the blocks of IP addresses. Please don't confuse me with the OP.
I don't even understand what that means. Is there a mandate to do things wrong? Would someone fire you if you used windows for your DHCP service and it was a version that had AD running as a DNS service too?
Ok, you *have* confused me with the OP. We run almost *no* Windows here, at least on the servers or workstations we support in this division. They do actual science here, and Windows...rotfl! running scientific compute clusters? To do what, figure out the first 100 decimal places of pi in a month?
So nobody ever needs a name/ip mapping to the nodes anyway?
We do map. We even have a master hosts file for the division. But DNS is not our purview.
And running another DHCP server on the network is *not* a Good Thing, and I feel as though we'd get a lot of grief if we did. Rules and regulations, forget "corporate" rules.
I thought you said you _were_ running a DHCP server. And the part
We are. In fact, each cluster head also runs a DHCP server, for all their nodes.
that confuses me is why anyone would split the addressing and naming authority into something that doesn't match the topology. That is, if you are working together with whoever runs the DNS I'd expect the name/IP mapping to be coordinated, probably with a central DHCP as well, or if your network management is delegated to you, then you'd do both independently. But if you are running something unusual that doesn't care about names or DNS then it doesn't matter...
We have a subnet that we control. We do the IPs. We give names, then register them with the group that does the whole campus, and they update the DNS.
mark
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Dec 2, 2011, at 9:33 AM, Johnny Hughes wrote:
On 12/02/2011 09:46 AM, Les Mikesell wrote:
On Fri, Dec 2, 2011 at 9:15 AM, Johnny Hughes johnny@centos.org wrote:
On 12/02/2011 08:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
I agree with Lamar ... I use WINS on a routed VPN network that has a dozen offices that uses Samba on Linux (and OpenLDAP) as the Domain Controller. Samba has an option called:
remote announce http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
and another called:
remote broswer sync http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.h...
These two options keep all my WINS/SMB networks synced all across the US.
Yes, but to make it work, the wins server has to have a static IP, which is what the discussion was about avoiding.... And it still doesn't handle duplicate names or provide a way to delegate naming rights to avoid them. So it can work, but only under some limited circumstances, and only for things using the matching protocols. But, if you have a registered DNS domain or a private one and constrain your lookups to start there, you could use a DNS server that accepts dynamic updates.
There is also certainly nothing wrong with doing dynamic dns if you have a linux box giving out dhcp addresses. You can run ddns and wins on the same box. I have both.
---- I routinely do the same ;-)
Craig
On Dec 2, 2011, at 7:54 AM, Lamar Owen wrote:
On Friday, December 02, 2011 08:42:42 AM Les Mikesell wrote:
[netbios naming is] like a roomfull of people yelling out their own name all the time as a means of identification with no way to handle those out of hearing distance or to arbitrate duplicates.
...
But that's a matter of luck, demanding that no one uses duplicates, and that all machines can broadcast to each other (i.e., no routers between them...).
WINS does not work this way. WINS works fine even when nodes are separated by routers and is the recommended way (at least by MS) to do SMB/CIFS name resolution in a routed network.
---- I think 'recommended' is a bit of a stretch - it is a possibility.
AD dispensed with WINS and uses only DNS for host resolution but it exists for non-AD / legacy / home usage.
Craig
On Friday, December 02, 2011 10:47:53 AM Craig White wrote:
I think 'recommended' is a bit of a stretch - it is a possibility.
'Recommended' if you don't want to (or can't) use either old-style NT domains or ActiveDirectory. When you need to support routable SMB/CIFS traffic for WinXP Home, Vista Home Premium, and/or Win7 Home Premium, AD (or a domain) is not an option.
AD dispensed with WINS and uses only DNS for host resolution but it exists for non-AD / legacy / home usage.
Now that SAMBA can do a reasonable AD implementation I'll likely transtition to LDAP/DNS and away from WINS for SMB/CIFS name resolution (once I complete all the other CentOS 4 EoL-forced transitions I have to do, though). LDAP in particular will make a lot of other things easier; but Rome wasn't built in a day, and neither are most networks.
CentOS 6 will eventually replace the C4 machines I still have in place, but I'm looking a several critical system transitions and upgrades to make that happen (I'll spare the details, as they are lengthy, but it involves specific versions of specific programs, one being PostgreSQL and some contributed backend modules for dealing with inversion large objects that aren't available for PostgreSQL past version 7.4). And then I can explore 'better than WINS' options.
I never said WINS was 'better' than DNS; on the contrary, DNS is quite a bit more stable and more robust than WINS in a number of ways (hierarchical namespace is but one example). But, as engineers say, 'the better is the enemy of the good enough' and WINS is 'good enough' for many use cases. In the OP's use case even broadcast-based CIFS name resolution isn't unreasonable, since it is a small network with a single layer-2 broadcast domain anyway. As long as you make an informed decision and understand the limitations, it is not an unreasonable solution.
Further, an AD infrastructure is quite a bit more complex than the OP's scenario would allow, whereas WINS isn't hard to do and in theory non-CIFS name resolution can be done with WINS.
To the best of my knowledge, and I reserve the right to be wrong, WINS does require one machine to have a static address (as would DNS) but all others can have dynamic addresses.
And it plays well in a predominately Windows environment.
YMMV, of course.
On Dec 2, 2011, at 5:10 AM, Timothy Madden wrote:
Maybe I got used too much to the way this thing "just works" on a Windows network. But I really expected a modern Linux OS to have some better decentralized name resolving support off-the-box for a small, router-based home network. I still think the wins support is there, only it is not started by default and as I can now see, it is also too difficult for me to set up.
---- perhaps difficult to set up because Linux systems really need a reasonably complete samba configuration and have nmb daemon running in order to 'speak WINS'. It also helps to ensure that all of the systems (Macintosh, Windows, Linux) are all using the same 'Workgroup' too.
You might want to check /var/cache/samba/wins.tdb (tdbdump /var/cache/samba/wins.tdb) or /var/cache/samba/wins.dat and also various incarnations of nmblookup such as nmblookup -d 2 '*' to directly check the subnet
I'm sort of surprised no one pointed out that mDNS/avahi type of name resolution was probably the way to go for a heterogenous network but yes, it too is not generally installed/configured on a normal Linux install.
http://en.wikipedia.org/wiki/Zero_configuration_networking
One must always keep in mind that a 'default' installation of a traffic inducing protocol such as any name based resolution system that relies upon broadcast will slow your network down. Just because Microsoft does it (WINS) and Apple does it (Bonjour) doesn't mean that it is the right thing to do.
Craig
On Friday, December 02, 2011 11:02:18 AM Craig White wrote:
I'm sort of surprised no one pointed out that mDNS/avahi type of name resolution was probably the way to go for a heterogenous network but yes, it too is not generally installed/configured on a normal Linux install.
While there is some distinct merit to a zeroconf setup (especially if you have Mac users), in a network of the OP's size multicast DNS could possibly end up being effectively using broadcasting, too, and thus not help in terms of network efficiency. But I don't think efficiency is a major concern with 8 workstations.
Having said that, I don't have any metrics since I've not personally tried it to see.
But it's a thought.
On Fri, Dec 2, 2011 at 10:29 AM, Lamar Owen lowen@pari.edu wrote:
I'm sort of surprised no one pointed out that mDNS/avahi type of name resolution was probably the way to go for a heterogenous network but yes, it too is not generally installed/configured on a normal Linux install.
While there is some distinct merit to a zeroconf setup (especially if you have Mac users), in a network of the OP's size multicast DNS could possibly end up being effectively using broadcasting, too, and thus not help in terms of network efficiency. But I don't think efficiency is a major concern with 8 workstations.
Having said that, I don't have any metrics since I've not personally tried it to see.
Nobody cares much about hardware/network efficiency these days since you are likely to have plenty except in those marginal wifi areas, but broadcasts get accepted by every NIC on the network and pushed up the network stacks until something drops them, where multicasts are only accepted by things that are configured to want them.
On Friday, December 02, 2011 11:43:48 AM Les Mikesell wrote:
Nobody cares much about hardware/network efficiency these days since you are likely to have plenty except in those marginal wifi areas, but broadcasts get accepted by every NIC on the network and pushed up the network stacks until something drops them, where multicasts are only accepted by things that are configured to want them.
Assuming multicast is more efficient than broadcast in a small environment, who cares whether it gets pushed up the stack, there's plenty of CPU to deal with it, right? Who needs efficiency in the network stack with plenty of CPU, no?
Sorry, couldn't resist; if you're going to care about efficiency on the network stack you shouldn't ignore efficiency on the wire. I'd hazard to say that you have more overcapacity of CPU to deal with the network stack than you have overcapacity on the physical network, at 1Gb/s, not to mention 100Mb/s. At 10Gb/s maybe not.
But, lacking metrics, it's somewhat of a moot point.
On Fri, Dec 2, 2011 at 11:16 AM, Lamar Owen lowen@pari.edu wrote:
On Friday, December 02, 2011 11:43:48 AM Les Mikesell wrote:
Nobody cares much about hardware/network efficiency these days since you are likely to have plenty except in those marginal wifi areas, but broadcasts get accepted by every NIC on the network and pushed up the network stacks until something drops them, where multicasts are only accepted by things that are configured to want them.
Assuming multicast is more efficient than broadcast in a small environment, who cares whether it gets pushed up the stack, there's plenty of CPU to deal with it, right? Who needs efficiency in the network stack with plenty of CPU, no?
Sorry, couldn't resist; if you're going to care about efficiency on the network stack you shouldn't ignore efficiency on the wire. I'd hazard to say that you have more overcapacity of CPU to deal with the network stack than you have overcapacity on the physical network, at 1Gb/s, not to mention 100Mb/s. At 10Gb/s maybe not.
But, lacking metrics, it's somewhat of a moot point.
My point is that every device on your network has to process every broadcast packet. Maybe you have CPU overkill on all your computers, but you might also have some dumb controllers too. And they have to go out the wifi too.
On Friday, December 02, 2011 12:40:32 PM Les Mikesell wrote:
On Fri, Dec 2, 2011 at 11:16 AM, Lamar Owen lowen@pari.edu wrote:
But, lacking metrics, it's somewhat of a moot point.
My point is that every device on your network has to process every broadcast packet. Maybe you have CPU overkill on all your computers, but you might also have some dumb controllers too. And they have to go out the wifi too.
Ethernet multicast frames, depending on switch implementation, may go to every device as well. How the NIC responds to multicast ethernet frames is likely implementation-dependent, but, again, I don't have metrics on that, except for a failure mode on a couple of controller-type devices we experienced once.
This failure appeared, on first blush, to be a broadcast storm, but ended up being a misconfigured IP webcam which was configured to send its mpeg4 stream via multicast as well; it loaded every port on every switch on one subnet's VLAN; our LAN is using a mix of cisco catalyst 6500, 5500, and 2900XL switches; some 3Com superstack II switches, and a handful of Extreme Networks Summit 1i switches; not low-end unmanaged stuff. This stream was ~5Mb/s (it is a relatively high-resolution color IP camera).
Now, we have a number of SitePlayer Telnet devices (really nice and inexpensive ethernet-to-serial boxes that have great use in remote serial consoles). These SitePlayer Telnet boxes have 10Base-T ports; the 5Mb/s mpeg4 stream overwhelmed them and dropped them off the LAN completely. Several of them hard-crashed and went completely offline, requiring a power cycle to get back to operation.
This was not broadcast traffic; it was multicast traffic, but the switches flooded those frames to every port in that VLAN anyway, and a controller that was not a member of that multicast group got flooded. Now, to be fair, the SitePlayer Telnet does Bonjour, and thus does respond to mDNS, but that is supposed to be on a different multicast group. Whether that was a factor or not I don't know; but I do know that the Davis Instruments ethernet devices we have, and that don't do mDNS, also went offline during the multicast event.
So, no numerical metrics, but anecdotal evidence that multicast can be just as bad as broadcast to controllers with insufficient bandwidth or CPU power.
(And it pointed to the fact that those SitePlayer Telnet boxes really should have been on a different VLAN and thus in a different broadcast domain.......)
On Fri, Dec 2, 2011 at 12:14 PM, Lamar Owen lowen@pari.edu wrote:
My point is that every device on your network has to process every broadcast packet. Maybe you have CPU overkill on all your computers, but you might also have some dumb controllers too. And they have to go out the wifi too.
Ethernet multicast frames, depending on switch implementation, may go to every device as well. How the NIC responds to multicast ethernet frames is likely implementation-dependent, but, again, I don't have metrics on that, except for a failure mode on a couple of controller-type devices we experienced once.
NICs have to accept broadcasts and pass them up to CPU-type processes. They may have efficient mechanisms to ignore multicasts they aren't interested in (but yes, it is implementation - dependent).
This was not broadcast traffic; it was multicast traffic, but the switches flooded those frames to every port in that VLAN anyway, and a controller that was not a member of that multicast group got flooded. Now, to be fair, the SitePlayer Telnet does Bonjour, and thus does respond to mDNS, but that is supposed to be on a different multicast group. Whether that was a factor or not I don't know; but I do know that the Davis Instruments ethernet devices we have, and that don't do mDNS, also went offline during the multicast event.
So, no numerical metrics, but anecdotal evidence that multicast can be just as bad as broadcast to controllers with insufficient bandwidth or CPU power.
Yes, if you fill the media capacity, things start to break, and on a point-to-point connection like 10BT there's not much difference between the media and the endpoints.
(And it pointed to the fact that those SitePlayer Telnet boxes really should have been on a different VLAN and thus in a different broadcast domain.......)
You might still flood the VLAN trunked connections between switches where the media is shared - but in practice that would probably be a higher capacity.
-
Alan McKay -
Craig White -
John Doe -
John R Pierce -
Johnny Hughes -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Timothy Madden