摘要

  • Meraki 的历史教学算例加入两份一年期交换机许可后，共同到期日从2017年4月16日变成3月14日，提前33天。
  • Co-Term 按许可数量、期间和种类权重计算共同日期。撤走设备不会退回许可时间；较少数量的续期密钥还会降低可用设备上限。

采购单上多了两份许可，日历上却少了33天。Meraki 把这笔看起来有点反常的账写进了自己的技术文档。新设备获得覆盖，原有许可池的共同到期日同时向前移动。购买数量与续费时间，就这样朝两个方向走了。

官方计算说明的示例 C把操作日期设在2015年3月31日。当时，一个组织还剩747天许可时间，随后加入两台 MS42P 交换机的一年期许可。文档给出的结果是剩余714天，到期日由2017年4月16日改为2017年3月14日。

这是厂商的历史教学算例。新增许可的365天，比原池剩余的747天短。两种时间被合到同一终点，较短的新期间拉低了共同期限。读懂这件事，靠的首先是看清许可进入哪一本账。

分公司的购买，进了全组织的时间池

Co-Termination 规则为一个 Meraki 组织的许可设定共同到期日。这里的组织是服务中的管理分组。原有许可与新增许可一起进入加权计算。

计算既看数量和期间，也看许可种类。详细说明采用相应许可的一年标价作为权重，称为 Base Price。它承担的是时间计算中的权重作用。采购人员谈下来的实际成交金额，留在采购账上；算共同日期时，文档用的是这套标价权重。

为新增设备加入许可，时间增量的起点是“新买期间减去原有剩余期间”。新买一年，池里原来还剩两年多，这一步就会出现负值。再按许可权重分摊，得到新的共同日期。官方算例中的33天，展示的正是这个方向。

对分公司而言，两份一年期许可解决了眼前的设备需求。对整个管理分组而言，这次购买又给共同日历放进了一组较短的时间。若审批只看新设备数量和采购金额，其他站点一起承担的日期变化就容易从表格边上漏过去。

设备搬进仓库，日历照走

这套账在撤机时同样值得细看。Meraki 明确说明，到期日取决于许可上限，而非当前设备数量。把设备从网络或组织移除，不会改变共同到期日。

当前设备数，统计的是已经加入组织内网络的设备。只放在库存、尚未加入网络的设备，不计入这个数量。许可上限则来自适用的有效许可，表示这套许可覆盖的容量。

两者之间可能出现数量超限：网络里仍有五台设备，许可却只覆盖两台。撤下多余设备可以解决这种超限。时间账仍由许可池决定，仓库多收三台旧设备，不会自动给共同日期补回几天。

同样，晚登记许可也省不出时间。文档说明，许可在处理时就开始消耗期间；等到后来才在 Dashboard 添加，并不能推迟起算。设备安装可以等装修、等机柜、等开业，已经开始跑的许可时间照自己的规则前进。

“续期”两个字，保不住原来的数量

把许可用于新增设备，与给组织续期，是两种操作。详细说明对单纯续期采用新买期间的全部时间；对新增设备，则把原有剩余期间纳入增量计算。应用密钥时选哪一种操作，本身就是采购结果的一部分。

“Renew my Dashboard license”还有一项直接效果：许可设备数量改为新密钥所载的数量。规则页给出的例子是，一个原有五台接入点的组织，使用覆盖两台接入点的三年期密钥续期。已有剩余时间保留；假如五台仍在使用，就会有三台超过新上限。

于是，一份写着三年期的续购单，可以同时带来较少的设备容量。企业若本来就计划把网络缩到两台，需要把另外三台退出网络的时间与密钥应用时间衔接起来。采购上的数量削减，会对运维提出一个实际交付要求。

Co-Term 规则为超额或到期提供30天宽限期。文档随后描述，许可状态持续未纠正会导致组织停用，相关示例包括管理和流量转发丧失。数量超额可以通过移除网络内多余设备或补足许可解决；活跃设备的覆盖到期，则需要补上新的许可时间。

当前通用许可问答区分了 Co-Term 与 Subscription，并把旧的 PDL 留给既有用户。一个组织使用一种许可模型。看这套共同日历之前，先确认自己所用的模型，才知道应当拿哪套规则核对。

要预测某个真实组织的具体新日期，还缺它的剩余期间、各类许可上限和权重、新密钥数量与期间，以及准备执行的操作；这些数据会决定实际结果。厂商自己的历史例子已经足够把采购问题问完整：这次多覆盖几台设备，操作之后，全组织又会在哪一天一起到期？