The ASIC is the powerhouse of the Nexus switch. The ASIC, or Application Specific Integrated Circuit, is a special purpose sillicon chip. The ASIC achieves high forwarding speeds as packets pass through the forwarding plane.

An ASIC in a general sense is not unique to networking. Many electronic devices use them for some specific purpose. In contrast, general processors, such as the CPU, perform many different tasks.

Different routers and switches will use ASICs in different ways. Even within the Nexus family, different ASICs achieve different goals. The Nexus 5000 series, for example, uses two different ASIC’s.

The Unified Port Controller (UPC) is the first N5K ASIC. Each UPC chip controls a small group of 4 or 8 ports, depending on whether the Nexus is a 5000 series or 5500 series. It handles processing packets upon ingress or egress for the port it manages. It also handles forwarding decisions between ports.

The second ASIC type is the Unified Crossbar Fabric (UCF). This is a bridge between many UPC’s, and manages packet switching and scheduling. This couples a UPC for the ingress port to a UPC for the egress port.

The Nexus switches use ASICs in cut-through switching mode. This achieves low latency and line-rate speeds. The 5548 has a latency of 2 microseconds. The Nexus switches transparently forward packets through the ASICs. This achieves high-performance in the data-plane.

The ASICs have a special place in forwarding packets. This means that querying them for packet drops is beneficial during troubleshooting.

It is good practice to spread etherchannel or LAG ports across different ASIC chips. For example, a four-port etherchannel may use two ports connected to UPC #1, and two on UPC #2.

This is to protect against ASIC failure. In the rare occasions when a port fails, there’s a good chance that it’s actually the ASIC that has failed. This may mean that a group of ports has or soon will fail. If all ports in an etherchannel are on a single failed ASIC, then the etherchannel will also fail.

Another reason to spread links across ASIC’s is because of oversubscription. Four 10G ports may have a theoretical capacity of 40G throughput. However, the ASIC that manages them may only have a throughput of 30G or 35G. This type of oversubscription works on the theory that not all ports will reach full capacity at once.

There’s good news for N5K owners though, as each 10G port is mapped at 12G to the ASIC. This means that the N5K is undersubscribed. This is to get line rate (one of the reasons for the high Nexus price tag). If you’re expecting ports to reach capacity, understand the internal architecture of your switch.

The show hardware internal carmel command lists the ASICs in a Nexus 5500. Different switches have different ASIC names, so the commands vary between models. For example, the Nexus 5000 series ASIC is ‘Gatos’ and the Nexus 5500 series is ‘Carmel‘.

N5500# show hardware internal carmel

Carmel ASIC Info:
idx|glb|sl|as|pts|state |kaddr   |uaddr   |bus:fn|irq(hex)|  MMmode[0:7]  |diag
---+---+--+--+---+------+--------+--------+------+--------+---------------+----
0  |0  |0 |0 |8  |ff    |fa800000|676cd000|f:0   |d2      |x:x:x:x:x:x:x:x|pass
1  |1  |0 |1 |8  |ff    |fa000000|66ecd000|11:0  |d1      |x:g:x:x:x:g:x:g|pass
2  |2  |0 |2 |8  |ff    |f9800000|666cd000|13:0  |d0      |x:x:x:x:x:x:x:x|pass
3  |3  |0 |3 |8  |ff    |f8000000|65ecd000|19:0  |cf      |g:x:g:g:g:g:g:g|pass
4  |4  |0 |4 |2  |ff    |f7800000|656cd000|1b:0  |ce      |-:-:-:-:s:s:-:-|pass
5  |8  |2 |0 |8  |ff    |f3000000|64ca4000|9:0   |cc      |x:x:x:x:x:x:x:x|pass
6  |9  |2 |1 |8  |ff    |f4000000|644a4000|8:0   |cb      |x:x:x:x:x:x:x:x|pass

The show hardware internal carmel all-ports command shows which port maps to each ASIC. This is useful when designing ASIC separation.

The name column is the internal port name, and the car column is the Carmel Number (the ASIC) that the port maps to. Mac is the port number in the ASIC.

Is it really necessary to go to all the effort of separating ASICs? It depends on where you are in the design lifecycle, and the level of risk you are willing to accept.

If you’re still in the design phase, it may be worth spending time thinking about ASIC separation. It won’t take a lot longer, as it’s just a matter of selecting appropriate ports for the etherchannel. If your switches are already in production, then it may not be worth going back and changing the design.

It’s a rare occurance to lose an ASIC, so the risk is quite low. If you’re in an industry with no room for error, it may be worth your time to consider ASIC separation. This eliminates another potential failure point.

Another way to mitigate this risk is to use virtual port-channels. vPC’s spread links across two different switches, and thus different ASICs. Keep in mind that the peer-link and keep-alive would still need ASIC separation.

The important factor is to consider your circumstances. You may have a switch such as the Nexus 93180 which only has one ASIC. This does not support ASIC separation. See the Cisco Live link below for more on this point.