RSTP configuration on redundant 5412 core

[lucentsound]

Hi all,
i ask for your help to configure the RSTP on the network diagram you can see in attached link.

The network is simple because, at the moment, no vlans and no routing must be configured so i need only that the stp works well.

Can anyone help me suggesting the CLI commands on the two core switch and on three edge?

Thanks a lot to all and have a good day.

 

[cajuntank]

To enable RSTP on your switches just have these commands in your config:

spanning-tree
spanning-tree force-version rstp-operation

I don't think you really need that last line anymore as RSTP is the default spanning tree protocol now a days.

You can do RSTP, but you have another choice that might be more benefit to you in your situation for maybe down the road. I would read up on MSTP.

MSTP will give you an advantage over STP and RSTP by allowing you to take advantage of VLANs so that instead of the entire port either being forwarded or blocked, the port is dynamically forwarded or blocked based on the VLAN. So in essence the port might be blocked for one VLAN, but forwarded for another instead of the port just being totally blocked like in STP or RSTP. Please see this article for configuration assistance.

http://ftp.hp.com/pub/networking/software/3500_5400_6200_AdvTrfGde-July2006-59913827.pdf

And you definitely need to read up on VRRP for utilizing both those core switches as routing and redundancy when your ready to tackle that. Here is the documetation you'll need:

http://h40060.www4.hp.com/procurve/...Configuration_note_Sept_08_EMEA_Eng_A4.pd.pdf

Also look at distributed trunking

http://cdn.procurve.com/training/Ma...0-8200-MCG-June2009-59923059-12-PortTrunk.pdf

Hope that helps.

 

[lucentsound]

Hi Cajuntank,
thank you very much for your suppor.

I read the documentation in your link and it was very interesting
especially for the Multiple Spanning-Tree.

In my case i have no vlans (except the default vlan1) so i think
i can't use MSTP ed VRRP. Is it correct?

Thanks again for your invaluable help and have a nice day.

 

[VinceWhirlwind]

You might not have any use for MSTP until you implement some VLANs, but you can definitely use VRRP.

Essentially, you configure
CORE1:
VLAN 1 interface = 10.1.1.1
VLAN 1 VRRP VRID 1
OWNER
virtual-ip-address 10.1.1.1
enable

CORE2:
VLAN 1 interface = 10.1.1.2
VLAN 1 VRRP VRID 1
BACKUP
virtual-ip-address 10.1.1.1
enable

[Obviously, you shouldn't use VLAN1 in real life]

So what happens is that both Cores listen for frames addressed to the MAC address of 10.1.1.1, but only CORE1 responds to them.
IF CORE2 loses its connection to CORE1, then it responds to frames addressed to the MAC address of 10.1.1.1

As far as your design goes, the most obvious improvement would be this:
If you have a v2 chassis, and if you have K15 firmware on there, then you should get one or two of these for each CORE:

http://h30094.www3.hp.com/product/sku/10303961/mfg_partno/J9548A

and one or two of these for each CORE:

http://h30094.www3.hp.com/product/sku/3976334/mfg_partno/J9150A

This would enable you to have 10Gb between COREs.

Your current setup will very quickly give you performance problems between COREs as all it will take is 2 hosts transferring data across the same 1Gb link to create congestion.

 

[VinceWhirlwind]

In fact, the main benefit of Procurve is how cheap it is to have 10Gb, so you could get a 2-port 10Gb module plus 2 10Gb GBICs to put in the back of each 3500 to give you a 10Gb uplink to each core.

As your uplinks form a loop with the two cores, one of them will be spanning-tree blocked, so with your current design you only have 1Gb between each access switch and the CORE. This will very frequently experience congestion as soon as you have two hosts doing a file transfer.

To home the 10Gb in your core, you can get an 8-port 10Gb SFP+ module (if you have a v2 chassis and K15 firmware) or a 4-port 10Gb SFP+ module or a 4-port 10Gb GBIC module if you have older chassis.

I seem to recall the v2 chassis even has 2 in-built 10Gb SFP+ ports in the top of the chassis as well???

 

[lucentsound]

Hi Vince, thank you for the support.

I can't understand very well the benefits of introducing VRRP in my scenario.

As i told you before only vlan 1 (default_vlan) for switch management is present at the moment.

So imagine i had three users, one on edge1, one on core-1 and the last one on core-2 belonging to the same vlan and imagine a fault happens on core-1: what is the difference if i had implemented VRRP or not?

Thank you again and sorry for my inexperience.

 

[jkupski]

VRRP will not do you any good at layer 2, but if one of your switches is serving as your gateway, then if that switch fails, your layer 3 network is effectively isolated (no router). VRRP will allow the second switch to take over the routing duties if the first fails.

 

[VinceWhirlwind]

I guess he may have the default GW for his network on a firewall or WAN router or something, in which case he doesn't need these to run as Layer3 switches.

The equipment you have is ideal to function as a layer3 core, if needed.

 

[cajuntank]

Agree with Vince, would be a shame to waste such a good equipment setup by not taking advantage of built in technologies to get those added redundancies.

 

[lucentsound]

Thank you again for your individual help!

I have the last question.

I would like to define a 4x1000SX port trunking between the twoo 5412: do you suggest me to use LACP or Trunk option?

Further, when i activate the spanning tree on all devices (cores and edges) with command:

spanning-tree
spanning-tree force-version rstp-operation

must i specify a priority or not (to identify the root bridge)?

Thanks again all!

 

[cajuntank]

In regards to the spanning tree, a priority lower than 8 will cause that switch to become the root otherwise it will look at the MAC addresses to determine who is the root.

On the LACP or Trunk discussion, if both switches support LACP, then I usually go that route as it offers some benefits over static trunking (I just copied and pasted this off some webpage):

Failover when a link fails and there is (for example) a Media Converter between the devices which means that the peer will not see the link down. With static link aggregation the peer would continue sending traffic down the link causing it to be lost.

The device can confirm that the configuration at the other end can handle link aggregation. With Static link aggregation a cabling or configuration mistake could go undetected and cause undesirable network behavior.

Here is a config example on LACP

http://www.hp.com/rnd/support/config_examples/2524_lacp.pdf

Hope that helps.

 

[VinceWhirlwind]

With STP I think what I've done with a pair of 5400s is give CORE1 a priority of 2, CORE2 a priority 3. The rest (Access switches) can stay on the default, which I thought was 5, but my memory's a bit hazy.

So CORE1 is root, but if it fails, CORE2 takes over that function, not that it would matter with your topology.