Re: VTY service set - VTYTutorial crashes 2911

viktor.s.wold.eide · ‎01-08-2015

Hi,

We have requested several API extensions, including for configuring the ip ospf cost on an interface:

ip ospf cost <VALUE>

So far this functionality has not been provided and hence are looking at alternative approaches. We really would like to avoid using the VTY service set, but we are looking into that as an intermediate solution.

When trying to run the VTY tutorial using 2911 routers, they crash immediately and consistently. This is not very encouraging, so we wanted to know if this is a known problem for the 2911 or not?

Our 2951 routers on the other hand, do not crash when running the VTY tutorial application.

We are using the following software version: sdk-c64-1.3.0.181

Router version and image, see below:

Application output (just hangs as router crashes).

./bin/VTYTutorial -a 10.0.225.55 -t tls -P pinfile

Enter username:

Enter password:

Connect to the Network Element

Create a VTY Object

Open the VTY to the Network Element

Get a timeout of the VTY to the Network Element : 0

Writing a command VTY to the Network Element ... "show onep status"

Response -

Status: enabled by: Config

Version: 1.3.0

Transport: tls; Status: running; Port: 15002; localcert: TP-self-signed-3721331056; client cert validation disabled

Certificate

Transport: tipc; Status: disabled

Session Max Limit: 10

CPU Interval: 0 seconds

CPU Falling Threshold: 0%

CPU Rising Threshold: 0%

History Buffer: Enabled

History Buffer Purge: Oldest

History Buffer Size: 32768 bytes

History Syslog: Disabled

History Archived Session: 1

History Max Archive: 16

Trace buffer debugging level is info

Service Set: Base State: Enabled Version 1.3.0

Service Set: Vty State: Enabled Version 0.1.0

Service Set: Mediatrace State: Disabled Version 1.0.0

Service Set: AdvancedRouting State: Disabled Version 1.0.0

Size of Command Results - 1

ParserState:inputline - show onep status

ParserState:parseReturnCode - 0

ParserState:parseErrorLocation - 10

VTY State - 2

VTY Max Response - 110

Writing a command VTY to the Network Element ... "show version"

R5#show version

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.4(3)M, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Compiled Mon 21-Jul-14 19:29 by prod_rel_team

ROM: System Bootstrap, Version 15.0(1r)M16, RELEASE SOFTWARE (fc1)

R5 uptime is 1 minute

System returned to ROM by error - a Software forced crash, PC 0x30EE0AFC at 12:24:18 CET Thu Jan 8 2015

System image file is "flash0:/c2900-universalk9-mz.SPA.154-3.M.bin"

Last reload type: Normal Reload

Last reload reason: error - a Software forced crash, PC 0x30EE0AFC

Joe Clarke · ‎01-08-2015

Can you post the "show stack" and "show region" output after the crash occurs? This sounds somewhat familiar.

viktor.s.wold.eide · ‎01-08-2015

Attached, as requested.

Best regards

Viktor

Joe Clarke · ‎01-09-2015

This is CSCup48067. Due to its nature, it won't always show up. However, it is fixed in 15.4(3)M1.

viktor.s.wold.eide · ‎01-12-2015

Thanks Joseph,

From what I can see, this updated image is from October last year. We'll

give it a try.

What is the best way for us to receive/subscribe to information about IOS

image updates which fixes issues relevant for onePK?

Best regards

Viktor

Joe Clarke · ‎01-12-2015

Unfortunately, there isn't a forum to be notified about onePK bug fixes in images. The best I can suggest is to continue to ask here if you run into issues. Keeping up with current images and even trains can be valuable as well, given how new onePK is.

viktor.s.wold.eide · ‎01-19-2015

Hi,

This case also illustrates a more general challenge regarding the software process around onePK libraries and images. The suggested approach is highly resource intensive for us compared to how it should be. Using this particular bug in the VTY service set as an example, the information about the bug was not available to us. As a result, we had to:

1. experience a problem ourselves first

2. determine whether the problem was on our side or in other third party libraries that we use, or not

3. check release notes for onePK and router images

4. ask on the onePK forum

In this case 2 was obvious as it was in the tutorial code. Number 1 was relatively simple, as it did happen consistently for the 2911 (but not for the 2951).

However, the normal case is for people to experience problems with their own onePK applications and not tutorial code. Testing with more recent IOS images is costly. The problem may only show up occasionally. More recent IOS images might also introduce other problems, which might be unknown to us and maybe also to Cisco. Targeting a number of different platforms (2911, 2951, ...) will further drastically increase the effort required to narrow the problem down.

Developing robust and resilient onePK applications is by itself challenging, as for distributed systems in general. Not having access to known issues and fixes leads to a huge waste of resources, as different people/companies/organizations duplicate each others efforts. As in this VTY service set bug example, the problem had been identified and fixed. Why not make it known?

Ideally, we would like to have access to the onePK bug tracking system, preferably at the same level as projects internally at Cisco using onePK. We have been asking for such access for more than a year. This kind of access is important to have an efficient development, deployment, and upgrade cycle.

Any progress in this area is highly appreciated.

Best regards

Viktor

viktor.s.wold.eide · ‎01-15-2015

Thanks Joseph, the 15.4(3)M1 image did fix this problem, as you wrote.

Best regards

Viktor