02-04-2015 11:13 AM - edited 03-07-2019 10:30 PM
Hi Friedns,
So this is My First Time Configuring Quality of Service ( QoS ) and i need some help to correct my Configuration or conform it's correct.
The Gool here is to give higher priority to SCADA Data over the Video Stream from the Camera (so that the Video don't eat all the T1 Bandwidth)
i am configuring QoS on Cisco 2851 Router IOS Version 15.1(4)M9.
The Traffic Come From the BVI Interface which include Interface G0/0 and Interfaces in NM-16ESW-1G (16Fa and 1G (G1/0))
The Traffic Leave the Router throght the T1 Line (we need higher priority to SCADA Traffic over the rest of the Traffic), SCADA Traffic in Subnet 192.168.135.0 .
So here is My Configuration:
ip access-list extended SCADA_DATA
permit ip 192.168.135.0 0.0.0.255 any
!
class-map SCADA
match access-group name SCADA_DATA
!
policy-map SCADA_PRIORITY
class SCADA
set precedence 5
!
interface BVI1
service-policy input SCADA_PRIORITY
R1#show ip inter brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES NVRAM up up
GigabitEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/0/0 10.10.15.2 YES NVRAM up up
FastEthernet1/0 unassigned YES unset up down
FastEthernet1/1 unassigned YES unset up down
FastEthernet1/2 unassigned YES unset up down
FastEthernet1/3 unassigned YES unset up down
FastEthernet1/4 unassigned YES unset up down
FastEthernet1/5 unassigned YES unset up down
FastEthernet1/6 unassigned YES unset up down
FastEthernet1/7 unassigned YES unset up down
FastEthernet1/8 unassigned YES unset up down
FastEthernet1/9 unassigned YES unset up down
FastEthernet1/10 unassigned YES unset up down
FastEthernet1/11 unassigned YES unset up down
FastEthernet1/12 unassigned YES unset up down
FastEthernet1/13 unassigned YES unset up down
FastEthernet1/14 unassigned YES unset up down
FastEthernet1/15 unassigned YES unset up down
GigabitEthernet1/0 unassigned YES unset up down
BVI1 192.168.135.1 YES NVRAM up up
Vlan1 unassigned YES unset up down
is this configuartion Correct ? is the Router will send SCADA traffic before the rest of the traffic ? are the interface that i apply the Service Policy to are correct ? do i need to apply any service policy to T1 (Serial0/0/0) ?
Thanks Alot My Friends
Solved! Go to Solution.
02-04-2015 01:34 PM
Hello,
Yes, you are on the right track, however you should be able to solve this issue while still adhering to QOS best practices regarding traffic marking. I'm not sure if your video traffic is already marked by the camera (is it Cisco?), but we aren't reserving any bandwidth for it here.
ip access-list extended SCADA_DATA
permit ip 192.168.135.0 0.0.0.255 any
!
class-map SCADA
match access-group name SCADA_DATA
!
policy-map SCADA_PRIORITY
class SCADA
set dscp af21
bandwidth 512
class class-default
fair-queue
!
interface Serial0/0/0
bandwidth 1536
service-policy output SCADA_PRIORITY
Basically, when using the priority statement you are saying to always service that queue first. By using the bandwidth statement, you are saying that traffic is guaranteed a certain amount of bandwidth, but it will be serviced "fairly" with other traffic. Meaning, it might not always get sent right away when data is present, but it will always get up to 512kbps of bandwidth.
Voice and video are much more noticeable when there is jitter. I doubt SCADA monitors will notice if it takes 40ms to get a packet instead of 15ms.
This config will allow you to go back and add voice and video to your queueing later if you decide to do so without having to change how you treat SCADA.
Finally, bear in mind that you are just affecting these packets as they leave the router. Typically your service provider will offer QOS service as well. Depending on what you buy, they will offer different classes different amounts of bandwidth, and you have to ensure that your markings match what they expect.
02-04-2015 11:49 AM
You don't need the service-policy input. Just put the service-policy output on the S0/0/0 port. Also, don't use IP Precedence. Use DSCP. That's a newer, better value to use.
Your classification and marking is fine, but you're not actually doing any queueing. You will need to specify the amount of bandwidth you want to reserve for that class in the policy-map. You can specify a finite number or a percentage of the bandwidth marked on the interface.
One last thing to consider, Cisco recommends video be marked AF41, so you may want to consider that. You are not currently queueing video, so it is sent best effort along with the SCADA traffic. If you're just doing this for a proof of concept, you can use whatever you want. But if you are creating a standard for your enterprise, you should review what Cisco recommends as DSCP standards for various traffic types.
02-04-2015 01:13 PM
hi shh5455,
so here is the changes that i did based on your post:
ip access-list extended SCADA_DATA
permit ip 192.168.135.0 0.0.0.255 any
!
class-map SCADA
match access-group name SCADA_DATA
!
policy-map SCADA_PRIORITY
class SCADA
set dscp af31
priority 512
!
interface Serial0/0/0
service-policy output SCADA_PRIORITY
if i put the Video AF41 that will give him higher priority than the SCADA Data and i don't want that.
this is for Enterprise Network, but in this case the SCADA data is more important than the Streaming Video from the Cameras.
please if i have mistake let me know with simple example
Many Many thanks for your help :)
02-04-2015 01:34 PM
Hello,
Yes, you are on the right track, however you should be able to solve this issue while still adhering to QOS best practices regarding traffic marking. I'm not sure if your video traffic is already marked by the camera (is it Cisco?), but we aren't reserving any bandwidth for it here.
ip access-list extended SCADA_DATA
permit ip 192.168.135.0 0.0.0.255 any
!
class-map SCADA
match access-group name SCADA_DATA
!
policy-map SCADA_PRIORITY
class SCADA
set dscp af21
bandwidth 512
class class-default
fair-queue
!
interface Serial0/0/0
bandwidth 1536
service-policy output SCADA_PRIORITY
Basically, when using the priority statement you are saying to always service that queue first. By using the bandwidth statement, you are saying that traffic is guaranteed a certain amount of bandwidth, but it will be serviced "fairly" with other traffic. Meaning, it might not always get sent right away when data is present, but it will always get up to 512kbps of bandwidth.
Voice and video are much more noticeable when there is jitter. I doubt SCADA monitors will notice if it takes 40ms to get a packet instead of 15ms.
This config will allow you to go back and add voice and video to your queueing later if you decide to do so without having to change how you treat SCADA.
Finally, bear in mind that you are just affecting these packets as they leave the router. Typically your service provider will offer QOS service as well. Depending on what you buy, they will offer different classes different amounts of bandwidth, and you have to ensure that your markings match what they expect.
02-04-2015 02:13 PM
Amazing .. thanks very much for your help
i don't think the Video traffic is marked by the Camera because it's not Cisco it's (COHU|HD) Helios.
i change the DSCP value to AF21 as you suggested (make more sense) and added the fair-queue under the default class.
as long as for the bandwidth command under the Serial Interface!
interface Serial0/0/0 bandwidth 1536
if i issue the command "show interface Serial0/0/0" the BW will be BW 1544 Kbit/sec. do i need to adjust that ? can you explain why ?
i am CCNP Certified and CCIE Student so i appreciate all the info.
Best Regards
02-04-2015 02:28 PM
The camera may or may not mark it's own traffic. If not, you'd have to make up another ACL to classify the traffic (e.g. via IP and ports, etc.). There is much more that can could be written on this topic, but QOS is a big topic!
As far as the bandwidth statement on the Serial interface, that can be a little confusing. By default a serial interface uses 1544 as it's bandwidth (even if you've only got a fractional T1 of say 768k). So to make sure QOS is using the right number, some people will actually define the bandwidth on the interface. (If we had a frac-T1, we might say "bandwidth 768"). This gets much more important when you have an ethernet handoff to your WAN provider because you may have a 100 Mbps link to them but you probably didn't buy a 100 Mbps worth of WAN bandwidth from them.
1536 vs 1544 is just me trying to be precise. A T1 is 1544 Kbps, but if you remove the framing bits (which can't be used to send your data anyway) it's really 1536 Kbps of available capacity. It's somewhat common to do that, but not absolutely necessary.
02-04-2015 02:22 PM
i have two Questions if you don't mind..
In Our Configuration Does the Packets leaving the router have DSCP value in the IP Header ? to be classify by the next router too ?
Also i can apply the Service-Policy to more then interface right ?
Ex:
R3#
interface Serial0/0/0:0
service-policy output SCADA_PRIORITY
Exit
interface Serial0/0/1:1
service-policy output SCADA_PRIORITY
Exit
interface Serial0/0/2:2
service-policy output SCADA_PRIORITY
End
02-04-2015 02:34 PM
Yes, your policy map is tagging the packets with DSCP AF21. Depending on how the next router handles it, it may or may not be preserved/honored.
I'm not familiar with your configuration on R3. Are you trying to apply different service policies to different DS0s on the T1? So if your T1 channels are not bonded together and you actually have separate 56/64k circuits, then yes you would treat them as separate interfaces. What you have should work, but you would need to modify your bandwidth statements to work with a 56k/64k circuit.
02-04-2015 02:44 PM
We are using Card HWIC-4T1/E1 on R3 to connect it to 3 Sites each site through T1 link, and Card HWIC-1DSU-T1 on the other sides.
All Routers will have the similar configuration as R1.
in other words:
R1 & R2 have HWIC-1DSU-T1 Connected to R3 which have HWIC-4T1/E1.
There are 4 other routers using T1 but it will be the same and 7 routers have Sattelite connection but that a different story.
Many Thanks
02-04-2015 12:25 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
If you're new to QoS, i.e. you're not real familiar with it, trying to actively manage traffic, could make things worse.
If your device supports it (and it might not with 15.x code), try just the fair-queue command on your serial interface.
i.e.:
interface s0/0/0
fair-queue
If you devices doesn't support that command, try:
policy-map YourName
class class-default
fair-queue
interface s0/0/0
service-policy output YourName
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: