Uplink configuration in the following scenario

[vipinrajrc]

Hi Experts,

Please see the attached image. I have checked all ports STP status. One access-layer is the root.

currently Core1 is the active HSRP switch. But its connection to the switch which is connected to PIX is in BLOCK state.

It is messed up. but i need the following thisng to be implemented

1)  I need to optimize this.

2)  i like to enable HSRP load balancing.

3) i like to configure uplink fast

Regarding uplink fast --> uplink fast need to be configured only in the distribution and core switches , right?

But in this scenario core1 to core2 ports are in block state.. I am totally in confusion.

Please suggets your opinions....

Thanks

Vipin

[Collin Clark]

The diagram is missing.

[vipinrajrc]

Yea... Sorry please check now

[lgijssel]

A few basic steps to begin with:

Configure the STP root on the switch which is normally the HSRP root:

spanning-tree vlan root primary

Do not use uplinkfast, a better option is to configure rapid spanning-tree:

spanning-tree mode rapid-pvst

This step must be performed on all switches. (disruptive)

After this, please check your setup again and start troubeshooting from here.

regards,

Leo

[Collin Clark]

1)  I need to optimize this.

What I would do is control where STP is blocking. Where you do it is up to you. Some like to block between the core switches and others prefer the access layer switch to block on one of the uplinks to the core switches (like you have). You should configure the core switches to be the roots of STP though, that's best practice.

2)  i like to enable HSRP load balancing.

HSRP is not load balancing, it provides gateway redundancy

3) i like to configure uplink fast

OK, it depends on what your distro is doing. Are you layer 2 everywhere or do have some layer 3 separation?

[vipinrajrc]

Hi

I am only having layer2 seperation(VLAN) .

[vipinrajrc]

Hi,

Can i configure uplink-fast in this scenario, without any problem??

Thanks

Vipin

[Collin Clark]

Please review the following docs-

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094641.shtml

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800951ac.shtml

[Jon Marshall]

As Leo says, if your switches support it use Rapid STP. Uplinkfast was an addition (Cisco proprietary) to the original STP. Rapid STP has uplinkfast functionlity built in so there no need to explicitly configure.

About your network diagram and optimisation. You have multiple distribution switches and then a pair of core switches. Is this for multiple buildings ie. is this a campus network where each distribution switch is in a separate bulding and the core switches interconnect the buildings or is all this just one building.

Where does the inter-vlan routing take place ie. on the distribution switches or the core switches ?

Jon

[vipinrajrc]

Hi Jon,

Yes each distribution switch is for seperate locations. and inter-vlan routing is happening in core switch itself.

Can i directly switch-over from PVST to RSTP? If it so, Root bridge will change from access to core automatically???

ONE BIG QUESTION..........................................

IS IT POSSIBLE TO OPTIMIZE THIS SCENARIO???

Thanks

Vipin

[Jon Marshall]

Vipin

You can go straight from PVST to RPVST yes but not without some downtime. Also it is worth checking if all your switches support RPVST.  You would still need to manually set the STP root.

As for optimisation it depends really. If all your inter-vlan routing is happening in the core then your distribution switches are merely aggregating the access-layer switches. So it depends on how your vlans are distributed across the buildings eg. if you have the same vlans in multiple buildings then it may make sense to have the core switches STP root and secondary.

But a lot does depend on traffic patterns within the campus and there is no easy answer to how to optimise the network. For example a standard approach to this setup is -

1) have each distribution switch in each building route the vlans for that building. This assumes you do not need the same vlan or more specifically the same IP subnet,in multiple buildings

2) each distribution switch would then connect to the core switches with L3 uplinks not L2. Currently if all the inter-vlan routing is done on the core switches then your uplinks will be L2.

the above provides fault-isolation and scales better in my opinion. But obviously i am not suggesting you do this as it would need a complete redesign of the network.

There is no easy answer to how to optimise but i would look at changing STP root and secondary and the answer to that depends on how the vlans are setup.

Are the same vlans spread across multiple sites or does each site have it's own vlans (IP subnets) that are routed off the core switch ?

Jon

[vipinrajrc]

Hi Jon ,

The setup is that VLAN1 spans across the entire infrastructure , All other VLANS confines to spectific locations and each access layer switch handles a seperate VLAN . I am not aware about L3 and L2 uplinks and it 's difference . Could you please help me with that please ? According to your opinion would there be any problems if we go ahead with configuring uplinkfast in the current setup ?

Many thanks ,

Vipin

[Jon Marshall]

Vipin

If your switches support RSTP then use it because it has uplinkfast functionality included ie. there is no need to configure it. If your switches don't support RSTP then yes you can configure uplinkfast but as with all things STP you should do it out of hours. I assume you are talking of configuring each distribution switch with uplinkfast ?

As for the more general design. What is vlan 1 used for ie. is it end user clients or a management vlan for the switches. If your distribution switches are L3 switches here is an alternative design that would show you some of the advantages of L3.

Currently because your connections to the core are L2 then one uplink is presumably blocking. This is assuming your core is not a 3750 switch stack or 6500 VSS. Because vlan 1 spans the entire switch infrastructure an STP loop in vlan 1 could take down the entire campus.

So forgetting vlan 1 for the moment, if all the other vlans (more specifically IP subnets) are confined to each building then you can -

1) route the vlans for each building on their local distribution switch

2) connect each distribution switch to each core switch using L3 links and not L2 trunk links.

3) run a routing protocol between your distribution switches and the core switches. Which routing protocol would depend on the feature set on your distribution switches. Or you can use static routes if each building has summarised address blocks.

the advantages of the above -

1) each distribution switch sees 2 equal cost paths to all remote locations and it can use both links at the same time ie. it will load balance across the links

2) an STP loop in one building is contained within that building ie. it cannot affect any other buildings

3) If you have multiple vlans per building currently to go from one vlan to another the traffic has to leave the buidling, go to the core and then be sent back to the same building. With the distribution switch doing the inter-vlan routing the traffic stays within the same building.

the main disadvantage is that you cannot have the same vlan/IP subnet in multiple buildings. Each vlan/IP subnet is only local to the specific site.

That is the way i would look to design it with the information you have supplied. It provides more fault-isolation and also uses both uplinks from each distribution switch to the core switches.  Any servers that are used by the entire campus could be connected to the core or ideally to a pair of dedicated switches which then connect to the core.

However the above was an example to help you understand. You could not implement this with vlan 1 spanning all sites and even if you could sort that out this would be a major redesign and implemenation task.

Additionally if the core switches were 3750s in a stack or the core switches were 6500 switches running VSS then you can actually design around STP limitations to an extent and have both links from each distribution switch forwarding to the core switches. But you would still face the disadvantages of 2) and 3) from the list above.

Jon

[vipinrajrc]

Hi Jon

Thank you so much . The post was much informative

VLAN55 is the management VLAN in the setup and VLAN1 is a normal VLAN which is used for connecting common machines in different areas. There exists redundant conenctions between Core 1 and Core 2 and both of them were found to be in blocking state . Is it necessary that uplinkfast be enabled in Core Swiches?

Thanks ,

Vipin

[Jon Marshall · Accepted solution]

Vipin

Uplinkfast could solve the problem if one of your distrbution switches was the STP root but not if it is an access-layer switch.

If the core interconect is blocking a much better approach is to first manually set the core switches to be STP root and secondary for all vlans. This would then mean the interconnect between the core switches should go from blocking to forwarding.

However you need to be aware that currently you could have both uplinks forwarding from your distro switches because you don't have a loop because it is being blocked on the core switch interconnect. So if the interconnect starts forwarding then an uplink from each distro switch has to block. This may be an issue if at the moment you actually need both links for traffic.

So you need to work out how much utilisation there is on the links from the distro to the core. The network may have been deliberately setup this way but it is not optimal. For example if you are running HSRP on the core switches and the interconnect is blocked then HSRP messages have to travel via the distro switches which is not good in this design.

This is why using L3 uplinks and limiting the L2 vlans to each distribution switches is more predictable in terms of traffic flows.

You really do need to work out any bandwidth issues before simply changing your STP/RSTP settings. You may not have an issue but if you change it it could have very unpredictable consequences.

Jon