Nexus TCAM：ARP 抑制区为何需要两个切片

你为 ARP 抑制区定尺寸，数清设计所需的表项，找到一个空闲容量比它还多的区域，改动却依然放不下。并没有谁数错。你读到的预算以切片为单位，而按双倍宽度切分的特性在考虑任何表项之前就需要两个切片。

把分配看成单位数量固定的布局问题，算术就开始正常工作了。

区域拥有的是切片，不是表项

这些平台上的 TCAM 被划分为切片，每个切片恰好属于一个区域。区域以切片计量，而特性的宽度决定它至少要占用几个切片。单宽特性可以住在一个切片里；双宽特性则需要相邻的一对。

Concept	What it means when you plan
Slice	The indivisible unit; it belongs to one region and cannot be shared
Feature width	Single or double; a double-width feature must have two slices available
Logical entries	What the feature wants to store, which only matters after the slices are allocated

所以空闲切片并不是自动可用的容量。分布在两个独立切片上的两个单宽区域，不会合并成新的双宽区域所需的那一对，而那张显示总体上有大量未用空间的表，说的是一个你花不掉的池子。

收集确切的硬件型号、NX-OS 版本、当前各区域的宽度与大小，以及占用每个区域的特性。在任何改动之前完成这些，因为重新加载之后，先前的状态只是记忆，不是事实。

show version
show hardware capacity
show running-config | include hardware profile

命令名称因平台和版本而异，切分指南只列出适用于其自身硬件的命令。要读你实际得到的输出，而不是假定另一个型号的命令会产生同一张表。

然后写下每个区域的用途。VACL 区域之所以是过滤容量是有原因的，QoS 区域之所以存在，是因为有人为一项仍在生效的策略做了规划。把那些空间当作可回收空间而不加核对的计划，就是悄悄移除特性的计划。为你打算缩小的每个区域指定负责人，并在变更窗口之前把新尺寸告诉该负责人。

也要考虑方向。在平台把入向和出向分配耦合起来的地方，一侧的改动可能消耗另一侧的预算，而只统计入向表的计划看起来正确，却会在重新加载时失败。

缩小一个大的单宽区域会释放一个切片。如果你的目标区域需要一对，那个单独的切片可能毫无用处，除非它与另一个空闲切片相邻，而相邻是布局的属性，不是总量的属性。

正是在这里，人们会断定平台坏了或文档错了。两者都不对。分配模型完全按它所说的运作，错的是数了空闲空间，而不是数正确位置上的空闲切片。把布局画在纸上之后，可用的那一对要么存在要么不存在，而这比争论总量更容易与平台负责人沟通。

还有一个值得点名的版本陷阱。Cisco 的切分指南描述的是特定一代硬件，并明确说明其模型既不是 Cloud Scale 也不是 Silicon One。区域名称、默认大小乃至哪些特性是双宽，在其他地方都不同，所以关于某一平台上某个特定区域的警告，是关于该平台和该版本的证据，而不是通用配方。

每一次切分都是容量交换。缩小一个区域来为 ARP 抑制腾出空间会削减该区域原本保护的东西，后果可能要等到需要这块空间的策略被重新应用时才显现。

在窗口之前取得每个受影响特性负责人的书面同意。这不是官僚主义：最初规划 VACL 区域的人知道它在过滤什么，而腾出空间的人通常不知道。

改变硬件布局的变更要预期重新加载。有些平台要求，有些不需要，但在可能重新加载时不做维护窗口规划，正是路由变更变成中断的方式。围绕重新加载而不是围绕命令来安排窗口，并把旧配置文本保存在失去管理会话的控制台也能读到的地方。

通过平台支持的流程实施计划，然后验证你保留下来的功能，而不只是新增的那一个。新切分的区域能工作、而过滤却悄悄停止匹配，这比最初的故障更糟。

重新读取容量输出并与你记录的基线比较，然后测试促成这次改动的那个特性。Nexus TCAM 切分指南是这里描述的宽度与切片模型的参考，包括它覆盖哪一代硬件。