Ethernet Switching
Reply
Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Maximum LAGs in Mixed EX4500/EX4200 Virtual Chassis

Hi all,

 

I have a proposed design that includes using a mixed EX4500/EX4200 Virtual Chassis.  I'm aware of the code versions needed to run this configuration but can't seem to find an answer to the following:

 

What is the maximum number of LAGs (or aggregated links, ae interfaces, etc) supported on the mixed VC?  

 

And, as an extension, are there any limitations on using member links from different model switches within a single LAG?

 

I'm fairly certain I found a document that said 64 LAGs were supported but I haven't been able to find that again.  I know that 64 LAGs are supported for an EX4500-only VC, but need confirmation for the mixed VC.

 

If you find a document that contains this info it would be extremely helpful to me if you could provide a link rather than just quoting from the document.

 

Many thanks in advance,

Ben.

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Contributor
papageno
Posts: 91
Registered: ‎07-08-2011

Re: Maximum LAGs in Mixed EX4500/EX4200 Virtual Chassis

I don't know any URL references for this, but I know for a fact it is 64.  The config from a mixed VC is below.

 

I am not aware of any limitations on configuring LAG members on different VC members, but be aware that there is a known problem with redundancy in the event of failure of the VC master, if any LAG members are on the master VC.  This may or may not be limited to OSPF.   We are currently working with JTAC and Juniper professional services on this.  I understand the problem will be fixed in JunOS 12.1, but until the fix is available, the best advice is to ensure that no LAG members are on the routing engines in the VC.  (In the deployment I am working on at the moment, the VC is intended for only connecting 10Gig LAGs, so in effect I have to add EX4200 members to the VC purely for them to run the VC as routing engines). 

 

> show configuration chassis aggregated-devices

ethernet {
device-count 64;
}

{master:3}
> show version
fpc0:
--------------------------------------------------------------------------
Hostname: <removed>
Model: ex4500-40f
JUNOS Base OS boot [11.3R1.7]
JUNOS Base OS Software Suite [11.3R1.7]
JUNOS Kernel Software Suite [11.3R1.7]
JUNOS Crypto Software Suite [11.3R1.7]
JUNOS Online Documentation [11.3R1.7]
JUNOS Enterprise Software Suite [11.3R1.7]
JUNOS Packet Forwarding Engine Enterprise Software Release
JUNOS Routing Software Suite [11.3R1.7]
JUNOS Web Management [11.3R1.7]

fpc1:
--------------------------------------------------------------------------
Hostname: <removed>
Model: ex4500-40f
JUNOS Base OS boot [11.3R1.7]
JUNOS Base OS Software Suite [11.3R1.7]
JUNOS Kernel Software Suite [11.3R1.7]
JUNOS Crypto Software Suite [11.3R1.7]
JUNOS Online Documentation [11.3R1.7]
JUNOS Enterprise Software Suite [11.3R1.7]
JUNOS Packet Forwarding Engine Enterprise Software Release
JUNOS Routing Software Suite [11.3R1.7]
JUNOS Web Management [11.3R1.7]

fpc2:
--------------------------------------------------------------------------
Hostname: <removed>
Model: ex4200-48p
JUNOS Base OS boot [11.3R1.7]
JUNOS Base OS Software Suite [11.3R1.7]
JUNOS Kernel Software Suite [11.3R1.7]
JUNOS Crypto Software Suite [11.3R1.7]
JUNOS Online Documentation [11.3R1.7]
JUNOS Enterprise Software Suite [11.3R1.7]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.3R1.7]
JUNOS Routing Software Suite [11.3R1.7]
JUNOS Web Management [11.3R1.7]

fpc3:
--------------------------------------------------------------------------
Hostname: <removed>
Model: ex4200-48p
JUNOS Base OS boot [11.3R1.7]
JUNOS Base OS Software Suite [11.3R1.7]
JUNOS Kernel Software Suite [11.3R1.7]
JUNOS Crypto Software Suite [11.3R1.7]
JUNOS Online Documentation [11.3R1.7]
JUNOS Enterprise Software Suite [11.3R1.7]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.3R1.7]
JUNOS Routing Software Suite [11.3R1.7]
JUNOS Web Management [11.3R1.7]

 

 

Hope this helps

 

Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Re: Maximum LAGs in Mixed EX4500/EX4200 Virtual Chassis

Thanks for your response papageno.  

 

I can see that you've configured the VC for 64 LAGs, but how many LAGs are you using?  I'm assuming that, if your LAGs are 2 members each, 1 member on each 4500 and there are none on the 4200s you could only be running a maximum of 40.  Is that correct?

 

I'd be grateful if you'd add to this thread once you've been able to determine if the fault condition you described applies to OSPF only.

 

Many thanks. 

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Distinguished Expert
dfex
Posts: 740
Registered: ‎04-17-2008
0

Re: Maximum LAGs in Mixed EX4500/EX4200 Virtual Chassis

According to the docs:  http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/interfaces-lag-overview.html

 

The maximum number for both stand-alone and virtual chassis EX4200 and EX4500s is 64, so by that logic it wouldn't matter which devices they were configured on, you could never exceed the limit.

 

I'm just about to implement this in a DC environment, so thanks for the tip about the Master RE and fail-over issues.

 

Cheers

Ben Dale
JNCIP-ENT, JNCIS-SP, JNCIE-SEC #63
Juniper Ambassador
Follow me @labelswitcher
Contributor
papageno
Posts: 91
Registered: ‎07-08-2011
0

Re: Maximum LAGs in Mixed EX4500/EX4200 Virtual Chassis

Hi Ben

 

You are correct that we would only have a maximum of 40 LAGs if there are only two EX4500s in the VC (without any additional uplink modules), but the reason I have configured 64 is to allow for future expansion of the VC with more EX4500s without the need to reboot the entire VC.

 

HAving worked on the problem more over the last few days, it seems the problem we were experiencing was partly due to an EX4500-only issue to be fixed in 12.1, and also to a known problem (PR575560) affecting the LACP daemon.  This PR was supposedly fixed in 11.3R1 but apparently it is still there.  As it caused the LACP daemon to restart with no obvious cause, and this causes a flap on all LACP interfaces, it will obviously affect any routing process dependent on the links remaining up.

 

The recommended workaround is to de-configure ethernet storm control for multicast traffic, and this seems to be stable now, i.e.:

 

set ethernet-switching-options storm-control interface all no-multicast

 

There is still some lack of clarity over exactly what the problem affecting EX4500 devices only is.

 

Hope this helps.

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.