Wired Intelligent Edge

 

Dear All

 

I have a fairly small network that i manage and I am looking to upgrade all 4 of the network switches. The switches that i am looking to purchase correspond as below:

 

SW1 & SW2 - ARUBA 3810M 16SFP+ 2-SLOT SWITCH (JL075A)

SW3 & SW4 - ARUBA 2540 48G POE+ 4SFP+ SWITCH (JL357A)

 

The network is all 1 subnet - class C

 

The picture above shows how i am looking to set things up when i purchase those switches.

 

The question is if I connect SW3 & SW4 together via MMF SFP+ 10Gbit then this will obviously create a network loop...  but how can i set this up so if a network loop does occur then there is no ''learning time'' between the switches and the ports don’t get blocked because otherwise my Hyper-V hosts that are connected to the SAN via iSCSI will lose connection and all the virtual servers will go down..

 

Also any other thoughts on this setup is also appreciated.

 

Hi,

 

The loop will be blocked by Spanning tree (need to enable before..)

 

The uplink port need don't set to edge (or portfast...)

Thanks alagoutte

 

So your saying i should enable STP or RSTP first on all the uplink ports..

 

The only bit i didnt understand was when u wrote:

 

''The uplink port need don't set to edge (or portfast...)''

 

Can you rephrase?

 

 

 

 

---

@timsmithsc wrote:

Thanks alagoutte

 

So your saying i should enable STP or RSTP first on all the uplink ports..

 

@The only bit i didnt understand was when u wrote:

 

''The uplink port need don't set to edge (or portfast...)''

 

Can you rephrase?

 

 

 

 

---

Spanning tree is enable by default on ALL ports (when it is enable)

After for avoid to wait for "client" port, it is possible to enable edge-port

but you don't need enable on "Uplink" port

Are you planning to deploy Backplane Stacking between SW1 and SW2?

 

If so, SW1 and SW2 will become one (logical) entity...and, supposedly, you are going to impose this new entity to be (R)STP Root (so with lowest priority or priority = 0).

 

I would also add that you should enable the root-guard option on all interfaces that, on STP root (the stack), will be involved in downlinks to non STP root SW3 and/or SW4...the root-guard option will prevent/avoid the SW3 or SW4 - or any switch connected behind them - to become (erroneously) STP Root (see here and here <- this one uses a Comware terminology but root-guard is the part interesting for you).

 

A nice source to undestand how to setup STP on the edge (access-level) could be this page too.

---

@parnassus wrote:

Are you planning to deploy Backplane Stacking between SW1 and SW2?

 

If so, SW1 and SW2 will become one (logical) entity...and, supposedly, you are going to impose this new entity to be (R)STP Root (so with lowest priority or priority = 0).

 

I would also add that you should enable the root-guard option on all interfaces that, on STP root (the stack), will be involved in downlinks to non STP root SW3 and/or SW4...the root-guard option will prevent/avoid the SW3 or SW4 - or any switch connected behind them - to become (erroneously) STP Root (see here and here <- this one uses a Comware terminology but root-guard is the part interesting for you).

 

A nice source to undestand how to setup STP on the edge (access-level) could be this page too.

---

 

Thanks, yes this was one of my worries, that either SW3-4 may become a root switch and i didnt want that..  i will check those articles out.

 

Yes i was thinking about stacking SW1&2 together.. however as i have never done this, what what is the real benefit for me here? because they way i believed it is that it would be almost like a rstp, where is say SW1 failed then SW2 would carry on anyway.. same as in a stack i presume...?

Is a stack more for ease of management? or is it for quicker convergence times? maybe because VSF is better than rstp?

 

Thanks

 

I would normally recommend loopfree network designs. This because STP could be complex and when not right configured it can gives a lots of fun. And a second reason is that with STP design not all uplinks can be active.

 

The 3810 support hardware backplane stacking modules, not VSF. 

 

The 2530 dont support stacking in anyway, the 2930F should be a perfect choice and support VSF stacking by using two default 10Gb DAC cables.

 

When choice for stacking on both core and edge switches you have some benefits:

• All uplinks are active (LACP)
• No need for spanning-tree (put it only on globaly)
• If routing is used on the core, 1 routing-table in the 3810 stack
• 1 Managent IP per stack, so you have to manage 2 switches instead of 4 switches individual.

Maybe a slightly more expensive but it think its well worth it.

 

 

 

I second @mkk: consider that having Aruba 3810M in backplane stacking and having SW3 and SW4 both stacked (VSF - which is a Frontplane Stacking technology approach - with Aruba 2930F oor Backplane Stacking with Aruba 2930M or older but still valid Aruba 2920) will permit you to use LACP Link Aggregation transparently in all your topology (between all of your Hyper-V/HPE StoreVirtual 4530 hosts and SW1+SW2 stack and between your SW1+SW2 stack and your SW3+SW4 stack...and, why not? pushing to the limit on the edge side, between your client hosts and your SW3+SW4 if you really want...not forgetting the Firewall too if it supports LACP)...consider that you can distribute - for resiliency - LAG's links so your connections will become more fault-proof...and all of this enhacing throughput (especially when data flows are any-to-any in terms of values fed into L2, L3 or L4 hashing algorithms used).

---

@parnassus wrote:

@I second @mkk: consider that having Aruba 3810M in backplane stacking and having SW3 and SW4 both stacked (VSF - which is a Frontplane Stacking technology approach - with Aruba 2930F oor Backplane Stacking with Aruba 2930M or older but still valid Aruba 2920) will permit you to use LACP Link Aggregation transparently in all your topology (between all of your Hyper-V/HPE StoreVirtual 4530 hosts and SW1+SW2 stack and between your SW1+SW2 stack and your SW3+SW4 stack...and, why not? pushing to the limit on the edge side, between your client hosts and your SW3+SW4 if you really want...not forgetting the Firewall too if it supports LACP)...consider that you can distribute - for resiliency - LAG's links so your connections will become more fault-proof...and all of this enhacing throughput (especially when data flows are any-to-any in terms of values fed into L2, L3 or L4 hashing algorithms used).

---

Thanks for this explanation parnassus@,   so as @mkk mentioned before the list of advantages to stacking this, and also your explanation above.. it seems like buying the extra stacking module has its benefits...

but im wondering if i can get most of these advantages in performance by just running a LACP connection between switch SW1 & SW2 ... instead of spending around £1500 extra on stacking modules for these 2 switches.. what are you thoughts?

 

 

Hi Tim,

 

The named benefits can only be achieved with the extra stacking link modules (and stacking cables). Without these stacking modules stacking is not possible on a 3810 switch because they dont support VSF.

 

If the extra costs is to much then you have to use the classic spanning-tree method as mentioned before. Then you dont have all paths active and you will have to manage all 4 switches individually.

 

The choice is yours. But I think that the 1500L is quickly recouped because less management effort will be needed in the coming years. But of course I do not know what your budget is.

 

Once again there is no good or bad, but rather a consideration whether you need this extra functionality and performance or not.

I add a consideration about resiliency: LACP adds resiliency and redundancy...LACP requires (it's a mandatory requirement) that member links are coterminus...so, in absence of any form of virtual stacking technology (Backplane/Frontplane stacking, it doesn't really matter), if you deploy LACP you must do it between single physical Switches and/or between a Switch and an Host...no stacking? no way to deploy LACP distributed across stack's members (at least if you just not deploy something like DT-Trunking...but this requires ISL...so, at that point, better to do real stacking)...so' at that level, resiliency can't be reached...and it will be confined within each Switch, not across them.

Another consideration is the achieveable throughput by using backplane stacking versus interconnecting two switches by LACP on frontplane ports...I leave you to do the math on that...without considering that backplane just doesn't use useful Ethernet ports leaving them free for access/uplinking usage.

---

@parnassus wrote:
I add a consideration about resiliency: LACP adds resiliency and redundancy...LACP requires (it's a mandatory requirement) that member links are coterminus...so, in absence of any form of virtual stacking technology (Backplane/Frontplane stacking, it doesn't really matter), if you deploy LACP you must do it between single physical Switches and/or between a Switch and an Host...no stacking? no way to deploy LACP distributed across stack's members (at least if you just not deploy something like DT-Trunking...but this requires ISL...so, at that point, better to do real stacking)...so' at that level, resiliency can't be reached...and it will be confined within each Switch, not across them.

Another consideration is the achieveable throughput by using backplane stacking versus interconnecting two switches by LACP on frontplane ports...I leave you to do the math on that...without considering that backplane just doesn't use useful Ethernet ports leaving them free for access/uplinking usage.

---

 

Thankyou parnassus@ this explanation as well as the one from @mkk is what i was looking for so i can make my decision on how to setup my new infrustrcuture.. 

 

Thanks again, 

Tim

---

@mkk wrote:

Hi Tim,

 

The named benefits can only be achieved with the extra stacking link modules (and stacking cables). Without these stacking modules stacking is not possible on a 3810 switch because they dont support VSF.

 

If the extra costs is to much then you have to use the classic spanning-tree method as mentioned before. Then you dont have all paths active and you will have to manage all 4 switches individually.

 

The choice is yours. But I think that the 1500L is quickly recouped because less management effort will be needed in the coming years. But of course I do not know what your budget is.

 

Once again there is no good or bad, but rather a consideration whether you need this extra functionality and performance or not.

---

 

@Thankyou mkk, this explanation as well as the one from @parnassus is what i was looking for so i can make my decision on how to setup my new infrustrcuture.. 

 

Thanks again, 

Tim

@mkk wrote:

I would normally recommend loopfree network designs. This because STP could be complex and when not right configured it can gives a lots of fun. And a second reason is that with STP design not all uplinks can be active.

 

The 3810 support hardware backplane stacking modules, not VSF. 

 

The 2530 dont support stacking in anyway, the 2930F should be a perfect choice and support VSF stacking by using two default 10Gb DAC cables.

 

When choice for stacking on both core and edge switches you have some benefits:

• All uplinks are active (LACP)
• No need for spanning-tree (put it only on globaly)
• If routing is used on the core, 1 routing-table in the 3810 stack
• 1 Managent IP per stack, so you have to manage 2 switches instead of 4 switches individual.

Maybe a slightly more expensive but it think its well worth it.

 

 

 

@mkk

Thankyou for this information.

 

---

 

---

@alagoutte wrote:

---

@timsmithsc wrote:

Thanks alagoutte

 

So your saying i should enable STP or RSTP first on all the uplink ports..

 

@The only bit i didnt understand was when u wrote:

 

''The uplink port need don't set to edge (or portfast...)''

 

Can you rephrase?

 

 

 

 

---

Spanning tree is enable by default on ALL ports (when it is enable)

After for avoid to wait for "client" port, it is possible to enable edge-port

but you don't need enable on "Uplink" port

---

 

Many thanks for clearning this up, i will give it a test.

A stp edge port or port fast is not part op de stp topology and will not need to learn if there is some loop, normaly you put stp edge enabled on your client interfaces.

Combine this with bpduguard protection so a client interface that connect to another client interface will blocked when the first bpdu packet come in on the second interface.

Turn stp-edge off on uplinkports so stp can calculate the paths and block the loop.

@mkk wrote:
A stp edge port or port fast is not part op de stp topology and will not need to learn if there is some loop, normaly you put stp edge enabled on your client interfaces.

Combine this with bpduguard protection so a client interface that connect to another client interface will blocked when the first bpdu packet come in on the second interface.

Turn stp-edge off on uplinkports so stp can calculate the paths and block the loop.

---

Thanks mkk, i will give this a test in my environment and hopefully should all go as planned.

A stp edge port or port fast is not part op de stp topology and will not need to learn if there is some loop, normaly you put stp edge enabled on your client interfaces.

Combine this with bpduguard protection so a client interface that connect to another client interface will blocked when the first bpdu packet come in on the second interface.

Turn stp-edge off on uplinkports so stp can calculate the paths and block the loop.