弈心：从事计算机网络工作十一年（新加坡7年，沙特4年），2013年考取CCIE，在新加坡先后任职于AT&T，新加坡交通部，苹果，Equinix，苏格兰皇家银行等大型企业、银行和政府部门
目前供职于“世界第一土豪大学“沙特阿卜杜拉国王科技大学（KAUST），担任Senior Network Engineer，为KAUST校史上第一位也是唯一一位华人IT部门高级职员
2019年6月在知乎发布了华语圈第一本专门为编程零基础的网络工程师量身打造的Python教程《网络工程师的Python之路》
疫情期间什么最重要？当然是居家隔离和远程办公
远程办公什么最重要？当然是各种VPN网络的速度和稳定性了
今天借这个机会来讲下在IPSec VPN里配置QoS需要注意的地方
背景：某公司ABC有site-1和site-2两块办公地点，两地之间的网络是由基于VTI的IPSec VPN隧道网络组成
最近Site-1和site-2之间各添加了一台重要的服务器，site-1这边的服务器IP是192.168.1.1（由R1的Lo0口模拟)，site-2的服务器IP为192.168.5.5（由R2的Lo0口模拟)，因为两台服务器的重要性，公司ABC需要保证它们之间的流量拥有最高优先权和带宽分配
作为公司ABC网工的你决定用LLQ(Low Latency Queueing)来满足需求，并在R2上分别按部就班地配置了LLQ所需要的ACL, class-map 以及policy-map，如下图所示：

问题：在R2的S0/0（23.23.23.2)口上敲上service-policy output LLQ引用前面的LLQ配置后，以为大功告成的你却发现没有起到预期的作用

从R2上ping 192.168.5.5 source 192.168.1.1 repeat 100后，在R2上查看policy-map，发现从192.168.1.1到192.168.5.5的流量并没有匹配到IMPORTANT_TRAFFIC这个class-map，所有流量都走的是class-default这个class-map

请问为什么？怎么解决？解析：在采用隧道模式的IPSEC中，每个IP数据报都有两个IP报头：外部IP报头和内部IP报头
这里ACL匹配了192.168.1.1到192.168.5.5的流量，也就是内部IP报头，但是policy-map匹配的却是外部IP报头，所以很多人会想到policy-map不应该配在s0/0这个口，而是该配在tun 0口下，思路没问题，但是在tun0口敲上service-policy output LLQ后又会到下面这个Tunnel端口无法支持CBWFQ的问题：

解法：要解决这个问题，有两种方法，分述如下：解法1：QoS Pre-Classify第一种解法最简单，也是我推荐的方法，即在隧道口上开启QoS Pre-Classify
QoS Pre-Classify的原理是在路由器对数据包做加密前，让路由器将内部IP报头拷贝一份，并将其临时保存在内存中
然后路由器以该内部IP报头作为参考，在随后的优先序列、分类等各种QOS操作中使用
具体的配置方法也很简单：在s0/0口上调用policy-map的基础上，在tun 0口上开启QoS Pre-Classify即可

另外，除了在tunnel口上开启QoS pre-classify，我们也可以在crypto-map里调用QoS pre-classify，效果一样，有兴趣的可以自己实验一遍，这里就不演示了
解法2：Hierarchical Queueing Framework (HQF)除了QoS pre-classify外，还可以使用Hierarchical Queueing Framework (基于层次的队列框架)来解决这个问题
听说过HQF这个术语的人不多，其原理其实很简单，就是在前面已有的policy-map LLQ的基础上，再写一个policy-map(这里我们在R2上再配置一个policy-map，将其命名为HQF)，然后再将第一个policy-map（也就是policy-map LLQ）通过service-policy命令镶嵌调用在第二个policy-map里（也就是policy-map HFQ），然后再将第二个policy-map直接在Tunnel口上调用即可（无需再碰s0/0物理端口）：

这里需要注意的是，HQF必须配置流量整形(shaping)才能生效，所以配置里多了一个shape average 1544000，关于流量整形(shaping)的话题不是这篇文章讨论的重点，这里大家知道即可