Thanks to everyone who shared thoughts, ideas and experience regarding monitoring bandwidth usage on Ethernet switch ports without including broadcast traffic. EVERYONE tends to agree that a separate VLAN for each co-located customer is the only professional way to do things "right". I agree, and plan to move in that direction, fast. Then I won't have to worry about broadcast traffic, either! Other recommended solutions included: - MRTG This is great (I use it elsewhere) but it doesn't directly address the issue I have of *not* including broadcast traffic - Cisco 6500 switches apparently support "Private VLANS", which don't burn up IP addresses. Sounds cool, wish I had a 6500 ;-) - AUI port -- several people pointed out that an unused AUI port on a switch will log broadcast traffic and no other; I can subtract that from traffic monitored on all other ports. Some people said that an unused VLAN1 has same behavior. - dumb hub -- by plugging in a dumb, passive Ethernet hub with nothing connected, it will receive broadcast traffic. I can then subtract that ports byte counters from others. - Cisco NetFlow / cflowd ( http://www.caida.org/tools/measurement/cflowd/ ) Seems very thorough, overkill for me right now. - RMON counting of unicast-Octets only - Extracting SNMP # multicast/broadcast packets, using average packet size and subtracting product from total byte count - HPOV + SNMPv2 Regards to all, --dmr David Ramsey Charlotte, NC
Thanks to everyone who shared thoughts, ideas and experience regarding monitoring bandwidth usage on Ethernet switch ports without including broadcast traffic.
EVERYONE tends to agree that a separate VLAN for each co-located customer is the only professional way to do things "right".
I agree, and plan to move in that direction, fast. Then I won't have to worry about broadcast traffic, either!
Other recommended solutions included:
- MRTG This is great (I use it elsewhere) but it doesn't directly address the issue I have of *not* including broadcast traffic
You might want to look at cricket and RRDTool for a much more scalable solution. [http://cricket.soundforge.net/].
- Cisco 6500 switches apparently support "Private VLANS", which don't burn up IP addresses. Sounds cool, wish I had a 6500 ;-)
I'd be interested in finding out more about this as we are currently using CAT 6500 switches and burning up IP addresses can you tell me more about this? Regards, Neil.
You might want to look at cricket and RRDTool for a much more scalable solution. [http://cricket.soundforge.net/].
- Cisco 6500 switches apparently support "Private VLANS", which don't burn up IP addresses. Sounds cool, wish I had a 6500 ;-)
I'd be interested in finding out more about this as we are currently using CAT 6500 switches and burning up IP addresses can you tell me more about this?
If I'm not mistaken, Private VLANs causes a big time split-horizon issue..
split-horizon states that you never should send information about a route back in the direction from which it came. Typically, this is only applicable to DV protocols and the like, but has meaning elsewhere. People have long ignored the rules of split horizon for routing, ie. Frame Relay networks. With the right configuration it really isnt an issue. But now for the hosting environment its even less meaningfull. In the private VLAN concept, communites of interest (for lack of a better term) are manually created, that allow a given port to only speak (L2) with the router port, and any other ports in its community. For the simple hosting environment its perfect. Everyone is assigned out of the same addressing block, regardless of the order in which the cages/servers were turned up. This is probably not the greatest solution for colo providers hosting cages and interconnects. But for a simple webfarm and hosting operations its very workable. My $0.02. From someone who as implemented them, and likes them very much. .chance -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alex Rubenstein Sent: Friday, July 28, 2000 11:22 AM To: Neil J. McRae Cc: (David M. Ramsey); nanog@merit.edu Subject: Re: SUMMARY: bw usage?
You might want to look at cricket and RRDTool for a much more scalable solution. [http://cricket.soundforge.net/].
- Cisco 6500 switches apparently support "Private VLANS", which don't burn up IP addresses. Sounds cool, wish I had a 6500 ;-)
I'd be interested in finding out more about this as we are currently using CAT 6500 switches and burning up IP addresses can you tell me more about this?
If I'm not mistaken, Private VLANs causes a big time split-horizon issue..
Chance Whaley wrote:
split-horizon states that you never should send information about a route back in the direction from which it came. Typically, this is only applicable to DV protocols and the like, but has meaning elsewhere. People have long ignored the rules of split horizon for routing, ie. Frame Relay networks. With the right configuration it really isnt an issue.
But now for the hosting environment its even less meaningfull. In the private VLAN concept, communites of interest (for lack of a better term) are manually created, that allow a given port to only speak (L2) with the router port, and any other ports in its community. For the simple hosting environment its perfect. Everyone is assigned out of the same addressing block, regardless of the order in which the cages/servers were turned up.
A caveat: Be very, very sure that you know what 'simple' means.
This is probably not the greatest solution for colo providers hosting cages and interconnects. But for a simple webfarm and hosting operations its very workable.
My $0.02. From someone who as implemented them, and likes them very much.
I like them (well, Extreme Networks' take on it at least) very much in theory, but am much less pleased with them in practice. If you're considering utilizing private VLANs, I would strongly suggest that you are completely familiar with all the special setups your customers will want in the future, you make it very clear that adding additional servers may force them to renumber. (This is especially important when a formerly simple hosting customer decides to implement load-balancing/firewall/other.) If you are only doing low end web-hosting or single-server colocation, this should work very well. If you're doing network hosting or anything at all complex, consider sticking with standard VLANs. If I were to build a large hosting facility, I would have a low end room with private VLANs for hosting at a discount, and everything else using standard VLANs. My $0.02. From someone who has been through this and now gets to suffer as a customer rather than a provider. Jeremiah
[ On Friday, July 28, 2000 at 09:47:28 (-0400), David M. Ramsey wrote: ]
Subject: SUMMARY: bw usage?
Other recommended solutions included:
- MRTG This is great (I use it elsewhere) but it doesn't directly address the issue I have of *not* including broadcast traffic
although MRTG is a good, working, solution for collecting and "visualising" SNMP data, it has a limited future and may not be usable/managable in large installation. Of the available replacements (at least of those based on RRDtool, the premier time-series database and graphing tool by the author of MRTG) I would highly recommend "Cricket": http://cricket.sourceforge.net/ -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (6)
-
Alex Rubenstein -
Chance Whaley -
David M. Ramsey -
Jeremiah Kristal -
Neil J. McRae -
woods＠weird.com