cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1998
Views
5
Helpful
5
Replies

CAT9K (9410 & 9300) - IOS-XE (Fuji) - slow interface range programming

davidtubbs1
Level 1
Level 1

Having an odd issue with CAT9K running Everest/Fuji (yeah I know no surprise). But I'm seeing odd behavior between code releases that I wasn't expecting.

 

From console (or ssh) on a C9410R running 16.06.03; BOOTLDR 10.6.2r(FC1) I can enter ranges of interfaces for programing and commands return (successful) very quickly. But on an identical C9410R (same card and sup modules) running 10.06.04; BOOTLDR 10.6.2r(FC1) entering a range of interfaces is a snails pace - to the point that it is almost faster to enter each interface's config individually than use range. 

 

I have several C9300-48U running on Fuji 16.8.1r; BOOTLDR 16.8.1r [FC4] that exhibit the same issue with range programming (even with a single switch in stack). 

 

Wondering if anyone else has seen this or if there is a known Bug.. I've not found anything googling, and I've reached out to our SA / SE but haven't heard back yet. The issue is easily repeatable (i have around a dozen on each rev at the moment, but I've paused the rollout of any more devices with 16.06.04 until I have some sort of answer. Main reason for wanting the newer code is to address bug fixes related to Multicast like those in CSCvh81931

5 Replies 5

Leo Laohoo
Hall of Fame
Hall of Fame
Post the complete output to the command "sh proc cpu sort | ex 0.00".

davidtubbs1
Level 1
Level 1

I opened 2 x SSH sessions to each test machine so that I could run 'show proc' while "idle" and while "running commands" to see if there was a difference. Neither switch seems to be maxing out as they are both around 3-4% utilization at "idle" and around 4-5% while "active"

 

From attached:

  • CH1-ZZZZZ is the switch running 16.06.03
  • DF1-XXXXX is the switch running 16.06.04

 

I setup a series of tests running the same command on the same modules on the 2 switches above and timing how long it took from enter to return to command prompt. I chose modules 1-3 (all ports on all 3 modules) and ran the following commands. 

 

  • spanning-tree portfast
  • no spanning-tree portfast
  • description NNNNNN
  • switchport voice vlan XX (XX is the site specific VLAN and same as what was currently on the switch to not disrupt any active users).

There was no discernible difference in the time it took for either switch to run these commands. Commands returned to command prompt in ≈ 1:05.00-1:12.00 (time in m:s.ms).

 

Both sites are relatively new, and we have been making configuration changes at both sites for the past several months. In all previous tests, the CH1 switches performed "quicker" though I don't have exact timers for those. We were also doing larger ranges of modules  (including all modules 1-8 except 5 & 6).

 

Maybe it just 'felt' faster on 16.06.03 than 16.06.04 or perhaps I need to revise my test scenario to "all modules" like we have been doing to see if that is what was making 16.06.03 "faster" ¯\_(ツ)_/¯ 

Reza Sharifi
Hall of Fame
Hall of Fame

It's probably a software bug. I have a 24 port 9300 running Version 16.8.1a, RELEASE SOFTWARE (fc1)

I can do all sorts of interface range combinations with no issues.

1 40    C9300-24UX         16.8.1a           CAT9K_IOSXE

HTH

 

Ricky S
Level 3
Level 3

I have the same issue with various 9200, 9300 and even 2960x switches.  Range commands take for ever.  Same configuration I can paste in other switches and it all goes in smooth.

As an example I am working on a C9200L-48T-4X running cat9k_lite_iosxe.16.12.04.SPA.bin

Just pasted a bunch of commands, went and made some coffee, came back and they are still going in. 

!

!

After I posted the message above, I moved onto configuring C9300-48P with the same configuration snippet that I used on the 9200 above.  Same situation, each command takes at least 10 seconds to go in.  This particular switch is running  cat9k_iosxe.16.12.04.SPA.bin

Time to make another coffee!

**UPDATE--RESOLVED**

I just found out what was causing this on my end.  Decided to come back and update in case anyone else has the same issue in the future. 

 

Well (duh!) ...I have command authorization configured. Each command entered into the CLI must be authorized.  In my case this was happening for each port in the range command.  So if I pasted 10 lines into a range that covers 48 ports, each of those lines has to be authorized 48 times...hence the slowness.

Cheers!

 

Review Cisco Networking for a $25 gift card