cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1158
Views
0
Helpful
12
Replies

Catalyst 2900S few questions

avilt
Level 3
Level 3

1) I have two Catalyst 2900S switches interconnected with 2 uplinks on port 1/0/47 and 1/0/48, hard coded as trunk.

If I hard code the speed and duplex on both switches, all 4 trunk ports go down. What is the reason and recommendation?

2) Both switches are in PVST mode, by default even though pvst is enabled they work just like CST right? Because I can see one port on non-root switch as BLK for all the vlan's and another as FWD for all the vlans.

1 Accepted Solution

Accepted Solutions

1) There is your answer - connecting switch to switch MUST be an x-over.  Unless you use the auto-MDIX feature, then the switchport s MUST be auto/auto.  If you change the speed/duplex you disable auto-MDIX then the switchport will go down as you now have a straight cable between switches which will NOT work.

2) if you have more than 1 uplink between a switch, 1 port will be forwarding, the others will be blocking; this is default for any spanning-tree.

View solution in original post

12 Replies 12

andrew.prince
Level 10
Level 10

1) Are you using straigth thru cables or x-over.  If you set the speed and duplex the auto-MDIX feature is disabled

2) CST is 1 spanning-tree instance for ALL VLANS. PVST and PVST+ as the name suggests PVST = Per VLAN Spanning-Tree

HTH>

1) I am using straigh thru cable since auto-MDIX is on.

2) I am aware of the difference between CST & PVST. I would like to know the default behaviour when 2 switches connected by multiple uplinks with multiple vlan's. What I see is on one uplink, all vlans are in FWD state and other up link BLK for all the vlans which is similar to CST.

1) There is your answer - connecting switch to switch MUST be an x-over.  Unless you use the auto-MDIX feature, then the switchport s MUST be auto/auto.  If you change the speed/duplex you disable auto-MDIX then the switchport will go down as you now have a straight cable between switches which will NOT work.

2) if you have more than 1 uplink between a switch, 1 port will be forwarding, the others will be blocking; this is default for any spanning-tree.

1) Understood the point 1.

2) Does it mean that for PVST, I need to manually define the mapping between uplinks and Vlans manually?

I don't understand the question please clarify!

With PVST, I was expecting 2 vlans in FWD state on one uplink and another 2 vlans to be on FWD state on another uplink as I have 4 vlans in toal. But by default this is not the case, all 4 vlans are in FWD state on one uplink alone.

Why would you expect that? 

Use your favorite search engine and search for "spanning-tree root bridge"

So unless I explicitely define root bridge for particular vlans, one uplink will be in FWD state for all the vlans and another uplink will be in BLK state for all the vlan even though pvst is enabled. Am I right?

yes

avilt wrote:

With PVST, I was expecting 2 vlans in FWD state on one uplink and another 2 vlans to be on FWD state on another uplink as I have 4 vlans in toal. But by default this is not the case, all 4 vlans are in FWD state on one uplink alone.


You could get this to work as you expect but it would be difficult in the situation you have described. With PVST you can have a different root-bridge for different VLAN's. Using this you could theoretically get 2 vlans active on one port and 2 vlans active on another, however to do so you need to have different root bridges for the different VLAN's and in each case the link to go to FWD mode must be closer to the root-bridge (for that VLAN) than the alternative link (same priority is broken by port number if I remember correctly so all VLAN's on one port would be normal occurence in the situation you describe). For the life of me I can't think how you could get two links going to and from the same place to see different priorities in electing the forwarding state link. It might not be possible, or maybe it is but I'd have to go do some reading on the spanning tree commands again to find out. Though in the case of same source and destination switch for two links isn't etherchannel the most prefered option anyway? Load Balancing via PVST is best used if you have multiple different paths to get somewhere and would prefer some VLAN's to divert one direction and others another. Prime example is HSRP, use priority and premption to define which switch/router is normally the active unit in HSRP and make sure traffic on VLANs that switch is active for flows to that switch first. In case the link (and only the link not the active HSRP switch/router) goes down, PVST would get traffic to the still active HSRP device via the standby unit. However now that we have link state tracking and can dynamically adjust priorities based on links failing there is probably much less need for this type of solution.

Thank You for the explanation. It's in a lab setup and I was curious to know about PVST implementation scenarios.

Of course in production with 2 siwthces I will go for ether channel with LACP.

Could you give me some scenarios/examples where PVST is most approproiate.

Cool, No worries.

Um, none. Use RPVST+ unless you are working with a multivendor environment. And If possible, just don't use any STP at all. I guess you should still configure it, stop stupid people from breaking stuff, but a properly tuned routing protocol will offer faster convergence and more predictiable operation so if you can taker Layer 3 to the network edge, do that. Otherwise there is a great range of products that offer support for Multi Chassis Ethernet through switch stacking and VSS, etc. If you do have to use some form of STP, try and keep it to the edge of the network in small domains (ie Within 1 network closet or at worst within a building), use RPVST+ and spend some time tuning it (timers) to achieve faster convergence.

As I mentioned earlier, any per-VLAN STP works well in a case that you have redundant paths back to the L2-L3 interface It's an old network design I'm slowly making go away now but we used to have approx 150 VLAN's spread across 2 core routers running HSRP on both. Adding RPVST+ to this and configuring properly worked perfectly. The systems had different priority for each HSRP instance making one router the prefered active unit, load balancd by prefering different routers be active for different VLAN's. We used RPVST+ and set the prefered active router as the root bridge for that particular VLAN and had all our distribution layer switches dual-connected to each router. For every VLAN the link to the standby HSRP router would block and the link to the active HSRP router would enter the forwarding state. It didn't happen a great deal but you could then also run dual uplinks between distribution and access layers (one access switch to two distribution layer switches), since the HSRP was evenly balanced half the VLAN's would use one upline and half would use the other and enter the blocking state for opposite VLAN's. No tracking of interfaces and changing HSRP priorities etc. If a core router failed HSRP became active for everything on one router, if a distribution layer switch lost access (contractors dig up a fibre) the cross connect between the core switches/routers would enter forwarding state for those VLANs and continue to provide access. You get the idea, same thing again for access layer loosing one connection to distribution layer. The problem of course is that the network is so flat it becomes a pain to manage. Hence it is now going away for a much better model that invloves less layer 2 spanning and more layer 3.

Review Cisco Networking for a $25 gift card