[j-nsp] MX304 Port Layout

Litterick, Jeff (BIT) Jeff.Litterick at state.sd.us
Fri Jun 9 12:41:20 EDT 2023


This is why we got the MX304.  It was a test to replace our MX10008 Chassis, which we bought a few of because we had to get at a reasonable price into 100G at high density at multiple sites a few years back now.  Though we really only need 4 line cards, with 2 being for redundancy.   The MX1004 was not available at the time back then (Wish it had been.  The MX10008 is a heavy beast indeed and we had to use fork lifts to move them around into the data centers).    But after handling the MX304 we will most likely for 400G go to the MX10004 line for the future and just use the MX304 at very small edge sites if needed.   Mainly due to full FPC redundancy requirements at many of our locations.   And yes we had multiple full FPC failures in the past on the MX10008 line.  We went through at first an RMA cycle with multiple line cards which in the end was due to just 1 line cards causing full FPC failure on a different line card in the chassis  around every 3 months or so.   Only having everything redundant across both FPCs allowed us not to have serious downtime. 


-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of Andrey Kostin via juniper-nsp
Sent: Friday, June 9, 2023 11:09 AM
To: Mark Tinka <mark at tinka.africa>
Cc: Saku Ytti <saku at ytti.fi>; juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [EXT] [j-nsp] MX304 Port Layout

Mark Tinka писал(а) 2023-06-09 10:26:
> On 6/9/23 16:12, Saku Ytti wrote:
> 
>> I expect many people in this list have no need for more performance 
>> than single Trio YT in any pop at all, yet they need ports. And they 
>> are not adequately addressed by vendors. But they do need the deep 
>> features of NPU.
> 
> This.
> 
> There is sufficient performance in Trio today (even a single Trio chip 
> on the board) that people are willing to take an oversubscribed box or 
> line card because in real life, they will run out of ports long before 
> they run out of aggregate forwarding capacity.
> 
> The MX204, even though it's a pizza box, is a good example of how it 
> could do with 8x 100Gbps ports, even though Trio on it will only 
> forward 400Gbps. Most use-cases will require another MX204 chassis, 
> just for ports, before the existing one has hit anywhere close to 
> capacity.

Agree, there is a gap between 204 and 304, but don't forget that they belong to different generations. 304 is shiny new with a next level performance that's replacing MX10k3. The previous generation was announced to retire, but life of MX204 was extended because Juniper realized that they don't have anything atm to replace it and probably will lose revenue. Maybe this gap was caused by covid that slowed down the new platform. And possibly we may see a single NPU model based on the new gen chip, because chips for 204 are finite. At least it would be logical to make it, considering success of MX204.
> 
> Really, folk are just chasing the Trio capability, otherwise they'd 
> have long solved their port-count problems by choosing any 
> Broadcom-based box on the market. Juniper know this, and they are 
> using it against their customers, knowingly or otherwise. Cisco was 
> good at this back in the day, over-subscribing line cards on their 
> switches and routers. Juniper have always been a little more purist, 
> but the market can't handle it because the rate of traffic growth is 
> being out-paced by what a single Trio chip can do for a couple of 
> ports, in the edge.

I think that it's not rational to make another chipset with lower bandwidth, easier to limit an existing more powerful chip. Then it leads to MX5/MX10/MX40/MX80 hardware and licensing model. It could be a single
Trio6 with up to 1.6T in access ports and 1.6T in uplink ports with low features. Maybe it will come, who knows, let's watch ;)

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list