[c-nsp] MST and Uplinkfast

Fri Aug 28 07:41:10 EDT 2009

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:andy.saykao at staff.netspace.net.au] 
Sent: Friday, August 28, 2009 2:50 AM
To: Lincoln Dale
Cc: cisco-nsp at puck.nether.net
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:ltd at cisco.com] 
Sent: Friday, 28 August 2009 12:07 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
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.