09-20-2008 03:34 PM - edited 03-03-2019 11:38 PM
We will be upgrading our branch offices from a Single T1 to x2 T1 connections.
We have VoIP implemented in our branch offices.
I am wondering if I need to be concerned about making this change to the interface.
The current config is shown below, is the Frame-Relay (frame-relay traffic shaping) doing anything significant that I could get burned by changing the config from Frame-relay encap to multilinkPPP encap?
interface Serial0/3/0
bandwidth 1536
no ip address
encapsulation frame-relay IETF
load-interval 30
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type cisco
max-reserved-bandwidth 100
hold-queue 256 in
hold-queue 256 out
!
interface Serial0/3/0.400 point-to-point
ip address 1.x.x.6 255.255.255.252
ip nbar protocol-discovery
ip flow ingress
ip flow egress
frame-relay interface-dlci 400 IETF
class mycompany-class
crypto map mycompany_Crypt
09-28-2008 09:25 AM
"You mentioned advising using WRED and FQ as we are using them,
are you talking about:
class class-default
set dscp default
fair-queue
random-detect
If so, how would you advise? "
Yes, I advise against since a) your policy appears to be trying to insure adquate bandwidth for the "DATA-Priority" class, and b) class-default is likely to contain non-TCP traffic.
I would suggest something like:
class class-default
set dscp default
bandwidth 128
"You also mentioned on an MPLS link, to make sure that the QoS is set up from remote side CE to PE router (which is what this policy is doing) and also from PE to CE router (which would be my Hub site router)."
The PE router is likely under the control of the MPLS provider. If it is, you'll need to understand what their QoS policy provides and mark your traffic to take advantage of it. (Likely you'll already doing so with the markings of EF/AF31/BE.)
"Also, why is the "max-reserved-bandwidth" not advised?"
The default insures some bandwidth for "other" traffic, such as L2 overhead. It can be changed but only if you understand the issues involved in changing the default. Since unused bandwidth is still available to you, you don't want to take away other special taffic bandwidth insurance unless you're sure it won't have an adverse impact.
09-28-2008 12:44 PM
Joseph,
If my policy is the following with the above ajustment:
policy-map PEFCU-QoS
class VOICE
priority 256
set dscp ef
class DATA-Priority
bandwidth 128
set dscp af31
class class-default
set dscp default
bandwidth 128
What happens to the rest of the pipe?
Dont these three different classes cover all of the traffic?
My understanding was:
We have VOICE matching a particular access-list
Data-Priority matching an access-list
And
Default covering everything else
If the pipe is 1.5M, and I apply a bandwidth value to the Default class, doesn't that lock me in to 128K for the default class?
09-28-2008 03:25 PM
"If the pipe is 1.5M, and I apply a bandwidth value to the Default class, doesn't that lock me in to 128K for the default class"
No, except for LLQ classes, bandwidth doesn't set a cap it sets a minimum. Both the DATA-Priority class and class-default class can use 100% of the link. If all three classes wanted bandwidth, VOICE would be limited to 256, and DATA-Priority and class-default should split the remaining available bandwidth.
09-28-2008 04:13 PM
Excellent,
Thank you Joseph for helping me understand.
My last question on this I promise:
I have read that you should set the policies to utilize only 75% of the total bandwidth and voice in the priority class to use a max of 33% of the total bandwidth.
If for example I was using the priority class for voice and video conferencing, does it matter if I set the priority class to a full 33% of a 3.0M pipe and leave the other two policies at their current values?
For example:
policy-map PEFCU-QoS
class VOICE
priority 1024
set dscp ef
class DATA-Priority
bandwidth 128
set dscp af31
class class-default
set dscp default
bandwidth 128
Can I set the values to whatever I want, or are there any particular rules to go by other than what I mentioned before?
Something else I noticed was that class af31 was used for voice signaling, but my access list is not related to voice signaling that the class is associated to, it is another application that is related to our customers.
The af31 can be applied in arbitrary ways like this as long as I match an access-list?
09-28-2008 06:25 PM
"I have read that you should set the policies to utilize only 75% of the total bandwidth and voice in the priority class to use a max of 33% of the total bandwidth."
The 75% is likely a reference to leaving 25% for "other" traffic which includes class-default. (I.e. unless you change max-reserved-bandwidth, other class's total bandwidth allocation shouldn't normally be definable to exceed 75%.)
The 33% is a rule-of-thumb suggested by Cisco to leave adquate bandwidth for non-LLQ classes.
"Can I set the values to whatever I want, or are there any particular rules to go by other than what I mentioned before?"
You can set the allocation to whatever you want with the guide that there's adquate bandwidth to support the need of the traffic. For instance, by you defining 128 Kbps for DATA-Priority, we're assuming that traffic will be "happy" with that as a minumum guarantee.
"Something else I noticed was that class af31 was used for voice signaling, but my access list is not related to voice signaling that the class is associated to, it is another application that is related to our customers.
The af31 can be applied in arbitrary ways like this as long as I match an access-list"
There are marking recommedations, that you might want to adhere to; MPLS providers might have a QoS model that behaves a certain way; Cisco WFQ weigth flows different based on IP precedence or DSCP class selector; etc.
The links, below, are some of Cisco "At-A-Glance" that might help you understand this.
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295a9b.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295abf.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295ac3.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295ab5.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa1.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aab.pdf
http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa8.pdf
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: