QoS marking problem

Question

I have a trouble to implement dynamic QoS between two sites (Site A, and site B) across low speed WAN link (512k). On each site I have Cisco 1921 router. Most important app is Oracle. Because of slow speed WAN links, I want to avoid exact bandwith reservation for Oracle. I only reserve 5% bandwith for network control(icmp, ssh, telnet...) and want configure next Qos scenario:
1. If Oracle traffic exist on a network, it must have 70% of link speed guaranteed, all other apps (e.g mail, file share, ftp) use rest of the bandwith.
2. If there isn't Oracle traffic on a network, all other apps can use all available bandwith.
Issue descrtption:
I used all Cisco guides, but when I implemented this on production it simply didn't work. There is no any significant improvement after implementing this (when I start network file sharing accross wan link, Oracle becomes etremly slow.). Do anyone hadsimilar problem?
Here is configuration wich I trying to implement:
ACL-s and class-maps used to mark traffic:
access-list 119 remark ###QoS-MGMT###
access-list 119 permit tcp any any eq 22
access-list 119 permit tcp any any eq telnet
access-list 119 permit icmp any any
access-list 120 remark ###QoS-DB_ORA###
access-list 120 permit ip any host 10.100.40.30
access-list 120 permit tcp any any eq 1521
class-map match-any Oracle
match access-group 120
class-map match-any Mgmt_Traffic
match access-group 119
policy-map LAN
class Mgmt_Traffic
  set dscp 7
class Oracle
  set dscp 5
class class-default
  set dscp default
policy-map WAN
class Oracle
  priority percent 70
class Mgmt_Traffic
  priority percent 5
Implementation of this policy maps (both sites are identical):
interface FastEthernet0/0
description WAN
bandwidth 512
service-policy output WAN
interface FastEthernet0/1
description LAN
bandwidth 512
service-policy input LAN
Thanx for help!

Answer 1

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
Any other idea?
Yes, several.
First, we might confirm whether CBWFQ is working as configured.  To be precise, when TAC "showed me" shaped/child CBWFQ worked correctly under 15.x, it was a specific 15.x something (I'll have to find what they actually used) and I took their word for it, i.e. I didn't actually confirm it operated correctly as our internal IOS usage standards don't (yet) allow 15.x code.
Easiest way to confirm correct operation, use a traffic generator to push 1 Mbps to the two classes and see if overall rate is limited to 512 Mbps and bandwidth proportions are 70/30.
I note you wrote you did try the 2nd LLQ policy, correct?  Well, it too should be tested to insure your rate is limited to 512 and 70/30 bandwidth split.  (You can also try a variation of the last w/o any FQ.)
If above tests confirm correct operation, then there are numerous reasons why you're not obtaining the performance you expect.  For example, your WAN vendor could have a misconfiguration or even a technical issue they're unaware of (my experience the former is rare, say less than 1% of the time, the latter is very, very rare but I've seen such too [e.g. 3 months of complaining to a tier one vendor, Ethernet performance not quite right, they finally found cause - buggy firmware on one of their line cards]); or the nature of your traffic you're testing with causes "unexpected behavior" (e.g. UDP vs. TCP?); or L2 rates vs. L3 rates (touched on that in my prior post); application sensitivity (e.g. don't know about Oracle, but some earlier version of SAP were extremely "fragile"); or etc.
So, first confirm CBWFQ is working as it should.  If not, you'll need to work with TAC.  If it's working correctly, we can start to eliminate other possible issues.