Whats up with show tech on ASR9K

[Peter L]

Hi

Just wondering what the thoughts was when the show tech command was designed in IOS-XR? Opened a case yesterday and was asked to do 6 different show tech captures. It took between 30 min and 60 min for each showtech file to run. That's maybe ok when you have a minor fault but in this case we had customer disturbances. Isn't that fun to sit and wait then....

Understand that you want to collect as much data as possible when doing a show tech but think its kinda ridiculous now. Maybe time to introduced show tech xxxx brief?

/Peter

[Aleksandar Vidakovic]

hi Peter,

there are two elements that cause the show tech collection to be slow on IOS XR: (1) IOS XR is highly distributed, information needs to be collected from all LC CPUs in the system and sometimes pulled from HW as well. (2) Almost all processes keep running trace files so that we can troubleshoot past events without requesting debugs and waiting for the issue to reoccur; these traces are always collected as part of the respective show tech.

While collecting a "show tech xxxx brief" may beat the purpose of a show tech, what we can look into is to make a show tech more specific. For example "sh tech-support cef" has on option to limit the output to a single prefix: "sh tech-support cef ipv4 x.x.x.x". We can evaluate the other show techs for similar optimisation.

In some scenarios, unfortunately, a full show tech may be required.

Can you share the TAC SR#  and the list of show techs that you were asked to collect?

Aleksandar

[Peter L]

Hi Aleksandar

The SR was 63700125. This is the show tech commands i was asked to run.

show tech

show tech-support bundles interface pw-ether <interface>
show tech-support dhcp ipv4 proxy
show tech-support ipsubscriber
show tech-support l2vpn
show tech-support arp
show tech-support subscriber

Understand that you want to collect as much info as possible and it takes time on a distributed system and the trace files is large. But when it take 60 min to collect the data i think you are collecting to much data, at least from a customer perspective. This should at least not be default behavior and maybe you should add a warning when running show tech that this will take time...

Still think it would be good with a show tech brief or something similar that collect the most important stuff in an IOS/IOS-XE manner that we can use if you have a critical error that you want some information collected on, before you do a reboot or something like that. 

Regards Peter

[mike-stevenson]

Hmm I don't suppose you would be having issues with PWHE and IPoE subscribers.. not getting arp responses to requests for the cpe default gateway after the subscriber session comes up? been there..  good luck on that.

[Peter L]

Hi Mike

Doesn't know yet but it's seems to be arp related. Have you had problem with arp on 5.2.4 when running bng-pwhe? Want to share your SR so i can send that to the TAC.

/Peter

[mike-stevenson]

Hi Peter,

yes we had major problems with this, ended up falling back to using a handbag interface (i.e. ethernet looped between interfaces)  our SR was SR 635645739  this lead to CSCuv71988.

cheers

[Peter L]

Hi Mike

Thanks for the info. Will update my TAC engineer with this and see if we are hitting the same bug. 

[Fredrik Lönnman]

Haha wait, what.. a bug in the officially BNG hardened release 5.2.4, causing ARP replies not to be sent on PWHE interfaces, which I'm guessing are rendering the feature useless, without a workaround or fix for 6 weeks and it's classified as Sev6 enhancement?

Surely this must be a bad joke.