RME 4.3.1 NetConfig behavior

[yjdabear]

A user has a NetConfig job set to execute "no speed 10" among a bunch of "no" commands on a couple of interfaces on two routers running two different versions of IOS 12.x.

routerA has one of those IOS bugs that produces the extraneous "username: " prompt before entering enable mode. This made NetConfig fail via SSH, so it seemed to have fallen back to TFTP, according to the job output. routerA was reported as a "success", including the "no speed 10" line in the output.

routerB had no such issue, but it "failed" because the IOS complained about "Cannot set speed to auto unless duplex is set to auto". I do not know at this time if routerA interface has/had the same issue.

The user says NetConfig actually failed to execute "no speed 10" on both routers' interfaces. Does that sound plausible? I didn't/don't have debug on, so I'm not sure how useful the job logs are.

[Joe Clarke]

It certainly could be.  Just because deviceA was reported as successful doesn't really mean it was.  Since TFTP was used, and TFTP has not error detection, the command could have been rejected by IOS for the same reason that deviceB rejected it.  The TFTP mechanism for deployment is nice because it's fast, but it's not a silver bullet.  IOS will still evaluate the commands with the parser, and if it doesn't like the syntax, or if the commands attempt to do something bad or unsupported, they will be silently rejected.

[yjdabear]

Thanks. A follow-on question that I forgot to pose earlier: The user said he subsequently manually removed the "speed 10" config. I wonder: Wouldn't he have encountered the same error prompt from IOS as well? I have shown him the NetConfig error output on routerB, but he still thinks it's a NetConfig bug for failing to execute "no speed 10".

[Joe Clarke · Accepted solution]

Netconfig is simply a frontend to the CLI.  It doesn't do anything magical.  It would run the command through the parser exactly how the user typed it (i.e. "no speed 10").  The parser will the same way when that command is run manually and via Netconfig.  If Netconfig showed a CLI error, the manual execution should have shown the same error (assuming all else config and state was being equal).