pretty great video,but you didnt configure any peer keepalive link along with ISC between the sw1 and sw2,can you let me know why we need peer keepalive and isc?
Hi Prateek, that's correct. Reason for not covering keepalive in this video is that I don't want to make the videos too long. I might be adding another video covering keepalive. The main purpose of keepalive is to avoid a split brain situation when the Interswitch link is broken. The ISC is required to sync all the tables and allow load balancing on. By the way, I have created another video that covers VSX, which is the next generation MCLAG. This video covers keepalive which works in exactly the same way as keepalive with MCLAG. VSX is the way forward for Aruba Networks. You can find the video here: ua-cam.com/video/b31py4NlLSo/v-deo.html
Hi, thanks for the great video! Is there any information on why Aruba changes the old terminology (distributed trunking)? I guess they changed pretty much everything to look more like ios and less like the old ArubaOS...
Well, the IOS (Catalyst) term for MC-LAG is MEC (Multi Chassis Etherchannel), the IOS-X term for MC-LAG is VPC, the ASR term is MC-LAG so I am not sure where the consistency is here :-). I guess Aruba is moving more to the terminology that has been accepted by the industry in general. For example, Juniper also uses the term MC-LAG. I think in general it is a good thing that vendors move away from fancy acronyms and long worded marketing flavored terms and change to terminology that has been accepted by the market or are driven by industry standards. And, at the end of the day, it all has to work and has to satisfy the customer's requirements, right? :-)
Hello! First thank you for your videos, they are very very helpful. I've been tinkering with MCLAG with keepalive enabled to have a more controlled environment in case of ISL failure. As I understand, if ISL fails, keepalives keep on going and the 8400 with higher priority shutsdown it's MCLAG interfaces, is that so? I haven't been able to do It :(
Hello Aarón, That is correct. You have to do three things. First, set the mclag priority with the command: mclag device-priority command. The switch with the lower value will continue forwarding. Second (and third) is that you need an additional Layer 3 connection between the two switches and configure an mclag keepalive peer. For example if you have a L3 connection between two switches, where switch1 IP is 10.10.1.1 and switch2 IP is 10.10.1.2, you configure the following on switch1: mclag keepalive peer 10.10.1.2 source 10.10.1.1. On switch 2 it's: mclag keepalive peer 10.10.1.1 source 10.10.1.1. If you are using vrf's other than the default vrf, you also have to specify the vrf. Once that's done you can check the keepalive link with the: show mclag keepalive status command. If you disconnect the ISL, the switch with the higher priority value should block all the ports. Finally, make sure that you have at least release 08 running on the switches. Good luck.
Hi! We managed to fix the problem. We were using loopback interfaces of both chassis to communicate the keepalives with OSPF routing. The problem was that the keepalives were going through the ISL link and that is not supported. I changed the cost of OSPF interfaces so keepalives go through other interfaces instead of the ISL link and now it works like a charm!
Yes that is correct, you have to make sure that the keep alives are not using the ISL link but are taking a non ISL path. This is the way it is supposed to work.
pretty great video,but you didnt configure any peer keepalive link along with ISC between the sw1 and sw2,can you let me know why we need peer keepalive and isc?
Hi Prateek, that's correct. Reason for not covering keepalive in this video is that I don't want to make the videos too long. I might be adding another video covering keepalive. The main purpose of keepalive is to avoid a split brain situation when the Interswitch link is broken. The ISC is required to sync all the tables and allow load balancing on.
By the way, I have created another video that covers VSX, which is the next generation MCLAG. This video covers keepalive which works in exactly the same way as keepalive with MCLAG. VSX is the way forward for Aruba Networks. You can find the video here: ua-cam.com/video/b31py4NlLSo/v-deo.html
@@AirheadsBroadcasting thank you very much for the reply,I'll definitely check out VSX
Hi, thanks for the great video!
Is there any information on why Aruba changes the old terminology (distributed trunking)? I guess they changed pretty much everything to look more like ios and less like the old ArubaOS...
Well, the IOS (Catalyst) term for MC-LAG is MEC (Multi Chassis Etherchannel), the IOS-X term for MC-LAG is VPC, the ASR term is MC-LAG so I am not sure where the consistency is here :-). I guess Aruba is moving more to the terminology that has been accepted by the industry in general. For example, Juniper also uses the term MC-LAG. I think in general it is a good thing that vendors move away from fancy acronyms and long worded marketing flavored terms and change to terminology that has been accepted by the market or are driven by industry standards. And, at the end of the day, it all has to work and has to satisfy the customer's requirements, right? :-)
How to enable routing on Interface lag multi-chassis ?
How does Aruba OSX emulate in GNS3?
Dik's using an OVA version of CX. It is not publicly distributed I'm afraid.
For educational purposes will there be a version for access for partners?
Hello! First thank you for your videos, they are very very helpful. I've been tinkering with MCLAG with keepalive enabled to have a more controlled environment in case of ISL failure. As I understand, if ISL fails, keepalives keep on going and the 8400 with higher priority shutsdown it's MCLAG interfaces, is that so? I haven't been able to do It :(
Hello Aarón, That is correct. You have to do three things. First, set the mclag priority with the command: mclag device-priority command. The switch with the lower value will continue forwarding. Second (and third) is that you need an additional Layer 3 connection between the two switches and configure an mclag keepalive peer. For example if you have a L3 connection between two switches, where switch1 IP is 10.10.1.1 and switch2 IP is 10.10.1.2, you configure the following on switch1: mclag keepalive peer 10.10.1.2 source 10.10.1.1. On switch 2 it's: mclag keepalive peer 10.10.1.1 source 10.10.1.1. If you are using vrf's other than the default vrf, you also have to specify the vrf. Once that's done you can check the keepalive link with the: show mclag keepalive status command. If you disconnect the ISL, the switch with the higher priority value should block all the ports. Finally, make sure that you have at least release 08 running on the switches. Good luck.
Hi! We managed to fix the problem. We were using loopback interfaces of both chassis to communicate the keepalives with OSPF routing. The problem was that the keepalives were going through the ISL link and that is not supported. I changed the cost of OSPF interfaces so keepalives go through other interfaces instead of the ISL link and now it works like a charm!
Yes that is correct, you have to make sure that the keep alives are not using the ISL link but are taking a non ISL path. This is the way it is supposed to work.
Was this changed in 10.04.0001