This series' Global Time post covered cascaded switches — two chips connected via a regular uplink port that, at most, keep their clocks in sync but otherwise remain independent. This post covers a different, often-confused concept: real switch stacking.
Like the internal switch fabric architecture, switch stacking is not a concept defined by the AUTOSAR SWS EthernetSwitchDriver. A full-text search for "stack"/ "stacking" in the SWS (R25-11) yields no hits outside of "software/protocol stack". This post therefore describes general networking hardware knowledge, not AUTOSAR normative text. |
Cascading vs. stacking
The decisive difference isn’t the cable — it’s the management and forwarding plane:
| Aspect | Cascading | Stacking |
|---|---|---|
FDB/ARL table | Each chip has its own | One shared table across all chips |
Management access | One access point per chip | One access point for the entire stack |
Clock synchronization | Optional ( | Usually an automatic part of the stacking protocol |
Connection | Regular uplink port | Dedicated stacking port(s), often a proprietary protocol, higher bandwidth than regular uplinks |
What architecturally makes a stack
A stack of multiple switch chips behaves externally like one single, larger switch:
Shared lookup table — a MAC address learned on one chip is immediately known on the other chip too; no separate per-chip learning needed
One management access point — a single IP/diagnostic address for the entire stack instead of one per chip
Consistent VLAN/priority configuration — changes apply to the whole stack, not just the chip where they were made
Dedicated stacking connections
Unlike a regular uplink, the stacking link is typically:
Higher bandwidth than regular ports, since it has to carry both payload traffic between the chips and control information (lookup synchronization, health checks)
Proprietary — often a vendor-specific protocol between two chips of the same family, rather than regular Ethernet
Effect on EthSwt_GetArlTable and SwitchIdx
From AUTOSAR’s point of view, the indexing scheme from
Part 1
(SwitchIdx + SwitchPortIdx) still applies — how a stack maps onto it
is purely a vendor decision that the SWS doesn’t prescribe:
One
SwitchIdxfor the entire stack — the most plausible option if the stack behaves externally like a single chip with more ports;EthSwt_GetArlTablethen returns a table spanning all physical chipsOne
SwitchIdxper physical chip — possible if the driver passes the stack’s internal split through transparently upstream; this then requires the driver to keep the shared FDB consistent across multipleEthSwt_GetArlTablecalls itself
Which option a specific MCAL vendor chooses is an implementation detail of the driver for that particular stacking-capable chip — the SWS doesn’t mandate anything here, because it doesn’t know the concept of a "stack" at all. |
Failure behavior
A stack has to be able to react to the failure of a member:
Failover — if one chip fails, the remaining chips should keep the stack running with a reduced port count, rather than failing entirely
Split-brain risk — if the stacking link itself fails (rather than a chip), both chip halves could believe they’re the active stack — a condition that has to be explicitly considered when selecting and configuring a stacking-capable chip
Use case in the vehicle
Stacking pays off when a single switch chip’s port count isn’t enough — for example, a large central zonal gateway that needs more ports than a single chip offers, but should still be configured and diagnosed as one logical management unit. For most zonal topologies with a modest port count per zone, the simpler cascading from Part 1 and the Global Time post is entirely sufficient.
Summary
| Aspect | Key takeaway |
|---|---|
Cascading vs. stacking | Cascading = independent chips, optionally synchronized clocks; stacking = one logical unit with a shared FDB/management plane |
AUTOSAR relevance | Not an AUTOSAR concept — pure vendor/networking-hardware territory, same as the switch fabric architecture post |
SwitchIdx mapping | Vendor decision: one |
Use case | Worthwhile when the required port count exceeds what a single chip offers |