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 port’s 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)?
    Daniel

    Hi 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
    Kevin

    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
    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,
    Bernhard

    Hi 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

  • Rapid PVST+

    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 Alqader

    Hi 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

  • Rapid pvst issues

    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?
    Regards

    Hi,
    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.

  • PVST and Rapid PVST

    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
    Dario

    We 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

  • Entire ipod and Library wiped

    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

  • Servererror: 451 Temporary local problem - please try later (exim / @hotmail)

    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