cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

3743
Views
14
Helpful
9
Replies
dmickels
Cisco Employee

Basics of adding a device into NSO... and other noob questions/issues.

I'm totally new to this product.  I've installed a VM using the "system install" method and have licensed it with Smart License.  That said, here are the issues/questions I've encountered.  Bear in mind that I'm NOT a programmer/developer but an old-time network engineer.  I'm trying to learn so that I might improve my scripting-foo.  Please bear that in mind if/when you respond as I probably don't know all your fancy jargon.

I've connected to the ncs_cli and noticed that I have no packages ("show packages" comes up blank).  Is this expected behavior?  Where do I get packages? (at least cisco-ios but cisco-asa would be very nice as well)

I've connected to the WebGUI and tried to add a device (a c3560) but apparently I'm doing it wrong as I keep getting various error messages.

I've done my best to read the manual(s) that came with the installation files but most (if not all) presume you performed the "local install" method and have access to the net-sim (and presumably some packages).  I've not found any documentation on how to use the WebGUI at all, alas.

Please help me get started.  I REALLY want to learn how to use this product.  I'd prefer not to use the net-sim feature though as I have enough real gear that I'd rather work with.

1 ACCEPTED SOLUTION

Accepted Solutions

There is just no reason to do a system install until you are putting together a production system with strict requirements on security, periodic backup and automatic start. The point with local install is exactly what you noticed: there's no need to set up users etc. So there's no need for this to be part of the "getting started" process. It just works.

I deal a lot with people setting up NSO for the first time. A small fraction are choosing system install because the documentation isn't clear enough that that is a bad choice for a first time user. That small fraction is causing a lot of support load because of things improperly set up not working as expected. I have requested many times that the system install option should be renamed into something that indicates more obviously that it's not what you want, unless you're actually going into production now.

View solution in original post

9 REPLIES 9
frjansso
Cisco Employee

I'd recommend that you start by installing NSO as a local install. That's the "correct" way of doing it if you're not in a production environment and it will save you some pain when learning NSO.

You can find all the NEDs here in the developer hub, check lower left "corner" of the first page for the link "NSO software". You cannot add any device before you have the correct NED for that device type (IOS, ASA etc).

I also urge you to go through the examples shipped with NSO.

Fredrik,

     Thank you for the quick reply!  I hear what you are saying and I can't argue that your path isn't the better one.  That said, I struggle with understanding something when it is ran against simulated "gear".  I guess I'm old and need to "see" it being applied in the "real world".

     So, let's assume I go through all the examples, then I perform a "system install".  Then what?  I'm back to where I am now, with no packages and no knowledge on how to add devices via the WebGUI.  (I've read through some of the examples and felt that they were too pre-prepared.  I just have too many initial questions I guess.)

     I'm sorry to push but I'm frustrated that everyone only discusses using the "local install" but then refers to the "system install" for anything doing with the real world.  Maybe that transition is obvious and hidden in some of the example materials but I'm having a hard time connecting those dots.  I feel I'll go through all the examples and become familiar with using NSO but only after it is already set up and has packages/devices installed.  Does that make any sense?

Who is saying that you need a system install to do anything with real devices? That is plainly wrong and as I wrote before, you should not do a system install unless you install NSO in production.

To add a device using CLI or WebUI, you need to provide the following parameters:

name of the device

address

device-type (i.e. NED, e.g. IOS, ASA etc)

state admin-state = unlocked

authgroup, leafref to an authgroup where the credentials are stored

Sorry to upset you.  I'm just confused on why I should be forced NOT to use a "production"-style install.  To me it just doesn't make sense to go through the trouble of installing NSO as a "local install" to learn and then have to re-install as a "system install" later.  Truly, if they are no different then why all the fuss?  Obviously the documentation is geared towards a "local install" style only... which is fine, I guess.

All that said, I've uninstalled my "system install" way and have installed the "local install" way.  I've started going through the examples as explained in the guide.  Hopefully this will translate over when I perform a "production" install and setup.  It is my fear that I'll be missing key insights since there obviously are differences between the different install types.

If you would, could you explain to me why there are the different install methods?  I get it that the "local install" is easy to delete, if you decide to go the other way, but the "system install" wasn't hard to remove either.  In fact the extra steps to get the local install prepped between the different examples seems more complex.  I'd think it would have been easier to populate the ncs database with an example, then "factory reset" when done with that example on a "system install" version than all this extra work required using "local install".  Just my 2 cents.

I'm sorry if I come across gruff.  Truly, I'm trying to understand why and am not just complaining.  I'm just really confused why everyone I've discussed this topic with says the same thing:  "System install is for production.  Use the local install!"  Okay, why can't I learn on a "production" system?

Great question! I think you're right questioning working with a local install first, developing, and then moving over to a system ditto when you're done.

System install is typically started automatically, you have a system where NSO is a part and when you start that system you want to have it start using systemd or similar. You're using one NSO version and you want it started automatically (or by some other service).

When developing you might want to have multiple NSO versions installed at the same time, for instance if you are developing an NSO service that needs to work on both NSO 4.3 and NSO 4.4. Then you create two local installations and switch between them. So you're using multiple NSO versions and you want to control exactly which version you start. Also the examples in the user guide are written assuming you are using a local install.

Hope that makes sense, there's probably more to it but I think this covers most of it.

The most important reason why there is a system install option is that for a production system there *must not* be any default credentials (user names, passwords, etc) for security reasons. This makes the system a little less friendly to get started with, as you need to define users, passwords, permissions etc the first thing you do.

Karl,

     That is a valid point.  I'd argue that if that is the main use case for "local install" then the documentation should reflect that AND focus more on the "system install" method.  That said, I'm assuming we want people to actually use the product and not just develop to it.  :-)

Jan,

     This too is a valid point.  Maybe I haven't reached this part in the "getting started" guide but I have not encountered the need to set up users.  If the documents were written the way I think they should be (aka written for a system install) then that difficulty would be addressed at the beginning.

There is just no reason to do a system install until you are putting together a production system with strict requirements on security, periodic backup and automatic start. The point with local install is exactly what you noticed: there's no need to set up users etc. So there's no need for this to be part of the "getting started" process. It just works.

I deal a lot with people setting up NSO for the first time. A small fraction are choosing system install because the documentation isn't clear enough that that is a bad choice for a first time user. That small fraction is causing a lot of support load because of things improperly set up not working as expected. I have requested many times that the system install option should be renamed into something that indicates more obviously that it's not what you want, unless you're actually going into production now.

I understand you logic.  However, I would argue that creating 2 different ways of performing an install is the issue at hand, not that "setting it up correctly is hard".  I'd argue that the reason people have such a hard time with the "system install" is because there is little/no documentation on the right way to do it!  As I mentioned earlier in this thread, it is hard to learn something knowing you'll need to completely do it over again (i.e. learning on "local install" then transitioning to "system install"); especially when the documentation (and support) keep telling you to "just use local install".

If "system install" is to be avoided so stringently then it shouldn't even exist.  Actually, I'd argue the opposite.  The documentation should focus on the "system install" method and the examples should be embedded in that context.  The "hard way" should be the developer's use case (since they are the professionals here and us "users/network engineers" are the dummies).

Sadly, all I want to do is learn how to set up NSO, add devices, and configure those devices.  The examples I've ran through so far have only covered the last of those 3 items.  Obviously there is a LOT of embedded knowledge in each of those steps but having the "local install" auto-magically perform the first 2 for you makes it hard to translate those portions to the real world.