VSP7400 link algorithm recommendation when connected to 5520 switch..
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-16-2022 06:32 AM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-17-2022 08:58 PM
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,
on 5520 what does,
Roland
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
on 5520 what does,
- show fabric attach assignments
- show fabric attach elements
- show port <PORT> vlan, show fdb, show vlan
Roland
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎03-02-2022 10:06 AM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-17-2022 04:54 AM
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
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
