I have a question regarding using class maps for QoS. I am using LLQ on my Internet connection, with a simple config, I need to guarantee 2 hosts 768 of my 1544 T1. I've set it up as follows;
match access-group 50
match access-group 51
access-list 50 permit 10.10.10.1
access-list 51 permit 10.10.20.1
service-policy output QoS
And finally, the question:
When I do a show int s0, the output says I have 390k of free bandwidth. Can someone help clear this up? The way I understand, the QoS shouldn't even take effect until the link is congested, so do I not have the 1544 available at all times? I'm just afraid I'm starving bandwidth. When I add 384x2+390 I get 1158 (far from 1544). Any insight on this would be greatly appreciated.
The maximum bandwidth available on an interface to be assigned to qos classes is by default, 75% of the interface bandwidth. In your case, this is 0.75*1544, which is how you get the 1158k. You can change this 75% figure by using the max-reserved-bandwidth command.
When you assign a service-policy to an interface, the bandwidth assigned to the various classes is subtracted from this available bandwidth.
The available bandwidth shown in the output of show interface is how much more bandwidth is available to be assigned to allocated to qos classes. This is a static bandwidth figure, and does not reflect the actual bandwidth on the interface.
The default figure of 75% for max-reserved-bandwidth allows 25% for the following:
- layer 2 keepalives etc
- traffic not matching any of the user-defined classes i.e. traffic that falls into the class-default class.
For an interface with a bandwidth of 1544k, you could allocate a service-policy with classes that assign a total bandwidth of up to 1158k i.e. the total of bandwidth assigned using the 'bandwidth' and 'priority' commands can be up to 1158k.
just to make sure: the "available" bandwidth is only to calculate what amount of bandwidth you can give to classes in your policy. The reasonable approach is to leave some bandwidth for traffic not accounted for in your policy-map, like Layer2 keepalives, routing updates and so on as already stated in the previous posts.
The whole Queueing configuration only kicks in when there is an overload situation. So to say your policy-map is a ruleset for the router what to do with IP packets which can not be sent immediately because the interface is congested. You basically define in which order the IP packets have to be taken out of packet memory and sent over the interface.
In case there is no congestion any traffic can occupy all your bandwidth, i.e. you always have T1.
Another thing is: with your "priority statement you define also a policer. So in case there is an overload situation you drop excess traffic from the two hosts to limit them to 384 kbps.
In case you do not want to limit them, but to give a minimum bandwith guarantee, you should use "bandwidth" instead of "priority" statements.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...