配置干净地提交,接口也起来了,隧道却仍然拒绝建立。日志里没有任何一句话说这个平台做不到;它只是没有去做。在 Junos 上,IPsec 是一项服务,需要机箱、服务硬件或软件路径与发行版的特定组合才能完成,而功能页面描述的是软件能力,不是你手上这台设备。这个元组必须逐项核对,因为提交结果只能证明解析器。

数据包实际走向何处

被 IPsec 选中的流量必须到达负责加密它的组件。在带有服务模块的平台上,选中的流会被引导到该模块,之后再回到转发路径。如果模块缺失、容量不足或者没有绑定到接口,配置依然存在,却不会有任何一个数据包被处理。提交输出里没有任何内容能把这种情况与正常状态区分开。

软件承载的实现把这项工作留在路由引擎上,或者放在内联硬件里,两者的资源上限差别很大。配置里能看到一条隧道,并不能告诉你究竟是哪条路径在真正承载它。

元组的五个部分

在读任何推荐之前,先把组合写下来,因为其中一个部分就可能让其余部分失效。三年前支持过某项服务的部件编号,说明不了这台机箱里现在的板卡和发行版。把下面几行当作清单来读,然后填入配置无法告诉你的那些取值。

PartWhat to recordWhere it fails quietly
Chassis and service hardwareModel plus the installed PIC, MPC or MICCard absent or not bound to the interface
ImplementationServices card, inline or software pathConfiguration accepted, no processing
ReleaseExact Junos versionThe feature arrives in a later build
Address families and modeOuter and inner family, tunnel mode, peer authenticationHalf the traffic silently unprotected
Entitlement and capacityLicence state and the workload profileCeiling reached only under load

地址族和工作负载是两行最容易被跳过的内容,而这两项检查成本很低、事后发现代价很高。要从设备上读元组,而不是从表格里读,因为配置报告的是你要求的东西,而不是实际安装的东西。两条命令就能覆盖其中大部分:show chassis hardware 给出真正插在槽位上的板卡,show version 给出确切的发行版。两者都不取决于配置是否正确,这正是关键所在。

show chassis hardware
show version

发行版门槛是真实门槛

发行版细节不是形式问题。Juniper 的 IPsec 概览 把多业务卡的 AES-GCM 支持定在 Junos 17.3R1,FIPS 模式则从 17.4R1 开始。因此同一个功能有两个门槛,取决于平台以何种方式运行,而你运行的模式决定哪一个适用。先核对模式,再核对功能列表。

要读的是你实际安装的那个确切版本的发行说明,而不是文档里最新的那一个。在更晚的构建里才出现的能力,不能假设在更早的构建里已经存在;为某一种板卡写的说明也不会自动适用于另一种。把发行说明里的那一行抄进设计记录,让这个结论自带出处,因为针对某个平台系列写的支持声明,并不是关于你运行的模式或者你手上板卡的声明。

容量取决于工作负载,而不是宣传数字

不带测量条件的宣传吞吐量只是一个营销数字。小包每比特的开销远高于大包,并发关联会占用内存,与这张卡共享的每一项其他服务都会减少剩下的余量。

按你预期会出现的流量来估算:典型与最坏情况下的包长、对端数量,以及这张卡是否还终结 NAT 或其他服务。然后为某一天某条路径承载的负载超过设计假设留出余量。假设硬件始终空闲的容量规划只是愿望,不是规划。如果这个数字对商业论证很重要,就在设备上以有代表性的负载测一次,并把这次测量结果与设计放在一起。

先写记录,再写设计

对设计需要的每一项能力,把平台参考、与发行版匹配的文档以及任何尚未解决的限制放在同一个地方。当元组中某一行不满足时,应当比对另一台已获批的网关,而不是围绕一份过时的采购清单重建设计。记录应当写明由哪个确切的系统承担这项工作,以及在什么限制之下。

只有在那之后才去核对对端,因为与远端的协议兼容性是下一个问题,绝不能替代本地支持。即使对端在提议上达成一致,也帮不了一台从不加密数据包的机箱。

相关文章