Thanks again for all the responses to my previous post.
We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3
card ofr our OC3.
The problem we have now is that we are only paying for 80 MB/s of the
OC-3, and the ISP is leaving the capping of it up to us. I have
googled and the only things I can find is that you can not do a real
cap on this type of interface.
We have tried the rate-limit command with various parameters and we
are unable to keep it at 80. I have read that this is not the correct
way to do it, but I'm not sure what is.
traffic-shape rate 75000000 90000000 90000000 1000 for example. Your rate limit will police your traffic and drop it all.
Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output.
~Jay Murphy
IP Network Specialist
NM State Government
IT Services Division
PSB – IP Network Management Center
Santa Fé, New México 87505
"We move the information that moves your world."
“Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.”
“Engineering is about finding the sweet spot between what's solvable and what isn't."
Radia Perlman
Please consider the environment before printing e-mail
I think if you try to traffic-shape 80Mbps on that platform you'll have
problems. We have a 7200 with NPE-G1 (rate limited at 80Mbps) and it killed
the CPU when the threshold was hit. I imagine that traffic-shaping would do
the same to CPU and memory. I'd lab it first.
Agree...when you rate limit verse shaping you can actually cause more traffic because the packets need to be retransmitted to deal with those that got dropped.
Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu
Honestly, cpu overhead shouldn't be an issue with a traffic shape queue. If it is, probably a seriously underpowered router or poor code. Now if you applied extensive rules for various traffic at different rates and queue priorities, I could see lots of extra ticks.
Don't get me wrong. I have 400mbps+ traffic shapes on my junipers and probably glad for the extensive hardware support (like I have a choice, no hardware support, the router won't do it)
I've seen that model preceded by a BSD machine with 2 physical ethernet
NICs. When I asked - "limiting for the 7206's outgoing", so I'm assuming
that was a CPU thing. In that case the 7206 was just an edge box for the
fibre, so doing nothing complex. Capped at 48Mbps (IIRC) in that case -
YMMV.
Also bear in mind that this is borderline black art - it needs a bit of
testing to be sure it's working as you expect
My usual technique is to replay some flows then set several iperf
streams going simultaneously to see how it reacts. Sometimes limiting
just seems to temporarily break down under stress in bizarre ways.
Whether it fails "open", "restricted" or "closed" seems to be very
unpredictable and not very reproducible on some kit- keep your eye on it
at first, or use BSD to do it if you're more familiar with that.
Also, are there any upgrades that can be done to this router to
increase it's processing power? Is there something better for the
7206VXR than the NPE-G1? I see the NPE-G2, but even on ebay it is very
costly.
I concur, we shape a 100Mb/s ethernet down to 50Mb/s on a 3845,
so that QoS is doable. The router gets brought to its knees
around 40Mb/s. Turn off shaping and the router is usable all
the way up to the 50Mb/s and then some.
Is there a more reasonable way to do this on Cisco?
max-reserved-bandwidth?
If your issue is cost for rates larger than 80 Mbps then you probably want
to find out what applications are using the bulk of the bandwidth and
either adjust your budget, or their performance expectations and allocate
network resources expressly. Flow data (even local cache analysis v.
exporting) would help you glean some of this, but external longer term
analysis would surely be more useful - and there are lots of way you can
do that - and use the data to either justify more budget or cull offending
applications.
As others have noted, rate *limiting* is usually indiscriminate and often
results in non-determinism and far less 'goodput' than rate-shaping. If
hardware constraints with those WAN-side PHY devices are gating, you
could always do it on the LAN side, and perhaps much more selectively
based on which application and associated network transaction traffic is
the most valuable to your business and in your operating environment.
Given, you didn't talk about asymmetries and egress traffic policy tweaking
at the CPE to induce desired ingress levels is usually a science in and of
it's self - but alas, if one must turn the steam valves
I can't see application of any rate-limiting policies indiscriminately be
desirable in any business environment, and suggest that if budget constrained
worst case you align network resource allocation with critical business
applications first via LAN-side rate-shaping functions - or AUPs, or....
With a G1 you'll be able to shape just fine, even do fancy stuff like fair-queue within those 80 megs. I've done this on a NPE-300, but only egress, and as long as packet sizes were fairly large (normal TCP sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of traffic. So with the added power of G1 you should definitely try before ruling it out.
Shaping is so much better than the packet dropping that a rate limiter does.
you could have a stab at using a PFsense box with two (and strictly ONLY
two, for this use) physical NICs. It has a GUI to set up traffic shaping
(see the sticky on the pfsense forums) PFsense 1.2.3 is current, don't
go for the experimental 2.0 for production. There's a book and
commercial support if you need it, free support via forums if you can't.
Only two physical NICs is necessary due to shaper problems with more
than two, whereas in a firewalling role the slots are the only limit
(but VLANS are the norm for bucketloads of ports on a firewall PFsense
box)
An ITX (Littlefalls etc) mobo with 512MB RAM with an extra PCI Intel NIC
added will do you fine
.
PFsense has nice traffic graphs, which helps you with shaping speeds in
a big way. It also has a TFTP server available for it so it's handy for
unmanned sites with only a few blue boxes
PS - a crazy afterthough - surely just about anything with a 10/100
ethernet link running at 100 and placed inline, cannot exceed 100Mbps -
and probably less if it's plastic-cased? Try a few 8-port junkers and
see what happens if you fancy a walk on the dangerous side. Watch out
for errors and smoke
With a G1 you'll be able to shape just fine, even do fancy stuff like fair-queue within those 80 megs. I've done this on a NPE-300, but only egress, and as long as packet sizes were fairly large (normal TCP sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of traffic. So with the added power of G1 you should definitely try before ruling it out.
Definitely worth the try. Your biggest enemy may be 12.4 IOS. It's bloated and buggy in my experience, but that has mostly been edge services. If 12.4 pegs your processor, you may want to check the software/hardware matrix and see if one of the older 12.0/2 service provider trains that they continued to add support for (probably some large customer's special requests). I don't know if it will support the G1, but if so, you might have better performance out of it.
Shaping is so much better than the packet dropping that a rate limiter does.
Definitely. My favorite off the wall use of shaping was to smooth traffic flow on a Gig-e to reduce microbursts from overrunning the hardware rx on a 7513.
Definitely worth the try. Your biggest enemy may be 12.4 IOS. It's
bloated and buggy in my experience, but that has mostly been edge
services. If 12.4 pegs your processor, you may want to check the
software/hardware matrix and see if one of the older 12.0/2 service
provider trains that they continued to add support for (probably some
large customer's special requests). I don't know if it will support the
G1, but if so, you might have better performance out of it.
Jack
We've implemented 400Mbps shaping with over twenty nested child policies (individual customer shaping and queuing within the 400M) on an NPE-G1 running 12.4(12c). CPU does start to become an issue at that point, and by removing the policy we can reach nearly 600Mbps on the same kit. We run standard ACL, OSPF, EIGRP, VRF Selection, MPLS, MP-BGP, etc. but do not run a full Internet BGP feed on these boxes, so you'll need to subtract that process usage if it applies. I would note that upgrading the box to 12.2(33)SRC caused a 20%+ increase in CPU attributed to the HQF (Hierarchical QOS Framework) process. We decided to stay with the 12.4 train.
Cory Ayers
CCIE #16874 (R&S), CCIP
Director of Network Strategy
Education Networks of America
