CentOS - Nov 2011 - How to make nodes in my local LAN see each other's names

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 at 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 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 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 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 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 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 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 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 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 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 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_reference_guide/17_NetworkBrowsing_07.html

On Friday, December 02, 2011 12:40:32 PM Les Mikesell
wrote:
> On Fri, Dec 2, 2011 at 11:16 AM, Lamar Owen <lowen at 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 Friday, December 02, 2011 01:17:19 PM m.roth at 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>