|
New Page 1
Thanks for the offer, Gurvinder, but I don't have
a specific need. I am hoping to trigger a more in depth discussion on this as a
knowledge transfer within this network. Looking at your site, I am sure you have
some opinions worth sharing with everyone.
Identifying the traffic itself is a good first
step. The question is to what detail and where. The WAN ports, since these
typically are connected to leased (recurring cost) services, are an obvious
choice. What I want to know first is who is talking to who, when, volume by
direction, packet sizing, and application. I want to see this over time to trend
usage. I want to be able to summarize the data by percentage of usage and
percentage of available bandwidth by locations, specific devices or users, and
application. Of course, I don't want the capture of this data to become a
performance hog in its own right, so my inclination is an external monitoring
approach. What traffic monitoring do you use, what do you collect, and how do
you use it?
When you say Cisco, I assume you are referencing
the tools that used to be the Optimal Networks suite. Excellent for modeling
changes and validating design expectations, but not particularly robust at
monitoring and data collection. What monitoring approaches are members here
using, and why did you choose it versus alternatives?
What are folks here doing with their providers in
terms of traffic management? If my circuits aren't point to point, my
performance efforts may be compromised once I get past the access loop onto a
"network neutral" common path. Has anyone a successful answer to this condition?
Another question to the members is what is your
traffic mix? What is using your bandwidth?
On the LAN side, my interest is a bit different.
First off, I want to know the "overhead" load of the applications and network
protocols in use. Next, I want to know the flows between segments. Again, I
don't want monitoring to creates its own performance issue.
Segmenting voice from data is interesting. Sort
of defeats the concept of convergence. The avoidance of extra station runs is
nullified, and common use leased circuits as a key benefit to packetized voice
is lost, it seems. Of course, I can see where performance could improve by doing
this.
Squid can be useful for reducing some traffic and
improving perceived performance, although the value will be based on the traffic
patterns of the particular network. I am not sure where caching would be of use
in a chat environment. Perhaps someone can expand on this?
Private Reply to Ken Hilving | 
