Migration to Rapid PVST
A small conundrum which I can't get my head around. can someone please help.
I have a meshed layer 2 network with multiple vlans in my server farm connecting to two core routers. All these devices are running in 802.1d Spanning Tree.
I want to migrate all these to 802.1w Rapid spanning Tree. However all the documentation I read suggets that when I reconfigure a switch to Rapid it will listen on its links to utilise the appropriate protocol (802.1w or 802.1d)in use by the connected switches.
As all my switches work in 802.1d mode as I migrate a switch it will be Rapid capable but will work in 802.1d mode because all the other switches are in this mode.
Changing an attached switch to rapid will result in that listening after the config change and it will only hear 802.1d from the other switches(whether they are rapid or not) because that is what is in use.
Eventually all but one of my switches will be rapid capable but they will all work in 802.1d mode. I'll then make the config change on this last switch, it will listen to waht is being talked (802.1d) and will then come up in that mode.
So all my switches are now rapid capable but are working in non-rapid 802.1d mode.
How do I make them use the 802.1w protocol ????
The config change doesn't take up or down the point to point links and I don't reboot after making the change. Hence from the documentation the port just listens and uses what is being sent from the other end which will be 802.1d!!!
I must be missing something or not understanding things correctly. Can someone please advise how the links become 802.1W
Thanks
Thanks for your help Gents.
I have managed to find a definitive answer to my question by much searching on the Cisco Website and comments made by yourselves.
The definitive answer is:
1. RSTP selectively sends 802.1D-configured BPDUs and topology change notification (TCN) BPDUs on a per-port basis.
2. When a port initializes, the migration-delay timer starts and RSTP BPDUs are transmitted. While the migration-delay timer is active, the bridge processes all BPDUs received on that port.
3. If the bridge receives an 802.1D BPDU after a ports migration-delay timer expires, the bridge assumes it is connected to an 802.1D bridge and starts using only 802.1D BPDUs.
4. When RSTP uses 802.1D BPDUs on a port and receives an RSTP BPDU after the migration-delay expires, RSTP restarts the migration-delay timer and begins using RSTP BPDUs on that port.
The upshot of all this is that when a switch is configured for rapid spanning tree (spanning-tree mode rapid-pvst), the switch initializes its ports. It will immediately start sending RSTP BPDUs. If the Switch on the other end of the link(s) understands RSTP BPDUs it will then start to send RSTP BPDUs. When the migration delay timer expires they will be talking to each other in Rapid spanning Tree mode.
Switch links that have non Rapid switches at the other end will come up in 802.1D mode.
The Switch will then have different links operating in different modes. In essence a hybrid Switch.
Consequently converting a large meshed switch network to Rapid spanning Tree is quite easy and simple. Just change switches one at a time and the links will automatically change to 802.1w where possible and will remain 802.1d where not. Eventually the entire network will progressively become 802.1w as more switches are reconfigured, until it is completely 802.1w
Simple
Similar Messages
-
Migrating from Rapid-PVST+ to MST
We wish to migrate our Rapid-PVST+ network of around 25 switches to MST but for reasons that we believe are valid we do not want to start with the core switches. We want to convert one part of our network first that is connected to the core with a single trunk link.
We are refering to this document: Understanding Multiple Spanning Tree Protocol (802.1s) and in particular the section headed 'Alternate Configuration (Not Recommended)'. We can accomodate the drawbacks of this scenario, and in any case it will only be a temporary setup unitl we complete the migration.
Under 'Invalid Configuration' it states that "If the PVST+ bridge is the root, this bridge must be the root for all VLANs (including the CST, which always runs on VLAN 1, regardless of the native VLAN, when the CST runs PVST+)". My question is if this is strictly correct (the border bridge MUST be the root for all the VLANs) or if the PVST+ sub-section as a whole must contain the root (e.g. the next PVST+ bridge in the topology would also be valid if its priority were high enough)?
DanielHi Daniel,
Let me start by explaining what is the problem with MSTP/PVST+ interoperation. Things to watch out for are direct consequences of the interoperation limitations so it is vital to understand what is going on.
When MSTP region is connected to an (R)PVST+ region, it tries to speak (R)PVST+ and process received (R)PVST+ BPDUs. This process is called PVST Simulation. However, there are major difficulties in this process: the (R)PVST+ uses per-VLAN semantics while MSTP runs instances with VLANs simply mapped onto them. The role and state of an MSTP boundary port is always determined by the IST ( = MSTI0) instance talking to the outside world, and is simply inherited by all instances running in the MSTP region. That means that if the port is discarding in IST, it is discarding in all instances (and hence all VLANs). If the port is forwarding in IST, it is forwarding in all instances (and hence all VLANs). The same goes for every role/state combination. This fact makes it impossible to do any per-VLAN semantics on an MSTP boundary port. Even if you tried to map incoming (R)PVST+ BPDUs into appropriate instances, you could arrive to an unsolvable situation where the port should be discarding for one VLAN and forwarding for another, although they are both mapped to the same MSTP instance.
These limitations are the guidelines according to which the PVST Simulation works. Because the MSTP boundary port should use only IST data when speaking to the outside world (that is how MSTP boundary port should operate according to IEEE specifications), PVST Simulation makes use of it: it takes the IST data and replicates it into PVST+ BPDUs sent out for all VLANs defined on the switch. In other words, an MSTP boundary port speaking to PVST+ region sends one PVST+ BPDU for each VLAN that is defined on the switch, using IST data as the contents of this BPDU. Essentially, this makes the entire MSTP region look like a single huge switch identically configured for each and every VLAN, with the configuration simply taken from the IST.
Doing this is easy. However, the opposite process is much more constraining: an MSTP boundary port tries to process every received PVST+ BPDU using the IST instance. This is where the troubles begin. If all received PVST+ BPDUs are supposed to allow stable and unambiguous determination of the MSTP boundary port role and state, they must be identical, i.e. the same Root Bridge ID, the same Sending Bridge ID, same Root Path Cost, same Sending Port ID, perhaps even the same timers in each received PVST+ BPDU (sorry for the "perhaps" word here - the PVST Simulation is practically undocumented and these are only my experiences - some areas are still white). Failure to meet this requirement, i.e. receiving two or more differing PVST+ BPDUs on an MSTP boundary port, results in PVST Simulation inconsistency and into permanent blocking of that port until the conflicting PVST+ BPDUs cease to be received.
Note that this requirement of receiving identical PVST+ BPDUs is impossible to achieve with current Catalyst switches: every recent Catalyst switch is using Extended System ID, i.e. it inserts the VLAN ID into the Bridge ID when creating a BPDU for a particular VLAN. Even if you configured the PVST+ region so that a single switch was the root bridge for all VLANs, its PVST+ BPDUs would still differ because each of them would carry a different Extended System ID in the RBID/SBID field.
The only way to prevent these problems is to make sure that the MSTP region is considered as the root switch for all VLANs. Because it is the IST whose data is visible outside the MSTP region, this can be accomplished by configuring the bridge priority on the IST root bridge so low that it beats all switches in the PVST+ region and thereby becomes the root bridge for all VLANs.
Now to your questions:
We are refering to this document: Understanding Multiple Spanning Tree Protocol (802.1s) and in particular the section headed 'Alternate Configuration (Not Recommended)'. We can accomodate the drawbacks of this scenario, and in any case it will only be a temporary setup unitl we complete the migration.
That document is a perfect reference. However, it does not describe the troubles related to the PVST Simulation because it does not take the Extended System ID into account. In fact, the scenario with the PVST+ region containing the root bridge for all VLANs is not possible to accomplish with current Catalyst switches. It is ironical that by striving for compatibility between MSTP and Cisco (R)PVST+, Cisco has actually created a situation where it is very easy to be incompatible. So in my opinion, you cannot accomodate for such a setup - you can not afford having a root switch in the PVST+ region because that would most probably lead to MSTP boundary ports being blocked due to PVST Simulation inconsistency.
I shall stress that these problems are created in particular by the PVST Simulation. Switches running pure IEEE STP/RSTP do not cause these problems because they run a single (R)STP instance for all VLANs. An MSTP boundary port can talk to a single external (R)STP always without problems - a single (R)STP can never produce two conflicting BPDUs. It is as easy as that. It is the overdone striving for compatibility with PVST+ BPDUs that is causing these troubles.
Under 'Invalid Configuration' it states that "If the PVST+ bridge is the root, this bridge must be the root for all VLANs (including the CST, which always runs on VLAN 1, regardless of the native VLAN, when the CST runs PVST+)". My question is if this is strictly correct (the border bridge MUST be the root for all the VLANs) or if the PVST+ sub-section as a whole must contain the root (e.g. the next PVST+ bridge in the topology would also be valid if its priority were high enough)?
It is not the border bridge exactly that must be the root bridge for all VLANs. As I explained earlier, the MSTP region talks to the outside world using IST data. If the MSTP region is to become a root bridge for all VLANs, then the IST root bridge priority must be the lowest among all PVST+ bridges. The IST root bridge itself can perfectly be an internal switch somewhere deep inside the MSTP region.
The same would be valid if the PVST+ region was to become the region containing the root bridge for all VLANs. This root bridge can be any switch inside the PVST+ region, not just a boundary switch. However, this would require, among other things, deactivating the Extended System ID which is not possible.
Please feel welcome to ask further!
Best regards,
Peter -
Migration from rapid-pvst to mst
Hi, we need to migrate our switching network (2 6513 and 8 4507 all running ios, we are using more than 200 vlan) from rapid-pvst to mst (we are going to interconnect some non-cisco switch). Is there any suggestion about this migration? Thank you.
Since you're having more than 200 vlan's, this suggestion of migrating from PerVlan RSTP(PVRSTP) to Multiple Spanning Tree (MST) is a good one. Before that ensure whether your cisco ios version supports MST feature. I think your catalyst switches all will support MST. It has2 main advantages.
1.Load Balancing,
2.Less cpu burden.
The following document explains in detail about MST:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml -
Behavior of running PVST+ & Rapid-PVST+ simultaneously?
Say you have a network w/ 10 switches.
9 of them run Rapid PVST, and one runs the legacy PVST.
Would the entire L2 network fall back to legacy PVST, or only the segment where the one switch that's not yet converted to Rapid?
This Cisco doc says: "
When any RSTP port receives legacy 802.1D BPDU, it falls back to legacy STP and the inherent fast convergence benefits of 802.1w are lost when it interacts with legacy bridges."
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a00807b0670.shtml
However, it doesn't really say if the compatibility fall-back applies to just one segment, or the entire network.
Also, what's the best way to migrate from 802.1D to 802.1w?
Is it best to go bottom-up (start from access, distro, then core), or top-down?
I've been doing it bottom-up, but wanted to know if that's appropriate.
thx
KevinDisclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Also believing, like Peter, STP with rapid-STP impacts only the joint segment, I prefer STP root core toward edge conversions. This to get the rapid-STP benefit to the core first, and to be able to selectively chose what "branches" I convert next. I.e. I might not convert from core to edge one hop layer at a time, but might choose a partial "tree" from the core. -
Spanning-tree modes: PVST vs RAPID-PVST
I am upgrading an old network and as I add switches, I would like them to run rapid-pvst, instead of just pvst which is what the older switches are running.
Last I checked (with a Cisco techie at Networkers 2006), it was OK to have trunked switches with different modes (pvst and rapid-pvst)... but now I'm hearing differently from a few other sources.
Can someone please verify if this is a concern and if so, how should one proceed?
Cheers...rapid-pvst+ can be migrated into your pvst+ environment.
rapid-pvst+ configured switches revert to pvst+ to provide interoperability.
cisco recommends configuring the rapid-pvst+ and pvst+ for different STP instances. the rapid-pvst+ root switch must be running rapid-pvst+ and the pvst+ root switch must be running pvst+; as well, the pvst+ switches should be at the edge of the network.
(this being said, upgrade your core first and move outward. keep your pvst+ root switch out of the core where rapid-pvst+ will be running)
please see the following link for more info:
http://www.cisco.com/en/US/products/hw/switches/ps5206/products_configuration_guide_chapter09186a00801ce264.html#wp1150840 -
Rapid-PVST+ Interacting with MSTP
Hi,
we want to implement MSTP at customer side. unfortunately there are some legacy switches who don't understand MSTP.
so we'll have to implement a "hybrid scenario" where the "core" speaks MSTP using instances and the access-switches are
using their "old" spanning tree protocol (talking with the Instance 0 of the MSTP).
now my question:
when the core is migrated to MSTP, is the IST Spanning Tree able to talk with legacy switches in a "rapid way"
(if the support it)?
i found a cisco document which deals with this topic, but i'm not completely sure that it answers my question....
Rapid-PVST+ Interacting with MSTP
An MSTP switch interacts with a Rapid-PVST+ switch in the same way that an MSTP switch interacts
with PVST+ switch. (See IST Interacting with PVST+.) The MSTP switch will send IST BPDUs in
802.1D format on all VLANs to the Rapid-PVST+ switch and IST will consider the port connected to
the Rapid-PVST+ switch to be at the boundary of the MST region.
Has anyone of you experience with such "hybird" MST/Rapid-PVST+ configurations?
thanks a lot for your answers &
kind regards,
BernhardHi Bernard,
In that scenario, as mentioned in the document, the MST region is going to send plain STP BPDUs to the rapid-PVST region. So basically, only STP will be run at the boundary between MST and rapid-PVST. In particular, there will be no proposal agreement possible on the vlans because MST only runs one instance (the CIST, instance 0), while rapid-pvst runs several instances (one per vlan). So the MST side does not have a per-vlan context that would allow it to answer the proposal from each individual PVST+ instance. To be honest with you, that could probably have been enhanced, but the interaction rapid-PVST/MST has never been a priority, as we hope that customers will be able to migrate the whole network to MST and only use this interaction as a temporary solution.
Regards,
Francois -
i'm searching for a document that helps me configuring Rapid PVST+?
Another issue, if you have around 20 VLANs, is it recommended to go to Rapid PVST+ or MST?
Thanks in advance
Abd AlqaderHi Ankur,
Thanks for your response.
i'm confused about the difference between RSTP, PVST+, and Rapid PVST+.
Also, when you have to span the VLANs (around 25 VLANs) across multiple access switches, with 2 uplinks from each to the two 6509 switches (both will be distribution & core). I'm thinking to implement either Rapid PVST+ or MST (manual load balance) with HSRP.
root switch VLAN will be the primary HSRP.
Is this a good design, or do you have another opinion?
Thanks in advance
Abd Alqader -
Hi,
I'm working for a company that has 2x 6500 chasis switches in the main building as Core switches (CORE1 and CORE2). There are 3 other buildings that house employees (Building 2 and Building 3) and a DR site. The "Core" switches at these other buildings are 3750 switches (stacks of 2). The buildings are connected with 1Gb fibre (MM) leased lines in a square:
Since a few days we are seeing alot of spanning tree recalculations on the Core switches of Building 2 and 3 which causes alot of network issues for the people in those buildings. More precisely the Gi1/0/1 interface on both core switches of those buildings (see red crosses in picture) are constantly displaying these messages:
Feb 3 10:25:31 Building2-CORE 801113: 690303: Feb 3 10:24:20.544 cet: RSTP(750): Gi1/0/1 rcvd info expired
Feb 3 10:25:31 Building2-CORE 801114: 690304: Feb 3 10:24:20.544 cet: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0750.
Feb 3 10:25:32 Building2-CORE 801115: 690305: Feb 3 10:24:20.544 cet: RSTP(750): updt roles, information on root port Gi1/0/1 expired
Feb 3 10:25:32 Building2-CORE 801116: 690306: Feb 3 10:24:20.544 cet: RSTP(750): we become the root bridge
Feb 3 10:25:32 Building2-CORE 801117: 690307: Feb 3 10:24:20.552 cet: RSTP(750): updt roles, received superior bpdu on St1
Feb 3 10:25:32 Building2-CORE 801118: 690308: Feb 3 10:24:20.552 cet: RSTP(750): St1 is now root port
Feb 3 10:25:32 Building2-CORE 801119: 690309: Feb 3 10:24:20.552 cet: RSTP(750): synced St1
Feb 3 10:25:32 Building2-CORE 801120: 690310: Feb 3 10:24:20.561 cet: RSTP(750): transmitting an agreement on St1 as a response to a proposal
Feb 3 10:26:21 Building2-CORE 801193: 690383: Feb 3 10:25:10.910 cet: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0750.
Feb 3 10:26:21 Building2-CORE 801194: 690384: Feb 3 10:25:10.910 cet: RSTP(750): initializing port Gi1/0/1
Feb 3 10:26:21 Building2-CORE 801195: 690385: Feb 3 10:25:10.910 cet: RSTP(750): Gi1/0/1 is now designated
Feb 3 10:26:21 Building2-CORE 801196: 690386: Feb 3 10:25:10.910 cet: RSTP(750): updt roles, received superior bpdu on Gi1/0/1
Feb 3 10:26:21 Building2-CORE 801197: 690387: Feb 3 10:25:10.910 cet: RSTP(750): Gi1/0/1 is now root port
Feb 3 10:26:21 Building2-CORE 801198: 690388: Feb 3 10:25:10.910 cet: RSTP(750): St1 blocked by re-root
Feb 3 10:26:21 Building2-CORE 801199: 690389: Feb 3 10:25:10.910 cet: RSTP(750): St1 is now designated
Feb 3 10:26:21 Building2-CORE 801209: 690399: Feb 3 10:25:10.919 cet: RSTP(750): transmitting a proposal on St1
Feb 3 10:26:21 Building2-CORE 801211: 690401: Feb 3 10:25:10.927 cet: RSTP(750): synced Gi1/0/1
Feb 3 10:26:22 Building2-CORE 801212: 690402: Feb 3 10:25:10.927 cet: RSTP(750): received an agreement on St1
And less than a minute later the same again. This is happening with all VLANs. There's about 125 VLANs and all go over the square.
From what I understand this means BPDU packts are not received in time (2 seconds) and spanning tree starts recalculation. We already asked the provider of the leased lines to test them but they claim nothing is wrong with them. It"s also a bit weird that we are seeing this on 2 different places (physically different locations and lines).
CPU usage looks normal (around 14%) on all switches in this square. Since it's happening on 2 locations I don't think a faulty cable or SFP is causing this.
Any ideas from you guys?
RegardsHi,
All links between the buildings are configured as trunks indeed with no VLAN restrictions (all VLANs allowed).
Here is the extract of the command on all 5 switches/stacks:
MAIN-CORE1#sh spanning-tree vlan 750
VLAN0750
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address 001c.0edc.eaee
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 8192
Address 001c.0edc.eaee
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
Gi1/3 Desg FWD 4 128.3 P2p
Gi1/4 Desg FWD 4 128.4 P2p
Gi1/5 Desg FWD 4 128.5 P2p
Gi1/6 Desg FWD 4 128.6 P2p
Gi1/7 Desg FWD 4 128.7 P2p
Gi2/22 Desg FWD 4 128.150 P2p
Gi2/23 Desg FWD 4 128.151 P2p
Po10 Desg FWD 3 128.1666 P2p
Interface Role Sts Cost Prio.Nbr Type
Po11 Desg FWD 3 128.1667 P2p
MAIN-CORE2#sh spanning-tree vlan 750
VLAN0750
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address 001c.0edc.eaee
Cost 3
Port 1666 (Port-channel10)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 16384
Address 001c.0edc.daee
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
Gi1/3 Desg FWD 4 128.3 P2p
Gi1/4 Desg FWD 4 128.4 P2p
Gi1/5 Desg FWD 4 128.5 P2p
Gi1/6 Desg FWD 4 128.6 P2p
Gi1/9 Desg FWD 4 128.9 P2p
Po10 Root FWD 3 128.1666 P2p
Po21 Desg FWD 4 128.1667 P2p
Building2-CORE1#show spanning-tree vlan 750
VLAN0750
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address 001c.0edc.eaee
Cost 7
Port 1 (GigabitEthernet1/0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33518 (priority 32768 sys-id-ext 750)
Address 108c.cf03.1d00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
Gi1/0/1 Root FWD 4 128.1 P2p
St1 Desg FWD 100 128.872 P2p
Gi2/0/1 Desg FWD 4 128.55 P2p
Building3-CORE1#show spanning-tree vlan 750
VLAN0750
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address 001c.0edc.eaee
Cost 11
Port 55 (GigabitEthernet2/0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33518 (priority 32768 sys-id-ext 750)
Address 8cb6.4fb9.7300
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
Gi1/0/1 Root BKN*4 128.1 P2p *LOOP_Inc
St1 Root FWD 100 128.872 P2p
Gi2/0/1 Root FWD 4 128.55 P2p
DR-01#show spanning-tree vlan 750
VLAN0750
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address 001c.0edc.eaee
Cost 4
Port 54 (GigabitEthernet2/0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33518 (priority 32768 sys-id-ext 750)
Address 0013.c37a.e300
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
Gi2/0/2 Root FWD 4 128.54 P2p
Gi1/0/1 Desg FWD 4 128.1 P2p
Fa1/0/13 Desg FWD 19 128.15 P2p
Here is the config of MAIN-CORE1 (I removed most interfaces, VLAN interfaces and ACL's from it):
MAIN-CORE1#sh run
Building configuration...
Current configuration : 44402 bytes
upgrade fpd auto
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
service counters max age 5
hostname MAIN-CORE1
boot-start-marker
boot system flash sup-bootdisk:s72033-ipservicesk9-vz.122-33.SXI6.bin
boot system flash sup-bootdisk:s72033-ipservicesk9-vz.122-18.SXF8.bin
boot-end-marker
security passwords min-length 1
logging buffered 5000000
no logging console
no logging monitor
aaa new-model
aaa authentication login default group radius local
aaa authentication login CONSOLE local
aaa authentication dot1x default group radius
aaa authorization exec default group radius local
aaa authorization network default group radius local
aaa session-id common
clock timezone cet 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
no ip domain-lookup
ip tftp source-interface Vlan60
ip ftp source-interface Vlan60
ip flow ingress layer2-switched vlan 20
ip sla 3
icmp-echo 172.31.99.5 source-ip X.X.X.X
timeout 2000
frequency 5
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo X.X.X.X source-ip X.X.X.X
frequency 5
ip sla schedule 4 life forever start-time now
udld aggressive
udld message time 7
mls qos map cos-dscp 0 10 18 24 34 46 48 56
mls qos
mls netflow interface
no mls acl tcam share-global
mls cef error action freeze
errdisable recovery cause udld
errdisable recovery cause security-violation
errdisable recovery cause psecure-violation
errdisable recovery interval 30
diagnostic bootup level minimal
spanning-tree mode rapid-pvst
spanning-tree vlan 1,21,166,168,210,842-843 priority 16384
spanning-tree vlan 2-3,7,10,17-18,28,41,44,60,70,78,96,110,112 priority 8192
spanning-tree vlan 121-122,125,127,140,169-170,199,209,213-214 priority 8192
spanning-tree vlan 220-221,253-254,299,318-322,343,350,411,415 priority 8192
spanning-tree vlan 420-421,425,430,450-451,460,500-501,540,602 priority 8192
spanning-tree vlan 650,702,710-716,740,750,895,900-902,910,920 priority 8192
spanning-tree vlan 940 priority 8192
spanning-tree vlan 20 priority 9
spanning-tree vlan 40 priority 8191
redundancy
main-cpu
auto-sync running-config
mode sso
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
class-map match-any test
class-map match-all DoubleTake_map
match access-group name DoubleTake
policy-map DoubleTake_Pol
class DoubleTake_map
set ip dscp af41
interface Port-channel10
description connection between cores
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
mls qos trust cos
interface GigabitEthernet1/3
description Trunk To access-sw1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 17,20,100,112,140,209,300,740,750
switchport mode trunk
switchport nonegotiate
mls qos trust cos
interface GigabitEthernet1/4
description Trunk To access-sw2
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 17,20,27,100,112,209,740,750
switchport mode trunk
switchport nonegotiate
interface GigabitEthernet1/5
description Trunk To access-sw3
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 17,20,70,112,209,221,740,750,901,902
switchport mode trunk
switchport nonegotiate
interface GigabitEthernet1/6
description Trunk To access-sw4
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,17,20,28,60,70,100,112,140,209,220,300,343
switchport trunk allowed vlan add 350,540,602,640,641,740,750,840-842,902
switchport mode trunk
switchport nonegotiate
mls qos trust cos
interface GigabitEthernet1/7
description Trunk to DR
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
speed nonegotiate
mls qos trust cos
interface GigabitEthernet2/22
description Link to FW1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,40,165,211-214,220,318,420,451,501,650,651
switchport trunk allowed vlan add 750
switchport mode trunk
logging event link-status
logging event spanning-tree status
load-interval 30
interface GigabitEthernet2/23
description link to FW1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 78,121,122,124-127,221,319-322,411,415,425,430
switchport trunk allowed vlan add 450,460,461,465,602,712,713,716,750
switchport mode trunk
logging event link-status
logging event spanning-tree status
load-interval 30
mls qos trust dscp
spanning-tree portfast edge
interface GigabitEthernet5/1
description Trunk To MAIN-CORE2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
mls qos trust cos
channel-group 10 mode on
interface GigabitEthernet5/2
description Trunk To MAIN-CORE2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
mls qos trust cos
channel-group 10 mode on
ip default-gateway X.X.X.X
ip classless
ip forward-protocol nd
ip forward-protocol udp discard
ip route X.X.X.X Y.Y.Y.Y
ip http server
ip http access-class 39
ip http authentication local
no ip http secure-server
ip flow-export source Vlan20
ip flow-export version 9
ip flow-export destination X.X.X.X 2000
ip radius source-interface Vlan20
logging trap debugging
logging source-interface Vlan20
logging X.X.X.X
tftp-server sup-bootdisk:s72033-ipservicesk9-vz.122-33.SXH1.bin
snmp-server community X
snmp-server ifindex persist
snmp ifmib ifindex persist
radius-server host X.X.X.X. auth-port 1645 acct-port 1646 key 7 Y
radius-server host X.X.X.X auth-port 1645 acct-port 1646 key 7 Y
control-plane
dial-peer cor custom
line con 0
exec-timeout 20 0
privilege level 15
password 7 Y
logging synchronous
login authentication CONSOLE
stopbits 1
line vty 0 4
session-timeout 300
access-class vty_mgmt in
transport input telnet
line vty 5 15
session-timeout 60
access-class vty_mgmt in
transport input telnet
exception core-file
mac-address-table notification mac-move
ntp clock-period 17179825
ntp source Vlan20
ntp master 1
end -
IE-2000-4TS-B or IE-2000-4TS-L1 support PVST+ or Rapid PVST+ ?
Hello. I need to know IE-2000-4TS-B or IE-2000-4TS-L1 support PVST+ or Rapid PVST+ ? This very important to me. In datasheet I can't find this information. I was try ask this in our - Russian CISCO support on last week but they are still don't answer me. I want know this as quickly as possible,else industrial network will be designed on MOXA switches with MSTP support (less preferably).
Hello,
Based on the switch configuration guide for 15.0(1)EY, both PVST+ and Rapid PVST+ are supported on the IE 2000:
The switch can use either the per-VLAN spanning-tree plus (PVST+) protocol based on the IEEE 802.1D standard and Cisco proprietary extensions, or the rapid per-VLAN spanning-tree plus (rapid-PVST+) protocol based on the IEEE 802.1w standard.
Source: http://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie2000/software/release/15-0_1_ey/configuration/guide/scg-ie2000/swstp.html -
Which spanning tree protocol is preferred PVST or rapid-PVST and why?
I have WS-C2960G-24TC-L and Cisco 3750G switches, I have option to configure PVST spanning tree or rapid-pvst. Please let me know which is better and why? also send me some document explaining both protocols in detail.
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
As Alex has noted, normally rapid-PVST should be preferred.
Depending on needs (and device support), MST might be better yet. -
Does it matter if you have lets say pvst on one or more switches on the same network and rapid pvst on other switches on the same network?
They're backwards compatible, but you'll lose the advantage of Rapid-pvst when connected to a pvst switch.
HTH,
John
*** Please rate all useful posts *** -
PVST+ vs rapid-PVST+
I have a network which consists of 28 2955C switches connected in a ring. The spanning tree works correctly if all of the switches are configured for PVST+. However if all of the switches are configured for rapid-PVST+ then multiple problems occur. Among them multiple roots, multiple switches disappearing from the network etc. Anyone know why?
Hello,
without knowing the exact details of your setup, make sure that all your VLANs are part of MST, since you cannot run PVST and MSTP at the same time. Also, try and set the root switch for your MST instance(s) manually, by using the 'spanning-tree mst instance-id root' command on the respective root switch.
HTH,
GNT -
Dell STP and Cisco Rapid-PVST+ interoperabillity
Referencing to this doc:
https://supportforums.cisco.com/docs/DOC-16177
which was very helpful, I noticed that I'm getting this error message:
%SW_MATM-4-MACFLAP_NOTIF: Host d067.e5cc.2e49 in vlan 1 is flapping between port Po11 and port Po12
I have Dell PC6248 connected to C3560 with two port channels. In fact, I have two Dell switches in a stack. As document describes, I configured MST on both switches and that resolved slow convergence of network, but above message now appears.
That MAC address is no host:
Cisco switch
Dell switch
Cisco switch:
Router_Switch#sh mac address-table
Mac Address Table
Vlan Mac Address Type Ports
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
All 0180.c200.0000 STATIC CPU
All 0180.c200.0001 STATIC CPU
All 0180.c200.0002 STATIC CPU
All 0180.c200.0003 STATIC CPU
All 0180.c200.0004 STATIC CPU
All 0180.c200.0005 STATIC CPU
All 0180.c200.0006 STATIC CPU
All 0180.c200.0007 STATIC CPU
All 0180.c200.0008 STATIC CPU
All 0180.c200.0009 STATIC CPU
All 0180.c200.000a STATIC CPU
All 0180.c200.000b STATIC CPU
All 0180.c200.000c STATIC CPU
All 0180.c200.000d STATIC CPU
All 0180.c200.000e STATIC CPU
All 0180.c200.000f STATIC CPU
All 0180.c200.0010 STATIC CPU
All ffff.ffff.ffff STATIC CPU
1 d067.e5cc.2e49 DYNAMIC Po11
255 d067.e5cc.2e47 DYNAMIC Po11
Total Mac Addresses for this criterion: 22
WSS_Dell_PC6248#show bridge address-table
Aging time is 300 Sec
Vlan Mac Address Port Type
1 04C5.A464.301F ch1 Dynamic
1 04C5.A464.3025 ch2 Dynamic
1 04C5.A464.3028 ch1 Dynamic
255 04C5.A464.3045 ch1 Dynamic
255 D067.E5CC.2E47 cpu Management
Total MAC Addresses in use:5
VLAN 255 is mgmt vlan. I didn't get that message before using mst.
Configuration of trunk ports on Dell:
interface port-channel 1
description 'TRUNK_3560_1'
switchport mode general
switchport general allowed vlan add 10,255 tagged
exit
What seems to be the problem here?CISCO 3560:
Router_Switch#show spanning-tree mst 0
##### MST0 vlans mapped: 1-4094
Bridge address 04c5.a464.3000 priority 32768 (32768 sysid 0)
Root this switch for the CIST
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
Fa0/25 Desg FWD 200000 128.29 P2p
Po11 Desg FWD 100000 128.136 P2p
Po12 Desg FWD 100000 128.144 P2p
Router_Switch#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
11 Po11(SU) - Fa0/33(P) Fa0/35(P)
12 Po12(SU) - Fa0/27(P) Fa0/36(P)
DELL:
WSS_Dell_PC6248#show interfaces port-channel
Channel Ports Hash Algorithm Type
ch1 Active: 1/g48, 2/g48 3
ch2 Active: 1/g47, 2/g47 3
(output omited)
WSS_Dell_PC6248#show spanning-tree mst-configuration
Name: D0-67-E5-CC-2E-47
Revision: 0
Instance Vlan Mapped
0 1, 10, 20, 255
WSS_Dell_PC6248#show spanning-tree
Spanning tree Enabled BPDU flooding Disabled Portfast BPDU filtering Disabled mode mstp
CST Regional Root: A0:00:D0:67:E5:CC:2E:47
Regional Root Path Cost: 0
###### MST 0 Vlan Mapped: 1, 10, 20, 255
ROOT ID
Address 04:C5:A4:64:30:00
Path Cost 100000
Root Port ch2
Hello Time 2 Sec Max Age 20 sec Forward Delay 15 sec
Bridge ID
Priority 40960
Address D0:67:E5:CC:2E:47
Hello Time 2 Sec Max Age 20 sec Forward Delay 15 sec TxHoldCount 6 sec
(output omited)
1/g47 Enabled 128.47 0 FWD Disb No No
1/g48 Enabled 128.48 0 FWD Disb No No
(output omited)
ch1 Enabled 96.626 100000 DSC Altn No No
ch2 Enabled 96.627 100000 FWD Root No No
(output omited) -
Questions VLAN design best practices
As per best practices for VLAN design:
1) Avoid using VLAN 1 as the “blackhole” for all unused ports.
2) In the local VLANs model, avoid VTP (use transparent mode).
Point 1
In a big network, I'm having VLAN 1 as the blackhole VLAN. I'd like to confirm that, even if we're not complying with best practices, we're still doing fine.
a) all trunk ports on all switches have the allowed vlans explicitly assigned.
b) about all ports on all switches are assigned to specific data/voice vlans, even if shutted down
c) the remaining ports (some unused sfp ports for example) are shutted down
d) we always tag the native vlan (vlan dot1q tag native)
So, no data is flowing anywhere on VLAN 1. In our situation, it is safe to use VLAN 1 as blackhole VLAN?
Point 2
Event if we're using local VLANs model, we have VTP in place. What are the reasons of the best practice? As already said, we allow only specific VLANs on trunk ports (it's part of our network policy), so we do not have undesired layer 2 loops to deal with.
Any thoughs?
Bye
DarioWe are currently using VTP version 3 and migrating from Rapid-PVST to MST.
The main reason for having VTP in place (at least for use) is to have the ability to assign ports to the correct VLAN in each site simply looking at the propagated VLAN database and to manage that database centrally.
We also avoid using the same VLAN ID at two different sites.
However, I did find something to look deeped: with MST and VTP, a remote switch can be root for a VLAN it doesn't even use or as active ports into, and this doesn't feel right.
An example:
1) switch1 and switch528 share a link with allowed vlan 100
2) switch1 is the root for instances 0 and 1
4) VLAN 100 is assigned to instance 1
5) VLAN 528 is not assigned to any particular instance so it goes under instance 0
6) VLAN 528 is the Local Data LAN for switch528 (switch501 has VLAN 501)
swtich528#sh spanning-tree vlan 528
MST0
Spanning tree enabled protocol mstp
Root ID Priority 24576
Address 1c6a.7a7c.af80
Cost 0
Port 25 (GigabitEthernet1/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768 (priority 32768 sys-id-ext 0)
Address 1cde.a7f8.4380
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
Gi0/1 Desg FWD 20000 128.1 P2p Bound(PVST)
Gi0/2 Desg FWD 20000 128.2 P2p Edge
Gi0/3 Desg FWD 200000 128.3 P2p Edge
Gi0/4 Desg FWD 200000 128.4 P2p
Gi0/5 Desg FWD 20000 128.5 P2p Edge
switch1#sh spanning-tree vlan 501
MST0
Spanning tree enabled protocol mstp
Root ID Priority 24576
Address 1c6a.7a7c.af80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24576 (priority 24576 sys-id-ext 0)
Address 1c6a.7a7c.af80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
Should I worry about this? -
Changing spanning tree modes / potential outages?
Hi All,
Our core / distribution / access layers are all currently configured to use Cisco's PVST+. We are now a fully populated Cisco network with no standards based STP so we can now migrate to Rapid PVST.
By simply changing the spanning tree mode on a an access switch to Rapid PVST will the vlans with spanning tree enabled suffer an outage ? If so will this be time be based on how the rest of the network is configured ? That is, if the rest of the network is still PVST+ and I change a switch to Rapid PVST will the outage deault to around 45 seconds based on PVST+ timers ?
Furthermore, as I understand it, even though this access switch would now be configured for Rapid PVST, the switch defaults back to PVST until the rest of the network (or VLAN) is configured for Rapid PVST.
My second question is this :
Assuming that all the access layer switches have been migrated to Rapid PVST, what would be the effect of then migrating the distributing and potentially core layer devices to Rapid PVST ? Will they also cause an outage on the VLAN on which STP is enabled ? Again, if so, what would the outage be ? Would this be based on PVST timers or Rapid PVST ?
Thanks in advance.
Chris.Mike
No problem and please do come back if needed.
One thing I should have answered from your questions but didn't directly was the question of the mac address of the root switch.
The mac address that is important in the root switch election is the one contained in the BPDU not the source mac address of the BPDU. The source mac address is simply that of the port that transmitted the BDPU.
If a switch flushes it's mac address table it would remove that mac address but that would make no difference as to whether the switch believed it had lost it's path to root or not.
In terms of switch to switch communication BPDUs are sent with a multicast destination mac address so removing that mac address has no effect on BPDUs being exchanged.
So the fact that you are seeing the switch reporting it has lost it's path to root is not a direct consequence of the mac address being flushed because it doesn't need that to send and receive BPDUs.
However with all the flooding of end to end devices because of the flushing an indirect consequence may be that BPDUs are getting lost.
Apologies for not making that clearer.
Jon
Maybe you are looking for
-
Media Encoder is not producing sharp .mp4 exports, any help please?
Hi all, I've been trying for a while now to export my After Effects CC 2014 project using Media Encoder CC 2014 as a MP4 file. I've chosen 'match source' settings, VBR 2 pass with various bitrates (even extremely high bitrate values) but my video is
-
How can I transfer Final Cut Pro 7 projects into Adobe Premiere?
I produced a whole whack of videos in FCP7. Then I got a new Apple Quad Core Intel Mac about a year ago... To find that FCP7 was no longer even usable. I still have FCP 7 on my Intel Core 2 Duo Apple Powerbook. I've read that I can export FCP7 XML fi
-
Im really sorry if this has been posted about before but I just cannot find it anywhere on the discussion boards. Yesterday I purchased some items from the itunes store, I havent upgraded to the latest version of itunes as I had heard people having t
-
Drobo NAS and Time Machine restore problems
My HDD crashed. I installed a new one. Reinstalled OSX Mavericks and tried a Migration Assistant from a DROBO 5N NAS (holding the Time Machine sparse.bundles). Profiles reinstalled, no data, no applications. Weird. I have tried Drobo, I have tri
-
Hello, a customer of mine has issues sending email to @hotmail/@live/@outlook mail addresses. the problem only occurs with these Microsoft addresses! when sending an email they get an error email reply (generated from within outlook) from "systemmana