[j-nsp] MX104 Limitations
raph at futomaki.net
Wed Jun 24 11:36:25 EDT 2015
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.
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.
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
More information about the juniper-nsp