Invalid interface name

[garyprice]

I'm having a bit of a problem with the k9-4235.....I have two erros on the system that a causing difficulty.n I'm using the IDS event viewer and the browser interface to manage this one sensor.

The first problem is setting up the sensor to shun connections to one of our 6513's. It worked fine for two days(correct ip, enable password, name of interface (gigabitethernet1/2)) and then I recieved the following message:

23Jun2003 20:45:03.675 46.930 nac[3224] Cid/E errSystemError ERROR: Invalid interface name [GigaBitEtherNet1/2] for device [192.???.???.???] Try using the name exactly as it appears in the router CLI.

The name is correct. I have removed all setups for shunning and rebuilt them. But still get they same error.

This is the biggest problem so far....

Also I am getting a duplicate signature error in the built in sig engines for atomic.ip and string.ip...... the sig number is 5366 and i can't remove the second occurence from the signature interface in the browser....

I was at IDS-sig-4.0-2-S46 but did a downgrade to IDS-sig-4.0-2-S44

Any ideas?

Gary Price

[ywadhavk]

Hi Gary,

Could you paste the cat config relevent to these interfaces, along with any description it may have? Do you have any # symbols in the config. If yes, might try removingthose.

Thanks,

yatin

[garyprice]

not using cat.... using ios

funny thing is it worked great for about a week and then out of then these error messages -invalid interface name-

there are now # symbols in the interface configuration for the interface on the 6513......

[jlively]

when you configured it in IDM , did you select router or cat? Since you are running IOS, you have to treat it just like a router. Are you connecting with telnet or ssh? Is this the only device you are trying to shun?

[garyprice]

Yes, selected router, I don't feel good about the next answer, telent... have a userid setup on that TACAS server that is used to connect to the router. it has the necessary rights to created ACL's. Remember the configuration worked for three days and then stopped. when it stopped is when the error messages began.....the sun process on the ids was connecting every minute to try and make changes to the ACL created by the ids.......I have talked to the router group and there are no changes that they have made to the router or the TACAS system that would have created a proble.....I'm stumped.....since the ids process functioned for three days it would seem logical that it just didn;t break. But I have other conserns, like the corrupted (duplicate signature) built in signature files. I have downgraded to 4.0 37 and will re-apply the sigs and service packs to bring it back to the curent configuration.

gprice

[jlively]

Is this the only device you are managing? can you please send a shof conf from the cat and a show stat net from the sensor cli to me? I will get with the developer and see if we can figure out what is going on. jlively@cisco.com

[stleary]

The sensor has become unable to find the blocking interface in the show

config response. The most likely reason is that someone has modified

the router config, and inadvertently added a '#' character, possibly in

the hostname, banner, or an ACL comment line. Connect to the router

via telnet, set enable mode and type the command 'show config'. Check

the output for '#' characters that occur before the prompt at the end of the

response. If you find any, perform the necessary configuration commands

to remove them.

[garyprice]

have performed the show config operations and found no # in the configuration. Only at the system prompt indicating you are in the enable mode.......

gp

[garyprice]

I ran tests this weekend. this is what i have deducted.

the ios version of the 6513 is the issue.

I am using (one) k9 -4235 IDS Device Manager, Version 4.0(2)S47 setup for blocking using a 6513 and a gigabitethernet interface. Userid and ACL on router has been configured to allow the IDS device to create ACL's on the router. In viewing the logs on the 6513 and the event logs on the ids this is what i discovered.

on a 6513 version 12.1(8b)EX3 the error messages in the logs on the ids is as follows:

evError: eventId=1056673742350958395 severity=error

originator:

hostId: Constitution(name of ids)

appName: nac

appInstanceId: 19845

time: 2003/06/30 15:08:21 2003/06/30 11:08:21 EDT

errorMessage: name=errSystemError ERROR: Invalid interface name [gigabitethernet1/2] for device [XXX.XXX..250.25] Try using the name exactly as it appears in the router CLI.

The shun/block process did not function....

on another 6513 version 12.1(12c)E1 the process worked fine...

the shun process showed the blocking device as active and that the predetermined address used to generate a block request via sig 9000(backdoor tcp request on port 12345) was active for 30 minutes.

The logs on the router showed the connection from the ids and the read/ write config for the ACL that was created for the interface on the 6513.

I believe that a min ios level is needed for the ids (IDS Device Manager, Version 4.0(2)S47 ) to use a 6513 as a shun device....

any confirmations on this finding?

gary price

[stleary]

The only IOS restriction I am aware of is 11.2 or better. 12.1 should work

correctly. I think there is something in the 'show config' output that is

causing the problem. Can you forward the output from this command

to me at stleary@cisco.com? I will be glad to take a look at it.

[garyprice]

NO,

I don't have the time to edit out the sensative information in the config.

I have had one of the router group members look at the config for the use of the # symbol and it is not being used. What is it that youwould be looking for in the config?

garyprice

[stleary]

The problem you describe points to a specific known error. The sensor is

able to log into the net device, send commands, and receive responses.

It works correctly at least some of the time, but currently is unable to

recognize the blocking interface. We see this scenario in the lab when

the character '#' is encountered in the 'show config' response. It is a

documented DDTS in all 3.x and 4.x sensors: CSCeb00581.

Otherwise, I would look at the show config response for an unexpected

sequence of characters. For example, each interface block should begin

wtih the string 'interface' and include the interface name. Or each interface

block should terminate with a line consisting of the character '!'.

Finally, I would look for new problems which have not been detected in

the lab or by other customers.