QoS Pre-classify in GRE over IPsec VPNs

简介

​ 当数据包被封装和/或加密时，To S 字节默认复制到新的 IP 标头，但其他标头字段不再可用于分类和 QoS 操作。 QoS 预分类允许 IOS 在内存中创建数据包的临时副本以用于分类，以便可以在封装和/或加密后对最终数据包执行 QoS 操作。本示例将介绍可在 GRE over I Psec VPN 中配置 QoS 预分类的三种不同方式，每种方式的结果是什么，以及每种方式的行为方式为何。

下图显示了此示例的拓扑：

​ R1 有一个到 R3 的 GRE over IPsec 隧道，该隧道将用于加密每个 LAN 子网之间的流量。 R1 连接到“主机”，该主机将用于模拟 LAN 上的主机以生成流量以测试我们的 QoS 预分类配置。 R3 使用环回来模拟其 LAN。

每个路由器初始配置的相关部分如下所示：

不配置QoS Pre-classify

​ 由于我们将在 R1 的 S0/0 接口上测试预分类出站，因此除了我们生成的流量外，我们不希望从接口发送任何流量，以使结果更易于解释。为此，我们将在 R1 和 R3 上创建静态路由，以便不需要路由协议流量，并在 R1 上禁用创建流量的不必要服务。 R2 不需要任何静态路由来创建完全可达性，因为 R1 和 R3 的 LAN 子网之间的所有流量都将通过 VPN 发送，并发往 R1 或 R3 的 S0/0 接口，这些接口直接连接到 R2。

R1和R3的配置如下：

​ 接下来，让我们创建一个策略映射，用于测试我们的流量是如何分类的。当我们对其进行测试时，我们将生成从“主机”到 R3 环回的 ping。根据执行分类的时间，流量可以分类为 ICMP 流量、GRE 流量或 ESP 流量，因此我们将创建一个类来匹配每一个并将它们添加到策略映射中。最后，我们将在 R1 S0/0 出站启用策略映射。

​ 现在我们准备看看流量在三个场景中是如何分类的。第一个场景没有配置预分类——换句话说，默认行为。我们从“主机”ping R3 的环回并检查 R1 上策略映射中的分类结果：

​ 数据包已被归类为 ESP 流量，该类的 QoS 操作（如果我们已配置）将在最终传出数据包上执行。这在实际网络中通常不是很有用，因为我们不知道 ESP 数据包内的流量类型。这就是 QoS 预分类的用武之地。

Crypto map 配置 QoS Pre-classify

​ 我们将研究的第二种情况是在加密映射上配置 qos 预分类。我们在 R1 上配置它并清除计数器以从我们之前的示例中删除流量统计信息：

​ 这次数据包已被归类为 GRE 流量。同样，这可能不是很有用，因为我们不知道 GRE 数据包中封装了什么。

Tunnel 接口配置QoS Pre-classify

​ 然后再次启动从‘Host’到 R3 环回的 ping 并查看策略映射统计信息：

​ 这次流量被归类为 ICMP，如果我们为 ICMP 流量配置了任何 QoS 操作，它们将在离开路由器时对最终 ESP 数据包执行。

Qos Pre-classify 流程

在Tunnel接口上预分类

1. R1 接收从“主机”到 R3 环回的 ICMP 数据包。

2. R1 对数据包执行路由表查找，发现 3.3.3.0 /24 out interface Tunnel 0 作为最佳匹配，这是我们静态配置的.

3. R1 将数据包“发送”到tunnel 0 并找到配置的 qos pre-classify 命令。此时会创建 ICMP 数据包的临时副本以用于分类，如下所示：

在crypto map上预分类

1. R1 接收从“主机”到 R3 环回的 ICMP 数据包。
2. R1 对数据包执行路由表查找，发现 3.3.3.0 /24 out interface Tunnel 0 作为最佳匹配，这是我们静态配置的
3. R1 将数据包“发送”到tunnel 0。默认情况下保留的隧道模式是 gre ip。 R1 在 GRE 标头之外添加一个 GRE 标头和一个新的 IP 标头，使用在隧道接口上配置的隧道源地址和隧道目标地址作为新 IP 标头的源和目标。
4. R1 在新的目标地址 10.1.23.3 上执行路由表查找，并找到默认路由出接口 S0/0 作为最佳匹配（这也是静态配置的。
5. R1 发现在 S0/0 上配置了一个加密映射，并在加密映射中找到了 qos pre-classify 命令。此时会创建数据包的临时副本，用于分类，如下所示：

未配置预分类

1. R1 接收从“主机”到 R3 环回的 ICMP 数据包。
2. R1 对数据包执行路由表查找，发现 3.3.3.0 /24 out interface Tunnel 0 作为最佳匹配，这是我们静态配置的
3. R1 将数据包“发送”到tunnel 0。默认情况下保留的隧道模式是 gre ip。 R1 在 GRE 标头之外添加一个 GRE 标头和一个新的 IP 标头，使用在隧道接口上配置的隧道源地址和隧道目标地址作为新 IP 标头的源和目标。
4. R1 在新的目标地址 10.1.23.3 上执行路由表查找，并找到默认路由出接口 S0/0 作为最佳匹配（这也是静态配置的）。
5. R1 发现 S0/0 上配置了加密映射，并且 GRE 数据包与加密映射中的 ACL 匹配。 R1 在 ESP 头之外添加一个 ESP 头和一个新的 IP 头，如加密映射和 I Psec 转换集所指定。
6. R1对最终的ESP数据包进行分类，将数据包从S0/0发送出去，如下图：

要查看的最后一个场景是在不使用预分类的情况下在隧道接口而不是物理接口上配置服务策略：

然后我们再次从’Host’发起ping到R3的环回并查看统计信息：

​ 就像第三种场景一样，流量被归类为ICMP，甚至不需要预分类。但是，此服务策略仅适用于离开隧道 0 的流量，而前三个场景将适用于离开 S0/0、隧道 0 和配置为使用 S0/0 的任何其他隧道接口的流量。最终，选择在何处应用服务策略以及在何处或是否应用 QoS 预分类将取决于要实现的目标。