Hello,
Does the MX204 support virtual chassis setup?
Regards,
Paschal Masha
Paschal,
It is not supported, nor is it recommended for redundancy in a routed setup. Please describe your (desired) topology, that way the community can discuss alternatives.
Thanks,
Sounds like the OP wants to build a chassis-based system out of non-redundant hardware. Mark.
No, but they do however work just great as an active-active pair of routers when cross linked and iBGP peered to each other and everything downstream connected to each one.
Chris
Thanks just wanted to know whether it was a supported feature.
What would have been nice is if Juniper oversubscribed the face plate of this platform, as most people are more likely to run out of ports than they would the 400Gbps forwarding capacity of Trio.
In some cases, we deploy more of these in the same PoP just because we need more ports, not because we need more capacity; and a chassis would not make sense for the function, yet.
Mark.
What would have been nice is if Juniper oversubscribed the face plate of
this platform, as most people are more likely to run out of ports than
they would the 400Gbps forwarding capacity of Trio.
You’re restricted to 400G because they did fixed lane allocations to the EA chip on the PFE to each port group. Doing an MRATE setup to let you access all 480G would have increased electrical complexity, and dramatically increased the price point of the box. There are tradeoffs. The more flexibility you want, the more expensive the box is going to be.
I’m not sure they allow oversubscription on anything in the MX line anymore honestly. I could be wrong, I’ve been face down in a specific subset of equipment for a while, someone please correct me if I am.
Does Fusion not make sense in this case? I’ve not had a ton of experience with it, but it does well to add a crazy port count to an otherwise very port limited device.
-Matt
On the new ACX line, yes.
If I look at the MPC7E, MPC10E, MX10003 and MX304, no oversubscription is allowed.
Even the LC2103 MPC on the MX10003 which has more ports than Trio capacity, won't let you use more than 1.2Tbps (3x Trio 3 chips on it).
We don't mess around with any other MX products, so not sure (although we are still yet to deploy the MPC10E's and the MX304).
Mark.
[faceplate oversubscription]
On the new ACX line, yes.
Not Trio, and different PLM 
We don't mess around with any other MX products, so not sure (although
we are still yet to deploy the MPC10E's and the MX304).
MX304 (well, strictly LMIC16) has the same restriction, and a need for another entry in the magic port checker (Port Checker | Juniper Networks Pathfinder) for restrictions beyond "SUM(port-speeds) <= 1.6T".
They make sense once you've looked at the block diagram for the thing and followed the lines, but things like "4x10G breakout can only go in odd-numbered ports, and you have to leave the corresponding next-lowest even-numbered port empty" are not instantly obvious.
Thanks,
Tim.
some of these port capabilities are weird to me. like on the ACX7100-48L you can do 4x100 or 8x50, but ONLY one 40g ?!
me@7100> show chassis pic pic-slot 0 fpc-slot 0 | find 400
48 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
49 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
50 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
51 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
52 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
53 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G
54 NA 1x10G
Not Trio, and different PLM
Yes, aware... I was just speaking in general for what is likely to be a very popular platform :-).
MX304 (well, strictly LMIC16) has the same restriction, and a need for another entry in the magic port checker (Port Checker | Juniper Networks Pathfinder) for restrictions beyond "SUM(port-speeds) <= 1.6T".
Yep.
That trick they did where you can live with one RE and get 3 MIC's in the MX304 is... well, I guess everyone will have their own opinion.
They make sense once you've looked at the block diagram for the thing and followed the lines, but things like "4x10G breakout can only go in odd-numbered ports, and you have to leave the corresponding next-lowest even-numbered port empty" are not instantly obvious.
They do take some getting used to. But this is what comes with all the flexibility operators often seek.
Mark.
Aaron Gould писал(а) 2023-08-23 12:38:
some of these port capabilities are weird to me. like on the
ACX7100-48L you can do 4x100 or 8x50, but ONLY one 40g ?!me@7100> show chassis pic pic-slot 0 fpc-slot 0 | find 400
48 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
49 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
50 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
51 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
52 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
53 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
4x10G 3x100G
54 NA 1x10G
Probably because 40G is a product 10G lanes. There are only 4 lanes available, and the speed of a single lane can vary. So, 40G is the max speed for the lowest single lane's speed.
Kind regards,
Andrey
In small edge PoP's, we attach an Arista 1U switch with tons of 1/10Gbps ports to an MX204 via 802.1Q. Works a treat. I've never been convinced by vendor-specific satellite systems :-).
On another note, the potential issue we might run into is pressure on control plane memory on the MX204 for us that run BGP Add-Paths. You can always upgrade the RE on an MX240/480/960, but the MX204 is fixed (and last time I checked, fiddling with Juniper RE memory was generally frowned upon).
Luckily, the MX10003 ships with 64GB of RAM, since it is now EoL.
The MX304 ships with 128GB of RAM, so anybody running Add-Paths on that box won't have an issue there.
Mark.
On another note, the potential issue we might run into is pressure on
control plane memory on the MX204 for us that run BGP Add-Paths. You can
always upgrade the RE on an MX240/480/960, but the MX204 is fixed (and
last time I checked, fiddling with Juniper RE memory was generally
frowned upon).
In my experience and testing with them, you have a decent bit of headroom past the published RIB/FIB limits before they’ll fall over.
They are holding up pretty well for us, mainly because we do a lot more BGP on MX480's than on MX204's. We use the MX204's mainly for peering and CDN gateways. Where we use them for edge customers, it's a handful of BGP sessions.
On MX480 16GB RE's running two full BGP feeds but hundreds of customer sessions, Add-Paths really eats into RAM. We've had to upgrade some of the busier routers from 16GB to 64GB RE's, especially on later versions of code where ROV can also bite into memory on boxes carrying lots of BGP sessions.
Mark.
No VC here, unsure if it works, but yeah, we like them and deploy them in pairs for metro-e (ce) and cbh for vlans carried over mpls pw
Reliable for us
Aaron
On MX480 16GB RE’s running two full BGP feeds but hundreds of customer
sessions, Add-Paths really eats into RAM.
It would, sure. Instead of storing a single prefix/next-hop with flags in memory, you now have to store every prefix/next-hop that you are announcing as well.
Indeed.
But it has been worth it. The load balancing from PE-to-PE has been fantastic, especially when coupled with BGP Multipath.
No more messing about with LOCAL_PREF for multi-homed customers, and it works just as well with different (but equal-length) AS_PATH's.
Mark.
I sincerely doubt there is much demand for new 40G these days.
Look at the population of 40G members on major IXes.
People have either one 10G, 2 x 10G, or 100G.
40G was a dead-end 9 years ago and much so more now.