BTW, a rate limiter or policer, in their default configurations, are often very severe methods to cap bandwidth. From the little you describe, unless your MetroE provider charges you for exceeding contracted bandwidth, imposing a rate limiter or policer that drops packets often doesn't provide much benefit more than stats showing you exceeding your contracted rate while it can adversly impact traffic performance (not uncommon to see effective rate lower than nominal configured rate). Depending on what exactly you're trying to accomplish, you might not want to use the defaults for Bc (and perhaps Be) and/or implement a shaper solution. For instance, if what you're trying to do is emulate a 100 Mbps Ethernet interface using a rate limiter or policer, will probably require some analysis for proper parameter settings beyond just configuration for a 100 Mbps rate.
You are right and what I'm trying to do is decide if we should scale down to 100 Mbps metro E from 1000 Mbps metro E.
I have PRTG on these ports and I'm getting bw utilization stats but I wanted to go an extra mile and limit the bandwidth to only 100 Mbps without getting the provider involved and review the reports at that time again.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...