I'm working on a network refresh that includes the customer aggregation. Services to customers are primarily across ethernet (LAN and MAN).
I've been researching/fighting/experimenting with methods to handle per-port bidirectional bandwidth control. The legacy configuration uses Cisco's CAR, and I've been looking at traffic-shaping and policing. From what I can see, the various bandwidth management techniques require increasing CPU as the traffic rate increase (more packets/bytes == more work for the CPU). I need a device that does at least HSRP/VRRP/equivalent plus OSPF and handles the bandwidth management. The 3550G (playing with it for a different project) reportedly has problems with multiple ports/streams above 1Mbs. The chassis-based devices (6500/7600) appear to punt at least some of the traffic to CPU, plus I'd like to deploy small devices per patch-panel and backhaul to the aggregation or core (depending on how much functionality is in the device). I'd like either a stackable or small chassis device that I can either configure "M"Mbs per port/VLAN or "P"percent per port, not necessarily with bursting capability. The extreme hypothetical environment would be 24ea 10/100/1000 ports each configured for 1Mbs bandwidth and hosts on all ports attempting to send and/or receive at line rate without cratering the device. I've also considered essentially aggregating multiple ports/VLANs on a switch and uplinking with a 100Mbs port. This would require monitoring and manual intervention to ensure the aggregate doesn't exceed 100mbs. We also have customers that need more than 100mbs which means I'd somehow have to ensure that a single customer couldn't consume the capacity of an entire GigE (unless provisioned for it). Am I missing a feature/device/configuration that is obvious to somebody else, or.... ? My concern with any CPU-based solution is that it won't scale as customer bandwidth needs continue to increase. I'd also prefer small, stand-alone devices and distribute them at the patch-panel level for "light bulb" replacement and ease of cable management. Thanks, _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
