QoS for OSPF, VOICE and CRITICAL Traffic
Clash Royale CLAN TAG#URR8PPP
I plan to implement the QoS policy below.
- The target is to garantee bandwidth to VOICE and CRITICAL traffic.
- It should be 1/3 for Voice and Video, 1/3 for Business Critical traffic,
1/3 for all the rest. - If one of the classes don´t use the reserved bandwidth, the other classes can take it.
- I would like to make sure OSPF is running fine even the when the links are congested to avaoid flappings etc.
The plan is:
- Parent policy to shape to 20Mbps
- Child policy to apply QoS for 1/3 Voice/Video, 1/3 Business Critical,
1/3 all the rest
The Questions:
- I read somewhere that routing protocol traffic gets automaticcally into the LLQ, thats true?
If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is priorized and gets transmitted even if the link is overloaded? - Is the approach in my policy right to do what i descriped above? Or
do i have some mistakes inside?
Open for tipps, tricks, critic, hints
Setup
- OSPF is running on both links where the policy should be applied
- Traffic is already marked by hard / sofphones for voice and video
- Platform where QoS should be implemented is Cisco 4500X running in VSS
PLANNED CONFIG
class-map match-any CM_QOS_VOICE-VIDEO-TRAFFIC
description Matching voice, voice signalling, video and app-sharing traffic
match dscp ef
match dscp cs3
match dscp af41
match dscp af21
!
class-map match-any CM_QOS_CRITICAL-TRAFFIC
description Matching critical traffic: Routing Protocol, Business critical, etc.
match access-group name ACL_BUSINESS-CRITICAL-TRAFFIC
match access-group name ACL_ROUTING-PROTOCOL-TRAFFIC ! Necessary or automatically put to LLQ?
!
policy-map PM_QOS_SHAPING-20M
class class-default
shape average 20000000
service-policy PM_QOS_WAN-EDGE
!
policy-map PM_QOS_WAN-EDGE
class CM_QOS_VOICE-VIDEO-TRAFFIC
priority percent 33
class CM_QOS_CRITICAL-TRAFFIC
bandwidth percent 33
class class-default
fair-queue
random-detect
!
interface te1/1/1
service-policy output PM_QOS_SHAPING-20M
!
interface te2/1/1
service-policy output PM_QOS_SHAPING-20M
!
cisco switch cisco-catalyst qos
add a comment |
I plan to implement the QoS policy below.
- The target is to garantee bandwidth to VOICE and CRITICAL traffic.
- It should be 1/3 for Voice and Video, 1/3 for Business Critical traffic,
1/3 for all the rest. - If one of the classes don´t use the reserved bandwidth, the other classes can take it.
- I would like to make sure OSPF is running fine even the when the links are congested to avaoid flappings etc.
The plan is:
- Parent policy to shape to 20Mbps
- Child policy to apply QoS for 1/3 Voice/Video, 1/3 Business Critical,
1/3 all the rest
The Questions:
- I read somewhere that routing protocol traffic gets automaticcally into the LLQ, thats true?
If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is priorized and gets transmitted even if the link is overloaded? - Is the approach in my policy right to do what i descriped above? Or
do i have some mistakes inside?
Open for tipps, tricks, critic, hints
Setup
- OSPF is running on both links where the policy should be applied
- Traffic is already marked by hard / sofphones for voice and video
- Platform where QoS should be implemented is Cisco 4500X running in VSS
PLANNED CONFIG
class-map match-any CM_QOS_VOICE-VIDEO-TRAFFIC
description Matching voice, voice signalling, video and app-sharing traffic
match dscp ef
match dscp cs3
match dscp af41
match dscp af21
!
class-map match-any CM_QOS_CRITICAL-TRAFFIC
description Matching critical traffic: Routing Protocol, Business critical, etc.
match access-group name ACL_BUSINESS-CRITICAL-TRAFFIC
match access-group name ACL_ROUTING-PROTOCOL-TRAFFIC ! Necessary or automatically put to LLQ?
!
policy-map PM_QOS_SHAPING-20M
class class-default
shape average 20000000
service-policy PM_QOS_WAN-EDGE
!
policy-map PM_QOS_WAN-EDGE
class CM_QOS_VOICE-VIDEO-TRAFFIC
priority percent 33
class CM_QOS_CRITICAL-TRAFFIC
bandwidth percent 33
class class-default
fair-queue
random-detect
!
interface te1/1/1
service-policy output PM_QOS_SHAPING-20M
!
interface te2/1/1
service-policy output PM_QOS_SHAPING-20M
!
cisco switch cisco-catalyst qos
add a comment |
I plan to implement the QoS policy below.
- The target is to garantee bandwidth to VOICE and CRITICAL traffic.
- It should be 1/3 for Voice and Video, 1/3 for Business Critical traffic,
1/3 for all the rest. - If one of the classes don´t use the reserved bandwidth, the other classes can take it.
- I would like to make sure OSPF is running fine even the when the links are congested to avaoid flappings etc.
The plan is:
- Parent policy to shape to 20Mbps
- Child policy to apply QoS for 1/3 Voice/Video, 1/3 Business Critical,
1/3 all the rest
The Questions:
- I read somewhere that routing protocol traffic gets automaticcally into the LLQ, thats true?
If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is priorized and gets transmitted even if the link is overloaded? - Is the approach in my policy right to do what i descriped above? Or
do i have some mistakes inside?
Open for tipps, tricks, critic, hints
Setup
- OSPF is running on both links where the policy should be applied
- Traffic is already marked by hard / sofphones for voice and video
- Platform where QoS should be implemented is Cisco 4500X running in VSS
PLANNED CONFIG
class-map match-any CM_QOS_VOICE-VIDEO-TRAFFIC
description Matching voice, voice signalling, video and app-sharing traffic
match dscp ef
match dscp cs3
match dscp af41
match dscp af21
!
class-map match-any CM_QOS_CRITICAL-TRAFFIC
description Matching critical traffic: Routing Protocol, Business critical, etc.
match access-group name ACL_BUSINESS-CRITICAL-TRAFFIC
match access-group name ACL_ROUTING-PROTOCOL-TRAFFIC ! Necessary or automatically put to LLQ?
!
policy-map PM_QOS_SHAPING-20M
class class-default
shape average 20000000
service-policy PM_QOS_WAN-EDGE
!
policy-map PM_QOS_WAN-EDGE
class CM_QOS_VOICE-VIDEO-TRAFFIC
priority percent 33
class CM_QOS_CRITICAL-TRAFFIC
bandwidth percent 33
class class-default
fair-queue
random-detect
!
interface te1/1/1
service-policy output PM_QOS_SHAPING-20M
!
interface te2/1/1
service-policy output PM_QOS_SHAPING-20M
!
cisco switch cisco-catalyst qos
I plan to implement the QoS policy below.
- The target is to garantee bandwidth to VOICE and CRITICAL traffic.
- It should be 1/3 for Voice and Video, 1/3 for Business Critical traffic,
1/3 for all the rest. - If one of the classes don´t use the reserved bandwidth, the other classes can take it.
- I would like to make sure OSPF is running fine even the when the links are congested to avaoid flappings etc.
The plan is:
- Parent policy to shape to 20Mbps
- Child policy to apply QoS for 1/3 Voice/Video, 1/3 Business Critical,
1/3 all the rest
The Questions:
- I read somewhere that routing protocol traffic gets automaticcally into the LLQ, thats true?
If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is priorized and gets transmitted even if the link is overloaded? - Is the approach in my policy right to do what i descriped above? Or
do i have some mistakes inside?
Open for tipps, tricks, critic, hints
Setup
- OSPF is running on both links where the policy should be applied
- Traffic is already marked by hard / sofphones for voice and video
- Platform where QoS should be implemented is Cisco 4500X running in VSS
PLANNED CONFIG
class-map match-any CM_QOS_VOICE-VIDEO-TRAFFIC
description Matching voice, voice signalling, video and app-sharing traffic
match dscp ef
match dscp cs3
match dscp af41
match dscp af21
!
class-map match-any CM_QOS_CRITICAL-TRAFFIC
description Matching critical traffic: Routing Protocol, Business critical, etc.
match access-group name ACL_BUSINESS-CRITICAL-TRAFFIC
match access-group name ACL_ROUTING-PROTOCOL-TRAFFIC ! Necessary or automatically put to LLQ?
!
policy-map PM_QOS_SHAPING-20M
class class-default
shape average 20000000
service-policy PM_QOS_WAN-EDGE
!
policy-map PM_QOS_WAN-EDGE
class CM_QOS_VOICE-VIDEO-TRAFFIC
priority percent 33
class CM_QOS_CRITICAL-TRAFFIC
bandwidth percent 33
class class-default
fair-queue
random-detect
!
interface te1/1/1
service-policy output PM_QOS_SHAPING-20M
!
interface te2/1/1
service-policy output PM_QOS_SHAPING-20M
!
cisco switch cisco-catalyst qos
cisco switch cisco-catalyst qos
edited Feb 16 at 19:31
Ron Maupin♦
66.9k1369125
66.9k1369125
asked Feb 16 at 18:12
JackJack
373
373
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Besides what Ron Trunk explained, you have some problems.
If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth
statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:
interface te1/1/1
bandwidth 19400
!
interface te2/1/1
bandwidth 19400
!
You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.
Typically, you want most of your traffic to be set as default (BE
), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.
You could set up something like this typical set of classes:
class-map match-any EGRESS-VOICE
description VoIP traffic
match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
description Video traffic
match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
description Control traffic for VoIP, Video, Routing, etc.
match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
description Business traffic that requires special treatment
match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
description Bulk traffic like backups, etc.
match ip dscp cs1 af11 af12 af13
!
Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.
policy-map EGRESS-UPLINK
description QoS for 20 Mbps uplinks
class EGRESS-VOICE
priority
police cir percent 23
class EGRESS-VIDEO
bandwidth remaining percent 30
police cir percent 23
class EGRESS-CONTROL
bandwidth remaining percent 10
class EGRESS-BUSINESS
bandwidth remaining percent 20
class EGRESS-BULK
bandwidth remaining percent 5
dbl
class class-default
bandwidth remaining percent 34
dbl
!
And, you apply the policy to your uplink interfaces:
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth
statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).
Edit:
If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):
policy-map EGRESS-20M
class class-default
shape average 19400000 77600
service-policy EGRESS-UPLINK
!
Then, use the shaping policy (which uses to the queuing policy):
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
add a comment |
QoS is a book-worthy topic. but here are a few quick answers:
I read somewhere that routing protocol traffic gets automatically into
the LLQ, thats true?
Not true
If not, how i can make sure the OSPF traffic in outbound direction
originated by the SW itself is prioritized and gets transmitted even
if the link is overloaded?
Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)
Is the approach in my policy right to do what i descriped above? Or do
i have some mistakes inside?
Your voice traffic should not be shaped. Put it in a priority queue before the shaper.
Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57003%2fqos-for-ospf-voice-and-critical-traffic%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Besides what Ron Trunk explained, you have some problems.
If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth
statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:
interface te1/1/1
bandwidth 19400
!
interface te2/1/1
bandwidth 19400
!
You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.
Typically, you want most of your traffic to be set as default (BE
), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.
You could set up something like this typical set of classes:
class-map match-any EGRESS-VOICE
description VoIP traffic
match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
description Video traffic
match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
description Control traffic for VoIP, Video, Routing, etc.
match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
description Business traffic that requires special treatment
match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
description Bulk traffic like backups, etc.
match ip dscp cs1 af11 af12 af13
!
Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.
policy-map EGRESS-UPLINK
description QoS for 20 Mbps uplinks
class EGRESS-VOICE
priority
police cir percent 23
class EGRESS-VIDEO
bandwidth remaining percent 30
police cir percent 23
class EGRESS-CONTROL
bandwidth remaining percent 10
class EGRESS-BUSINESS
bandwidth remaining percent 20
class EGRESS-BULK
bandwidth remaining percent 5
dbl
class class-default
bandwidth remaining percent 34
dbl
!
And, you apply the policy to your uplink interfaces:
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth
statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).
Edit:
If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):
policy-map EGRESS-20M
class class-default
shape average 19400000 77600
service-policy EGRESS-UPLINK
!
Then, use the shaping policy (which uses to the queuing policy):
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
add a comment |
Besides what Ron Trunk explained, you have some problems.
If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth
statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:
interface te1/1/1
bandwidth 19400
!
interface te2/1/1
bandwidth 19400
!
You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.
Typically, you want most of your traffic to be set as default (BE
), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.
You could set up something like this typical set of classes:
class-map match-any EGRESS-VOICE
description VoIP traffic
match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
description Video traffic
match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
description Control traffic for VoIP, Video, Routing, etc.
match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
description Business traffic that requires special treatment
match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
description Bulk traffic like backups, etc.
match ip dscp cs1 af11 af12 af13
!
Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.
policy-map EGRESS-UPLINK
description QoS for 20 Mbps uplinks
class EGRESS-VOICE
priority
police cir percent 23
class EGRESS-VIDEO
bandwidth remaining percent 30
police cir percent 23
class EGRESS-CONTROL
bandwidth remaining percent 10
class EGRESS-BUSINESS
bandwidth remaining percent 20
class EGRESS-BULK
bandwidth remaining percent 5
dbl
class class-default
bandwidth remaining percent 34
dbl
!
And, you apply the policy to your uplink interfaces:
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth
statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).
Edit:
If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):
policy-map EGRESS-20M
class class-default
shape average 19400000 77600
service-policy EGRESS-UPLINK
!
Then, use the shaping policy (which uses to the queuing policy):
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
add a comment |
Besides what Ron Trunk explained, you have some problems.
If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth
statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:
interface te1/1/1
bandwidth 19400
!
interface te2/1/1
bandwidth 19400
!
You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.
Typically, you want most of your traffic to be set as default (BE
), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.
You could set up something like this typical set of classes:
class-map match-any EGRESS-VOICE
description VoIP traffic
match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
description Video traffic
match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
description Control traffic for VoIP, Video, Routing, etc.
match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
description Business traffic that requires special treatment
match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
description Bulk traffic like backups, etc.
match ip dscp cs1 af11 af12 af13
!
Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.
policy-map EGRESS-UPLINK
description QoS for 20 Mbps uplinks
class EGRESS-VOICE
priority
police cir percent 23
class EGRESS-VIDEO
bandwidth remaining percent 30
police cir percent 23
class EGRESS-CONTROL
bandwidth remaining percent 10
class EGRESS-BUSINESS
bandwidth remaining percent 20
class EGRESS-BULK
bandwidth remaining percent 5
dbl
class class-default
bandwidth remaining percent 34
dbl
!
And, you apply the policy to your uplink interfaces:
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth
statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).
Edit:
If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):
policy-map EGRESS-20M
class class-default
shape average 19400000 77600
service-policy EGRESS-UPLINK
!
Then, use the shaping policy (which uses to the queuing policy):
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
Besides what Ron Trunk explained, you have some problems.
If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth
statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:
interface te1/1/1
bandwidth 19400
!
interface te2/1/1
bandwidth 19400
!
You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.
Typically, you want most of your traffic to be set as default (BE
), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.
You could set up something like this typical set of classes:
class-map match-any EGRESS-VOICE
description VoIP traffic
match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
description Video traffic
match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
description Control traffic for VoIP, Video, Routing, etc.
match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
description Business traffic that requires special treatment
match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
description Bulk traffic like backups, etc.
match ip dscp cs1 af11 af12 af13
!
Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.
policy-map EGRESS-UPLINK
description QoS for 20 Mbps uplinks
class EGRESS-VOICE
priority
police cir percent 23
class EGRESS-VIDEO
bandwidth remaining percent 30
police cir percent 23
class EGRESS-CONTROL
bandwidth remaining percent 10
class EGRESS-BUSINESS
bandwidth remaining percent 20
class EGRESS-BULK
bandwidth remaining percent 5
dbl
class class-default
bandwidth remaining percent 34
dbl
!
And, you apply the policy to your uplink interfaces:
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-UPLINK
!
Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth
statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).
Edit:
If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):
policy-map EGRESS-20M
class class-default
shape average 19400000 77600
service-policy EGRESS-UPLINK
!
Then, use the shaping policy (which uses to the queuing policy):
interface te1/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
interface te2/1/1
bandwidth 19400
service-policy output EGRESS-20M
!
edited Feb 16 at 20:58
answered Feb 16 at 19:28
Ron Maupin♦Ron Maupin
66.9k1369125
66.9k1369125
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
Comments are not for extended discussion; this conversation has been moved to chat.
– Ron Maupin♦
Feb 18 at 4:38
add a comment |
QoS is a book-worthy topic. but here are a few quick answers:
I read somewhere that routing protocol traffic gets automatically into
the LLQ, thats true?
Not true
If not, how i can make sure the OSPF traffic in outbound direction
originated by the SW itself is prioritized and gets transmitted even
if the link is overloaded?
Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)
Is the approach in my policy right to do what i descriped above? Or do
i have some mistakes inside?
Your voice traffic should not be shaped. Put it in a priority queue before the shaper.
Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
add a comment |
QoS is a book-worthy topic. but here are a few quick answers:
I read somewhere that routing protocol traffic gets automatically into
the LLQ, thats true?
Not true
If not, how i can make sure the OSPF traffic in outbound direction
originated by the SW itself is prioritized and gets transmitted even
if the link is overloaded?
Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)
Is the approach in my policy right to do what i descriped above? Or do
i have some mistakes inside?
Your voice traffic should not be shaped. Put it in a priority queue before the shaper.
Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
add a comment |
QoS is a book-worthy topic. but here are a few quick answers:
I read somewhere that routing protocol traffic gets automatically into
the LLQ, thats true?
Not true
If not, how i can make sure the OSPF traffic in outbound direction
originated by the SW itself is prioritized and gets transmitted even
if the link is overloaded?
Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)
Is the approach in my policy right to do what i descriped above? Or do
i have some mistakes inside?
Your voice traffic should not be shaped. Put it in a priority queue before the shaper.
Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.
QoS is a book-worthy topic. but here are a few quick answers:
I read somewhere that routing protocol traffic gets automatically into
the LLQ, thats true?
Not true
If not, how i can make sure the OSPF traffic in outbound direction
originated by the SW itself is prioritized and gets transmitted even
if the link is overloaded?
Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)
Is the approach in my policy right to do what i descriped above? Or do
i have some mistakes inside?
Your voice traffic should not be shaped. Put it in a priority queue before the shaper.
Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.
answered Feb 16 at 18:37
Ron TrunkRon Trunk
37.8k33577
37.8k33577
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
add a comment |
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
Hello Ron, thx for feedback. Ah yes you are absolutly right regarding the voice traffic and the shaper. Thx for the hint.
– Jack
Feb 16 at 19:55
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57003%2fqos-for-ospf-voice-and-critical-traffic%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown