cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
514
Views
0
Helpful
1
Replies

CCO Documentation Gone for 2.2.3 Director!

crossmanj
Level 1
Level 1

Y'know I really do try to research these things on my own before I bring them to y'all, but when the documentation is removed from the website - well, that makes it a bit hard. Specifically, in this case the link at <http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/index.htm> has a link that says "Cisco Secure Intrusion Detection System Release 2.2.3", but there are only the release notes when I follow it.

So instead, I'll ask y'all my question. I am still working on the Shunning Server Sensor and the Shunning Client Sensor configuration. I trust y'all when you say it will work - I just can't get it there.

MARCABAL, you might want to check your last instructions to me - especially if you had cut and pasted them. It appears that part of your post - specifically the part where describing the nrexec command line - had some formatting that was filtered out of your post by the forum software as it was posted. So I have no idea where I need to provide host and org ID's in the nrexec command line.

But what I am finding is that I have nrconns established for all of the client sensors to the shunning sensors. But when the shunning client sensor sends a shun to the shunning server sensor, the nrconns bounce back and forth between being established and not. That is to say, the shunning sensor flashes yellow in the Director, and I get what appears to be a ROUTE DOWN (997) from the shunning sensor, which then goes away for a while and then comes back (996).

Now I figure that mysterious Connection Number field in the routes file may have something to do with it, but then again, I have no on-line docs to check. :-) Before i started mucking about with all of this sensor-to-sensor communications, all of my sensors are set to use Connection Number 1 to the Director, and the Director has all 1's back to the sensors.

Should these use the same numbers. Should they all be set to '2' so that the Shunning sensor has a connection 1 to the Director and all connection 2's for the shunning? Or maybe I'm just barking up a tree. I don't know, but I just had to tell the Change Review Board again that I have been unable to get my shun testing complete.

Oh - that is my own fault, btw, not y'all's. I was teaching an incident response class Thursday and Friday, and yesterday I had a bunch of incidents which needed my attention - so I'm only now returning to my shun testing.

But today and tomorrow I am all over this testing....

1 Reply 1

marcabal
Cisco Employee
Cisco Employee

For your setup all routes should be listed as "1".

The only time a "2" is used is if you are building in alternative routes between the same two machines. Very rarely does anyone ever setup a second route between the same two machines.

As for the nrexec command to try:

nrexec 10003 hostid orgid 1 30 ShunHost 1.1.1.1 5

replace hostid with the numerical hostid of your shunning server

replace orgid with the numerical orgidid of your shunning server

You should be able to execute this exact command on the shunning server itself, the shunning client, and the director.

Then you can change the ids to match the shunning client and execute it on the shuning client and the director.

The Route Downs should not be part of your problem. They will happen anytime a sensor is reconfigured because postoffice is temporarilly stopped on the sensor so all directors and sensors talking to it will generate a route down message.

If you are seeing this Route Down when performing a shun then it is a new problem which we would have to look in to.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: