The exact same software and signatures are installed on all IPS Appliances and Modules.
So any features that are not hardware specific will work the same across all IPS Appliances and Modules.
So the only difference will be with the hardware and how it can be deployed because of the hardware.
An IPS-4240 is faster than an SSM-20.
(If performance is a concern, you could use an ASA 5540 with an SSM-40, or even put an SSM-40 inside your ASA 5520s instead of using SSM-20s. The SSM-40 is faster than the IPS-4240.)
The biggest difference customers fid is in how the 2 can be used for promiscuous monitoring. The IPS-4240 can be deployed in promiscuous mode to monitor traffic from switch span ports. (Which is the most typical promiscuous deployment).
The SSM-20 can NOT monitor traffic from a switch span port. The SSM-20 Can be deployed promiscuously, but the promiscuous traffic that it monitors is limited to traffic that is passed through the ASA chassis in which it is placed. The ASA can not receive promiscuous traffic, and so the ASA has ot be inline for the traffic.
The Normalizer Engine is not used on the SSM-20. The ASA does the Normalizer and so the Normalizer is not needed on the SSM-20.
ARP signatures can not be detected with the SSM-20. The ASA responds to and handles all ARP packets, so the SSM does not see them.
The SSM-20 has an advantage when considering Fail-Over deployments. The SSM-20 simply relies on the Fail-over capability of the ASA. You have to independantly configure each of the SSM-20s in the 2 ASAs, but can rely on the traffic fail-over capability of the ASA.
There is no special configuration needed on the SSM-20s to use them inside ASA fail-over pairs.
For the IPS-4240 you would need to make special network designs to try and get similar functionality for the Appliance.
The SSM-20 also has an advantage in case of major failures. The ASA constantly monitors the SSM-20 and can "fail-open" to allow traffic to pass even if the entire module fails.
For the IPS-4240 you would need special network designs to handle the situation should the entire sensor fail.
So the SSM-20 (or any other SSMs) have definite advantages over the Appliances in terms of ease of deployment if you have ASAs already deployed.
The IPS-4240s (or any other Appliances)biggest advantage is if you need to do Promiscuous monitoring of local networks, and need to be able to monitor for lower layer ARP attacks.
What is the life expectancy of the IPS-4240? We have a requirement to do promiscuous monitoring on a network and need the 4240. Any idea what the EOS/EOL of the device is? All of our other IDS devices have reached EOL and we're concerned about the 4240 going EOS. Thanks.
There are currently no EOS/EOL Bulletins for the IPS-4240.
The IPS-4240 will continue selling for the foreseeable future, and there is currently no documented date for which signature support will end.
The End-of-Sale Policy for Signature File Release on Intrusion Detection and Prevention (IDS/IPS) Sensors documents Cisco's official policy for how long Signature Updates can be expected for EOS platforms.
d) Hardware products announced as reaching end-of-sale status are provided with software support for three (3) years. In the event that a major or minor software release is not supported on the end-of-sale hardware, Cisco will support signature releases for up to three (3) years after the hardware end-of-sale date on the last available software release for that hardware platform.
When a platform is going to be End Of Saled, the EOS/EOL Bulletin will usually be generated at least 6 months prior to the End of Sale Date. And by the policy above the Signature Support for that platform will continue for 3 additional years beyond the End of Sale date.
Since there is no EOS/EOL bulletin out for the IPS-4240, you can expect Signature Support for MORE than 3.5 years on that platform.
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...