Bug in autosmart port macros

Question

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.

Answer 1

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