cancel
Showing results for 
Search instead for 
Did you mean: 

VSP7400 link algorithm recommendation when connected to 5520 switch..

VSP7400 link algorithm recommendation when connected to 5520 switch..

RodR
New Contributor
I have a triangular network , two 7400;s connected by MLT and then each VSP connected to a stack of 5520 48 port switches.
The 5520 stack is using ports 1:60 and 2;60 as a dynamically configure share with L3 algorithm .

The system if basically fabric attach , so my understanding is that the networks with their NSI dynamically attach to teh correct links.

When running on one link from the 5520 stack ,  the AV application AES67 is stable and works as expected , when bringing up teh secondary link 2:60 on te 5520 , the application becomes non operational ( application is mcast ) its left for 30-60 seconds to see if teh network changes resolve and allow teh application to stabilize , teh app does not stabilize until the second link is disabled .

Question is this an issue where fabric takes time to resolve the changes and it needs more time , and/or is there a modification I can make to the sharing algorithm  on both the 5520 and VSP7400
3 REPLIES 3

Anonymous
Not applicable
Hi Rob,

Does it work with one link only when it is 2:60?
Have you configured a SMLT on the VSP 7400s side down to 5520?
When both links connected,
   on the 7400s what does,
    • show mlt <id>
    • show fa assignment
    • show fa elements
    • show fa interface
    • show fa statistics
   display?

   on 5520 what does,
    • show fabric attach assignments
    • show fabric attach elements
    • show port <PORT> vlan, show fdb, show vlan
display?

Roland

RodR
New Contributor
Hi

Just to answer some of your question ..
The Application would not work and was dropping " counters " ( EAS67 device ) when link 2:60 was also enable as a L3 share.
All the fabric stuff was working and also the mcast application Dante, AV screens   could be shared between stacks .. so the issue was the EAS67 AV protocol..
We had a number of goes at this , considering the network is operational with everything else working as expected..
It a L2 network so no Mcast routing
Each switch had it fdb flushed to see if that would make a difference .. it did not

So we went back to the sharing algorithm as a final throw of the dice..
This was changed from " en sharing 1:60 grouping 1;60,2:60 algorithm address-based L3" ( previously been automatic with the fabric attach operation, to en sharing 1;60 grouping 1;60,2:60 al add L2

This had an immediate effect with the AES67 application displaying no more " counter " issues
This was left running over the weekend and approx 34,000,000 counters were recorded with only 172 lost !!!

The next part is to configure all the other stacks the same way, and for the AV team to test all their applications and also check the operation of the other services on the network.

Hopefully all will be good
Many thanks for your help


Marlon_Scheid
New Contributor III
Hi Rob,

did you enable Fabric Attach also on 2:60? You have to enable it manually its not automatically enabled if you enabled it on the Sharing Master Port.

regards
Marlon
GTM-P2G8KFN