Hi all, Unlike other platforms, the MX architecture if very flexible in how it > uses its memory. For example, when a Cisco SUP720-3BXl says "1 million > IPv4 routes", this means precisely 1 million, because they have exactly > 72MB of TCAM and each IPv4 route takes a 72-bit entry, so they can fit > exactly 2^20 entries (assuming no other IPv6/MPLS/multicast routes). On > the MX the limits are much more arbitrary, as long as it all fits into > the (very very large) lookup memory. >
The negative side here is that most scaling numbers must be tested in order to know them. Looks like this is the reason for which Juniper doesn't like to publish scaling numbers, though I know, they have a strong system of tracking them. More difficult to track it when it's open and hard to explain that what is written is rather an arbitrary number, not a hard limit. For sales people it can be sometimes not easy to understand this 'arbitrary number which really depends’ talks, when a competitor says ‘hey, what a nonsense, 1 million means 1 million’. At least it seems to be the way Juniper's marketing think of this. I doubt it is the right one, they could make it a strong point if they wanted. At the era of M20 and 200 customers at all this could had been a nice strategy but now it looks like an "every barber knows that" sort of secret and those questions "how much of X does Y support?" are a burden to Juniper's SE teams all over the word. > Now that said, from everything I can read it looks like the scaling > design for MAC addresses was 256k for DPCs and 512k for MPCs. I have > absolutely no idea if there is a fixed limit behind that, or if it's an > arbitrary number. On DPCs it may have been related to what the EZchip > could do > >From what I know, it's 128k per EZ, 512k per DPC and 1M per box. No idea about Trio. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
