Re: [j-nsp] vmember limits in EX series stack
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/ signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On Tue, May 1, 2012 at 5:35 PM, Chuck Anderson 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On Tue, May 1, 2012 at 7:57 AM, Jeff Wheeler wrote: > On Mon, Apr 30, 2012 at 11:15 PM, 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: > > 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On Mon, Apr 30, 2012 at 11:15 PM, 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: 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 Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
