[j-nsp] Poll Question (VRF scale on MX)

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Thu Dec 21 11:25:26 EST 2017


Hi Sebastian,
Is this 10M FIB within the next hop 4M DWORD allotted space or also using recommended 80% of the shared EDMEM space too or even all of it actually not leaving anything for FW and Counters or proper functioning of the LU?
Being a vendor I'd boot it up to a theoretical max just to look good so yes I'd need the above info to make an informed judgement or as you suggest do a throughout scaling testing.  

adam 

netconsultings.com
::carrier-class solutions for the telecommunications industry::

> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf
> Of Sebastian Becker
> Sent: Thursday, December 21, 2017 12:46 PM
> To: Jason Lixfeld
> Cc: Juniper List
> Subject: Re: [j-nsp] Poll Question (VRF scale on MX)
> 
> Hi Jason,
> 
> you’re right … the claims means that there is no (extra) software restriction
> besides what the hardware can deliver itself.
> 
> The MX204 should have the following scale limits:
> 
> FIB:		10M (IPv4 and IPv6 combined)
> RIB:		80M (IPv4); 50M (IPv6)
> VRFs:	6050
> 
> Mostly the given values are single scaled. So make sure you test that in a
> multiscale enviroment.
> 
>> Sebastian Becker
> sb at lab.dtag.de
> 
> > Am 21.12.2017 um 13:24 schrieb Jason Lixfeld <jason-jnsp at lixfeld.ca>:
> >
> > Hey there,
> >
> > General question - MX204-IR, for example, claims no RIB/FIB scale
> restrictions.  While I’m sure with that claim, RIB scale is limited to the amount
> of physical memory available on the box, I’m not sure what the physical limits
> are around the FIB.  My understanding is that it’s Trio Gen 3 based, but to
> that, I don’t actually know enough about the architecture yet to be sure.
> >
> > Thanks!
> >
> >> On Dec 21, 2017, at 6:19 AM, <adamv0025 at netconsultings.com>
> <adamv0025 at netconsultings.com> wrote:
> >>
> >> Hi folks,
> >>
> >> I have this large scale rollout and while doing scaling testing and
> >> Juniper recommendations will get you some confidence, I'd like to
> >> understand where we land on the graph in comparison with other
> >> operators (can't get this info from Juniper folks unfortunately).
> >> But we can build our own anonymous public database right here on the
> list.
> >> So what I'd like to collect from you all is:
> >>
> >> Junos code version:
> >> Number of VRFs:
> >> Number of destinations (total or average per VRF):
> >> Output from: request pfe execute target fpc0 command "show jnh 0
> >> pool" (+ type of card this was executed on)
> >> 	- this output will tell you where you are at with regards to your
> >> next-hop memory utilization (whether you are within the pre-allocated
> >> 2+2M or already borrowing something from the shared pool)
> >>
> >> You can contact me on or off list and I shall publish a summary graph
> >> (anonymous of course)
> >>
> >> Thank you very much.
> >>
> >> adam
> >>
> >> netconsultings.com
> >> ::carrier-class solutions for the telecommunications industry::
> >>
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list