Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: juniper

vmember limits in EX series stack

 

 

nsp juniper RSS feed   Index | Next | Previous | View Threaded


naveen at lastninja

Apr 30, 2012, 8:15 PM

Post #1 of 7 (1352 views)
Permalink
vmember limits in EX series stack

I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200
virtual chassis configuration (8 linecards). I've run into a warning
when committing the configuration:

warning: Exceeded vmember threshold limit, it is recommended to
have not more than 32752 vmembers

Our current setup has 200 VLANs defined; and can grow anywhere upto 300
in the future.

Additionally we have around 200 downstream cisco switches; each with
redundant uplinks (so 400 ports). A downstream switch will have an
upper bound of 24 distinct active vlans for the trunk port on the
VC.

Therefore the expected real vmember usage is something like: 200*24 = 4800
or 400*24 = 9600 if considering the redundant uplinks to the downstream
switches.

In this case can the vmember warning be safely ignored? I'm assuming
the warning is due to the worst case; where all 8*48 ports in the stack
are specified to trunk all vlans, so 8*48*200 = 76800 vmembers. However
as stated above the actual amount of vmembers expected (as defined on the
ownstream switches) is far less.

To manually specify the members for each downstream switch trunk port
requires a significant amount of administrative overhead. I would prefer
each trunk port just allow all the vlans.

The documentation is pretty sparse to indicate why this limit is imposed
except espouse caution that the switch process may fail/restart without any
substantial explanation. It would be nice what resources are being tied up.

- Naveen

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


cra at wpi

May 1, 2012, 6:35 AM

Post #2 of 7 (1306 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

On Mon, Apr 30, 2012 at 08:15:59PM -0700, Naveen Nathan wrote:
> To manually specify the members for each downstream switch trunk port
> requires a significant amount of administrative overhead. I would prefer
> each trunk port just allow all the vlans.

Doesn't that mean you are effectively always sending all broadcast
traffic on all VLANs down every port? That seems pretty pessimal.
Perhaps you could use GVRP or MVRP to automatically maintain VLAN
memberships.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jsw at inconcepts

May 1, 2012, 6:57 AM

Post #3 of 7 (1299 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

On Mon, Apr 30, 2012 at 11:15 PM, Naveen Nathan <naveen [at] lastninja> wrote:
> I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200
> virtual chassis configuration (8 linecards). I've run into a warning
> when committing the configuration:

I found your problem. You are attempting to retire a Cisco 6509 by
replacing it with a closet full of stackables. That is a pretty
foolish thing to do.

--
Jeff S Wheeler <jsw [at] inconcepts>
Sr Network Operator  /  Innovative Network Concepts

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


bennetb at gmail

May 23, 2012, 9:44 AM

Post #4 of 7 (1242 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

On Tue, May 1, 2012 at 7:57 AM, Jeff Wheeler <jsw [at] inconcepts> wrote:
> On Mon, Apr 30, 2012 at 11:15 PM, Naveen Nathan <naveen [at] lastninja> wrote:
>> I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200
>> virtual chassis configuration (8 linecards). I've run into a warning
>> when committing the configuration:
>
> I found your problem.  You are attempting to retire a Cisco 6509 by
> replacing it with a closet full of stackables.  That is a pretty
> foolish thing to do.
>
Yeah cause that shared 16Gbps backplane in the classis model is so
much better than 64Gbps.

I don't find this post useful and I probably shouldn't have indulged
you with a reply

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


nick.kritsky at gmail

May 23, 2012, 10:19 AM

Post #5 of 7 (1236 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

On Tue, May 1, 2012 at 5:35 PM, Chuck Anderson <cra [at] wpi> wrote:
> On Mon, Apr 30, 2012 at 08:15:59PM -0700, Naveen Nathan wrote:
>> To manually specify the members for each downstream switch trunk port
>> requires a significant amount of administrative overhead. I would prefer
>> each trunk port just allow all the vlans.
>
> Doesn't that mean you are effectively always sending all broadcast
> traffic on all VLANs down every port?  That seems pretty pessimal.
> Perhaps you could use GVRP or MVRP to automatically maintain VLAN
> memberships.

According to relnotes, GVRP is no longer supported after 11.1.
MVRP could work but I am not sure about cisco-juniper interoperability here.

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 :)

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


naveen at lastninja

May 28, 2012, 11:38 PM

Post #6 of 7 (1227 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

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.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jgoodwin at studio442

May 29, 2012, 12:41 AM

Post #7 of 7 (1222 views)
Permalink
Re: vmember limits in EX series stack [In reply to]

On 01/05/12 13:15, Naveen Nathan wrote:
> I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200
> virtual chassis configuration (8 linecards). I've run into a warning
> when committing the configuration:
>
> warning: Exceeded vmember threshold limit, it is recommended to
> have not more than 32752 vmembers
>
> Our current setup has 200 VLANs defined; and can grow anywhere upto 300
> in the future.

(I *knew* there was a post I'd meant to reply to a while back...)

It's not clear from your post whether you know how VLAN's map to ports,
and how static they are, but one option that makes managing it fairly
sane is using apply groups. A simple (but not EX type) example is at:

http://laptop006.livejournal.com/55440.html

And a variant that's EX-specific made it into last year's tips book:

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/junos-tips-techniques/
Attachments: signature.asc (0.26 KB)

nsp juniper RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.