Code recommendations for X450G2

[davidj_cogliane]

I am looking for a conservative code upgrade recommendation.

We have just under 100 X450G2 stacks deployed on a customers network. Per the software release recommendations page (Updated in March) we are running 21.1.3.7-patch1-4.

We have experiences a know bug on this code twice now. When replacing a failed master the ssh key gets corrupted causing the replacement switch to fail repeatedly.

The tac engineer I was working with recommended 22.3.1.4, but that seems like a step. It is a different major release and does not even have any patches yet. I cannot find the CR he reference but here are the log messages.

10/02/2017 10:02:38.34 Slot-1: 55561c44 8fc40000 lw a0,0(s8)
10/02/2017 10:02:38.34 Slot-1: 55561c40 00000000 nop
10/02/2017 10:02:38.34 Slot-1: 55561c3c 0320f809 jalr t9
10/02/2017 10:02:38.34 Slot-1: 55561c38 8f9990a4 lw t9,-28508(gp)
10/02/2017 10:02:38.34 Slot-1: 55561c34 1091000f beq a0,s1,0x55561c74
10/02/2017 10:02:38.34 Slot-1: 55561c30 <8c440000>lw a0,0(v0)
10/02/2017 10:02:38.34 Slot-1: 55561c2c 00561021 addu v0,v0,s6
10/02/2017 10:02:38.34 Slot-1: 55561c28 0017b080 sll s6,s7,0x2
10/02/2017 10:02:38.34 Slot-1: 55561c24 8e020000 lw v0,0(s0)
10/02/2017 10:02:37.86 Slot-1: Code:
10/02/2017 10:02:37.86 Slot-1:
10/02/2017 10:02:37.86 Slot-1: Process exsshd pid 2119 died with signal 11

We do not want the customer to have to deal with the ssh key bug but we also don't want to open ourselves up to potential new issues by moving to to new of a code version.

Thanks for your thoughts,

[Patrick_Voss]

Hello David,

With any upgrade of code I would recommend looking at the release notes for that version to make sure there isn't any potential issues with the configuration running on the switch.

The solution 2 workaround should prevent the issue form happening at all and prevent any downtime as long as it is done before any SSH attempts are made. I recently had a case where the customer did this and they did not experience any crash.

Hope this helps!

[davidj_cogliane]

Patrick,

Thanks, that is the same article the other engineer found.

The work around is a bit of a rough as of the customer who will usually be looking to get back up and running fast. Both times I encountered this I saved the config as a script, unconfigured the stack, ran easy stacking, loaded the script, enabled ssh. It works but takes a few minutes.

So my only real alternative would be the last patched version of 22.2.x? That should have a little more run time and be fully patched by now.

Unless you advise against it I will likely go the 22.2.x route?

Thanks,