This is a little off the subject, but may a part. Cisco being Cisco has some variances in MST's adherence to the IEEE 802.1s standard. In certain IOS's the MST BPDU's are tagged, while some are not. Not tagging is what the 802.1s standard calls for. Outside of the bug ID's below. Workgroup switch (2960, 3750, 3560, ME-3400, etc...)IOS's 12.2(44)SE and below send the MST BPDU's untagged. 12.2(46)SE and above send the frames tagged. Cisco 7600 series IOS's up to 12.2(33)SRD send the frames untagged...while those IOS's below it send the frames tagged. This also affects the 6500 (think it's fixed in SXI??)..not sure what other platforms maybe affected...
I have been told by TAC that the IOS version 12.2(52)SE for the LAN switches will have the MST BPDU tag issue fixed...ETA 09/29/09. Hope this saves someone a few grey hair :-) CSCsm12766 "vlan dot1q tag native" feature doesn't work on C3750 switches This bug was fixed in 12.2(46)SE and so switches running this and above versions got affected. CSCsv91358 dot1q tag native and voice vlan expect tagged traffic on an access port This bug was fixed in 12.2(50)SE and later codes and so 3560 switches running these codes got affected. These bugs fixes were also ported for other platforms causing this issue. Now to address this issue, there were two bugs filed, one on 6500 platform and another on 3750 switches as below: CSCta17209 Port put into dispute in MST due to agreement BPDU tagged incorrectly Symptom: Port put into blocking due to P2P dispute after upgrade to 12.2(50)SE+ while using MST. Conditions: The upstream switch needs to have vlan dot1q tag native configured and the root does not. The agreement BPDU being sent from the upstream swtich is being incorrectly tagged with the native vlan dot1q tag and is causing the port to go into dispute status. Workaround: Configure dot1q tag native on the root or unconfigure dot1q tag native on the upstream switch. This bug is currently not fixed in any new versions. CSCsk33045 MST BPDU *must* be sent untagged, even when the switch is configured wit In order to be compliant with the IEEE 802.1s standard, the MST BPDU *must* be sent untagged, even when the switch is configured with the "tag native" command. As per the 12.2(18)SXF IOS release on the Catalyst 6500, this is not happening and therefore can cause interoperability issues with other vendors -----Original Message----- From: Andy Saykao [mailto:[email protected]] Sent: Friday, August 28, 2009 2:50 AM To: Lincoln Dale Cc: [email protected] Subject: Re: [c-nsp] MST and Uplinkfast Hi Licoln, We may have to do what you have suggested - thanks for the suggestion. I labbed all this up today with mixed results. Basic access layer switch with an access port (laptop pulgged into it) and two links out (one to dist1-switch and one to dist2-switch). Each dist switch connecting to a core switch. I then shut the primary link on the access switch to see what happens to the access port. I also had a constant ping from the core switch to the laptop. Vanilla config on access switch: interface GigabitEthernet1/0/1 description Laptop plugged in switchport access vlan 2 switchport mode access no ip address Results: 2950 - PVST (access port stays forwarding) - MST (access port goes through blk,list,lrn) - IOS 12.1(22)EA8a 3750 - PVST (access port stays forwarding) - MST (access port stays forwarding) - IOS 12.1(19)EA1 3560 - PVST (untested but should stay forwarding) - MST (access port goes through blk,list,lrn) - IOS 12.2(40)SE MST's uplinkfast implementation seems to behave differently depending on which hardware platform you're using. If you've got 2950's and 3560's in your network, you'll have to set the access ports to portfast and enable bpduguard. No need to configure anything on the 3750's (although it would be best practice to also define these access ports as edge ports). Cheers. Andy -----Original Message----- From: Lincoln Dale [mailto:[email protected]] Sent: Friday, 28 August 2009 12:07 PM To: Andy Saykao Cc: [email protected] Subject: Re: [c-nsp] MST and Uplinkfast On 28/08/2009, at 9:18 AM, Andy Saykao wrote: > I have noticed that with MST and rapid failover that those ports which > are not boundary ports or do not have portfast enabled go through the > blocking, listening and learning states again before forwarding. whether its PVRST+ or MST used, you should always mark your 'edge' port correctly as being 'edge' such that they are operating as "portfast" with "bpduguard". it sounds like you have edge ports configured as "network" ports - so the system HAS to wait for the "forwarding delay". since you're saying that is 30 seconds not 15 seconds, that implies the system is falling back to legacy (802.1D-2004) behavior. cheers, lincoln. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organisation. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
