I have a problem with my QoS policy, or I should better say, I have a problem understanding how my policy manages to achieve what ask of it without dropping a packet!
Here is the scenario:
We have an GRE point-to-point Tunnel, Crypto-Map protected with IPsec, and we shape traffic going out of it to 10Mbps. We use HQF so I have a parent shaping policy applied outgoing on the tunnel interface and a child policy with 5 classes (default included). The path towards the other end of the tunnel can handle 100Mbps all the way, and CPUs on the edge routers are monitored and within normal operation levels, so there is nothing other than my shaper limiting traffic to 10Mbps. Policy Classes “A”, “C”, “D”, “Default” are set with “queue-limit 234” (Class “B” gets the default 64 packets) therefore the sum of the max-queues of all 5 classes equals less than 1000 packets which is the default “max-queue” value on the physical interface that sources the tunnel. Ping shows RTT through the Tunnel is around 12msec.
This is how I test my policy:
I FTP a large ISO file to a host on the other side of the tunnel. This first FTP matches class "C" for example and it exceeds the classe's assigned "weight". I notice that tunnel outgoing traffic gets shaped to 10 Mbps. “show policy-map” shows a few packets queued but no drops… With the tunnel still being full (10Mbps) I start a second FTP that matches Class “D”, large ISO file again, and after a while “show policy-map” shows that the two classes are traversed by traffic in proportion to the “weights” assigned to them with the bandwidth command. Tunnel traffic remains 10Mbps and still a few packets in queue but no drops… Even more, “normal” network traffic matching the other classes (not exceeding their assigned “weights”) still went through without a problem.
How does my policy manage to shape traffic to the requested size without dropping packets?
My (obviously wrong) theory:
What I would expect was that when TCP exceeded the available BW of a class, packets would pile up on the class queue until it got full and start tail-dropping. Then TCP eventually would have to retransmit the unacknowledged data and lower the window size until it tries to enlarge it again after a while and we end up with tail-drop like before and here we go again, as a result shaping traffic to 10Mpbs.
But where are my tail-drops??? What am I missing here?
The router is a Cisco 2821 with IOS c2800nm-advsecurityk9-mz.151-4.M12a. Here is a piece of my config:
class-map match-any A match access-group name ACL_A class-map match-any B match access-group name ACL_B class-map match-any C match access-group name ACL_C class-map match-any D match access-group name ACL_D ! ! policy-map CHILD class A bandwidth percent 5 queue-limit 234 packets class B bandwidth percent 5 class C bandwidth percent 40 queue-limit 234 packets class D bandwidth percent 40 queue-limit 234 packets class class-default queue-limit 234 packets bandwidth percent 10 ! policy-map PARENT class class-default shape average 10000000 service-policy CHILD ! ! interface Tunnel1 bandwidth 10000 ip address x.x.x.x 255.255.255.252 ip mtu 1400 ip flow ingress ip flow egress load-interval 30 qos pre-classify keepalive 3 3 tunnel source GigabitEthernet0/1.4042 tunnel destination z.z.z.z tunnel path-mtu-discovery service-policy output PARENT ! ! interface GigabitEthernet0/1 no ip address load-interval 30 duplex auto speed auto ! ! interface GigabitEthernet0/1.4042 bandwidth 10000 encapsulation dot1Q 4042 ip address w.w.w.w 255.255.255.252 crypto map XXXZZZ !