6.4.4　Not-So-VRF说明

图6-7给出了一个NSV样例的配置方案。本节随后将对基本图注及NSV实现的步骤进行说明，它们包括：

·在核心/汇聚层实现NSV

·VRF选择替换方案

图　6-7　Not-So-VRF样例

·在WAN边缘/对等层实现NSV

前述小节中完成的NSV及WCCPv2配置（或代码）均基于图6-7描述的样例。

R32是图6-7所示NSV样例配置的主角，它担当了DC核心/汇聚层中租户E的multi-VRF路由，而在DC的WAN边缘/对等层又变成了租户F的PE路由。

说明：R32的IOS版本为12.4（15）T9，该版本不支持VRF感知的WCCPv2功能，但支持VRF选择方法。

说明：本例应用的DC WAN优化器为Riverbed VSH-2050-H虚拟Steelhead设备，该设备支持WCCPv2，分支WAN优化器（为了简便，未在图中标注）为Riverbed SH-1050-H Steelhead设备，以物理in-path方式部署在远程分支上。

在核心/汇聚层实现NSV

本小节为租户E实现了NSV方案，此时，R32作为了DC核心/汇聚层的multi-VRF路由。整个操作分6步完成：

·Step1　定义WCCP路由ID。显然这是最基础的一步，因为WCCPv2经常选择路由上数值最大loopback接口的IPv4地址（如果没有配置loopback，将选择物理接口的最大IPv4地址）作为路由ID。

·Step2　可选操作，如果loopback或接口的IPv4地址均未获取，则创建一个最大的IPv4 loopback。进行这一步操作时要小心，因为它有可能对路由上所实施的其他协议的属性产生影响（例如，路由中的路由ID或类似操作）。代码清单6.4说明了在R32上如何创建了loopback2并作为WCCP路由ID。

代码清单6.4　创建最大IVv4 loopback

说明：如果已有一个loopback存在，并且已经被当成WCCP路由ID使用，就不要再创建其他更大的IPv4 loopback地址。

·Step3　在最大IPv4 loopback（WCCP路由ID）上实现VRF选择机制，它是整个操作的关键所在。代码清单6.5解释了在VRF租户E的loopback2上配置VRF选择。“ip vrf receive”接口命令使得loopback2在VRF租户E的路由表内可见，不过调用该命令之前要求已经配置好了PBR。在NSV方案中，PBR路由映射的主要任务是确保“ip vrf receive”接口命令能够正确执行，因而用到的PBR路由映射实际上也是一个空白路由映射（即一个摆样子的路由映射）。

代码清单6.5　在租户E IPv4 loopback上应用VRF选择

说明：用户不需要去创建一个“摆样子”的路由映射，因为本来就是需要一个空的路由映射。

VRF选择方法配置好后，loopback将会在VRF租户E的路由表中出现。代码清单6.6说明了该如何使用“show ip route vrf Tenant-E”命令来验证此步骤是否成功。

代码清单6.6　验证VRF租户E路由表中的IPv4 loopback

代码清单6.7描述了连接到SH47（如图6-7所示）子接口上已完成的配置。

代码清单6.7　连接至租户E WAN优化器的VRF接口

说明：如果发生了某个WAN优化器的out-of-path部署存在VLAN不可得的情况，用户通常可以在其相应的802.1Q端口新创建一个。

·Step4　通过激活全局IPv4路由泄露完成NSV方案。全局IPv4路由表必须要知道如何访问WAN优化器，VRF可以通过全局IPv4路由泄露实现。从代码清单6.7可知，SH47位于子网10.2.47.0/24，借助VRF租户E的路由表，可以通过接口f1/0.247访问。代码清单6.8解释了一个全局IPv4静态路由如何将这一可达信息泄露给全局IPv4路由表。

代码清单6.8　租户E上的VRF到全局IPv4的路由泄露

代码清单6.9　验证VRF租户E子网已进入全局IPv4路由表

代码清单6.9调用了“show ip route”命令，对子网10.2.47.0/24是否已经能够通过全局IPv4路由表可达进行验证。

当以上4个步骤都完成后，最初只在全局IPv4路由表中可见的WCCP路由ID 10.2.100.32，现在在VRF租户E的路由表中也变得可见了，而最初只能通过VRF租户E的路由表访问的子网10.2.47.0/24，也可以通过全局IPv4访问。步骤1～4圆满完成了NSV替换策略，剩下的步骤（Step5和6）都属于标准WCCPv2配置设置了。

说明：VRF到全局IPv4的路由泄露对R32而言是本地完成，而且只在WCCP路由ID和SH47间实现，对租户E上现有的L3路径隔离不会造成影响。SH47是一个透明的代理，因此实际的源及目的地址仍然只能够通过VRF租户E上的路由表进行访问。

·Step5　涉及了R32上租户E（参见图6-7）的WCCPv2全局配置，代码清单6.10中的重定向ACL假设此时在服务器S5（10.2.50.88）上只有一个TCP应用在运行，租户E分支办公室上的远程客户（10.2.10.78）可以访问到S5。

代码清单6.10　租户E上R32的WCCPv2全局配置

·Step6　如代码清单6.11所示，在相应接口（f1/0.231和f1/0.235）入口配置WCCPv2。子接口f1/0.231是面向WAN接口（连接租户E的远程分支）而子接口f1/0.235是面向DC LAN的接口（连接服务器S5），两个接口都基于VRF。

代码清单6.11　在R32上为租户E配置WCCPv2接口

SH47（参见图6-7）的配置在代码清单6.12中进行了简单说明。配置了基本的逻辑in-path，对租户E上R32的WCCPv2配置进行了回应。

代码清单6.12　SH47上租户E的WCCPv2配置

VRF选择技术的替代方案

如果用户的IOS或其他软件版本不支持VRF选择技术该怎么办呢？有一个非正规的方法可以解决该问题，但又需依赖另一种直接连至multi-VRF/WCCPv2路由的L3设备。在图3-7中，这样的L3设备为路由CE30，它是直接连接至R32（multi-VRF/WCCPv2路由）的“boomerang”路由。

代码清单6.13重现了上一节步骤3（参见“在核心/汇聚层实现NSV”部分）的过程，但这次不再使用VRF选择技术。尽管这样会使步骤3变得非常麻烦，不过因此放松了对IOS版本的要求还是值得的，支持WCCPv2的IOS就够用了。步骤3的替代方案如下：

·Step3b　代码清单6.13解释了如何新创建一个R32上的子接口f1/0.99以打开一个到CE30的Ipv4“裂缝”（或一条直接的Ipv4路径），紧接着通过使用一个指向CE30（10.2.99.30）的VRF静态路由将WCCP路由ID访问信息泄露给VRF租户E的路由表，该静态路由也是子接口f1/0.99的下一跳。

代码清单6.13　VRF选择的替代配置

代码清单6.14展示了boomerang路由的配置，CE30的子接口（f0/0.99）配置与R32子接口（f1/0.99）配置相对应，Ipv4静态路由只简单地将任一目的地址为10.2.100.32（WCCP路由ID）的IP包返回至R32（10.2.99.32）。

代码清单6.14　Boomerang路由配置

说明：替代方案仅对步骤3进行变更（参见“在核心/汇聚层实现NSV”部分），其他步骤都保持不变，只有R32（参见代码清单6.13）和CE30（参见代码清单6.14）的配置会发生变化。

在WAN边缘/对等层实现NSV

本小节将探讨在WAN边缘/对等层，使用相同路由R32（参见图6-7）的VRF租户F上实现NSV方案。由于增加了VRF租户F，现在系统中包含了两个VRF：VRF租户E和VRF租户F。别忘了WCCPv2只能在全局Ipv4地址空间中访问它的路由ID,NSV替代方案也不会改变这一点，因此在multi-VRF环境中（例如VRF租户E和VRF租户F），位于不同VRF地址空间内支持WCCPv2的WAN优化器，彼此之间仍然需要共享WCCP路由ID，因此，要重写步骤3到6：

·Step3c　由于WCCP路由ID（loopback 2）已经在代码清单6.4中定义好了，我们可以直接跳至步骤3，就如上一节“在核心/汇聚层实现NSV”中所描述的一样，由于PBR路由图在前面租户E的VRF选择配置（参见代码清单6.5）中已经完成，租户F只需要执行“ip vrf receive”接口命令即可，如代码清单6.15所示。

代码清单6.15　在租户F的Ipv4 loopback上应用VRF选择技术

当配置好VRF选择机制后，相应的loopback应该出现在VRF租户F的路由表中。代码清单6.16解释了如何执行“show ip route vrf Tenant-F”命令来验证这一过程。

代码清单6.16　在VRF租户F路由表中验证Ipv4 loopback

代码清单6.17描述了连接至SH48（参见图6-7）子接口的当前配置。

代码清单6.17　连接至WAN优化器的VRF接口

·Step4c　由代码清单6.17可得，SH48位于子接口10.2.48.0/24，借助VRF租户F路由表信息，可知能通过接口f1/0.248访问到SH48。代码清单6.18（step 4c）对全局Ipv4静态路由将如何将这一可达信息泄露给全局Ipv4路由表进行了说明。

代码清单6.18　全局Ipv4路由VRF泄露给租户F

代码清单6.19将执行“show ip route”命令，来验证子网10.2.48.0/24是否已经能够通过全局Ipv4路由表可达。

代码清单6.19　验证VRF租户F子网是否已经在全局Ipv4路由表中

当步骤3c（参见代码清单6.15）和步骤4c（参见代码清单6.18）都完成后，WCCP路由ID10.2.100.32在租户F的路由表中已经可见了，而子网10.2.48.0/24现在也可以通过全局Ipv4路由表可达了。

·Step5c　代码清单6.20将探讨如何在R32上为租户F完成WCCPv2配置。在服务器S6（10.2.60.88）上运行的重定向ACL应用需要进行优化，租户F的远程办公室的远程客户（10.2.20.78）访问了它。

代码清单6.20　为R32上的租户F配置WCCPv2

说明：当IOS版本或其他系统版本不支持VRF感知的WCCPv2时，用户可以为不同的VRF配不同的服务组以作为备选方案。

·Step6c　如代码清单6.21所示，面向VRF的DC WAN接口f1/0.236已经实现了双向WCCPv2重定向，这种特殊的重定向被称为服务隔离模式。该模式主要应用于需要对到某一接口实行严格重定向的场合，使得只有经过该接口并且能与WCCP重定向ACL匹配成果的网络流量才会实施重定向操作。

代码清单6.21　为租户F在R32配置WCCPv2接口

如图6-7所示，R32在WAN边缘/对等层，相当于租户F的PE路由，R32的面向WAN接口，子接口f1/0.232连接到P32（某个P路由），并且打上了MPLS标签。在代码清单6.21中应用了服务隔离模式，因为我们希望在已经打上MPLS标签的R32f1/0.232上跳过实现WCCPv2重定向这一操作。

在代码清单6.21中，为了防止R32f1/0.236的出口重定向操作重新拦截前面已经完成重定向处理的网络流（重复重定向）而形成重定向回路，在连接到SH48（参见图6-7）的接口R32f1/0.248上执行了“ip wccp redirect exclude in”命令。

说明：由于出口重定向技术必须要执行路由器表检索以访问到界外接口而完成出口重定向，因此何时采用服务隔离模式或使用WCCP出口重定向在于哪种机制能得到更高效的CPU利用率。

代码清单6.22对SH48（参见图6-7）配置进行了简单说明。它启动了逻辑in-path，并与R32上租户F的WCCPv2配置相对应。

代码清单6.22　在SH48上为租户F配置WCCPv2

说明：对于支持重叠支持技术的NSV解决方案而言，在每一个VRF都配备了指定的WAN优化器。此时，附加虚拟设施的WAN优化器最为关键。要注意，WAN优化器必须拥有一个唯一的IP地址，因为这一信息将被泄露给全局IPv4路由地址表，并在各VRF（例如VRF租户E和VRF租户F）间共享这一路由信息。