[j-nsp] MX104 Limitations

[Raphael Mazelier]

Hello,

I have no the full knowledge to disccussall of the points above, but the 
real point is where you come from ? mx80 ? and why you need an upgrade 
to (say) mx104 ?

And for what I know:

1. MX104 like MX80 have no SBC, true. They are integrated router.
So no redundancy on this point.

2. Yes.

8. If true it could be a real problem.BFD could be a huge resource consumer.

10. MX104 is an hardenned router. So the chassis can operate with a 
larger range than the MX80. But this is not the sole use case of mx104.
So if you want to use it in a hard environnement you have to buy the 
good card. Seems logic to me.

11. What the point if the chassis is correcltly cooled ?

The other points are really for special use case. If you need this kinds 
of feature you have to carefully test any router you want to use.

Regards,

Le 24/06/15 15:08, Colton Conor a écrit :
> We are considering upgrading to a Juniper MX104, but another vendor (not
> Juniper) pointed out the following limitations about the MX104 in their
> comparison. I am wondering how much of it is actually true about the MX104?
> And if true, is it really that big of a deal?:
>
> 1.       No fabric redundancy due to fabric-less design. There is no switch
> fabric on the MX104, but there is on the rest of the MX series. Not sure if
> this is a bad or good thing?
>
> 2.       The Chassis fixed ports are not on an FRU.  If a fixed port fails,
> or if data path fails, entire chassis requires replacement.
>
> 3.       There is no mention of software support for MACSec on the MX104,
> it appears to be a hardware capability only at this point in time with
> software support potentially coming at a later time.
>
> 4.       No IX chipsets for the 10G uplinks (i.e. no packet
> pre-classification, the IX chip is responsible for this function as well as
> GE to 10GE i/f adaptation)
>
> 5.       QX Complex supports HQoS on MICs only, not on the integrated 4
> 10GE ports on the PMC. I.e. no HQoS support on the 10GE uplinks
>
> 6.       Total amount of traffic that can be handled via HQoS is restricted
> to 24Gbps. Not all traffic flows can be shaped/policed via HQoS due to a
> throughput restriction between the MQ and the QX. Note that the MQ can
> still however perform basic port based policing/shaping on any flows. HQoS
> support on the 4 installed MICs can only be enabled via a separate license.
> Total of 128k queues on the chassis
>
> 7.       1588 TC is not supported across the chassis as the current set of
> MICs do not support edge time stamping.  Edge timestamping is only
> supported on the integrated 10G ports.  MX104 does not presently list 1588
> TC as being supported.
>
> 8.       BFD can be supported natively in the TRIO chipset.  On the MX104,
> it is not supported in hardware today.  BFD is run from the single core
> P2020 MPC.
>
> 9.       TRIO based cards do not presently support PBB; thus it is
> presently not supported on the MX104. PBB is only supported on older EZChip
> based MX hardware.  Juniper still needs a business case to push this forward
>
> 10.   MX104 operating temperature: -40 to 65C, but MX5, MX10, MX40, MX80
> and MX80-48T are all 0-40C all are TRIO based. Seems odd that the MX104
> would support a different temperature range. There are only 3 temperature
> hardened MICs for this chassis on the datasheet: (1) 16 x T1/E1 with CE,
> (2) 4 x chOC3/STM1 & 1 x chOC12/STM4 with CE, (3) 20 x 10/100/1000 Base-T.
>
> 11.   Air-flow side-to-side; there is no option for front-to-back cooling
> with this chassis.
>
> 12.   Routing Engine and MPC lack a built-in Ethernet sync port.  If the
> chassis is deployed without any GE ports, getting SyncE or 1588 out of the
> chassis via an Ethernet port will be a problem.  SR-a4/-a8 have a built-in
> sync connector on the CPM to serve this purpose explicitly.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>