Wired Intelligent Edge

Greetings all!

In this infrastructure I have two Aruba 5400R (VSF) with fiber modules that are used to connect with the multiple data cabinets around the infrastructure.

In the data cabinets I used Aruba 2930F with two redudant fiber optics per data cabinet, directly connected to the Aruba 5400R VSF.

Example: Two Aruba 2930F (VSF) in data cabinet 10 is connected directly with two redudant fiber optic cables to both Aruba 5400R (VSF) in the data center.

Aruba 2930F (1) - 1/49 <---> 1/A10 - Aruba 5400R (1)

Aruba 2930F (2) - 2/49 <---> 1/A10 - Aruba 5400R (1)

My objetive with this implementation is:

The redudant port only goes up when the first one goes down, and I thought that if I configured STP the protocol would automaticaly detected the redudant fiber and handled it correctly.

The problem is that both interfaces are always up on all data cabinets (probably any misconfiguration??).

But my bigger problem about this is that I have an extensive logging, full of high collision and drop rates on multiple interfaces on all switches, and I can't understand what could possible be wrong.

If I need to provide more information about this implementation, let me know.

Thank you very much.

Hi!

In the example you cited probably you meant:

• Aruba 2930F (1) - 1/49 <---> 1/A10 - Aruba 5400R (1)
• Aruba 2930F (2) - 2/49 <---> 2/A10 - Aruba 5400R (2)

isn't it?

Would be interesting to see sanitized running configurations of both VSF (5400R zl2 and 2930F) and relevant show spanning-tree against involved ports on both ends.

Is there a good reason to not consider link aggregation (AKA Port Trunking, possibly with LACP) instead of dealing only with one active link and the other in standby? I mean...if both links are connected why not using both links concurrently (dual benefit: enhanced resiliency and throughput between each access and the core)?

Hello Davide,

You are 100% right ! I wanted to write "2/A10 - Aruba 5400R (2)"

I surely can post running configuration and spanning-tree informations of both switches.

From what I understanded related to your question about link aggregation.... You are saying that problably I should create a link of both fiber connections rather than having them configured separately?

Well... I guess that the main reason of having them separately was simply because at the beginning we only focused on having a redudant connection and not in the benefits (as you mencioned) of having link aggregation !

My real problem at this moment is that STP is not handling it as I think it should, and possible for that I'm having so many interface errors...

I always thought that STP would recognize that the two connections are for the same switch and proceded to turn down one...

---

@Andre Pacheco wrote: You are saying that problably I should create a link of both fiber connections rather than having them configured separately?

Yes, you should. I mean...if you have two fiber optic run between each access cabinet and the core cabinet (thus between each standalone switch on the access side and the VSF at core) why not using both paths concurrently (each Access Switche and the Core's Modules aren't already equipped with proper SFP/SFP+ Transceviers on two ports per end?)?

You will gain (a) no issue with STP, (b) added resiliency (no STP discard->forward delay on the the inactive link) and (c) enhanced throughput (especially in the many-to-many case of traffic flowing between Access and Core).

---

@Andre Pacheco wrote:My real problem at this moment is that STP is not handling it as I think it should, and possible for that I'm having so many interface errors...

---

That's pretty strange...STP should manage a loop correctly by disabling the "offending link" provided that it is correctly configured (and two single links between each of your access switch and the core form a loop for sure...)...that flapping is abnormal...you could play with link weight (to force STP select a link over the other if they are both with the same weight <- that way you programmatically decide what link of the pair should carry the traffic and what link should not) but it should not be necessary.

It's true that you're expressly creating a network with various loops...but (R)STP or (M)STP should manage those loops correctly and once the spanning-tree is stable - if no other instability jumps in - the network should be quite stable (protected by loops).

Do the flaps stop if you manually shutdown all secondary links (and thus if you manually remove the causes for various loops)?

---

@Andre Pacheco wrote: I always thought that STP would recognize that the two connections are for the same switch and proceded to turn down one...

---

That's exactly the purpose of a well configured STP on a well designed network topology.

Now that I re-read better your first post I noticed that you have another issue:

---

@Andre Pacheco wrote: But my bigger problem about this is that I have an extensive logging, full of high collision and drop rates on multiple interfaces on all switches, and I can't understand what could possible be wrong.

---

High Collision and Drop rates aren't typically related to STP...but could easily be related to broadcast storm(s) and, finally, to the fact that STP is probably not working/configured correctly...it's important (I would say essential) to understand what is your Spanning Tree configuration all over your network, how you protected your core, how you protected your access ports at access layer and how you configured your access switch uplinks to your core.