我的 QoS 策略有问题，或者我应该说，我在理解我的策略如何在不丢包的情况下设法实现它的要求时遇到了问题！
这是场景：
我们有一个 GRE 点对点隧道、受 IPsec 保护的加密映射，我们将流出它的流量调整为 10Mbps。我们使用 HQF，因此我在隧道接口上应用了传出的父整形策略和具有 5 个类（默认包括）的子策略。通往隧道另一端的路径可以一直处理 100Mbps，并且边缘路由器上的 CPU 受到监控并且处于正常操作级别，因此除了我的整形器将流量限制为 10Mbps 之外别无他物。策略类“A”、“C”、“D”、“默认”设置为“队列限制 234”（“B”类获取默认 64 个数据包）因此所有 5 个类的最大队列总和等于少于 1000 个数据包，这是提供隧道的物理接口上的默认“最大队列”值。Ping 显示通过隧道的 RTT 大约为 12 毫秒。
这是我测试政策的方式：
我将一个大型 ISO 文件通过 FTP 传输到隧道另一端的主机。例如，第一个 FTP 匹配类“C”，并且它超过了类分配的“权重”。我注意到隧道传出流量被调整为 10 Mbps。“show policy-map”显示了一些排队的数据包但没有丢包......隧道仍然满（10Mbps）我启动了第二个与“D”类匹配的FTP，再次是大的ISO文件，过了一会儿“show policy-map ” 显示这两个类别的流量与使用带宽命令分配给它们的“权重”成比例。隧道流量保持 10Mbps，队列中仍有一些数据包但没有丢包……更重要的是，与其他类别匹配的“正常”网络流量（不超过其分配的“权重”）仍然没有问题。
问题：
我的策略如何在不丢包的情况下将流量调整为请求的大小？
我的（显然是错误的）理论：
我所期望的是，当 TCP 超过类的可用 BW 时，数据包会堆积在类队列中，直到它满了并开始尾部丢弃。然后 TCP 最终将不得不重新传输未确认的数据并降低窗口大小，直到它尝试在一段时间后再次放大它，我们最终会像以前一样出现尾部丢弃，然后我们又来了，结果将流量整形为 10Mpbs。
但是我的尾巴在哪里？？？我在这里错过了什么？
路由器是带有 IOS c2800nm-advsecurityk9-mz.151-4.M12a 的 Cisco 2821。这是我的配置的一部分：
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
!
