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-184.108.40.206
Router version and image, see below:
Application output (just hangs as router crashes).
./bin/VTYTutorial -a 10.0.225.55 -t tls -P pinfile
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"
Status: enabled by: Config
Transport: tls; Status: running; Port: 15002; localcert: TP-self-signed-3721331056; client cert validation disabled
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"
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.4(3)M, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
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
Can you post the "show stack" and "show region" output after the crash occurs? This sounds somewhat familiar.
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?
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.
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.