On 12/26/24 14:46, Randy Bush wrote:
In a distributed fabric, where is the traditional control plane run?
Say I've got 100 BGP sessions of upstream,peer, and downstream across
ten routers. Is each pizza box grinding this out on its own, or is the
work done on the x86 box mentioned in the larger installations?
one way to think of it is that each pizza box (customer facing ports)
recognizes control plane messages (e.g. port 179) and "punts" them to
the control plane box, aka routing engine.
This is similar to the way I think about it.
In a router(switch) with a bunch of linecards (1 or more) there are a
set of match rules (ACLs if you will) which match traffic bound for the
control-plane and forward them via a management port to the control
plane cpu, conveniently this is also where you implement your
control-plane-protection. If you substitute ethernet switch for
line-card, broadly you are an in a similar place conceptually if the
main control plane processor is at some remove from the switch that is
now a line card. at some point you need to encapsulate the control-plane
messages because the managment next-hop is remote rather than local and
the neighbor is also a switch.
For me, the realization a decade ago was that enclosing a large number
of asics in sheet metal with the assiciated midplane and glue logic was
a higher capital risk and reduced the size of the addressable market vs
smaller switches with could be assembled piecemeal into a larger switch.
The white box vendors and the ODMs are loath to build something that has
limited market addressability so it becomes more attractive over time to
build large assemblies of box rather than large boxes that can leverage
the atom of switch that the 1/2ru pizza box can enclose and just buy
more of them. That said the maximum radix of a single large switch asic
right now is 512 * 100G ports. so you need to be able to build a box
that can enclose that many ports or the 64 x 800G, that, that maps to
which is still a very hefty pizza box.
randy