Nexus TCAM: why an ARP-suppression region needs two slices

You size an ARP-suppression region, count the entries the design needs, find a region with more free capacity than that, and the change still does not fit. Nothing was miscounted. The budget you were reading is measured in slices, and a feature carved as double-width needs two of them before any entry is considered.

Treat the allocation as a layout problem with a fixed number of units, and the arithmetic starts to behave.

A region owns slices, not entries

TCAM on these platforms is divided into slices, and each slice belongs to exactly one region. Regions are sized in slices, and the feature's width determines how many slices it consumes at minimum. A single-width feature can live in one slice; a double-width feature needs a contiguous pair.

So a free slice is not automatically usable capacity. Two single-width regions sitting on separate slices do not combine into the pair a new double-width region requires, and the table showing plenty of unused space in total is telling you about a pool you cannot spend.

Record the baseline before you carve

Collect the exact hardware model, the NX-OS release, the current region widths and sizes, and the features consuming each region. Do this before any change, because after a reload the previous state is a memory rather than a fact.

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

Command names vary by platform and release, and the carving guide names the ones that apply to its own hardware. Read the output you actually get rather than assuming a command from a different model produces the same table.

Then write down what each region is for. A VACL region is filter capacity for a reason, and a QoS region exists because somebody sized it for a policy that is still in force. A plan that treats those as reclaimable space without checking is a plan to remove features quietly. Name an owner for every region you intend to shrink, and give that owner the new size before the window.

Account for direction as well. Where the platform couples ingress and egress allocation, a change on one side can consume budget on the other, and a plan that only counts the ingress table will look correct and fail on reload.

What freeing one large slice does not do

Shrinking a big single-width region frees one slice. If your target region needs a pair, that single slice may be useless unless it is adjacent to another free slice, and adjacency is a property of the layout rather than of the total.

This is the point where people conclude the platform is broken or that the documentation is wrong. Neither is true. The allocation model is doing exactly what it says, and the mistake was counting free space instead of counting free slices in the right positions. Once you have drawn the layout on paper, the available pair either exists or it does not, and that is a much easier conversation to have with the platform owner than an argument about totals.

There is also a version trap worth naming. The Cisco carving guide describes a specific generation of hardware and states plainly that its model is neither Cloud Scale nor Silicon One. Region names, default sizes and even which features are double-width differ elsewhere, so a warning about a specific region on one platform is evidence about that platform and release, not a universal recipe.

Changing a region is a feature change

Every carve is a capacity trade. Reducing a region to make room for ARP suppression reduces whatever that region was protecting, and the consequence may not appear until the policy that needs the space is reapplied.

Get the owner of each affected feature to agree in writing before the window. That is not bureaucracy: the person who sized the VACL region originally knows what it is filtering, and the person making room generally does not.

Expect a reload for changes that alter the hardware layout. Some platforms require it and some do not, but planning without a maintenance window when a reload is possible is how a routing change becomes an outage. Schedule the window around the reload rather than around the command, and keep the previous profile text somewhere you can read it from a console that has lost its management session.

Apply and verify against the baseline

Apply the plan through the platform's supported process, then verify the functions you preserved, not only the one you added. A newly carved region that works while filtering silently stopped matching is a worse outcome than the original failure.

Re-read the capacity output and compare it to the baseline you recorded, then test the feature that motivated the change. The Nexus TCAM carving guide is the reference for the width and slice model described here, including which hardware generation it covers.