Reduce ARP Traffic

We've migrated to a new version of our mission-critical application that for
us has turned out to be very unstable. In an effort to troubleshoot the
problem, the vendor has been running a protocol analyzer on our network for
a few days. We discovered we had a lot of Spanning Tree Protocol traffic
generated by our relatively new GB switches, but we thought we found where
to turn that off. His latest update confirmed this and had a new
observation:

"There was no sign left of the spanning-tree protocol. However there is a
lot lf ARP request traffic. This may be reduced by updating the DNS tables
and setting up a static host table in all workstations."

Before I mail the guy back with a lot of bonehead questions, I want to check
a few things. First of all, my environment:

- 30 Workstations, 4 Servers, all Windows XP/2003
- I'm using DHCP reservations for my workstations/laptops and of course
static IPs for my servers.
- I'm running two DNS servers (I have two DCs for redundancy)
- I have 3 switches: 2 GB Managed switches & 1 10/100 Unmanaged switch
- We use a single, private /24 subnet

I've found enough thru searches to know I can probably figure out how to
script some static ARP entries for my workstations. What I'm not so clear
about is what entries will be most useful, and where. My workstations
rarely talk to each other; they speak mostly to my servers and to a few
network printers. If I create static ARP entries for my servers and
printers on my workstations, will that significantly reduce ARP traffic? Or
would my servers all need static ARP entries for all the workstations for
this to make any difference?

This leads to my next question, which is: what is he talking about with
updating the DNS tables? I'm not sure how DNS figures into this since ARP
isn't about translating between machine names and IP addresses, but simply
about mapping IP addresses to MAC addresses. Does this have something to do
with Dynamic DNS that I'm not familiar with?

Finally, on a subnet of my size (fewer than 50 nodes), should I even need to
bother trying to reduce ARP traffic? I have a hard time believing it's
sufficient to create any kind of real broadcast storm, unless I'm either
being attacked from within (not likely) or something is failing.

Opinions? Thoughts? Comments?

Thanks in advance!!

BJ

"Bryan L" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> We've migrated to a new version of our mission-critical application that
for
> us has turned out to be very unstable. In an effort to troubleshoot the
> problem, the vendor has been running a protocol analyzer on our network
for
> a few days. We discovered we had a lot of Spanning Tree Protocol traffic
> generated by our relatively new GB switches, but we thought we found where
> to turn that off. His latest update confirmed this and had a new
> observation:
>
> "There was no sign left of the spanning-tree protocol. However there is a
> lot lf ARP request traffic. This may be reduced by updating the DNS
tables
> and setting up a static host table in all workstations."

If he thinks the ARP requests are a problem then it is no wonder to me that
he/they worte an unstabile Application. Ethernet requires ARP,..ARP is
supposed to be there just like you are seeing it. Spanning Tree is supposed
to be there just like is was as well and you shouldn't have messed with it.
Neither of these "mess up" anything. The App they wrote is unstabile
because that is how they wrote the thing resulting from the fact that they
probably know very little about networking and the fact that they have you
chasing STP and ARP packets around with a packet sniffer tends to prove that
to me.

> Finally, on a subnet of my size (fewer than 50 nodes), should I even need
> to bother trying to reduce ARP traffic? I have a hard time believing it's
> sufficient to create any kind of real broadcast storm, unless I'm either
> being attacked from within (not likely) or something is failing.

No, you shouldn't have to worry about any of that and you can run 250-300
hosts before you have to worry about congestion caused by *normal*
IP/Ethernet Broadcasts (APR, STP, DNS, WINS, DHCP, etc). I do not think
there is anything wrong with your LAN,..period. I think they wrote a lousey
Application and are trying to blame everything else because it doesn't work
right. If there was a problem with the design of your LAN you would have a
lot more things not working right than just their Application.

It seems to be typical of some programmers when they aren't quite sure what
they are doing,..to want to change the environment to accomidate their
Application rather than write the Application correctly so it works in a
"normal" existing environment.

....and yes, I "held back" a little bit :-)

I don't have much patients for Vendors and their Applications in these kind
of situations. I've had to fight those battles here as well.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Deployment Guidelines for ISA Server 2004 Enterprise Edition
http://www.microsoft.com/technet/pro...isaserver.mspx
-----------------------------------------------------

Philip,

Thanks for the reply. You've confirmed my hunch that my network was too
small for those things to really have any affect. It's been a while since
had to remember anything about STP; is there any reason to turn it back on?
I'm running on a single subnet so I'm not routing between subnets. As for
ARP, I understood it to be a part and parcel of running an IP-ethernet
network, so I'm not too worried about that either.

The reason we're looking to network issues as possible causes is that we've
ruled out nearly everything else. I've spoken with other businesses similar
to or larger than ours running the same application, and although a few had
some initial issues with stability, they've been resolved and are now pretty
solid. To eliminate variations between my workstations, I initially
deployed them via a carefully configured sysprepped image. To rule out any
possibility that my system image was somehow the cause, I wiped one
workstation and did a clean, manual reinstall of the OS, installing only the
basic apps needed to test my theory. The user on that workstation didn't
see any reduction in errors. I'd consider some wierd issue with hardware,
but I have a few users on different model workstations than the norm, and
they have the same problems. Aside from a core network infrastructure
issue, the only other things I can think of are a weirdly corrupt server
install, incompatible/interfering software on one of my servers, a unique
group policy issue (I make extensive use of GPOs), some hard-to-identify
user behaviour, a malfunctioning node on my network that randomly throws out
nasty, malformed broadcast traffic (?!), solar flares, nearby vampire
activity, or Martha Stewart's stock portfolio.

Once the packet sniffer is removed, they'll spend a week or so crunching the
data collected, then call me with a full report. I really hope they DO find
something wrong with my network (like the horizontal cabling; I've wanted to
rewire the office since I got here almost two years ago), just so we can get
some resolution on this problem. If they come up empty-handed, we only have
a few ideas left to test before we're tapped out.

Thanks again for the reply, I'll keep you posted.

BJ


"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "Bryan L" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> We've migrated to a new version of our mission-critical application that
> for
>> us has turned out to be very unstable. In an effort to troubleshoot the
>> problem, the vendor has been running a protocol analyzer on our network
> for
>> a few days. We discovered we had a lot of Spanning Tree Protocol traffic
>> generated by our relatively new GB switches, but we thought we found
>> where
>> to turn that off. His latest update confirmed this and had a new
>> observation:
>>
>> "There was no sign left of the spanning-tree protocol. However there is
>> a
>> lot lf ARP request traffic. This may be reduced by updating the DNS
> tables
>> and setting up a static host table in all workstations."
>
> If he thinks the ARP requests are a problem then it is no wonder to me
> that
> he/they worte an unstabile Application. Ethernet requires ARP,..ARP is
> supposed to be there just like you are seeing it. Spanning Tree is
> supposed
> to be there just like is was as well and you shouldn't have messed with
> it.
> Neither of these "mess up" anything. The App they wrote is unstabile
> because that is how they wrote the thing resulting from the fact that they
> probably know very little about networking and the fact that they have you
> chasing STP and ARP packets around with a packet sniffer tends to prove
> that
> to me.
>
>> Finally, on a subnet of my size (fewer than 50 nodes), should I even need
>> to bother trying to reduce ARP traffic? I have a hard time believing
>> it's
>> sufficient to create any kind of real broadcast storm, unless I'm either
>> being attacked from within (not likely) or something is failing.
>
> No, you shouldn't have to worry about any of that and you can run 250-300
> hosts before you have to worry about congestion caused by *normal*
> IP/Ethernet Broadcasts (APR, STP, DNS, WINS, DHCP, etc). I do not think
> there is anything wrong with your LAN,..period. I think they wrote a
> lousey
> Application and are trying to blame everything else because it doesn't
> work
> right. If there was a problem with the design of your LAN you would have a
> lot more things not working right than just their Application.
>
> It seems to be typical of some programmers when they aren't quite sure
> what
> they are doing,..to want to change the environment to accomidate their
> Application rather than write the Application correctly so it works in a
> "normal" existing environment.
>
> ...and yes, I "held back" a little bit :-)
>
> I don't have much patients for Vendors and their Applications in these
> kind
> of situations. I've had to fight those battles here as well.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Guidance
> http://www.microsoft.com/isaserver/t...dance/2004.asp
> http://www.microsoft.com/isaserver/t...dance/2000.asp
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
>
> Deployment Guidelines for ISA Server 2004 Enterprise Edition
> http://www.microsoft.com/technet/pro...isaserver.mspx
> -----------------------------------------------------
>
>
>
>
>
>

"Bryan L" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Philip,
>
> Thanks for the reply. You've confirmed my hunch that my network was too
> small for those things to really have any affect. It's been a while since
> had to remember anything about STP; is there any reason to turn it back
on?

It is really only needed if the Switches have redundant Layer2 pathes
(that's Layer2 not 3),...it has nothing to do with subnetting. The Switches
will examine the redunant pathes and keep the faster one while shutting down
the slower one,...the slower one then acts as a fall-back link if the first
one fails.

> Once the packet sniffer is removed, they'll spend a week or so crunching
the
> data collected, then call me with a full report. I really hope they DO
find
> something wrong with my network (like the horizontal cabling; I've wanted
to
> rewire the office since I got here almost two years ago), just so we can
get
> some resolution on this problem. If they come up empty-handed, we only
have
> a few ideas left to test before we're tapped out.

It would help if I knew what "unstabile" meant in the context of this
particular Application and how it is behaving or whatever it is doing wrong.
Also, does the Application use machine names (Netbios Names) when it "does
its thing"?

Extensive use of GPOs is a "red flag" to me,...you can create total nuclear
disaster with GPOs in the blink of an eye if you aren't carefull.

Other than that, I'd have to see what ideas they come up with later.

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

I agree with Phillip. This software vendor is trying to cop out.

I once had to t-shoot a dial in issue with a vendor. They first tried to
claim the possibility of our designated phone line was bad. I called them on
it and said, "Look I called Bell South and had them do a diagnostic on the
line, it is clean." There response was, "Well how do we know their
diagnostic was accurate?", "We know cause they are the freakin' phone
company!", "Well can we put a new cord between the modem and wall jack?", "I
did, brand new.", "Well how do we know it is good?' and on and on.

Back to STP the reason I was posting, Phillip is right, STP is only used if
you have 2 paths from one network devise, i.e. say 2 switches and a dual nic
server that is connected to each for redundancy. In this instance you have
to have STP or else you will have a loop.

Chris

"Bryan L" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Philip,
>
> Thanks for the reply. You've confirmed my hunch that my network was too
> small for those things to really have any affect. It's been a while since
> had to remember anything about STP; is there any reason to turn it back
> on? I'm running on a single subnet so I'm not routing between subnets. As
> for ARP, I understood it to be a part and parcel of running an IP-ethernet
> network, so I'm not too worried about that either.
>
> The reason we're looking to network issues as possible causes is that
> we've ruled out nearly everything else. I've spoken with other businesses
> similar to or larger than ours running the same application, and although
> a few had some initial issues with stability, they've been resolved and
> are now pretty solid. To eliminate variations between my workstations, I
> initially deployed them via a carefully configured sysprepped image. To
> rule out any possibility that my system image was somehow the cause, I
> wiped one workstation and did a clean, manual reinstall of the OS,
> installing only the basic apps needed to test my theory. The user on that
> workstation didn't see any reduction in errors. I'd consider some wierd
> issue with hardware, but I have a few users on different model
> workstations than the norm, and they have the same problems. Aside from a
> core network infrastructure issue, the only other things I can think of
> are a weirdly corrupt server install, incompatible/interfering software on
> one of my servers, a unique group policy issue (I make extensive use of
> GPOs), some hard-to-identify user behaviour, a malfunctioning node on my
> network that randomly throws out nasty, malformed broadcast traffic (?!),
> solar flares, nearby vampire activity, or Martha Stewart's stock
> portfolio.
>
> Once the packet sniffer is removed, they'll spend a week or so crunching
> the data collected, then call me with a full report. I really hope they
> DO find something wrong with my network (like the horizontal cabling; I've
> wanted to rewire the office since I got here almost two years ago), just
> so we can get some resolution on this problem. If they come up
> empty-handed, we only have a few ideas left to test before we're tapped
> out.
>
> Thanks again for the reply, I'll keep you posted.
>
> BJ
>
>
> "Phillip Windell" <@.> wrote in message
> news:(E-Mail Removed)...
>> "Bryan L" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> We've migrated to a new version of our mission-critical application that
>> for
>>> us has turned out to be very unstable. In an effort to troubleshoot the
>>> problem, the vendor has been running a protocol analyzer on our network
>> for
>>> a few days. We discovered we had a lot of Spanning Tree Protocol
>>> traffic
>>> generated by our relatively new GB switches, but we thought we found
>>> where
>>> to turn that off. His latest update confirmed this and had a new
>>> observation:
>>>
>>> "There was no sign left of the spanning-tree protocol. However there is
>>> a
>>> lot lf ARP request traffic. This may be reduced by updating the DNS
>> tables
>>> and setting up a static host table in all workstations."
>>
>> If he thinks the ARP requests are a problem then it is no wonder to me
>> that
>> he/they worte an unstabile Application. Ethernet requires ARP,..ARP is
>> supposed to be there just like you are seeing it. Spanning Tree is
>> supposed
>> to be there just like is was as well and you shouldn't have messed with
>> it.
>> Neither of these "mess up" anything. The App they wrote is unstabile
>> because that is how they wrote the thing resulting from the fact that
>> they
>> probably know very little about networking and the fact that they have
>> you
>> chasing STP and ARP packets around with a packet sniffer tends to prove
>> that
>> to me.
>>
>>> Finally, on a subnet of my size (fewer than 50 nodes), should I even
>>> need
>>> to bother trying to reduce ARP traffic? I have a hard time believing
>>> it's
>>> sufficient to create any kind of real broadcast storm, unless I'm either
>>> being attacked from within (not likely) or something is failing.
>>
>> No, you shouldn't have to worry about any of that and you can run 250-300
>> hosts before you have to worry about congestion caused by *normal*
>> IP/Ethernet Broadcasts (APR, STP, DNS, WINS, DHCP, etc). I do not think
>> there is anything wrong with your LAN,..period. I think they wrote a
>> lousey
>> Application and are trying to blame everything else because it doesn't
>> work
>> right. If there was a problem with the design of your LAN you would have
>> a
>> lot more things not working right than just their Application.
>>
>> It seems to be typical of some programmers when they aren't quite sure
>> what
>> they are doing,..to want to change the environment to accomidate their
>> Application rather than write the Application correctly so it works in a
>> "normal" existing environment.
>>
>> ...and yes, I "held back" a little bit :-)
>>
>> I don't have much patients for Vendors and their Applications in these
>> kind
>> of situations. I've had to fight those battles here as well.
>>
>> --
>> Phillip Windell [MCP, MVP, CCNA]
>> www.wandtv.com
>> -----------------------------------------------------
>> Understanding the ISA 2004 Access Rule Processing
>> http://www.isaserver.org/articles/IS...cessRules.html
>>
>> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
>> http://download.microsoft.com/downlo...7/ts_rules.doc
>>
>> Microsoft Internet Security & Acceleration Server: Guidance
>> http://www.microsoft.com/isaserver/t...dance/2004.asp
>> http://www.microsoft.com/isaserver/t...dance/2000.asp
>>
>> Microsoft Internet Security & Acceleration Server: Partners
>> http://www.microsoft.com/isaserver/partners/default.asp
>>
>> Deployment Guidelines for ISA Server 2004 Enterprise Edition
>> http://www.microsoft.com/technet/pro...isaserver.mspx
>> -----------------------------------------------------
>>
>>
>>
>>
>>
>>
>
>

> It is really only needed if the Switches have redundant Layer2 pathes
> (that's Layer2 not 3),...it has nothing to do with subnetting. The
> Switches
> will examine the redunant pathes and keep the faster one while shutting
> down
> the slower one,...the slower one then acts as a fall-back link if the
> first
> one fails.

Hmmm, it's coming back to me now; it's been a while since I thought much
about certain aspects of networking. Thanks for the reminder. I actually
WILL want STP turned on at some point because if I can get a few extra ports
(I'm nearly maxed out now), I'd like to have an extra link between switches
in case one of those ports goes bad on me, and I'd like to start using the
second NICs

> It would help if I knew what "unstabile" meant in the context of this
> particular Application and how it is behaving or whatever it is doing
> wrong.
> Also, does the Application use machine names (Netbios Names) when it "does
> its thing"?

Unstable means errors generated by the application. These are not native
Windows errors (Illegal Operation, Memory Errors, etc), but errors that
actually log an entry in a custom event log for that application. In most
cases they blow away the window the user was working in, meaning there's
usually some reentry of data neeeded. There are several known causes of
this specific type of error, but we've addressed all those causes and are
still experiencing the errors. The vendor is really scratching their head
on this one. I don't think the application uses Netbios names, since this
vendor is also an ASP that hosts many of its customers via their online
version of the product. They access their data across the internet using
TCP/IP only. It is a .NET application; we made the decision to run the
in-house version rather than the online version, meaning we have a SQL 2000
server and a web server in-house.

> Extensive use of GPOs is a "red flag" to me,...you can create total
> nuclear
> disaster with GPOs in the blink of an eye if you aren't carefull.

I agree. I've been careful with my GPOs; I know they can become
unpredictable if you go in willy-nilly and jack around with them too much.
I think my next step may be to create a test OU that blocks inheritance of
all policies, and selectively apply only the policies needed to provide
basic functionality. Other details, like application deployment,
configuration of IE, Office 2003, Start Menu, Windows Firewall, etc, can be
done manually. If the errors go away for the users tested, I can then start
troubleshooting my GPOs to see which one(s) are to blame. Does that seem
like a sound strategy?

It's hard for me to imagine a setting or even a bug that could cause the
behavior we're having, though. The errors do not occur consistently; there
are days when a user will have a dozen errors before lunch, and other times
when a user may go two or three days without a single issue. The
unpredictability and inconsistency of these errors is one of their most
maddening aspects.

> Other than that, I'd have to see what ideas they come up with later.

Thanks for the reply.

BJ

"Bryan L" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> TCP/IP only. It is a .NET application; we made the decision to run the
> in-house version rather than the online version, meaning we have a SQL
2000
> server and a web server in-house.

Ok.

> done manually. If the errors go away for the users tested, I can then
start
> troubleshooting my GPOs to see which one(s) are to blame. Does that seem
> like a sound strategy?

Sounds good to me.

> It's hard for me to imagine a setting or even a bug that could cause the
> behavior we're having, though. The errors do not occur consistently;
there
> are days when a user will have a dozen errors before lunch, and other
times
> when a user may go two or three days without a single issue. The
> unpredictability and inconsistency of these errors is one of their most
> maddening aspects.

You could test file & registry accesses (and failures) by using FileMon and
RegMon. I think you can get them free from SysInternals
(http://www.sysinternals.com). Play with them for a while, it will be
obvious what you can do with them. Temporarily removing any local copy of
Anti-virus software on the user's machine may be a good trouble-shooting
step too.

Good luck.

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

> You could test file & registry accesses (and failures) by using FileMon
> and
> RegMon. I think you can get them free from SysInternals
> (http://www.sysinternals.com). Play with them for a while, it will be
> obvious what you can do with them.

Thanks for the suggestion; I'll check it out.

> Temporarily removing any local copy of
> Anti-virus software on the user's machine may be a good trouble-shooting
> step too.

Already tried that one. The user who had the clean reinstall of her
workstation was removed from our enterprise antivirus management console, so
no antivirus product or even the agent was deployed to her for several days.
When it became clear it hadn't made a difference I added her back in and she
was deployed our standard antivirus configuration.

Additionally, we ran a SQL trace for a full business day on our DB server,
while at the same time turning on the application's verbose event logging on
selected workstations. I also had each of those users keep a written log of
every error, noting the time and what he/she was doing at the time, to make
it easier to interpret the event log data. They've been chewing on that
data for a week or so now.

I'll post back with the results of your suggestions as well as my GPO
testing.

Bryan

STP is also a must for those of us running education networks where the kids
think it's fun to knock the network down by looping the ethernet. It's
apparently called an aggressive user base :-)

"Chris Patterson" wrote:

> I agree with Phillip. This software vendor is trying to cop out.
>
> I once had to t-shoot a dial in issue with a vendor. They first tried to
> claim the possibility of our designated phone line was bad. I called them on
> it and said, "Look I called Bell South and had them do a diagnostic on the
> line, it is clean." There response was, "Well how do we know their
> diagnostic was accurate?", "We know cause they are the freakin' phone
> company!", "Well can we put a new cord between the modem and wall jack?", "I
> did, brand new.", "Well how do we know it is good?' and on and on.
>
> Back to STP the reason I was posting, Phillip is right, STP is only used if
> you have 2 paths from one network devise, i.e. say 2 switches and a dual nic
> server that is connected to each for redundancy. In this instance you have
> to have STP or else you will have a loop.
>
> Chris
>
> "Bryan L" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Philip,
> >
> > Thanks for the reply. You've confirmed my hunch that my network was too
> > small for those things to really have any affect. It's been a while since
> > had to remember anything about STP; is there any reason to turn it back
> > on? I'm running on a single subnet so I'm not routing between subnets. As
> > for ARP, I understood it to be a part and parcel of running an IP-ethernet
> > network, so I'm not too worried about that either.
> >
> > The reason we're looking to network issues as possible causes is that
> > we've ruled out nearly everything else. I've spoken with other businesses
> > similar to or larger than ours running the same application, and although
> > a few had some initial issues with stability, they've been resolved and
> > are now pretty solid. To eliminate variations between my workstations, I
> > initially deployed them via a carefully configured sysprepped image. To
> > rule out any possibility that my system image was somehow the cause, I
> > wiped one workstation and did a clean, manual reinstall of the OS,
> > installing only the basic apps needed to test my theory. The user on that
> > workstation didn't see any reduction in errors. I'd consider some wierd
> > issue with hardware, but I have a few users on different model
> > workstations than the norm, and they have the same problems. Aside from a
> > core network infrastructure issue, the only other things I can think of
> > are a weirdly corrupt server install, incompatible/interfering software on
> > one of my servers, a unique group policy issue (I make extensive use of
> > GPOs), some hard-to-identify user behaviour, a malfunctioning node on my
> > network that randomly throws out nasty, malformed broadcast traffic (?!),
> > solar flares, nearby vampire activity, or Martha Stewart's stock
> > portfolio.
> >
> > Once the packet sniffer is removed, they'll spend a week or so crunching
> > the data collected, then call me with a full report. I really hope they
> > DO find something wrong with my network (like the horizontal cabling; I've
> > wanted to rewire the office since I got here almost two years ago), just
> > so we can get some resolution on this problem. If they come up
> > empty-handed, we only have a few ideas left to test before we're tapped
> > out.
> >
> > Thanks again for the reply, I'll keep you posted.
> >
> > BJ
> >
> >
> > "Phillip Windell" <@.> wrote in message
> > news:(E-Mail Removed)...
> >> "Bryan L" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed)...
> >>> We've migrated to a new version of our mission-critical application that
> >> for
> >>> us has turned out to be very unstable. In an effort to troubleshoot the
> >>> problem, the vendor has been running a protocol analyzer on our network
> >> for
> >>> a few days. We discovered we had a lot of Spanning Tree Protocol
> >>> traffic
> >>> generated by our relatively new GB switches, but we thought we found
> >>> where
> >>> to turn that off. His latest update confirmed this and had a new
> >>> observation:
> >>>
> >>> "There was no sign left of the spanning-tree protocol. However there is
> >>> a
> >>> lot lf ARP request traffic. This may be reduced by updating the DNS
> >> tables
> >>> and setting up a static host table in all workstations."
> >>
> >> If he thinks the ARP requests are a problem then it is no wonder to me
> >> that
> >> he/they worte an unstabile Application. Ethernet requires ARP,..ARP is
> >> supposed to be there just like you are seeing it. Spanning Tree is
> >> supposed
> >> to be there just like is was as well and you shouldn't have messed with
> >> it.
> >> Neither of these "mess up" anything. The App they wrote is unstabile
> >> because that is how they wrote the thing resulting from the fact that
> >> they
> >> probably know very little about networking and the fact that they have
> >> you
> >> chasing STP and ARP packets around with a packet sniffer tends to prove
> >> that
> >> to me.
> >>
> >>> Finally, on a subnet of my size (fewer than 50 nodes), should I even
> >>> need
> >>> to bother trying to reduce ARP traffic? I have a hard time believing
> >>> it's
> >>> sufficient to create any kind of real broadcast storm, unless I'm either
> >>> being attacked from within (not likely) or something is failing.
> >>
> >> No, you shouldn't have to worry about any of that and you can run 250-300
> >> hosts before you have to worry about congestion caused by *normal*
> >> IP/Ethernet Broadcasts (APR, STP, DNS, WINS, DHCP, etc). I do not think
> >> there is anything wrong with your LAN,..period. I think they wrote a
> >> lousey
> >> Application and are trying to blame everything else because it doesn't
> >> work
> >> right. If there was a problem with the design of your LAN you would have
> >> a
> >> lot more things not working right than just their Application.
> >>
> >> It seems to be typical of some programmers when they aren't quite sure
> >> what
> >> they are doing,..to want to change the environment to accomidate their
> >> Application rather than write the Application correctly so it works in a
> >> "normal" existing environment.
> >>
> >> ...and yes, I "held back" a little bit :-)
> >>
> >> I don't have much patients for Vendors and their Applications in these
> >> kind
> >> of situations. I've had to fight those battles here as well.
> >>
> >> --
> >> Phillip Windell [MCP, MVP, CCNA]
> >> www.wandtv.com
> >> -----------------------------------------------------
> >> Understanding the ISA 2004 Access Rule Processing
> >> http://www.isaserver.org/articles/IS...cessRules.html
> >>
> >> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> >> http://download.microsoft.com/downlo...7/ts_rules.doc
> >>
> >> Microsoft Internet Security & Acceleration Server: Guidance
> >> http://www.microsoft.com/isaserver/t...dance/2004.asp
> >> http://www.microsoft.com/isaserver/t...dance/2000.asp
> >>
> >> Microsoft Internet Security & Acceleration Server: Partners
> >> http://www.microsoft.com/isaserver/partners/default.asp
> >>
> >> Deployment Guidelines for ISA Server 2004 Enterprise Edition
> >> http://www.microsoft.com/technet/pro...isaserver.mspx
> >> -----------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
>

Bryan L wrote:
> We've migrated to a new version of our mission-critical application that for
> us has turned out to be very unstable. In an effort to troubleshoot the
> problem, the vendor has been running a protocol analyzer on our network for
> a few days. We discovered we had a lot of Spanning Tree Protocol traffic
> generated by our relatively new GB switches, but we thought we found where
> to turn that off. His latest update confirmed this and had a new
> observation:
>
> "There was no sign left of the spanning-tree protocol. However there is a
> lot lf ARP request traffic. This may be reduced by updating the DNS tables
> and setting up a static host table in all workstations."
>

Since you not mention how much ARP traffic you have you might have a
look back on it.
The reason is: As soon as a machine has the relation between IP-Nr and
MAC address there should be no need for further arp. So the traffic
should be almost zero.

So something might trashes your arp entries in the swich/client what
might lead to connection losses.

BTW: You have a brigde to another network ?

Anyway: For testing i would do the following:
1) Check why your ARP traffic is high
2)Create a simple static IP network between 1 client and the server -
the best would be to use a dedicated port on the server and isolated
the physical link between the 1 client and the server. This way you you
should be able to see if your network was the problem causing part

2) Check your DHCP Server setup - not that the lease time is to short.

hth
Hajo