NBNS (Netbios) storm, how to prevent?

Hi,
I am a administrator on a small 650 station server 2003 / Windows XP pro
network. We use active directory, DNS and Wins. Our Music department has a
seperate small 30 station Windows XP pro network hosted by Red Hat Linux. I
am not the admin for the Linux network.

The Linux network is connected to my network to allow music staff to access
the Internet, Intranet and email which are hosted on my servers.

Our network has recently suffered intermittent periods of down time which
has caused our students (for we are a school) significant difficulty in
using our PCs. It has also caused a great deal of frustration.

Anyhow on hearing about Ethereal I installed and started using it. Bingo,
whenever the pings time out on my network I see hundreds of NBNS for the
same name from a single client on the Music network.

When I disconnect the Music network the problem goes away but then they
complain about their loss of email, Intranet and Internet.

I don't know enough about Linux to help the admin of the Linux system but I
do know that I cannot afford to have this occur again.

So I was wondering if I could use an old NT 4 box with two NIC's as a router
or is there a better approach? Would NBNS requests be routed by NT 4 acting
as a router?

Any help appreciated.

Andy.

Make sure the problem client is not configured to use a nonexistent or
erroneous WINS server.

If the query is for a name that exists on the network, create an lmhosts
file on the problem client which maps the correct IP address to the name.
If the name does not exist, map the name to 127.0.0.1.

NBNS queries are directed packets, so they would be forwarded by a
multihomed NT4.0 machine with IP forwarding enabled.

Doug Sherman
MCSE Win2k/NT4.0, MCSA, MCP+I, MVP

<Andy> wrote in message news:up8$(E-Mail Removed)...
> Hi,
> I am a administrator on a small 650 station server 2003 / Windows XP pro
> network. We use active directory, DNS and Wins. Our Music department has a
> seperate small 30 station Windows XP pro network hosted by Red Hat Linux.
I
> am not the admin for the Linux network.
>
> The Linux network is connected to my network to allow music staff to
access
> the Internet, Intranet and email which are hosted on my servers.
>
> Our network has recently suffered intermittent periods of down time which
> has caused our students (for we are a school) significant difficulty in
> using our PCs. It has also caused a great deal of frustration.
>
> Anyhow on hearing about Ethereal I installed and started using it. Bingo,
> whenever the pings time out on my network I see hundreds of NBNS for the
> same name from a single client on the Music network.
>
> When I disconnect the Music network the problem goes away but then they
> complain about their loss of email, Intranet and Internet.
>
> I don't know enough about Linux to help the admin of the Linux system but
I
> do know that I cannot afford to have this occur again.
>
> So I was wondering if I could use an old NT 4 box with two NIC's as a
router
> or is there a better approach? Would NBNS requests be routed by NT 4
acting
> as a router?
>
> Any help appreciated.
>
> Andy.
>
>

"Doug Sherman [MVP]" <(E-Mail Removed)> wrote in message
news:O$(E-Mail Removed)...
> Make sure the problem client is not configured to use a nonexistent or
> erroneous WINS server.
>
> If the query is for a name that exists on the network, create an lmhosts
> file on the problem client which maps the correct IP address to the name.
> If the name does not exist, map the name to 127.0.0.1.
>
> NBNS queries are directed packets, so they would be forwarded by a
> multihomed NT4.0 machine with IP forwarding enabled.
>
> Doug Sherman
> MCSE Win2k/NT4.0, MCSA, MCP+I, MVP
>

Doug,

Thanks for posting. What would you recommend we use to stop such traffic
being broadcast? Our network Switches are all 3Com 4200 series.

We know we can deal with this traffic once it has occured but the situation
is such that it would be better if we could implement a solution
that would isolate the two networks save for Internet access (port 80) and
Email (Outlook 2003). Our switches do have vlan support but we don't have
experience of this and I we don't have the time to spend discovering that
isn't the way forward for us. My thoughts are now leaning towards a
firewall. Any comments.

Thanks,

Andy.

<Andy> wrote in message news:(E-Mail Removed)...
> Thanks for posting. What would you recommend we use to stop such traffic
> being broadcast? Our network Switches are all 3Com 4200 series.

As he said,..they aren't "broadcasted", they are "directed". Switches and
Routers are irrelevant.

> We know we can deal with this traffic once it has occured but the
situation
> is such that it would be better if we could implement a solution
> that would isolate the two networks save for Internet access (port 80) and

No. The solution is to solve the problem,..not block the problem. You need
to check for an invalid network configuration on the Host causing the
problem.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
>
> <Andy> wrote in message news:(E-Mail Removed)...
> > Thanks for posting. What would you recommend we use to stop such traffic
> > being broadcast? Our network Switches are all 3Com 4200 series.
>
> As he said,..they aren't "broadcasted", they are "directed". Switches and
> Routers are irrelevant.
>
> > We know we can deal with this traffic once it has occured but the
> situation
> > is such that it would be better if we could implement a solution
> > that would isolate the two networks save for Internet access (port 80)
and
>
> No. The solution is to solve the problem,..not block the problem. You need
> to check for an invalid network configuration on the Host causing the
> problem.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
Phillip,

Thanks for posting a reply. This is the first time I have come across the
term "directed" in this context. Google returned the following

"A network in which each arc has an associated direction of flow.
Directionof flow can be determined by arc direction (e.g., each arc is
digitized so that it is oriented downstream), a value in an item in the AAT,
or through the use of a selection file."

From this I am unable to work out in what way NBNS are directed.

My problem is that I am not the admin of the network from where this traffic
is originating. I have no control over their configuration and they rely on
my network solely for Internet access, Email and IIS. When problems have
occured they have fixed them only for the problem to re occur some time
later. Meanwhile I am getting some heat from a particular head of department
and looking silly.

Call me paranoid but I would like to have something in place that would
prevent my network being affected even if the same problem re - occurs on
the Music (other) network.

Any recommendations?

Andy.

<Andy> wrote in message news:%(E-Mail Removed)...
> From this I am unable to work out in what way NBNS are directed.

I can make it simpler.

When something is Broadcasted it is sent to the subnet's broadcast address.
If the network was 192.168.1.0/24 then that address would be 192.168.1.255.
All hosts on the subnet respond to it if the "payload" is valid for them.

When something is Directed it is sent specifically to the destination it is
meant for. Only the one host possessing the target address will respond, all
other hosts ignore it.

> Call me paranoid but I would like to have something in place that would
> prevent my network being affected even if the same problem re - occurs on
> the Music (other) network.

If I have not confused my acronyms (which happens sometimes), this is a
NetBios Name Server query packet. In other words a WINS Server query. The
packet,.. because it is directed,.. will always reach the destination
network belonging to that address no matter how many routers and switches
are in the way,..even if the actual target WINS Server doesn't exist.

So the solution is to stop the originating Host (the Linux machine) from
querying the WINS Server in the first place. In Linux, I suspect, this is an
SMB/Samba "thing". That is about all I can tell you about that,..Linux is
not my "area".

You could block this with ACL's on a Router if these are infact on
different subnets with a Router between them,...however doing so can cause
other problems. Blocking it only "hides" the problem,..it doesn't solve it.
Blocking it will also not prevent it from causing problems on the "Music"
subnet and they will still be screaming for you to fix it.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Sorry, Andy: In this context, 'directed' simply means 'addressed.' The
term 'directed' is commonly used to distinguish packets sent to a specific
IP address from 'broadcast' packets which are sort of sent to all addresses.
A router or multihomed computer will not without special configuration
forward any kind of broadcast packets. However, the whole purpose of a
router is to read the destination address of directed packets. Then
depending on the destination address, it forwards them either to its default
gateway, or some network it is connected to, or some network it has a route
to.

NBNS packets are directed to the specific IP of a name server - either for
the purpose of registering the sending machine's name, or as queries for
name resolution. And, they will be cheerfully forwarded by a multihomed
NT4.0 machine configured as a router regardless of whether the destination
IP actually exists. It sounds like one of the music dept. machines is
configured to use a name server IP that is supposed to be on your network.
If the source of these packets is confined to a specific music dept.
machine, the easiest/cheapest thing to do is troubleshoot the offending
machine.

Beyond that, if you want to isolate the entire music dept. except for
Internet access, you could probably do this by installing proxy server
software on your multihomed NT4.0 machine, configure the clients with no
default gateway, and configure music client IE and O/E to use the proxy
server.

Doug Sherman
MCSE Win2k/NT4.0, MCSA, MCP+I, MVP

<Andy> wrote in message news:%(E-Mail Removed)...
>
> "Phillip Windell" <@.> wrote in message
> news:(E-Mail Removed)...
> >
> > <Andy> wrote in message news:(E-Mail Removed)...
> > > Thanks for posting. What would you recommend we use to stop such
traffic
> > > being broadcast? Our network Switches are all 3Com 4200 series.
> >
> > As he said,..they aren't "broadcasted", they are "directed". Switches
and
> > Routers are irrelevant.
> >
> > > We know we can deal with this traffic once it has occured but the
> > situation
> > > is such that it would be better if we could implement a solution
> > > that would isolate the two networks save for Internet access (port 80)
> and
> >
> > No. The solution is to solve the problem,..not block the problem. You
need
> > to check for an invalid network configuration on the Host causing the
> > problem.
> >
> > --
> >
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> >
> Phillip,
>
> Thanks for posting a reply. This is the first time I have come across the
> term "directed" in this context. Google returned the following
>
> "A network in which each arc has an associated direction of flow.
> Directionof flow can be determined by arc direction (e.g., each arc is
> digitized so that it is oriented downstream), a value in an item in the
AAT,
> or through the use of a selection file."
>
> From this I am unable to work out in what way NBNS are directed.
>
> My problem is that I am not the admin of the network from where this
traffic
> is originating. I have no control over their configuration and they rely
on
> my network solely for Internet access, Email and IIS. When problems have
> occured they have fixed them only for the problem to re occur some time
> later. Meanwhile I am getting some heat from a particular head of
department
> and looking silly.
>
> Call me paranoid but I would like to have something in place that would
> prevent my network being affected even if the same problem re - occurs on
> the Music (other) network.
>
> Any recommendations?
>
> Andy.
>
>
>
>

"Doug Sherman [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Sorry, Andy: In this context, 'directed' simply means 'addressed.' The
> term 'directed' is commonly used to distinguish packets sent to a specific
> IP address from 'broadcast' packets which are sort of sent to all
addresses.
> A router or multihomed computer will not without special configuration
> forward any kind of broadcast packets. However, the whole purpose of a
> router is to read the destination address of directed packets. Then
> depending on the destination address, it forwards them either to its
default
> gateway, or some network it is connected to, or some network it has a
route
> to.
>
> NBNS packets are directed to the specific IP of a name server - either for
> the purpose of registering the sending machine's name, or as queries for
> name resolution. And, they will be cheerfully forwarded by a multihomed
> NT4.0 machine configured as a router regardless of whether the destination
> IP actually exists. It sounds like one of the music dept. machines is
> configured to use a name server IP that is supposed to be on your network.
> If the source of these packets is confined to a specific music dept.
> machine, the easiest/cheapest thing to do is troubleshoot the offending
> machine.
>
> Beyond that, if you want to isolate the entire music dept. except for
> Internet access, you could probably do this by installing proxy server
> software on your multihomed NT4.0 machine, configure the clients with no
> default gateway, and configure music client IE and O/E to use the proxy
> server.
>
> Doug Sherman
> MCSE Win2k/NT4.0, MCSA, MCP+I, MVP
>

Doug,

Thank you for clearing up "directed"

I have a basic grasp of protocols and ports but not the detail. We suffered
real problems with our LAN over the few months following terrific growth in
the number of clients utilising it. From about 200 to 600 in 2 months. We
replaced our Allied Teleysn switches with 3com kit, copper links between the
cabs were replaced with fibre and this resolved most issues.

Though we still had problems, someone recommended ethereal and that's how we
spotted the NBNS packets (hundreds of the blighters) which corresponded to
pings timing out and showing silly response times. What I don't understand
is why so many of these packets are transmitted in sucession. I don't see
this behaviour from a windows client.

All of our clients (around 680) are connected together via a switched
network with not a router in sight (save the Internet router) so these
bloody NBNS packets bring our network to it's knees.

I could install ISA 2000 on a old system and use that then.

Thanks for that. Food for thought.

Andy.

"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> <Andy> wrote in message news:%(E-Mail Removed)...
> > From this I am unable to work out in what way NBNS are directed.
>
> I can make it simpler.
>
> When something is Broadcasted it is sent to the subnet's broadcast
address.
> If the network was 192.168.1.0/24 then that address would be
192.168.1.255.
> All hosts on the subnet respond to it if the "payload" is valid for them.
>
> When something is Directed it is sent specifically to the destination it
is
> meant for. Only the one host possessing the target address will respond,
all
> other hosts ignore it.
>
> > Call me paranoid but I would like to have something in place that would
> > prevent my network being affected even if the same problem re - occurs
on
> > the Music (other) network.
>
> If I have not confused my acronyms (which happens sometimes), this is a
> NetBios Name Server query packet. In other words a WINS Server query.
The
> packet,.. because it is directed,.. will always reach the destination
> network belonging to that address no matter how many routers and switches
> are in the way,..even if the actual target WINS Server doesn't exist.
>
> So the solution is to stop the originating Host (the Linux machine) from
> querying the WINS Server in the first place. In Linux, I suspect, this is
an
> SMB/Samba "thing". That is about all I can tell you about that,..Linux is
> not my "area".
>
> You could block this with ACL's on a Router if these are infact on
> different subnets with a Router between them,...however doing so can cause
> other problems. Blocking it only "hides" the problem,..it doesn't solve
it.
> Blocking it will also not prevent it from causing problems on the "Music"
> subnet and they will still be screaming for you to fix it.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>

We are on the same physical subnet but differnet logical subnet.

However the music network can be completley isolated from ours quite easily,
I've done it! so ACLs on a router is another approach. Linux isn't my area
either but I am told that this is a Samba issue and this definitley isn't my
area!

Thanks for the post. Much appreciated.
Will post back what we go for and how well it does or doesn't work!

Andy.

<Andy> wrote in message news:%(E-Mail Removed)...
> All of our clients (around 680) are connected together via a switched
> network with not a router in sight (save the Internet router) so these
> bloody NBNS packets bring our network to it's knees.

You should keep the number of clients below 300 or 250,...perferably below
250.

> I could install ISA 2000 on a old system and use that then.

Then you would turn half your network into an "untrusted network". If you
don't understand the scope of what that means and fully understand the
ramifications of that, then I don't recommend doing it. Proxys are *not*
routers.

Build a simple Router out of an old duel-nic NT4 Workstation box to split
the system into two subnets to "breakup" the number of hosts per segment.

Then,.....fix the real problem,...the Linux box,...fix it. I mean, we're
talking Linux here,...reload it from scratch, ...or throw it out in the
street, ...or pay someone to steel it,...or smash it with a sledge hammer if
you have to,...and replace it. Or find the people responsible to building
it up in the first place and have them fix it or rebuild it.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com