Qos pre-classify

can ay body explain and what are
the effects of qos pre-classify command when apply to gre tunnel interface

When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the original packet
Headers and correctly classify the packets. so we are using QOS pre-classify command.
Regards,
Hariharan k

Similar Messages

How does QOS pre-classify realy work

Hi,
Does Qos pre-classify simply copy the precedence feild form the inside packet to the encapsulation header or does it apply the policy-map of the source physical interface?
I would say it only copy the feild but I have a GRE over IPsec tunnel mode that's behaving funny...

Ok, it works like I expected.
Now for my funny router...
I've got my main campus and a remote site connected by an encrypted GRE tunnel. Where do I place de QOS pre classify command, on the tunnel interface or on the crypto-map...or on both.
I've tried configuring it on both. On the policing policy-map on the outgoing interface, my match statement is an ACL trying to match on ESP traffic (the hit counter doesnt increase) and I've added a line for the un-encrypted trafic IPs and this one has hits. In the child policy, I've got hit with my IP precedende value in my voice class, that part is ok.
So, why can't I match on my permit ESP host A host B? And how is it possible to have match on the acl (permit ip any to remote site range)? The later should be encrypted when it hit the outbound policy map.

Qos pre-classify not classifying packets correctly.

This is a little 831 router (12.4.4T) with one private and one public interface connected to a 1000/256 ADSL circuit. There is a VPN to the Head Office with a GRE tunnel and EIGRP.
The Tunnels bandwidth is set to 1544 since there is a frame-relay backup and the service provider hasnt configured their parameters correctly, but this shouldnt affect the QoS.
Whats happening is that we can only see a very small amount of traffic being classified correctly and all other traffic seems to match the last (ip any any) access-list. The fact that the data is being classified seems to indicate that the qos pre-classify is working but we dont know why its not matching the correct data classes.
Any ideas would be greatly appreciated...
router#sh policy-map int eth1
Ethernet1
Service-policy output: soho01-vpn-256
Class-map: AC-CLASS-G1 (match-any)
14110 packets, 2414498 bytes
5 minute offered rate 9000 bps, drop rate 0 bps
Match: access-group name AC-G1
14110 packets, 2414498 bytes
5 minute rate 9000 bps
Queueing
Output Queue: Conversation 73
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1/60
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G2 (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G2
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 74
Bandwidth 8 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G3 (match-any)
12 packets, 968 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G3
12 packets, 968 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 75
Bandwidth 32 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 9/558
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G4 (match-any)
1621 packets, 266028 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G4
1621 packets, 266028 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 76
Bandwidth 64 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 19/1240
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G5 (match-any)
9336 packets, 693246 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name AC-G5
9336 packets, 693246 bytes
5 minute rate 1000 bps
Queueing
Output Queue: Conversation 77
Bandwidth 16 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 8248/511990
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G6 (match-any)
369616 packets, 79361172 bytes
5 minute offered rate 164000 bps, drop rate 0 bps
Match: access-group name AC-G6
369616 packets, 79361172 bytes
5 minute rate 164000 bps
Queueing
Output Queue: Conversation 78
Bandwidth 8 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 310/24424
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
4750 packets, 285000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Someone please correct me if I am wrong but if you add the 5 minute offered rate for all your classes you are classifying about 175K worth of traffic throughout your service policy. If I am reading correctly your circuit is 256 up 1M down.
From looking at your configuration it seems most of your traffic is matching the class named class AC-CLASS-G6. There is no access list defined for this class so essentially all traffic that hasn?t matched a previous class will match here. This explains why you?re not matching any traffic on the default class.
It is recommended to only assign queues for up to 75% of the available bandwidth. IOS determines what this 75% is based on the bandwidth statement. Right now you have queues defined for all but 2K of your available bandwidth which means traffic that doesn?t match any of your classes will be tail dropped during times of congestion. I assume you are intending to do this based on the max-reserved-bandwidth command and the missing access list.
When using qos-preclassify essentially what happens is the ToS bits are copied into the post gre or IPSEC IP header. In this case you are not matching based on DSCP marking you are matching on IP address so therefore when packets egress your E0 interface the post GRE or IPSEC IP header doesn?t have an address or type field that matches your class statements. If you were to mark traffic based on these classes with a DSCP marking (i.e. AF 31, 32, 33) at the inbound interface you could then copy these markings and provide the appropriate PHB on your egress interface E0.
HTH
RS

QoS - DSCP - Classifying the packets

Hi,
I have set up a practice lab in GNS3 for understanding "Classifying & Marking" DSCP values. The topology is like this:
(R2)---------f0/0(R1)f0/1----------(R3)
R2 has two loopback interfaces with IP addresses 172.1.2.100/25 for loopback0 & 172.1.2.200/25 for loopback1
R3 has tow loopback interfaces with IP addresses 172.1.3.100/25 for loopback0 & 172.1.3.200/25 for loopback1
When Telnet Session is initiated from R2's 172.1.2.100 to R3's 172.1.3.100, R1 should mark the egress IP packet out of fa0/1 with DSCP value of 10(AF11).
The truncated configuration is as follows:
ip access-list extended MyTraffic
permit ip 172.1.2.0 0.0.0.127 172.1.3.0 0.0.0.127
class-map match-all test3
match access-group name MyTraffic
match protocol telnet
policy-map p3
class test3
set ip dscp af11
interface FastEthernet0/1
ip address 10.1.3.1 255.255.255.128
duplex auto
speed auto
service-policy output p3
The configuration works all right, but when telnet session is initiated from R2's 172.1.2.200 to R3's 172.1.3.200, the egress IP Packet out of fa0/1
is found with the DSCP value of 110000 (Class selector 6), where it should be 000000 (Best Effort Delivery) isn't it..???
This is the first time I'm posting on forums, kindly help me in understanding this..!!

Hi - this forum is for Cisco Modeling Labs. Please refer to the GNS3 forum for answers to those questions.

Router Dead , when i applied QOS on virtual-temp interface for vpn !!

hi all ,
i have a simple brief topology below :
PSTN======(R1-7206)>F1=======F2>(R2-7604 catalyst)>>>F1=========Internet
i have two router
R2========>MLS 7604
R1======>cisco 7204
on R2 , Im doing matching to QOS by dscp , im matching acls ips from internet with dscp values :
here is CONFIG for matching :
Gateway7600#sh policy-map LLQX
Policy Map LLQX
    Class YOUTUBE
      set ip dscp af43
    Class FACEBOOKVIDEOS
      set ip dscp af33
    Class HTTP
      set dscp af23
    Class DNSQOS
      set dscp af13
    Class class-default
      set ip dscp af11
================
Gateway7600#sh class-map
Class Map match-all FACEBOOKVIDEOS (id 7)
   Match access-group name facebookvideos
Class Map match-all DNSQOS (id 8)
   Match access-group name dnsqos
Class Map match-all HTTP (id 6)
   Match access-group name browsing
Class Map match-any class-default (id 0)
   Match any
Class Map match-all YOUTUBE (id 5)
   Match access-group name youtube
Gateway7600#
=========================================================
on this router i applied this policy map on interfaxce F1 in direction
and here matching is well :
Gateway7600#sh policy-map interface gigabitEthernet 1/5 in
GigabitEthernet1/5
Service-policy input: LLQX
    class-map: rate-limit (match-all)
      Match: access-group name rate-limit
      police :
        4088000 bps 384000 limit 384000 extended limit
      Earl in slot 1 :
        139044930 bytes
        30 second offered rate 143032 bps
        aggregate-forwarded 134420937 bytes action: transmit
        exceeded 4623993 bytes action: drop
        aggregate-forward 22544 bps exceed 0 bps
    class-map: YOUTUBE (match-all)
      Match: access-group name youtube
      set dscp 38:
      Earl in slot 1 :
        132693939697 bytes
        30 second offered rate 212144928 bps
        aggregate-forwarded 132693939697 bytes
    class-map: FACEBOOKVIDEOS (match-all)
      Match: access-group name facebookvideos
      set dscp 30:
      Earl in slot 1 :
        10726758352 bytes
        30 second offered rate 20682720 bps
        aggregate-forwarded 10726758352 bytes
    class-map: HTTP (match-all)
      Match: access-group name browsing
      set dscp 22:
      Earl in slot 1 :
        56874058537 bytes
        30 second offered rate 92669832 bps
        aggregate-forwarded 56874058537 bytes
    class-map: DNSQOS (match-all)
      Match: access-group name dnsqos
      set dscp 14:
      Earl in slot 1 :
        160308954 bytes
        30 second offered rate 303552 bps
        aggregate-forwarded 160308954 bytes
    class-map: class-default (match-any)
      Match: any
      set dscp 10:
      Earl in slot 1 :
        67394864030 bytes
        30 second offered rate 126884864 bps
        aggregate-forwarded 67394864030 bytes
=================================================================================
now the problem is below
on router 7200 , it is LNS router connected with LAC roiuter for ADSL customers.
now here is config of policy map on 7200 router:
R11#sh policy-map
Policy Map MATCH_MARKS
    Class MATCH_YOUTUBE
      bandwidth 220000 (kbps)
    Class MATCH_FACEBOOKVIDEOS
      bandwidth 20000 (kbps)
    Class MATCH_HTTP
      bandwidth 100000 (kbps)
=========================================================
R1#sh class-map
Class Map match-all MATCH_FACEBOOKVIDEOS (id 2)
   Match ip dscp af33 (30)
Class Map match-all MATCH_HTTP (id 3)
   Match ip dscp af23 (22)
Class Map match-any class-default (id 0)
   Match any
Class Map match-all MATCH_YOUTUBE (id 1)
   Match ip dscp af43 (38)
==========================================================
here is virtual-template interface before i apply the QOS
R1#sh running-config interface virtual-template 1
Building configuration...
Current configuration : 352 bytes
interface Virtual-Template1
bandwidth 1000000
ip unnumbered Loopback0
ip tcp adjust-mss 1412
ip policy route-map private
no logging event link-status
qos pre-classify
peer default ip address pool bitsead1 bitsead2
ppp mtu adaptive
ppp authentication pap vpdn
ppp authorization vpdn
ppp accounting vpdn
max-reserved-bandwidth 90
end
=========================================
when i apply the command
(service-poliy output MATCH_MAKRS ) under virtual-template interface i have console logs :
Insufficient bandwidth 149760 kbps for the bandwidth guarantee (220000)
Insufficient bandwidth 149760 kbps for the bandwidth guarantee (220000)
Insufficient bandwidth 149760 kbps for the bandwidth guarantee (220000)
also i have
*Jul 9 22:28:38.242: Interface Virtual-Access2551 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.250: Interface Virtual-Access627 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.258: Interface Virtual-Access786 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.266: Interface Virtual-Access623 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.274: Interface Virtual-Access2559 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.282: Interface Virtual-Access2281 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:38.290: Interface Virtual-Access142 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 9 22:28:40.262: %SYS-2-INTSCHED: 'suspend' at level 3 -Process= "VTEMPLATE Background Mgr", ipl= 3, pid= 278, -Traceback= 0x756FF0z 0x3439C58z 0x2778D70z 0x2CACCD0z 0x2CC63E0z 0x2CC7FF8z 0x2CADC74z 0x2CBE058z 0x2CA0340z 0x2CA04F8z 0x2E0BB18z 0x2D23378z 0x2D1825Cz 0x2D18738z 0x2E66FE0z 0x2D971ACz
*Jul 9 22:28:40.262: %SYS-2-INTSCHED: 'suspend' at level 3 -Process= "VTEMPLATE Background Mgr", ipl= 3, pid= 278, -Traceback= 0x756FF0z 0x3439C58z 0x2778D70z 0x2CACD28z 0x2CC63E0z 0x2CC7FF8z 0x2CADC74z 0x2CBE058z 0x2CA0340z 0x2CA04F8z 0x2E0BB18z 0x2D23378z 0x2D1825Cz 0x2D18738z 0x2E66FE0z 0x2D971ACz
after i apply it ,
the cpu is 100 % and the router got down !!!
now
what is the problem ????
here is ios for 7200 router
R1#sh version
Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T7, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Tue 28-Feb-12 12:53 by prod_rel_team
ROM: System Bootstrap, Version 12.4(12.2r)T, RELEASE SOFTWARE (fc1)
Bras1 uptime is 13 weeks, 1 day, 9 hours, 24 minutes
System returned to ROM by reload at 16:24:51 GMT+3 Tue Jun 17 2003
System image file is "disk2:c7200p-adventerprisek9-mz.124-24.T7.bin"
Last reload reason: Reload Command
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
[email protected].
Cisco 7206VXR (NPE-G2) processor (revision A) with 917504K/65536K bytes of memory.
Processor board ID 36858624
MPC7448 CPU at 1666Mhz, Implementation 0, Rev 2.2
6 slot VXR midplane, Version 2.11
Last reset from power-on
PCI bus mb1 (Slots 1, 3 and 5) has a capacity of 600 bandwidth points.
Current configuration on bus mb1 has a total of 0 bandwidth points.
This configuration is within the PCI bus capacity and is supported.
PCI bus mb2 (Slots 2, 4 and 6) has a capacity of 600 bandwidth points.
Current configuration on bus mb2 has a total of 0 bandwidth points.
This configuration is within the PCI bus capacity and is supported.
Please refer to the following document "Cisco 7200 Series Port Adaptor
Hardware Configuration Guidelines" on Cisco.com <http://www.cisco.com>
for c7200 bandwidth points oversubscription and usage guidelines.
1 FastEthernet interface
3 Gigabit Ethernet interfaces
2045K bytes of NVRAM.
250880K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
==============================================================================
wish to Help ASAP
regards

hi ,
i did
the same issue ,
i did a TEST policymap that has 30 percent gurantee
but the same result!!!!!!!!!!!!!!!!
the router god down agian !
here is logs :
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.605: Interface Virtual-Access1896 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.797: Interface Virtual-Access1317 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.809: Interface Virtual-Access993 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.817: Interface Virtual-Access1699 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.981: Interface Virtual-Access254 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:33.993: Interface Virtual-Access687 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.001: Interface Virtual-Access35 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.009: Interface Virtual-Access160 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.017: Interface Virtual-Access1337 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.029: Interface Virtual-Access1670 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.037: Interface Virtual-Access1948 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.049: Interface Virtual-Access1669 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.109: Interface Virtual-Access1334 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.117: Interface Virtual-Access151 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.125: Interface Virtual-Access761 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.137: Interface Virtual-Access810 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.197: Interface Virtual-Access1522 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.237: Interface Virtual-Access1692 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.257: Interface Virtual-Access368 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.305: Interface Virtual-Access1758 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.317: Interface Virtual-Access2061 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.325: Interface Virtual-Access1203 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.337: Interface Virtual-Access188 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.345: Interface Virtual-Access1975 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.357: Interface Virtual-Access1172 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.509: Interface Virtual-Access1647 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.517: Interface Virtual-Access458 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.609: Interface Virtual-Access608 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.621: Interface Virtual-Access2128 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.633: Interface Virtual-Access1167 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.641: Interface Virtual-Access487 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.653: Interface Virtual-Access1793 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.665: Interface Virtual-Access2280 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.769: Interface Virtual-Access839 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.781: Interface Virtual-Access2311 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.793: Interface Virtual-Access1788 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.857: Interface Virtual-Access8 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.869: Interface Virtual-Access2243 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:34.881: Interface Virtual-Access580 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.057: Interface Virtual-Access6 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.065: Interface Virtual-Access1331 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.077: Interface Virtual-Access1235 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.177: Interface Virtual-Access1748 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.189: Interface Virtual-Access2262 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
*Jul 11 02:40:35.205: Interface Virtual-Access2136 max_reserved_bandwidth config will not
take effect on the queueing features configured via service-policy
i want to ask a question , could this be from IOS ????

Is QOS causing IPSEC replay errors?

Should there be a "service-policy" command on the outbound interface when using the "qos pre-classify" under the crypto map?
I have several point-to-point links that use both the qos pre-classify and the service-policy on the interface, and all those links generate %CRYPTO-4-PKT_REPLAY_ERR errors under load.
Other links that only encrypt are not getting the %CRYPTO-4-PKT_REPLAY_ERR errors under load.
The documentation for QOS and VPN: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087ac4.html
Only states to use the "qos pre-classify" ???
I believe the packets are going through the QOS process twice. Once before encryption, and then again afterward resulting in the resequencing.

Hi,
IPSec replay error can also be caused due to a smaller replay window size. You might wanna try in creasing the replay window size.
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455ad4.html
HTH,
-Kanishka

DMVPN QoS Configuration over sat link

Hi everyone, having one of those days where I cant seem to see the trees through the forest! Hopefully someone can point the way :)
We have a DMVPN setup with Hub & spoke, 3 remote sites over satellite but the remote sites internet traffic does not come over the vpn, it goes out via the ISP.
One particular site we've been having flooding and packet loss issues with has now been increased from 256k to a 512Kb Cir and the ISP has allowed a 1536 burst - this is where im confused most!
Almost all examples of QoS i see is to limit/restrict the flow to less than the provider CIR is allowing to avoid them dropping packets, so in this scenario, how do I make the most of the burst rate?
The DMVPN is currently set up with QoS policies via IP nhrp map groups, shaping the tunnel to 256k then child maps prioritizing mgmt, Skype etc. Although this seems like a great idea, im being led to believe I should just have qos pre-classify on the tunnel and set the policy-map on the Internet interface, but what I cant work out is how to prioritize or allocate most of the bandwidth to the tunnel for 'work related' purposes and limiting web browsing as currently it seems http/https traffic it taking all the bandwidth!
If I don't use the bandwidth command on the physical interface it appears it believes it has 100m, so I think I need to set it 512k but not sure how to utilize the burst.
Then im guessing I should use something like priority percent and shape average percent to prioritize tunnel traffic over http but does qos then need to be configured on the Hub somewhere as well?
If anyone has a similar setup and can provide example config that would be great.
Any assistance is greatly appreciated, please let me know if you want any configs/outputs.
Cheers,
Kev

Thanks for the reply Marcin, however that doesn't really answer my question(s).
I am fully aware of per tunnel qos as well as HQos, im just no expert in either!
I understand that per tunnel qos applies the settings to the tunnel, but anything Not going via the tunnel will not have any qos applied and that currently seems to be the issue, naughty streaming media and http/https traffic flooding the link!
Using Hqos will apply to the whole link, but it seems I need qos-pre classify on the tunnel to apply before it gets encrypted, or should I just prioritise all GRE so that all tunnel traffic gets priority?
Perhaps I just have my settings too low, http(s) traffic takes all it can leaving work related tunnel traffic, email etc starved of BW.
If anyone has any example configs of similar setups that would be much appreciated, its easier for me to reverse engineer! :)
cheers,
Kev

ME3800 qos-group

IN_POLICY:
I am trying to work on a qos setup where I want to use ip_acl to classify traffic and qos-group to (internally) mark incoming traffic on a layer-2 (trunk) interface (say INTF_IN).
[ This trunk interface is only carrying 1 vlan. I can see the policy picking up traffic on the basis of the defined ip_acl and the packets and byte counter incrementing. From this I am extracting that it is able to see the IP details coming over the trunk interface. ]
OUT_POLICY:
I then want to use that qos-group marking and prioritize traffic correspondingly, when the traffic goes out another layer-2 (access) interface (say INTF_OUT).
Topology:
These two layer-2 interfaces (INTF_IN and INTF_OUT) provide connectivity in between two routers.
Problem:
Classification on the out-going policy on INTF_OUT does not seem to to be picking up the qos-group classification, made by the incoming policy on INTF_IN.
[Here I am assuming that the internal coloring/marking of qos-group is visible to the outgoing interface. Software config guide seems to confirm this functionality as well and in fact suggests that as a way to get around the limitation where ip_acl cannot be used to classify traffic in the outgoing policy.]
Note:
1) As a separate test to confirm if the ME3800 is able to see the IP details on the incoming trunk interface (INTF_IN), I set up random DSCP values and could confirm that the traffic was getting marked. So this makes me be very sure that the ME3800 is actually picking up IP details from the trunk link/interface (INTF_IN).
2) I also tried to use Input-Interface with vlan but came to know that it is not supported on the incoming policy.

Hello Sourabh,
the key command for QoS in DMVPN is the
qos pre-classify
On the headend hub router, the mGRE tunnel interface is configured for qos pre-classify because the service policy is matching on the destination IP address in the original unencrypted IP header. The service policy, however, is applied to the outside interface, and the packets are encrypted when the QoS matching decision is invoked. Configuring qos pre-classify gives the service policy the ability to match on the clear text values.
interface Tunnel0
qos pre-classify
interface FastEthernet0/1.100
description Outside interface
This is from page 49 of the document in your link.
Normally, a DiffServ Model is used with some traffic classes based on the DSCP field with some well-known settings like EF for VoIP bearer channels (conversations)
I see that there is also an example based on destination address with ip access-lists. This can be helpful if your address plan allows to identify some services with some type of destinations
This directly maps to the routing table in a static way.
However, the scheduler you can use is elastic resources not used are redistributed between the other traffic classes.
So we can say there is not a strict need to be able to map to the routes in a "dynamic way".
If you look at the QoS command reference we can see that among the many parameters/options of the match commands there are no attribute of dynamic routes.
One could think to match a route tag or other route property but all the commands for setting and for matching a route tag are available only in route-maps and not within class-map objects.
So as far as I know QoS objects are oriented to traffic flows and you have a choice between using in-band markings like DSCP in DiffServ model or you can classify the flows based on the destination address but referencing them directly with ACLs
Hope to help
Giuseppe

QoS on the Cisco 3925

Dear Sirs.
I have two data centers and L3 VPN tunnel between them.
But I have only 100Mbps links to provider network.
Also I have two user groups:
1. High priority.
2. Normal priority.
I can use policing on the 3925 routers and limit maximum speed of the normal priority traffic (for example - 60Mbps) but if channel is free, it is not good.
I want to do, to normal priority traffic can use full bandwith (100Mbps) if no high priority traffic present. And if high priority traffic is present, normal priority traffic can use for example 50% of bandwith.
Also I can use QoS mechanism on the Nexus and 6500, because their SVI interface is default gateways for users workstation.
What best method for achieving my goal?
Thanks!

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 your interface is running at 100 Mbps, and your provider doesn't cap at a lower rate, a CBWFQ on you egress interface should do the trick.
On your tunnel, add qos pre-classify.
On your physical interface, add service-policy output YouNameIt.
Also add:
class-map match-all HiPriority
match ...
policy-map YouNameIt
class HiPriority
bandwidth percent 50
fair-queue
class class-default
bandwidth percent 50
fair-queue

DMVPN dual hub - qos preclasify limitation

Hi,
Reading the DMVPN design guide I found: "qos pre-classify is not supported in an architecture that implements two different headends for mGRE tunnels and VPN tunnels."
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf
Currently i am using a single headed DMVPN design with qos preclasify configured on the hub and voice works just perfect. My concern is with regards to implementing a secondary hub for redundancy. How will the qos be handled if the qos preclasify is not supported?
Thanks,

I'm not aware of any limiation if you're using two separate tunnel interfaces (as opposed to two NHRP mappings on a single tunnel interface).
Nor does:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html#GUID-182BD32F-56D4-479C-BFEF-B9738291E046
mention any.
If in doubt, please open a TAC case.

MPLS Qos

hi, i had a doubt.
our network is ip N/w and our service provider is C&W MPLS N/w , we had configured Qos in our routers and marking done by using DSCP for voice traffic and for IPSEC traffic we are using access-list , i know few thing like if our data want to cross MPLS network, DSCP to IP Precedence mapping will be done in Provider Edge router because MPLS Qos is based on MPLS exp bit 3 bit , but my doubt is how the ipsec data will be marked in PE router of C&w which we had mark it by using Access-list...

HI Hariharan, [Pls RATE if HELPS]
For the IPSec marking's to work please enable "qos pre-classify" command in CE Router.
When packets are encapsulated by encryption headers, QoS features are unable to examine the original packet headers and correctly classify the packets. Packets traveling across the same tunnel have the same encrypted headers, so the packets are treated identically if the physical interface is congested. With the Quality of Service for Virtual Private Networks (VPNs) feature, packets can now be classified before the encryption occur.
The qos pre-classify command enables the QoS for VPNs feature .
Hope this Helps. Please Rate if HELPS
Best Regards,
Guru Prasad R.

Effect of fragmentation in QOS

If the packets are fragmented in ingress and QOS is used, Does the QOS will be maintained after fragmentation. Like in GRE we have QOS pre classify to preserve the bits.
regards
shivlu jain

Hi Shivlu,
During every fragmentation, the IP header is preserved. So if a packet is fragmented, first the header is preserved, the payload is fragmented and the original IP header is applied to all fragmented packets. This way you will still keep the IP Precedence or DSCP values in the IP header.
This is true for GRE too.
However, packet fragmentation can spike up your router processor.
Link efficiency can be improved using Link Fragmentation Interleaving (LFI) by reducing serialization delay.
HTH.
Amit.

QoS PreClassify Command

Hi Guys,
I hope someone can help me here. Just revising some ONT stuff before exam and realised that i do not understand when the 'qos pre-classify' command is used when implementing QoS over VPNs.
Can someone clearly expalin when exactly you use the QoS Pre-Classisfy command and when not to use it.
Forever Greatful
Stephen
PS - i'm gonna post this over in 'Certifications' also for a bit more exposure.

If the before encapsulation packets have TOS settings that you want to "analyze" after the packets have been encapsulated with a VPN packet, then you can use pre-classify to copy the TOS values to the VPN packet's TOS. NB: The copied TOS can be overwritten, but that won't change the original packet's TOS.
E.g. you have VoIP packets marked with TOS values (perhaps a DSCP EF) so QoS can give them better treatment. If the original packet's TOS isn't copied to the VPN packet's TOS, QoS could no longer tell the difference between VoIP packets and FTP packets since they are now likely to be encrypted. (Pre-Classify is the command to cause the copy.)

IPSEC Tunnel Protection and per-tunnel QOS shaping doesnt do any shaping.

I am having a small brain implosion as to why this will not work.
I have tried the QOS policy on the tunnel interfaces and on the ATM interface. No shaping occurs. The interfaces transmit at their leisure.
Please can someone having a better day than me tell me what I am doing wrong?
Below is the relevant (and standard) config. without the service-policy command applied anywhere. Any help appreciated.
class-map match-any APPSERVERS
match access-group name TERMINALSERVERS
class-map match-any VOICE
match protocol sip
match protocol rtp
match dscp ef
policy-map QOSPOLICY
class VOICE
    priority 100
class APPSERVERS
    bandwidth percent 33
class class-default
    fair-queue 16
policy-map TUNNEL
class class-default
    shape average 350000
service-policy QOSPOLICY
interface Tunnel0
bandwidth 350
ip address 172.20.58.2 255.255.255.0
ip mtu 1420
load-interval 30
qos pre-classify
tunnel source Dialer0
tunnel destination X.X.X.X
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile IPSECPROFILE
interface Tunnel1
bandwidth 350
ip address 172.21.58.2 255.255.255.0
ip mtu 1420
load-interval 30
delay 58000
qos pre-classify
tunnel source Dialer0
tunnel destination Y.Y.Y.Y
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile IPSECPROFILE
interface ATM0/0/0
no ip address
load-interval 30
no atm ilmi-keepalive
interface ATM0/0/0.1 point-to-point
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
interface Dialer0
bandwidth 400
ip address negotiated
Thanks,
Paul

Hi mate,
This is an 1841 with 12.4 (20) but Ive tried it on 15.1 on a 1941 also. I get some measure of traffic reduction but I cannot fathom what it is actually doing.
In the lab with the 1841 and a flat shaper I get this:
policy-map SHAPE
class class-default
    shape average 600000
interface Tunnel0
bandwidth 700
service-policy output SHAPE
R1#sh policy-map int
Tunnel0
Service-policy output: SHAPE
    Class-map: class-default (match-any)
      18664 packets, 26423115 bytes
      30 second offered rate 452000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 45/0/0
      (pkts output/bytes output) 18659/27808530
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000
R1#sh policy-map int
Tunnel0
Service-policy output: SHAPE
    Class-map: class-default (match-any)
      19044 packets, 26964413 bytes
      30 second offered rate 451000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 45/0/0
      (pkts output/bytes output) 19039/28378426
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000
It just holds the data rate around 450 kbps. ??
Here are the types of results I get when the HQoS is applied to the Tunnel interface in the lab:
policy-map QOS
class IP2
    drop
class IP3
    priority 300
class class-default
policy-map TUNNEL
class class-default
    shape average 600000
service-policy QOS
interface Tunnel0
bandwidth 700
service-policy output TUNNEL
R1#sh policy-map int
Tunnel0
Service-policy output: TUNNEL
    Class-map: class-default (match-any)
      14843 packets, 20884436 bytes
      30 second offered rate 362000 bps, drop rate 75000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/3942/0
      (pkts output/bytes output) 14009/15858326
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000
      Service-policy : QOS
        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/3942/0
          (pkts output/bytes output) 6464/9540288
        Class-map: IP2 (match-all)
          385 packets, 533940 bytes
          30 second offered rate 28000 bps, drop rate 28000 bps
          Match: access-group 102
          drop
        Class-map: IP3 (match-all)
          10411 packets, 14628188 bytes
          30 second offered rate 191000 bps, drop rate 75000 bps
          Match: access-group 103
          Priority: 300 kbps, burst bytes 7500, b/w exceed drops: 3942
        Class-map: class-default (match-any)
          4047 packets, 5722308 bytes
          30 second offered rate 143000 bps, drop rate 0 bps
          Match: any
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 7545/6318038
This is after 10 minutes of running transfers to all endpoints to utilise the classes in the policy.
So why dont we see shaping that moves towards the configured values?
Thanks.

VPN GRE QOS tunnel how do i ?

i have two sites connected by VPN, i run a GRE tunnel between both so that eigrp works. This is fine for data but voip is poor.
I would like to prioritorise the voip traffic over the GRE tunnel but can't find any examples where this has been done.
Has anyone done this?

Mark the packets coming into the router at the LAN interafce. Add the command QOS pre-classify to the Tunnel interface and Crypto-map. At this point you can either enable Fair-queueing on the WAN interface or build a Service policy and add that to the WAN interface. Fair-queueing, by default will use the precedence bits to prioritize traffic. So the packets will already be in the correct order (prioritized) by the time they enter the tunnel. You can also use a service policy and guarantee bandwidth to certain classes. The policy also uses Fair-queue to prioritize the highest TOS bits first.
In the attached sample:
#Policy "LAN" would go on the LAN interface
interafce FAST0/0
service-policy input LAN
#Policy "QOS-128-Port" would go on the WAN interface
interface s0/0
service-policy output QOS-128-Port
*You cannot have fair-queue enabled on an inbound service policy

Qos pre-classify

Similar Messages

Maybe you are looking for