[j-nsp] MPC5EQ Feedback?
Scott Harvanek
scott.harvanek at login.com
Wed Nov 1 12:24:38 EDT 2017
Good to know on the last part, right now we have just XL based PFEs, so we wouldn’t want to add anything LU based to drop our capacity, XL or EA only.
Scott H
> On Nov 1, 2017, at 11:23 AM, Pavel Lunin <plunin at gmail.com> wrote:
>
>
>
> Worth to note that XL-based PFEs have much more SRAM and are capable to hold like ~10M IPv4 LPM records in the FIB in contrast to ~2.4M for LU (I've never reached the limit, so these numbers are rather what I've read / been told here and there). And, of course, if you have both LU and XL-based cards in the same box, your FIB is limited by the "lowest common denominator".
>
> 2017-11-01 17:07 GMT+01:00 Pavel Lunin <plunin at gmail.com <mailto:plunin at gmail.com>>:
>
>
> There were two versions of MPC3:
>
> 1. MPC3 non-NG, which has a single XM buffer manager and four LU chips (the old good ~65 Mpps LUs as in "classic" MPC1/2/16XGE old trio PFEs).
> 2. MPC3-NG which is based on exactly the same chipset as MPC5, based on XM+XL.
>
> MPC4 is much like MPC3 non-NG though it has two LUs instead of four with a new more "performant" microcode.
>
> XL chip (extended LU), which is present in MPC5/6 and 2-NG/3-NG has also multiple ALU cores (four, IIRC) but in contrast to MPC3 non-NG and MPC4 these cores have a shared memory, so they don't suffer from some limitations (like not very precise policers) which you can face with multi-LU PFE architectures.
>
> MPC7 has a completely new single core 400G chip (also present in the recently announced MX204 and MX10003).
>
> This said, I find MPC4 quite not bad in most scenarios. Never had any issues, specific to its architecture.
>
> P. S. Finally this choice is all about money/performance.
>
>
> Kind regards,
> Pavel
>
>
> 2017-11-01 16:46 GMT+01:00 Scott Harvanek <scott.harvanek at login.com <mailto:scott.harvanek at login.com>>:
> Adam,
>
> I thought that the MPC3E and MPC5E had the same generation Trio w/ XL and XQ chips? Just the MPC5E has two XM chips.
>
> Scott H
>
>
>
> > On Nov 1, 2017, at 10:28 AM, <adamv0025 at netconsultings.com <mailto:adamv0025 at netconsultings.com>> <adamv0025 at netconsultings.com <mailto:adamv0025 at netconsultings.com>> wrote:
> >
> >> Scott Harvanek
> >> Sent: Tuesday, October 31, 2017 6:57 PM
> >>
> >> Hey folks,
> >>
> >> We have some MX480s we need to add queuing capable 10G/40G ports to
> >> and it looks like MPC5EQ-40G10G is going to be our most cost effective
> >> solution. Has anyone run into any limitations with these MPCs that aren’t
> >> clearly documented?
> >>
> >> We intend to use them for L3/VLAN traffic w/ CoS/Shaping. Currently we’re
> >> doing that on MPC2E NG Qs w/ 10XGE-SFPP MICs , any reason we couldn’t
> >> do the same on this along with the adding of the 40G ports? Any Layer3
> >> limitations or the normal 2MM/6MM FIB/RIB?
> >>
> > Hey Scott,
> > I'd rather go with a standard Trio architecture i.e. one lookup block one buffering block (and one queuing block) -so mpc3 or mpc7.
> > To me it seems like 4 and 5 are just experiments with the Trio architecture that did not stood the test of time.
> >
> > adam
> >
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp <https://puck.nether.net/mailman/listinfo/juniper-nsp>
>
More information about the juniper-nsp
mailing list