Hi Tobias, that’s not right. You need to differ between redundancy and non-redundancy-mode:
With Fabric Redundancy in MX960 (SCBEs: 2 active, 1 spare): Premium2 Chassis (non-enhanced midplane): MPC5E 205G MPC7E 400G Premium3 Chassis (enhanced midplane): MPC5E 240G MPC7E 480G In the non-redundant mode (so all three SCBEs are online and active) you will not suffer from any limitation as long as all three are online. But if one dies you will have the limitations in a Premium2 chassis. So it depends on the model you want to use. We need a full redundant switching fabric so we have to calculate with these limitations. — Sebastian Becker > Am 14.11.2017 um 23:35 schrieb Tobias Heister <li...@tobias-heister.de>: > > > Hi, > > Am 14.11.2017 um 13:27 schrieb Sebastian Becker: >> The enhanced midplane allows you already to use higher bandwidth with >> redundancy at least on the MX960. 205G per slot (not > enhanced) against >> 240G per slot (enhanced) So if you want to use a MPC5E-100G10G and populate >> every port (2x100G plus 4x10G) > you need the enhanced midplane and the >> SCBE2. Same for the MPC5E-40G10G and the Q-Versions of these cards. >> Otherwise you > overbook the midplane. > > Funny enough the MPC7 has no reduced Bandwidth with the non enhanced > Midplane, so for now only MPC4/5 suffer from that old midplane. I always > wondered why that is the case. Might be a combination of PFE/Trio Generation > and frequency/speed per Serdes to Fabric connectivity. If somebody knows the > details i am eager to know. > > We will see what SCBE3 might bring there (other than allowing us to run MPC7 > at full speed with redundancy and pave the way for future MPC) > > -- > Kind Regards > Tobias Heister > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
