I'm looking at configuring QOS across a frame-relay WAN. We have a 1536 Port/768 PVC. My question is does the router base the bandwidth percentages on the port or pvc speed? Thanks in advance for your help.
I guess that you are talking about a serial interface, a serial interface defaults to 1544 Kbit bandwidth, you need to use the "bandwidth 768" to reflect the actual PVC bandwidth for the QoS calculations to be done correctly according to your actual available bandwidth regardless the physical bandwidth that your interface is capable of.
Mohammed, thanks for your help. The interface is serial as you thought. If I set the bandwidth statement to 768, will that affect the circuits ability to burst up to port speed?
You are very welcomed. You can't burst up to the port speed if you are contracted to a 768 PVC (according to your contract with your service provider, most probably the provider has policed your PVC with this value), and thus you need to configure the interface with the actual PVC bandwidth in order for the QoS to operate in the desired manner, baring in mind that the bandwidth command doesn't affect the physical speed of the interface, it will be used for the QoS calculations, which will eventually be used for adjusting your QoS behavior.
Hi Mohammed. We have the contracted 768 rate, but are allowed to burst up to port speed by our carrier. Would you recommend I just enable traffic shaping at the 768 bandwidth and not burst? Thanks.
We are mapping traffic to four classes (per our carrier) with class 1 for voice, 2 and 3 for data, and 4 is the default. My main concern is how the traffic and QOS markings would be affected by allowing the circuit to burst to non-guaranteed speeds.
Whether to burst depends on whether you're able to tolerate packet lost or additional latency when sending above CIR. (In theory, if you keep to CIR, you should obtain performance similar to a leased line of the same bandwidth.)
In practice, especially at a T-1 rate, if you're using a major carrier in the US or Canada, using full port speed is seldom an issue.
There is a middle of the road approach. You can often configure traffic shaping to use full port speed but if frame-relay congestion is seen, it will automatically reduce speed to your CIR rate. The shaper will increase speed, back up to full port rate, if no new congestion is detected.
If you have asymmetric bandwidth connections to the frame cloud, the higher bandwidth connection should have a shaper used to limit bandwidth to no more than the far side's port rate.
Adding to Mohammed's posts, Shaping would allow a port to operate at the shaping rate, however if you are bursting above the port speed, you are thenat Risk of the possibilty that some of your sensitive traffic could be dropped.
You should agree with the service provider about the shaping if you will do it at average or at peak, at average you can burst at Bc, at peak you could burst at the Be. hence, if you have dedicated bandwidth link you could shape at peak, if not,then its recommended to shape at average.
For QoS classes & marking that you have, then you will need Paren policy, child policy to be applied.