Switching

I was asked what I think about the proposal to link one EX series switch with 6x 1 Gbps CAT6 copper interfaces in a 802.1ad link aggregation group to another existing EX access switch Virtual Chassis from the same model. The reason is saving time and money. They want to connect 8 PC’s but there are only 6x CAT6 cables to the existing EX series Virtual Chassis Access switches in the Satellite Equipment Room available.

The existing LAN has the rather common spine leaf topology, just about as displayed in the sketch below, but with the absence of the core layer switches and with a lot of layer 2 vlans. The (orange) Distribution switches are coupled together with 2x fibre LAG interfaces to form a Virtual Chassis.

The distribution switches have the lowest rstp bridge priority, the (blue) access switches have a higher bridge priority (rstp enabled on all interfaces). The new ex series switch shall be configured with the highest bridge priority of all. There is no BPDU-, loop-, or root protection. Storm control is enabled on all the switches.

What do you think about this proposal?

With regards,

Jean

If I understand correctly the orange distribution switchs are a virtual chassis.  Hence they are logically a single switch.

As a result you can make the dual connections of each blue access switch an ae bundle connecting to an ae bundle on the orange switch.  Thus a single connection, no loops possible, but with full hardware redundancy.

This makes better use of the links and still maintains the hardware redunancy.  Removing the need for spanning tree at all in the distribution to access layer.

I think that is what the proposal is saying, and I would agree. 

Assuming I understand the setup correctly.

Steve,

Thank you for giving your response,

The blue lines are indeed (also) ae links. The question is about daisy chaning a new switch via an ae interface to an existing (blue) access switch. The new daisy chained switch is not displayed in the scetch.

So what do you think about daisy chaining in general and in this particular scenaro?

Well nobody wants to go multiple levels with switching, but physical connection setups will sometimes demand we have to do so.

I assume then the additional downstream switch will come back to a single VC stack which can have the ae bundle as you note for some link redundancy.

Since these are VC running ae links, I don't understand what RSTP is doing or why it is needed in this scenario there won't be any blocking ports and all links are in use since there cannot be any loops.

Steve,

I gues rstp is configured on the distribution and access switches for loop prevention in the case of accidentially faulty coupling of access interfaces. 

With regards,

Jean

I see the possible benefit of prevention you note in running RSTP for the system.  If the rest of the system is running RSTP then I would also run it on the newly added switches for consistency.

It's just my generally preference to avoid enabling protocols that are not needed as a general rule to keep the system free in resources, potential bugs and surface area of attack on the running protocols.

Steve,

Thank you. 

You are stating: "Well nobody wants to go multiple levels with switching",
Why not?

Some last qustions about rstp in this matter:

What do you think about advising to leave it this way en to additional configure BPDU prevention on all the edge interfaces of all access switches for preventing e.g. (illegal) daisy chaning of some more switches (other than the one legally proposed)?

How about not to configure rstp on the new switch and leave rstp on the original access en distribution switches as is?
Can you prevent the new switch from generating BPDUs by deleting al the entries in the protocols rstp hierarchy?

With regards,

Jean

I think his comment "Well nobody wants to go multiple levels with switching" is based on the general fact that with multiple levels there are always extra physical hops any communication will encounter, so there will be some added delay, plus more hardware/etc.  In general, for a VC based campus networks traffic is mostly North-South, which means [generally] very little inter-VC traffic.  So most traffic from Access to Core, just hits a Distribution switch, and not another VC switch at the same layer.

As for the RSTP/BPDU Block question, you could implement this on the existing Blue VC downward interfaces (but not the AE to the Distribution layer), such that you now control where and who can add an extra [STP enabled] switch.  Yes if you disable/delete RSTP entry for an interface, that interface will not generate BPDUs.

One thing not mentioned (I believe) is that if the new switch is of the same model type as the Blue VC (EX model type not mentioned), you could just as easily extend this switch to be part of the Blue VC.  You do this by enabling all the relevant interfaces to run VCPe.  Juniper EX allows VC connectivity over Ethernet, as well as by dedicated VC ports.  This does not solve the "extra layer or multiple levels situation", but does make management of this [previously] standalone switch, be part of the existing VC, instead of by itself.  Maybe a case of 6 of 1, half-a-dozen of the other.

Also, I would not refer your topology as Spine-Leaf.  In true Spine-Leaf the Spines are not connected.  Your design is just basic long-time used multilayer with each different layer being a VC.  Again, 6 of 1, half-a-dozen of the other.

Good luck.

As RCCPGM notes, the cascading switch topology just creates more points of failure and additional hops.

I like his idea to use the connects to simply add another node as a Virtual Chassis but I'm not sure on the multiple links use case for that.  You mention have a six port ae I'm pretty sure you cannot do that with the VC link.

Not sure I follow the RSTP question, but if I understand the concern is people connecting STP enabled switches to the access ports you would need that blocking to occur on all the edge devices.