[j-nsp] MX304 reliability

Saku Ytti saku at ytti.fi
Tue May 5 02:53:09 EDT 2026


Not contributing much here, rambling mostly.

MX304 from product marketing follows MX80, MX104, MX204, but
technically it's very different.

Previously from the WAN+LAN side of Trio connected WAN ports, that is,
the Trio had 2xports compared to fabric ports, because no capacity was
used for fabric. This of course means the smallest average packet size
at 100% is twice as large, because PPS remains the same, but port
count doubles, which I can't recall anyone actually suffering from, as
the PPS budget is still good enough.

MX304 has up-to 3 Trio YT, so it needs fabric to connect them, and
we're missing 'true 304' which would be single YT, with all WAN ports.
This single YT MX304 would still be 2/3 of the port density of MX304,
which almost no one exceeds, because most buy it with RE redundancy.
So the box would be basically third of the CAPEX with in practice
similar port-density had it followed the 80/104 design.

In practice it may be impossible to do this in YT, because YT is
really two Trio in a package, and those Trios still need fabric to
talk to each other. But even this seems like huge omission, because
they actually have shared memory between the Trio chip, so you're
using fabric to loopback the packet back to the same physical memory,
because you're lacking some magic signal to tell 'pick up packet from
memory address X', it has to come from fabric. I think this omission
is fixed in next-gen Trio and it can do local switching between the
package instances(?) and I hope MX404 or whatever follows will again
deliver true pizzabox design. And perhaps people in this list who talk
to Juniper remind them that they want a simple and cost efficient
single Trio box.

I can't stop wondering what would have happened if Juniper tried to
sell Trio-PCI in newegg with open spec, let people build their linux
edge boxes with NPUs, NVIDIA style. I did suggest it repeatedly to
Juniper, because I was worried about their small unit numbers shipped
and thought it would be good to try something. I don't think there is
almost any overlap between the companies who'd build Trio-PCI edge box
and companies who'd buy MX, so it feels weird not to try.

On Mon, 4 May 2026 at 23:42, Aaron1 via juniper-nsp
<juniper-nsp at puck.nether.net> wrote:
>
> I have a few 304’a doing a lot of ENNI/EVC/CBH/Carrier Ethernet.  Been solid.  I dug through email, and came across an initial issue with Juno’s upgrades, I recall related to these PR’s.
>
> PR1792524
> PR1721421
>
> Aaron
>
> > On May 4, 2026, at 1:15 PM, Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net> wrote:
> >
> > Hello, juniper-nsp readers.
> >
> > From the article https://www.juniper.net/documentation/us/en/software/junos26.1/chassis/topics/topic-map/chassis-guide-tm-fabric-plane-mngmnt.html :
> > Limitations
> >
> > • MX304 routers have only one built-in SFB and one FPC. Hence there is no fabric redundancy support.
> >
> > Does anybody encountered MX304 HW failures that required a chassis replacement and how real is the risk of such a failure?
> >
> > Kind regards,
> > Andrey
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti


More information about the juniper-nsp mailing list