A little late to the party, but I've been accused of worse. 

We transitioned our network from Cisco 6500 platform to MX104s, and at the same 
time converged our Internet Edge onto those MXes too. It's the only Juniper 
router I'm aware of that actually fits *nicely* into a two-post rack, and they 
draw little power for what they are (approx. 150W on DC at idle at lower 
temperatures).

The low-end MXes can do a lot of things, but that doesn't mean you SHOULD 
necessarily do them. Anything CPU-heavy is a good example. Convergence time on 
three full feeds takes about 10-15 minutes in my experience, say in the case a 
major upstream drops. This isn't a big deal for everyone and for my employer 
certainly not enough to justify a bigger box on its own. One of the platform's 
strengths is also its weakness, in that the MX104 is essentially fabricless. 
Each of the "PIC" slots is a carved out chunk of a single forwarding engine. 
This is why they're limited to the 2-XFP MICs for 10 GbE options, unlike bigger 
MXes that take MICs with a much greater port density and support more than 4 
SFP+es. This is also why you have things that will affect the entire chassis at 
once, such as one of my favourite optics bug (plug in an SFP too slowly and all 
SFPs reset) and the DDoS Protection feature (blackholes an entire class of 
traffic on ALL ports). They are not suitable for core use for th
 is reason. 

They are very handy but less than great. MX104 is really made for telecom 
remotes and small COs with limited floor plans. MX80 and variants would be a 
convenient solution if you got one from the used market and have a 4-post rack. 
Both are really intended as 1 GbE aggregation routers. The MX104 is better 
since it has redundant REs, and if you just need some stuff off of an MS-MIC 
then it'd be a reliable low-maintenance box. But be aware that you're paying a 
premium for the form factor and not for something that will be in your network 
for a long time as they have very limited upgradability.  We were originally 
pretty excited but we're replacing a lot now since they just can't deliver the 
10G port density we need. Heck I think you can get smart lightbulbs these days 
that come with 10GbE ports...


Based on things I see in the mailing list, I'd take a serious look at splitting 
things up into more scalable components, such as the vMX and maybe an MX204 - 
systems that have real upgrade potential - although I have no idea what the 
pricing is like since we're going the "Big MX" route.


On Wednesday, April 11, 2018 5:32 AM, Saku Ytti wrote:
> 
> On 11 April 2018 at 04:31, Chris via juniper-nsp
> <juniper-nsp@puck.nether.net> wrote:
>
> > Since the MX104 has user replacable RE's I really wish Juniper would at
> > least offer a different option with a more beefy CPU/RAM but I don't think
> > that would ever happen...
>
> I think JNPR believes MX204 is the 'next gen MX104'. I bet if there
> was MX204 with 2xQSFP28 + 24-48xSFP+, sold attractively priced with BW
> license, so that SFP+ as 1GE and sub would make sense, those would
> sell really well.

Indeed it would. Even better if they hardened up the MX204 so it could be 
installed in the same environments.

> New RE for MX104 was on the table early on in the MX104 history, but
> then JNPR changed tracks, citing XEON not being thermally possible on
> it.

I would bet money that this has as much to do with it as planned limited 
lifetime of the platform. Maybe two thirds of our MX104s have baked PEM0 (the 
most down-wind power supply) out of existence. Any better CPU in there would 
have to be something like an ARM to keep the thing from roasting both power 
supplies simultaneously.

> I suspect more correct reason is that they don't see sufficient market
> potential in device like MX104. I think Cisco and Juniper are very
> confused about market, they appear to think entire market consists
> solely of large scale DC providers. That only addressable market is
> market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is
> almost dead.

I have noticed this as well. A lot of noise about ultra-dense machines that 
take up way too much space (depth) and need half a rack's worth of break-out 
cables to do anything interesting. That is, as long as "interesting" means 
"inside the building". I think vendors are taking "cloud" too seriously, as it 
seems that everybody's forgotten that the access and aggregation layers 
actually exist. Err I mean to say, just use hyperconverged Next Gen 5G. It's 
magic! Right?



On Thursday, April 12, 2018 3:58 AM, James Harrison wrote:
>
> On 11/04/2018 10:51, James Bensley wrote:
> > I would agree with
> > you that low port coun't, good, and reasonably priced mixed 1G/10G
> > devices aren't plentiful in choice from vendors. We open a lot of
> > small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for
> > us but each with their own caveats.
>
> Particularly if you include the requirement for temperature hardening -
> we deploy a lot of street cabinet sites, and MX104s and ASR902s are
> basically the only boxes in town that have reasonable 10G density and a
> sensible temperature range for external boxes. We don't need the full
> capability of a 104 (and feature-wise the 920 and 902s are chock full of
> unfortunate compromises) but sadly the higher bandwidth stuff based
> around x86 and BRCM silicon isn't yet entering the temp-hardened space.
>
> We have a few 104s out in prod doing fairly basic bits of EVPN and
> they're very capable boxes - just pricey for the ports we need.

This. Exactly this. There are more options from Mikrotik in this space than 
from "real" vendors. Sadly (or perhaps ironically) we've asked our sales team 
to help us figure out something for wireless towers (fixed wireless broadband, 
not mobile) and they told us we wanted MX104s. "For sites serving 100 
residential customers? Really?" So we use surplus Cisco 7301s instead with 
heated and ventilated cabinets.


- Ross
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to