SG350X - possibly weird macro behavior on FW 2.5.8.15

[christian.rudolph]

Hello everyone,

updated a stack of 3 SG350X-48MP last weekend from FW 2.5.7.85 -> 2.5.8.15. Update procedure completed successfully but got caught by the "you cannot login after fw update anymore if your password contains special characters". Therefore carried out the procedure "administrator-password-recovery-for-300-and-500-series" successfully and set a new password without specials characters. Everything OK so far.

By comparing the saved "running configs" (before FW upgrade / after FW upgrade) afterwards I noticed some strange differences. See picture below (left side running-config FW 2.5.7.85 | right side running-config FW 2.5.8.15):

List of installed macros as follows:

#show parser macro brief              
default interface : ap, no_ap
default interface : desktop, no_desktop
default interface : guest, no_guest
default interface : host, no_host
default interface : ip_camera, no_ip_camera
default interface : ip_phone, no_ip_phone
default interface : ip_phone_desktop, no_ip_phone_desktop
default interface : printer, no_printer
default interface : router, no_router
default interface : server, no_server
default interface : switch, no_switch

Firmware as follows

sh ver
Active-image: flash://system/images/image_tesla_hybrid_2.5.8.15_release_cisco_signed.bin
  Version: 2.5.8.15
  MD5 Digest: 2e8ebc72af122e80edd3b8989609daa8
  Date: 05-Oct-2021
  Time: 17:30:57
Inactive-image: flash://system/images/image_tesla_cbs350_hybrid_2.5.7.85_release_cisco_signed.bin
  Version: 2.5.7.85
  MD5 Digest: e766e20b0d080a72db3ec00888d595a0
  Date: 18-Jan-2021
  Time: 21:15:01

Is there anything I have to worry about? How can I correct the strange macro display / naming. Are the the macro in question applied successful or is there any malfunction to expect now?

Thanks in advance for your effort.

Regards,

Christian

[balaji.bandi]

looks for me some bug here, if you have a maintenance window,. try no macro save and reload and enable macro and test it?

[christian.rudolph]

Hi,

thank you for your suggestion. Unfortunately there is no maintenance window in the near time. The stack is in production.
I had have discovered some more anomalies:

#show macro auto ports
SmartPort is Enabled
Administrative Globally Auto SmartPort is controlled
Operational Globally Auto SmartPort is enabled

 Interface   Auto SmartPort   Persistent          SmartPort Type          
             Admin State      State                                       
----------- ----------------- ----------- ------------------------------- 
 [... other ports removed from output ...]        
  gi3/0/1       disabled        enabled               default             
  gi3/0/2        enabled        enabled               default             
  gi3/0/3        enabled        enabled               default             
  gi3/0/4        enabled        enabled               unknown             
  gi3/0/5        enabled        enabled               default             
  gi3/0/6        enabled        enabled               unknown             
  gi3/0/7        enabled        enabled               unknown             
  gi3/0/8        enabled        enabled               unknown             
  gi3/0/9        enabled        enabled               unknown             
 gi3/0/10        enabled        enabled               unknown             
 gi3/0/11        enabled        enabled               unknown             
 gi3/0/12        enabled        enabled               unknown             
 gi3/0/13        enabled        enabled               unknown             
 gi3/0/14        enabled        enabled               default             
 gi3/0/15        enabled        enabled               default             
[... other ports removed from output ...]

All ports currently connected to an SNOM IP-Phone are shown in the output above as SmartPort-Type "unknown".
Drilled down to the two ports shown in the running-config of my starting post:

#show macro auto ports ge3/0/6
SmartPort is Enabled
Administrative Globally Auto SmartPort is controlled
Operational Globally Auto SmartPort is enabled
Auto SmartPort is enabled on gi3/0/6 
Persistent state is persistent
Interface type is unknown
No macro has been activated
#show macro auto ports ge3/0/7
SmartPort is Enabled
Administrative Globally Auto SmartPort is controlled
Operational Globally Auto SmartPort is enabled
Auto SmartPort is enabled on gi3/0/7 
Persistent state is persistent
Interface type is unknown
No macro has been activated

Note the "Interface type" is "unknown / No macro has been activated".

My hypothesis: the whole thing does not completely blowed up only because of the port-setting "Persistent state is persistent". Therefore the confugration of the VoIP-ports "survived" the (now broken) new firmware only because they were properly configured by the older firmware when a VoIP-phone plugged into the respectively ports and this configuration was/is "sticky" at present time.

Next step I will do if on site: plug in a VoIP-Telephone in an uncofigured port an check if the auto macro ist fired/applied on that specific port.

I have the feeling, my customer is in some danger now losing his ability to communicate with VoIP if something unforseen happening to the switch / infrastructure.

CISCO - any offical thoughts?

Thank you all in advance.

Regards

Christian