This post is more than 5 years old
29 Posts
0
24561
Force10 VLT and fast failover
Forgive me if this belongs somewhere else, but I could not find a Force10 forum. We have a 4820T pair configured as a VLT domain. Our "leaves" are Dell 5548s and 6224s connected via LAGs to the 4820T "spines". It seems in a failure scenario we cannot get our paths back up in less than about 7-8 seconds. In one of the white papers they were showing 1.5 sec path recoveries. What is the determining factor in getting a fast recovery? We have RSTP hello times etc dialed as low as they can go on the PowerConnects FWIW. Is there something else in say LACP etc that we have missed causing the path recovery to be slow?
Bubbagump210
29 Posts
0
June 25th, 2014 11:00
We figured it out. It turns out it was the Hello Time in RSTP. One of the Force10 white papers describes setting the Hello Time to .5 sec which we did. It turns out that is bad. The PowerConnects were at a Hello Time of 2 (the protocol default) and could not be set as low as 0.5. Once we set the Force10s to a Hello Time of 2, the world was happy. 700ms failovers were had by all.
DELL-Josh Cr
Moderator
Moderator
•
8.5K Posts
0
June 2nd, 2014 15:00
Hi Bubbagump210,
Is there a lot of other traffic on the 5548s and 6224s? You may want to try the lacp timeout short command on the 6224 and the 5548s and see if that helps. Is the VLT interconnect a static LAG? Have you tried making the LAG from the Powerconnects to the Force10 a static LAG? Is the firmware on each device up to date? Page 974 shows some other things to check for the recommended configuration. http://www.force10networks.com/CSPortal20/KnowledgeBase/DOCUMENTATION/CLIConfig/FTOS/S4820T_9.4(0.0)_Config_Apr_09_2014.pdf
DELL-Josh Cr
Moderator
Moderator
•
8.5K Posts
0
June 3rd, 2014 12:00
For the static lag it is just to test to see if it is an LACP issue causing the delay.
Bubbagump210
29 Posts
0
June 3rd, 2014 12:00
Currently there is nearly no traffic as this is a lab environment we are testing in before going to production. LACP is indeed set to short timeouts. Let me try a static LAG, though that seems counterintuitive when it comes to resiliency.