Basic update , the Av team change the way the devices were working as we seemed to have one interface on the switch , where a single port had 3 IP addresses all advertising the same mcast address ( Sh mcast cache 239.254.78.7) and the AV software was reporting lost /missed and duplicate packets.
Thsi was addressed to the hardware supplier and resolved.
This is a Triangular network scenario , with multiple stacking replicating the same..where the edge stack is a 5520 with port 1:60 going to a VSP7400 and 2:60 going to a different VSP7400 with MLT joining the two VSP7400 together , the network I am looking at is not routed and just L2.
As part of the test for AES67 port 2:60 was disabled ,on all stacks therefore forcing all data traffic progressed down 1:60 to the distribution, and then back up to the other test stack so that the MLT and the second distribution VSP7400 were not involved in the data path.
The 5520 are using fabric attach , with NSI statements , and the VSP7400 also use teh statement to attach teh correct vlan to teh correct ports ( mlt and physical )
On bringing port 2:60 on the 5520 back online , the AES67 application failed.. we left it for about a minute to see if it would resolve its problems , which it did not ..
Being new to VSP and Fabric what are the expected delays when bringing up a shared link and what is the expected disruption as the fabric will need to build
The sharing on the 5520 is dynamic again does this delay in getting the up-links stable, as now port 2;60 is added dynamically to all the networks that share that port .
what is the recommended link algorithm to use on the 5520 to VSP7400 , currently set to L3 on the 5520 while looking at the VSP MLT and port setting there are no additional parameters configured for a hashing algorithm .
Any recommended fixes taht you have found would be worth trying , or should I not expect a fast convergance and just leave teh kit for a bit longer to sort itself out
