[j-nsp] vmember limits in EX series stack
Naveen Nathan
naveen at lastninja.net
Tue May 29 02:38:05 EDT 2012
On Wed, May 23, 2012 at 09:19:26PM +0400, Nick Kritsky wrote:
> As per original question, Juniper states pretty clearly:
> "If you ignore the warning and
> commit such a configuration, the configuration succeeds but you run
> the risk of crashing
> the Ethernet switching process (eswd) due to memory allocation failure."
>
> If you plan to enable all downstream ports as trunks with "vlan
> members all", you are going to exceed this limit not just for 10% but
> more than twice. I would not recommend this risk :)
Yep, and I found out the painful way. I did come across more information
through correspondence with some excellent people, and felt that this
information may serve those that come across similar error messages.
A few releases back, prior to 11.1 the commit check was disabled.
This was added as a warning because of multiple core dumps due to
memory exhaustion of the eswd process. As much is known, there is
no hardware representation for vmember (but vlans have such
a resource) so the limit is purely based on memory limits of each
platform.
Depending on each platform, number of vlans supported changes, it's
decided that (vlans * 8) as the vmember limit for each platform in EX.
eswd needs memory for other things such as mac learning, etc. if it uses up
all memory for just vmember maintenance, then the mac learning capability
gets restricted.
More information about the juniper-nsp
mailing list