I just upgraded my test sensor to IPSv6. I wonder if anyone tried it and able to answered the following questions.
1. Is it still based on rdep communication? That's how I receive from my management server.
2. I don't think IPS2.2 MC can manage IPS6. Did anyone try it with IPS3 MC?
3. It seems to upgrade the configuration from 5 to 6 automatically without any problem, or is it just because I upgrade the test sensor with not much of config on it anyway? Did anyone encounter problem during upgrade?
4. I can't find any info on the doc that spell out memory and hard-drive spaces requirements for IPSv6. I have most of the 4235 sensor, my test sensor is always peek up around 70% on memory without sniffering any traffic. Not sure if it's normal.
5. Any feedback on new features? especially Anomaly detection, OS fingerprinting and CSA Collaboration?
It seems like I just upgrade everything to v5 (40+ sensors). Now that I have to go through this upgrade path again. ai...
1) RDEP originated in version 4.x for remote querying of events, remote configuration, and remote statistics requests.
Version 5.x still supported RDEP for remote querying of events, and remote statistic requests, but also added a new SDEE server for remote querying of alerts (SDEE is similar to RDEP but supports additional fields), and switched to a different method of remote configuration.
Version 6.x supports everything that version 5.x did. So version 6.x does support both RDEP and SDEE for querying of alerts.
(NOTE: In a future IPS version the RDEP remote querying of events will be removed and only SDEE will be supported. So some time in the next 8 months you will want to convert any home grown RDEP client into an SDEE client. Also new 5.x and 6.x fields will only be seen in SDEE alerts and not RDEP alerts.)
2. Neither VSM nor the CSM 3.0 can manage a version 6.x sensor. A new version of CSM will be released earlier next year that can manage a version 6.x sensor.
If you use VMS or CSM for configuration management, then you may want to consider staying with version 5.x for now.
The release of version 6.x does NOT stop the support of version 5.x sensors. If I remember correctly version 5.x signature support will continue for at least another 12 months and possibly even 18 months or more. So don't feel rushed to jump immediately to verison 6.x.
3. Version 5.x to version 6.x upgrades have been specifically designed to upgrade with as few problems as possible. But there could always be the edge cases that we could not foresee during development.
My recommendation is to always save off your sensor configuration to a remote ftp or scp server prior to the upgrade.
My other recommendation would be to install S263 on your 5.1 sensor before upgrading to version 6.0. This is because S263 was a coordinated release with 6.0, and added the new Anomaly Detection and other features into the signature configuration files (the new features can be seen but not used on a 5.x sensor). If your 5.x sensor is able to upgrade to S263 without an issue, then you have an even higher confidence that it will upgrade to 6.0 without an issue.
Originally S262 was to be the coordinated delivery, but issues were found with S262 and so S263 was created as the coordination point.
Since the delivery of S263 I have heard of only one configuration conversion problems, and we were unable to recreate the problem.
4. All you need to check is that your sensor is in the supported hardware list. The IPS 6.0 verison supports the base hardware of all of the sensors. We don't offer any memory or disk upgrades for these sensors, and so no memory or disk upgrades would be required for the 6.0 upgrade.
Your 4235 sensors are supported with the default hardware.
The reason for the 70% memory usage is because of a change in the sensor architecture. In previous version the sensorApp process responsible for analysis would request additional memory as needed, but this is no longer the case in 6.0. Instead in 6.0 the sensorApp process pre-allocates all of the memory it is allowed to have. SensorApp then internally manages it's own memory; it does not give unused memory back to the system nor does it request any additional memory from the system (except in some extreme cases). So what you are seeing is very normal, and internally your sensorApp has plenty of unused memory that sensorApp is internally managing.
5. Check the 6.x Release Notes and Configuration Notes.
You are one of the first to install 6.0 so few others will have had experience with these features as of yet.
As for upgrading from 5.x to 6.x do not feel like you or forced to make this upgrade right now. As I mentioned above, the 5.x version will continue to be supported for at least another 12 months and likely 18 or more months.
thanks for your reply. That answers most of my questions. I will like to make some comments to dive into the subject deeper.
1. The reason I ask for rdep support because I am using CIC rdep probe to collect ips events. I am not sure when cisco will release the new rdep probe to support sdee communication in CIC product. As long as rdep is supported, I am good for now.
2. well, I have more than 40 appliance on the network. I am not going to upgrade all to 6.x if I don't even have a mc to manage them.
3. well, I have a lengthy configuration on my production sensor. I was able to convert one early this week. I will keep my finger cross to convert all of them.
4. well, I have to disagree with you on this one. All my 4325 came with 1GB memory and probably 18GB hard drive space. When I use my test 4250, everything works fine. However, when I move the the hard-drive to 4235, during the boot, it will error out, error message: out of resource, kernel panic. I put the hard-drive back to 4250, the memory without doing any kind of traffic spanning, stays around 1.4 GB. Therefore, I think the my current hardware, especially memory needs to upgrade in order to run 6.x. I will contact our rep to see what kind of options that we have in this case.
5. oh, well, I am not in the hurry to upgrade all. However, we do have CSA here and I like to see the integration with new version. I think in this case, we definitely need test more on the new features.
You state that you are seeing problems when moving the 4250 harddrive into a 4235 appliance.
This is not supported and can lead to unkown consequences.
The physical harddrive can be moved from a 4250 to a 4235, but the image installed on that harddrive has not been made to move from a 4250 to a 4235. So if the harddrive is moved you would need to re-install the base sensor software from scratch (install from CD).
During initial installation the software will detect the type of hardware and configure the sensor for that specific type of hardware. Internal configuration files get modified during installed based on the type of hardware detected.
When installed on a 4250 it detects that 2GB are available on that platform and will optimize itself to run within that memory.
When installed on a 4235 it detects that only 1GB is available on that platform and will optimize itself to run within that more limited memory.
NOTE: The amount of memory is based on the platform type. Trying to add an additional 1GB of memory to a 4235 could confuse the software and is not supported.
Software that has ben optimized for the 4250 will not run properly on a 4235 and will likely generate errors.
(Can't tell you what errors since it not something we support or test.)
If you are going to move the harddrive from one model sensor to another model sensor, then plan on re-imaging from CD so the installation process can detect the hardware and optimize the configuration for that hardware.
NOTE: If your main purpose in moving the harddrive is to receate the configuration on the other sensor, then you might try copying the configuration instead of moving the harddrive.
Copy the configuration of the 4250 to a ftp server, and then shutdown the 4250.
Bring up the 4235 and run setup just to set the initial network parameters and then copy the config on to the 4235 from the ftp server.
Cisco does not sell and does not support additional memory on the 4235s. The IPS 6.0 software was designed to run within the 1GB of memory that is the default on the 4235 sensors. But to run properly it needs to detect that it is a 4235 on initial installation so the software can configure itself correctly for that platform.
Now it is possible that because of tunings you have made in your configuration, that the tunings may have worked in a 5.x version on a 4235 but not on a 6.x version on a 4235.
The new features in IPS 6.0 do take up a bit more memory than was used in IPS 5.1. This means there may be less space memory available in the 6.x sensor for things like Custom Signatures.
If your configuration is one that pushes the sensor to the edge os it's available memory then your options include:
1) Reducing your customizations (removing some of the custom signatures even)
2) Optimizing your custom signatures (many custom signatures are written in ways that consume large amounts of memory and can often be rewritten with the Multi-String engine that consume less than half the amount of memory when done in other engines)
3) Disable some of the new IPS 6.0 features (like disabling Anomaly Detection)
4) Disable signatures that do not apply to your network (filter through the signatures and disable ones that don't apply to the type of machines in your network)
5) Or lastly consider an upgrade to a larger model sensor with more base memory.
The internal settings for a 4250 do not match those of a 4235.
The currently released version of MARS is able to pull events from an IPS v6.0 sensor.
But the current version of MARS will not be able to show the new fields that were added to the alerts as part of version 6.0.
This is an interesting thread. I wish I had read it before I upgraded a sensor to 6.0.
It has cost our customer a lot of money to upgrade to CS-MARS, for one IPS and one ASA. But now I discover that IPS v6 is not fully supported with MARS, as in it can not see the new fields in v6, it does not support new sigs instantly like VMS. What is Cisco doing with security these days??
But the question I wanted to ask is about the 4215 sensor that only has 479 M RAM and is using 383. While updating sigs, it stops responding for a long time like an hour, or maybe never is able to be managed again, until we power it off. It seems that the high mem usage maybe causing this.
Do you have any suggestions?