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....
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 126.96.36.199 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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...