Bug in autosmart port macros

[Tim Butters]

Good morning,

I'm observing what appears to be a bug in the smartport feature on our SG300 switches. We use this for our Auto Voice VLAN. We are using our own user defined macro's in place of the ip_phone and ip_phone_desktop as we use native vlans different than what these macro's allow. I believe this to be a bug.

Reproducing steps:

1. Define user based macro - including anti macro:

macro name user_ip_phone
#macro description user_ip_phone
#macro keywords $uservoice_vlan
#
#macro key description: $uservoice_vlan: The voice VLAN ID
#Default Values are
#$uservoice_vlan = 30
#
switchport mode trunk
smartport switchport trunk allowed vlan add $uservoice_vlan
#
spanning-tree portfast
@
macro name no_user_ip_phone
#macro description no_user_ip_phone
#macro keywords $uservoice_vlan
#
#macro key description: $uservoice_vlan: The voice VLAN ID
#Default Values are
#$uservoice_vlan = 30
#
smartport switchport trunk allowed vlan remove $uservoice_vlan
#
spanning-tree portfast
@
macro name user_ip_phone_desktop
#macro description user_ip_phone_desktop
#macro keywords $uservoice_vlan
#
#macro key description: $uservoice_vlan: The voice VLAN ID
#Default Values are
#$uservoice_vlan = 30
#
switchport mode trunk
smartport switchport trunk allowed vlan add $uservoice_vlan
#
spanning-tree portfast
@
macro name no_user_ip_phone_desktop
#macro description no_user_ip_phone_desktop
#macro keywords $uservoice_vlan
#
#macro key description: $uservoice_vlan: The voice VLAN ID
#Default Values are
#$uservoice_vlan = 30
#
smartport switchport trunk allowed vlan remove $uservoice_vlan
#
spanning-tree portfast
@

2. Apply these to the built in macros:

macro auto user smartport macro ip_phone user_ip_phone $uservoice_vlan 30
macro auto user smartport macro ip_phone_desktop user_ip_phone_desktop $uservoice_vlan 30

3. Set an interface to the following:

int gig1

switchport mode trunk

switchport trunk native vlan 10

spanning-tree portfast

spanning-tree bpduguard enable

4. Apply an IP phone to the interface and it will apply the user_ip_phone macro:

int gig1

spanning-tree portfast

spanning-tree bpduguard enable

switchport trunk allowed vlan add 30

switchport trunk native vlan 10

macro description user_ip_phone

!next command is internal.

macro auto smartport dynamic_type ip_phone

5. This is normal behaviour and is what we are expecting. We also expect that when the switch reboots or the interface is changed, the anti macro no_user_ip_phone should be used.

6. Two strange behaviours occur throughout the course of a reboot.

On firmware 1.4.XX, when the switch reboots the anti macro is performed on the interface - however, the no_ip_phone macro is used instead of the no_user_ip_phone. This removes the native vlan information which is what we do not want and we are left with:

int gig1

spanning-tree portfast

spanning-tree bpduguard enable

switchport trunk allowed vlan add 30

macro description "user_ip_phone | no_ip_phone    | user_ip_phone"

!next command is internal.

macro auto smartport dynamic_type ip_phone

On firmware 1.3.5X, when the switch reboots - the same occurs and the anti macro no_ip_phone is run but the config remains the same for some strange reason:

int gig1

spanning-tree portfast

spanning-tree bpduguard enable

switchport trunk allowed vlan add 30

switchport trunk native vlan 10

macro description "user_ip_phone | no_ip_phone    | user_ip_phone"
!next command is internal.
macro auto smartport dynamic_type ip_phone

However on firmware 1.3.5X, I have observed on multiple occasions on different switches, the statement: "macro auto user smartport macro ip_phone user_ip_phone $uservoice_vlan 30" being removed from the config after reboot which sees the default ip_phone and no_ip_phone macro run.

Impact

This is causing a massive impact on our environment. We've had the last few years on version 1.3.5 and the user macros have worked apart from when the switch has rebooted after being in operation for a few months, this is when the "macro auto user smartport macro ip_phone user_ip_phone $uservoice_vlan 30" gets removed and users cannot get data on their port. This has been hard to debug and investigate and seems to happen randomly.

This is why I have tried upgrade to the 1.4.XX firmware, but have discovered the behaviour is even worse and the behaviour I outlined above happens on every reboot of the switch.

We have about 20 to 25 SG300's in production, only one of which is still within it's 12 months, and I cannot troubleshoot with this switch as it's heavily used. Therefore I cannot approach Support directly with this as there are no switches to troubleshoot on - however, I do feel the above behaviour can be reproduced and I suspect there must be some sort of bug in the macro (anti-macro) application on ports following a reboot.

[Aleksandra Dargiel]

Hi Tim,

It is recommended to open ticket with Small Business Support team so they can report as a bug:

http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

Please PM case number.

Aleksandra

[Tim Butters]

Hi Aleksandra,

I have tried but in order for me to do that I need a switch that is less than 12 months old. The only SG300 switch I have that is less than 3 years old cannot be remotely troubleshooted as it is in fairly heavy production.

I have around 20 - 25 SG300 switches spread around my company, all purchased in the last few years.

[Aleksandra Dargiel]

Hi Tim,

This looks more like a problem affecting series rather than configuration assistance. Let me try to recreate the issue so we do not need to perform any tests on your network.

Aleksandra

[Tim Butters]

thank you Aleksandra, this is greatly appreciated.

[Aleksandra Dargiel]

Hi Tim,

I have seen similar issue with inbuilt smartport macro Ip_phone_desktop when removing the phone cause PC to go to VLAN 1 instead of the native vlan on port.

This has been reported already. I wonder if it would not be good workaround for you to assign static smartport macro IP_phone_desktop with different native vlan per interface. I tested this in my lab and have not seen any problem when removing the phone or rebooting the switch.

[jialbert]

Hi Tim,

I saw this problem in 1.4 while not in 1.3.5.

Now there is a solution for this issue, which is to add the trunk native vlan setting to the user defined macro so that it will finally be recovered after reboot.

no macro auto user smartport macro ip_phone_desktop

# disassociated the user macro

macro name u_ip_phone_desktop

#macro keywords $u_native_vlan $u_voice_vlan

#

#macro key description: $u_native_vlan: The native VLAN for trunk

#                       $u_voice_vlan: The voice VLAN ID

#Default Values are

#$u_native_vlan = 10

#$u_voice_vlan = 30

#

#the default mode is trunk

smartport switchport trunk allowed vlan add $u_voice_vlan

smartport switchport trunk native vlan $u_native_vlan

no macro description

#

spanning-tree portfast

@

macro name no_u_ip_phone_desktop

#macro keywords $u_voice_vlan

#

#macro key description: $u_voice_vlan: The voice VLAN ID

#Default Values are

#$u_voice_vlan = 30

#

smartport switchport trunk allowed vlan remove $u_voice_vlan

no macro description

#

spanning-tree portfast auto

@

macro auto user smartport macro ip_phone_desktop u_ip_phone_desktop $u_native_vlan 10 $u_voice_vlan 30

[Tim Butters]

Hi jialbert,

Thanks for this. Yes I agree that adding the switchport trunk native vlan setting to the user macro will provide a workaround for the issue - however, we use different native vlan settings per interface.

Gig1 may be on native vlan 10, gig5 may be on native vlan 12. Both of which have phones plugged in. This is why I didn't include the native vlan setting in my user macro. I don't think there is a way of preserving the native vlan information in the macro at all is there?

I see it happening all the time in 1.4 and there must be behavioral change in the firmware- but in 1.3, the only bug I have found is that the macro auto user smartport macro ip_phone user_ip_phone $uservoice_vlan 30 gets removed from the config on reboot. I cannot reproduce this all the time but I have seen it happen. I have only seen it int switches which are powered on for a very long time before reboot.

[jialbert]

Hi Tim,

Thanks for the information and given this situation, it looks like 1.3.5 is a better option for production network.

The issue found in 1.4.0 will be raised internally.

[Tim Butters]

Thank you for that.

Would there be any reason at all why the macro auto user smartport macro ip_phone user_ip_phone $uservoice_vlan 30 would get removed from a config following a reboot? Would there be any reason as to why it would be removed during power loss to the switch (not a graceful shutdown)? Providing the command is in the startup-config I wouldn't have thought there would be an issue regardless of how the switch is restarted?

[jialbert]

The occasional loss of configuration in 1.3.5 may due to the system is under some sort of exception condition, such as dealing with other tasks, that prevents voice vlan command to be executed.

Auto smart port feature is an automation mechanism and when there is anomaly, some of the macro command lines could get stuck and fail to run.

Moreover, user defined macro adds another layer of overhead for the system to handle. 

While raise of this case will help to investigate and seek enhancement.

[Tim Butters]

Thanks jialbert - I originally saw this error in my environment, where this line of code was removed and was running the original ip_phone macro against the port which totally screwed my environment up.

This is why I upgraded to 1.4 to see if it had been corrected but I now ran into this issue of it happening on every reboot.

Would it be possible to look into the volatility of user macro's and the potential for the set statement to dissapear from the config? Do you need anything from me on this?

[jialbert]

Hi Tim,

Sure that will be part of the investigation. 

Current information on the case is clear and this will raise awareness internally. 

If any further help needed, will contact you, thanks.