It concerns an internetworking solution that we have configured for an electrical company constituted with 3 buildings, A, B, C. In order to link them we have used 3 switchs : catalyst 6509 on Bloc A, catalyst 6006 on Bloc B, catalyst 3550-12G on Bloc C. In each floor there is different combination of catalyst type 3524 XL and 3548 XL with 2 GBIC ports. (look at the figure joined)
Would you give us advice in order to found an optimal combination of parameters for the activation of EtherChannel service between the 3 core switchs and even between each core switch and its switchs floor.
Ive just activated this service but unfortunately Ive discovered this error : when I execute a ping between each core switch and its switchs floor we obtain 100 % of success rate. But when I execute a ping between a hosts of the same or different floors we obtain only 65% of success rate.
The rate of loss of the ping disappears when I disconnect the second link of EtherChannel
This may not solve your problem, but it would be a basic design approach that would make it simpler to trouble shoot what is not working correctly.
Since you are just showing the non-default configuration, I assume you made no modifications to Spanning Tree Protocol. If that is the case, then the bridge with the lowest MAC address was elected the root bridge for that VLAN. Not knowing where the root bridge is, you cannot predict/design which ports will be blocking and which ports will be forwarding anywhere that redundant links occur.
In summary, pick a root bridge, assign it as root, use Root Guard, to prevent someone from adding a switch with a lower priority and accidently changeing the root bridge.
Have you confirmed that the Etherchannel link came up properly from both ends. Confirm that you see the bundle from both switches. When we setup an etherchannel, we use desirable and silent on both sides.
You should also consider UDLD for all of your links between switches(especially fiber), I have recently seen a situation where not having that turned on, wrecked havoc on a very large core due to instability in the routing protocol when one switch had an uplink flapping(physical layer problem).
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...