I’ve done something like three million Cisco UCS installations. I treat them as something like performance art these days, going through a polished routine of technical facts and banter. One could say I’ve done too many. One could say that often, and loudly.
Anyway, every now and then I’ll have a customer interrupt the flow with a Good Question. I love when that happens, as it usually means I’m about to learn something new. Recently, a network guy—the network guys always start trouble—asked me about the port-to-ASIC mapping in a 6200-series Fabric Interconnect. And I realized I really didn’t know. Cursory Googling didn’t turn up a concrete answer. I reasoned aloud that since the Fabric Interconnects share the same hardware guts as the Nexus 5K switchest the internal plumbing was likely the same, and was able to turn up an answer for 5596 port mappings. The customer wasn’t terribly satisfied with this answer, as his 6296s differed in product number and, in fact, color from their Nexus switch cousins.
Some digging turned up an NX-OS command that would display these mappings on a 5500, and it turns out the same command works on the Fabric Interconnects. For a 6200-series FI, connect to the CLI of your FI, enter NX-OS configuration mode (connect nxos), and enter the command “show hardware internal carmel all-ports.” You’ll see something like the following:
The first column indicates the FI port, and the third indicates the internal ASIC (or Unified Port Controller) number. So, on a 6200-series FI, each group of eight contiguous ports is backed by an individual ASIC.
A similar command works on the older 6100-series FIs—“show hardware internal gatos all-ports.” The difference reflects the different ASIC codenames between platforms. Output should be similar to the following:
Again, first column is port number, third is ASIC number. On a 6100-series FI, each block of four ports is backed by an individual ASIC.
Now, why did the network guy want this information? He was interested in potentially spreading port assignments across ASICs, as they had recently been bitten by an issue where an ASIC failed. This concern was alleviated after talking through FI failure scenarios, as ultimately the OCD-appeal of having neat, contiguous blocks of uplinks won out over protecting against the profoundly unlikely event of the same ASIC failing on two FIs.