Creating Custom Standard Drivers in IBM NCM
Key Points
- IBM Network Configuration Manager (NCM) includes many built‑in drivers and offers a wizard to create custom **standard** (CLI‑based) drivers, but not “smart model” drivers.
- Standard drivers work only with devices that expose a command‑line interface via Telnet or SSH; they cannot be created for GUI‑only, API‑only, or menu‑driven devices.
- The video demonstrates building a driver that gathers command output and runs simple CLI commands on a Linux server, illustrating the same process used for any CLI device.
- Before creating a driver you must plan the VTOs (Vendor, Type, Model, OS) – selecting unique values that don’t duplicate existing entries and considering how VTO filters will affect device selection.
- The driver must include logic to verify the device’s model and OS version by matching specific CLI command output, with optional string mapping techniques not covered in this demo.
Sections
Full Transcript
# Creating Custom Standard Drivers in IBM NCM **Source:** [https://www.youtube.com/watch?v=2TrI0m9D1F0](https://www.youtube.com/watch?v=2TrI0m9D1F0) **Duration:** 00:30:14 ## Summary - IBM Network Configuration Manager (NCM) includes many built‑in drivers and offers a wizard to create custom **standard** (CLI‑based) drivers, but not “smart model” drivers. - Standard drivers work only with devices that expose a command‑line interface via Telnet or SSH; they cannot be created for GUI‑only, API‑only, or menu‑driven devices. - The video demonstrates building a driver that gathers command output and runs simple CLI commands on a Linux server, illustrating the same process used for any CLI device. - Before creating a driver you must plan the VTOs (Vendor, Type, Model, OS) – selecting unique values that don’t duplicate existing entries and considering how VTO filters will affect device selection. - The driver must include logic to verify the device’s model and OS version by matching specific CLI command output, with optional string mapping techniques not covered in this demo. ## Sections - [00:00:00](https://www.youtube.com/watch?v=2TrI0m9D1F0&t=0s) **Untitled Section** - - [00:26:34](https://www.youtube.com/watch?v=2TrI0m9D1F0&t=1594s) **Enabling Debug Logging and CLI Test** - The passage outlines changing ITCM driver logs to debug level, restarting the service to verify device data, then creating a native CLI command set to test that the new driver correctly executes and returns results. ## Full Transcript
in this video I will demonstrate how to
create new custom standard drivers with
it NCM IBM tiv network configuration
manager before starting the
demonstration I will provide some
background on it NCM drivers and I will
briefly discuss the information that
should be collected in advance prior to
creating a new
driver it NCM ships with drivers for a
large number of network devices for
devices that are not covered out of the
box itcm provides a wizard to create new
custom standard type drivers standard
drivers are Ci or command line interface
drivers that provide basic configuration
backup and configuration change
functionality new smart model type
drivers cannot be created using the
driver creation
wizard it is usually possible to create
a new custom standard driver for devices
that have a CLI interface that is
directly access accessible via telnet or
SSH it may be difficult or not possible
to create new custom standard drivers
for devices that require navigating a
menu to reach the CLI interface or they
make significant use of special
characters in their interface it is not
possible to create new standard drivers
for devices that only have GUI or API
interfaces for configuration
management it NCM is intended to manage
network devices such as rers and
switches but depending on your
requirements it may be possible to
manage specific aspects of other devices
such as Linux servers in this video we
will create a driver that can collect
the output of a set of commands for a
Linux server and that can execute simple
CLI commands on a Linux server the basic
steps to create a new standard driver
are the same for all device types with a
CLI
interface keep in mind that if you need
comprehensive server management IBM has
products that are better suited for that
task in order to work if efficiently
when using the driver creation wizard it
is important to do some planning for
your new driver I will review the
decisions you need to make and the data
you need to collect before starting work
on your new driver first what values
will you use for the vtos the vendor the
type the model and the OS version you
cannot use a vtm OS that is an exact
match for a vtm OS that already exists
in
itcm you should also consider how your
choice of vtos will affect selecting
devices and other itcm resources when
using vtos filters in this example we
will use a vtos of Linux server Cent OS
6X it is possible for drivers to support
multiple models and Os versions if the
behavior and CLI commands for those
models and Os versions are very similar
in this example we will support one
model Cent OS and two OS versions
five-star and six-star next decide how
your new driver will verify the model
and OS version information when
communicating with the device typically
you need to identify CLI command output
that contains exact or Wild Card matches
for the model and OS version strings
there are ways to map or replace strings
found in the command output but we will
not cover that topic in this example in
this example we will use the output of
the command
catc
r-ras since that output contains matches
for both the model and the OS version
strings you must know the sequence of
prompts and responses used when logging
onto the device you will need to edit
part of the driver to match some or all
of that sequence and finally you need to
decide what you consider the devices
configuration to be we need to be able
to collect this data from the device and
store it in
itcm in this example we will capture the
output of the commands
catc hosts and netstat
DNR this slide provides the output of
the commands used in this example for
determining the devices vtos and for
collecting the device's configuration
data you may find this data useful to
refer to during the demonstration of
creating a new custom standard
driver we'll launch the new driver
creation wizard by navigating to the
system manager tab the driers section
and then from the tool tools menu we'll
select new
driver when the new driver window opens
select IBM templates then select CLI
based via telet or SSH we are not going
to demonstrate creating tl1 based
drivers in this
example then click
next and in the driver details panel we
enter the data that we decided upon
earlier so our vendor was going to be
Linux
the type was going to be
server the model was going to be Cent
OS and the OS was going to be
6X the supported model would be sent
OS and the supported os's were going to
be
fstar and
six-star both the supported models and
the supported OS values are comedy
limited
lists we'll click next to move to the
device script
section device scripts control the
configurable details of the handshake
between itcm communication handlers and
the device for functionality such as
logging on executing commands and
transferring data we're going to addit
SSH section of the device script since
our Linux server only allows SSH
connections we will select an existing
device script template by using the
selection box is near the bottom of the
screen in this case we'll pick a
Cisco router
7200 and a version 12.3 we're using a
Cisco router template because there are
no vtm os's in it NCM that have Behavior
really similar to a Linux server and a
Cisco router 7200 family of drivers has
an SSH connection section that will work
pretty well with that extensive
modification note that if you have a
custom device script that is closer to
the behavior of your new vtos you can
always paste in that script uh from the
text mode of the editor
we'll click open to load the device
script and once it loads we'll make sure
that we have the SSH tab selected and
that we have the
form editing mode selected Advanced
users may prefer to use the text mode of
the editor however you must navigate the
device script manually and be sure that
you're editing the correct section when
you use this mode in this example we're
going to use the form mode the first
section we will edit will be the connect
section this is the section that handles
logging on to the
device we will use information from the
device log on sequence to edit the
section since we are using SSH
programmatically it's likely that we
will only need to know the prompt that
indicates that we've successfully logged
on even though this section is designed
to handle telnet as well as SSH we will
also need to remove any extra lines that
are specific to the template vtm OS to
avoid executing commands that do not
apply to our Target device we'll first
edit the script content to remove the if
and if block that handles the enable
command for routers since this does not
apply to uh Linux
servers next we'll remove the lines that
control setting the terminal width and
length on a Cisco rouer since these also
don't apply to a Linux server
finally we'll change our prompt from a
pound sign to a dollar sign since in
this case we're logged in as a non-root
user and we'll be seeing the dollar
character as the last character in our
prompt next we'll edit the section of
the script that parses the model
information from the device
output we've already decided that we
will use the output of the cat Etc Red
Hat release command to provide the vtos
data that will parse in this section
we'll edit this section to reflect the
information from the output of that
command note that in order to have a
good match in this case we've included a
carriage return line feed character
after the Red Hat
release line that comes right before the
Centos string which is our model and
we've also included a leading and
trailing space after the word release
next we'll edit the section that
determines the OS version we'll click on
the config do version Tab and edit that
information also using the output of the
command catet Red Hat
release the concept cep of feature sets
doesn't apply to the OS versions of
Linux servers so we'll delete those
lines we'll change the rest of the lines
to match what we see in the output of
etsy Red Hat
release in this case we want to identify
or parse out the string 6.7 as the OS
version so our F began string will be
Cent OS release with a trailing space
and our find end string will be a
leading space followed by opening
parentheses next we'll edit the section
that pulls what we consider to be our
running configuration data from the
device we'll click on config do running
we want to send the command cat Etsy
host and netstat DNR to the device we
need to edit the commands that we want
to send in this section and the prompt
that lets us know when we've received
each command response we also need to
add information strings to parse for
that indicate the start and the end of
the configuration data so we will paste
in the commands we want to send
first note that we are sending an echo
command to Output as a start marker
we'll use the echoed string as the find
begin value in the upper
panel
note that we're also proceeding this
with a line feed character so that we
can avoid including the actual Echo
command itself in our configuration
output data this is not required having
a start marker and we're simply doing
this to show an example of how this can
be done also note that we don't put a
final weight equals dollar sign remember
the dollar sign is the prompt we're
looking for we do not put an a final
weight equals dollar sign line at the
end of this set of commands because we
want to catch the final dollar prompt as
our config running. end marker both to
tell us that we've received all the data
and when we're parsing for the end of
the configuration data next we'll edit
the information or diag section we'll
click on the diag
tab this section allows us to collect
additional information from the device
in addition to what we considered to be
our configuration data unlike
configuration data historical versions
of this data are not kept only one copy
of this data per device is kept the
database field that stores this data is
fairly large but if the collect the data
is too large for the field it will cause
a driver error and the entire unit of
work for the device will fail we need to
edit the commands that we going to send
in this section and the prompt that lets
us know we've received each command
response we also have have to add a
string to parse for that indicate that
we've received all the informational
data in this example we'll send a single
command slin if
config we'll also change our prompt that
indicates the end of data to the dollar
sign
character note that we don't have a
weight equals dollar sign uh because we
want to in intercept the uh the final
dollar sign character as the end of our
data however if we had multiple commands
as we saw before we
edited uh after each command except for
the final command we would have a weight
equals dollar sign line to make sure
that we'd received all data from the
First Command before we started a second
command next we'll edit the device
script section that controls sending CLI
commands to the device using native CLI
command
sets these commands can either either
make changes to the device or return
data from the device or possibly
both in this example we are going to
send commands to the device in line in
the SSH session with the device the
section of the device script used for
this purpose is the stream file section
CLI commands resulting from processing a
native CLI command set are stored in a
temporary file and this section handles
streaming the lines from the temporary
file to the device we will remove the
existing commands that are intended for
a Cisco router and replace those or
leave only the commands that are needed
for a Linux
server we'll also change the prompt
we're waiting for to our dollar prompt
next we'll edit global settings for the
device script we'll select cect the
miscellaneous tab we'll change the
prompts to match our dollar sign
prompt and we'll add a line that strips
the final line off the configuration
data this is an optional line this line
may or may not be useful to you
depending on your data and whether or
not a trailing line is a problem for
your use of the configuration data next
we'll edit the config tag again global
data or global settings we'll change the
configuration type to single
config since we don't have the concept
of a startup and running configuration
on a Linux
server and we'll change the prompts to
our dollar
prompt even though these values are
probably overridden by specific script
sections this completes editing the
device script so we'll click next to
move on to the resource access or rad
section since we plan to use SSH to
communicate with our Linux server we'll
select the SSH Tab and make sure it's
enabled in the transport section we'll
make sure that our streaming put and get
checkboxes are checked this is because
we want to send and receive data over
our SSH connection stream rather than
creating an FTP server to send data back
and forth to the device in the SSH
option section we'll select ssh2 because
our Linux version uses ssh2 instead of
ssh1 there are no changes we'll make in
the authentication section in the
command line we simply make sure that we
are using the SSH script
type in the configuration section we'll
leave native compare selected we're
going to turn off reboot on config list
load this probably doesn't make sense
for a Linux server and we don't want to
reboot our server unnecessarily anyway
we'll allow line by line for Native
command sets this allows all commands to
be executed in the command set even if
some of them error out which may be
useful when we try to collect
information from the Linux server later
we're going to leave the compare device
and itcm checkbox checks for network
devices this box should always be
checked for normal use but if your Linux
server responses are not consistent this
may cause itcm to incorrectly think that
it NCM and the Linux server are out of
sync in that case we can edit the driver
and change the setting we only have a
single configuration since we don't have
the concept of a startup command with
Linux so we'll leave the multiple config
compare checkbox unchecked and we'll
also leave the disable config checks on
changes unchecked this way it NCM will
check to see if someone has changed the
the Linux server configuration outside
of itcm before it makes a change we're
going to turn off pre writes for imports
and syns this is the equivalent of the
copy running to start command for a
Cisco router and it really doesn't apply
to a Linux server we'll leave the report
diffs checkbox unchecked uh for import
we'll still see any differences when we
do a configuration synchronization and
we're going to leave the update on
change check for our info which was our
diag section from the device script and
for configuration so when we actually
make changes we'll get our configuration
and our information updated we'll leave
the data type as CLI since we're just
getting the output of CLI commands since
we're not going to use the tnet and ALT
T telnet access
types we'll disable telnet since we may
use it later and since we have no
intention of having another access type
we'll simply remove the alt tnet type
this concludes the changes we need to
make to the resource access document so
we'll click next we'll enter a
description for the new custom driver
you should enter a description that's
going to make sense to you a week a
month or a year later when you come back
to try to figure out what you created
this driver
for the last screen simply shows us the
details of the driver we just created
and we can always find this information
later in the itcm driver management
guey now that we finished creating our
driver if we refresh our driver's panel
by toggling back and forth between
screens we'll be able to see our new
driver in our top row with our Linux
server Centos 6X and we'll notice that
this starts with CST indicating it's a
custom standard
driver U now it's time for us to test
our driver at try to actually import a
device of this vendor type model in OS
before we can do that we need to add
credentials for the Target device into
an authentication resource we've created
a custom driver test realm just to keep
things organized in this example and
we've already created a authentication
for our Centos Target device you'll
notice that we set the filter on this to
Linux as the vendor server as the type
and sent OS as the model and we've left
the OS version wild card if we look at
this we can see that we just have one
entry with our username our password and
we've also set that password as the
enabled password although for a Linux
server we shouldn't need an enable
password we're just doing this to avoid
a possible null po or exception at
execution time in case some routine is
called that looks for an enabled
password value now now we need to create
a device of that type uh we're just
going to use the Linux server that itcm
is running on and we're just going to
name it by its host name so we won't
have to worry about name
resolution so we'll create a new network
resource we'll put in the IP address of
our itcm
server and we'll select our new vendor
type model in OS
we happen to know from looking at our
red hat-- release file that this is a
6.x OS version but even if we picked the
5.x at runtime the parsing logic in the
device script that we edited would find
the right version and substitute
that now that we've created the device
we'll import it to see if our driver
Works clicking on Import in the context
menu opens our import network resources
wizard we can see that our device is
already
selected so we'll just step through the
wizard we're going to ignore errors
we've got an authentication resource so
there's no need to override the
passwords the priority really doesn't
matter for the unit of work we're going
to create since it'll be the only unit
of work running on our example
system and we'll schedule this for
immediate
execution it'll just give it a
description we can look for our unit of
work in Q manager and track its
status in this case we can see that our
U aired out we'll take a look at the U
log and get an idea what the problem is
in this case it looks like there's a
problem with our Command uh to get the
model section
we did something wrong sending the ETC
Red Hat Das release command so we'll
have to go back and add it the driver uh
and correct that
error we'll navigate back to the
driver's
panel and from the tools menu we'll
select edit
driver this brings up our driver wizard
again and there's one driver we can edit
which is our new
one we'll navigate back to the device
script panel and we'll select the SSH
Tab and we'll go down to our model
section we can see that we left the
equals out between the model. send and
the command cat Etsy SL Red Hat D relase
so we'll correct that
we'll check config version uh to make
sure we didn't make the same error which
we
didn't then we can click finish close
our Editor to save our changes to our uh
new
driver and after saving our driver we'll
go back and we'll try our import
again
and we'll check the status of our
currently executing uh unit of
work
and we can see that this
time we were able to successfully import
our
device now we'll go and check the uh
configuration data and the info data for
that
device we'll have to use view native
commands to see the configuration data
since this is a standard driver and
there is not a guey editor for the
configuration
as we expected we have our config start
marker line we've got the output of
catc hosts and the output of netstat
DNR if we look at our information data
that's under the hardware tab for
historical reasons itcm used to model
hardware and there was a gooey layout
for the chassis however that work has
now been deferred ref to it&m however
itcm still collects the text data in
this section and we can see the output
of
oursin if config command
here if the new driver fails when
importing the device and a basic check
of device connectivity device log on
credentials and the accuracy of your
device script editing in the new driver
don't solve the problem you can set the
driver logging level to debug to get
additional troubleshooting information
to do this edit the driver log.
properties file in the config
/properties
directory under the itcm base install
location near the top of the file change
the line log for j. root log or equals
error comma driver log to log for j.
root log or equals debug driver log save
the file and restart
itcm when it NCM restarts
test your work against the device again
after that review the data in the
drivers. log file under the logs
directory of the itcm base install
location once you're done
troubleshooting remember to set driver
logging back to error level to avoid
degrading itcm
performance now that our new driver is
working correctly to import devices into
itnc
we need to test to be sure that it will
correctly execute CLI commands from a
native CLI command set in order to do
that we need to create a native CLI
command set of the same
vtos as the new
driver for our example we've created a
simple native CLI command set called get
you limit
data the vendor filter is set to Linux
the type filter is set to server and
we've left the model and Os filters wild
carded since the command we're going to
use will work on probably any Linux
server we can see that we're just going
to send the command UL limit d
a the driver framework takes care of
connecting to the device sending this
command and detecting that the command
is completed successfully in this case
we're going to select a type
interrogation native command set because
we want to return results and be able to
view those
results so our next step is to apply
that command set to the device we could
apply the command set from the device or
from the command set itself using the
context menu apply native command set
this opens a wizard we can see that the
command set is already
selected and we'll just walk through the
wizard and select the device
we don't need to supply credentials
since we already have an authentication
resource and we don't really care about
the priority in this case since our
system is not very busy and we'll
schedule this uh command set unit of
work for immediate
execution and we check the progress of
our Command set and our Q
manager look at the work currently
executing and bore into our Command
set and take a look at the resulting
unit of work
log we can see that our Command set has
completed
successfully it sent our Command ulimit
d
a and it got back the response we
expected uh for a nonroot
user this concludes our example of
creating and testing a custom standard
driver with basic capabilities to backup
configuration data and to execute CLI
commands although examples for a Linux
server creating drivers for network
devices requires the same basic steps