02-09-2015 04:23 AM
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
02-09-2015 07:35 AM
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
02-09-2015 07:37 AM
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.
02-09-2015 08:11 AM
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
02-09-2015 08:12 AM
thank you Aleksandra, this is greatly appreciated.
02-10-2015 10:23 AM
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.
02-09-2015 10:49 PM
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
02-10-2015 12:06 AM
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.
02-10-2015 12:13 AM
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.
02-10-2015 12:46 AM
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?
02-10-2015 01:08 AM
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.
02-10-2015 02:14 AM
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?
02-10-2015 02:27 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide