I have a query regarDing the Cisco IDSM , ASA -AIP-SSM (IPS) and IPS 4200 series sensors' hardware bypass unit . Please let me know if the hardware fails in both the cases how will the traffic pass through .Is there any inbuilt hardware bypass built in the same
The ASA sends heartbeat packets on the data-plane to the SSM. These heartbeat packets are to detect when the SSM stops passing through packets.
A similar heartbeat also sent through an internal control plane where the ASA sends control messages to the SSM. These heartbeats on the control plane are to help the ASA detect other problems on the SSM.
If the analysis-engine on the SSM fails, but the driver continues working, then the driver on the SSM will go into ByPass mode (assuming ByPass was configured for "auto").
The driver doing ByPass is what we call software bypass. Packets continue to be sent to the SSM from the ASA, and the ASA heartbeat packets continue to be sent. The ByPass in the driver sends the packets right back to the ASA. So the ASA does Not detect a failure.
If on the other hand there is a OS failure or driver failure on the card, then the driver will not by able to ByPass traffic.
The ASA will not get back the heartbeats on the data plane.
The ASA will consider the SSM as failed (not just the analysis engine but the entire module).
Once the SSM failure is detected, then there are a few things that the ASA itself might do.
If the ASA is configured for failover with another ASA/SSM; then the ASA will failover to that other ASA/SSM.
If the ASA is standalone (no failover pair, or the other ASA is in the pair is also failed), then the ASA will look at the "ips" policy configuration. If the policy is configured for "fail-open" then the ASA will do its own analysis of the packets and transmit the packet without ever sending it to the SSM (this would be the ASA acting as the bypass for the SSM). If the policy were configured for "fail-close" then the ASA will intentionally drop all traffic that would have otherwise been sent to the SSM.
If there is a failure in other areas of the sensor, then the failure is generally in a process we call mainApp.
MainApp is responsible for communicating with the ASA through the control plane, as well as most of other features of the sensor that are not specifically the monitoring of traffic.
If mainApp fails then the ASA heartbeats on the control plane will not be sent back to the ASA, and the ASA considers the SSM as having failed (even if heartbeats are still going through on the data-plane).
Because the SSM is considered failed, the same failover or fail-open will happen as I discussed above.
A wire or spanning tree are not viable failover options when using an ASA with an SSM.
The ASA itself provides the "fail-open" option for SSM failures.
If the ASA itself is the thing that fails, then the ASA provides failover to a second ASA. You would need to read up on ASA configuration and management to learn about ASA failover deployments as they are different than IPS Appliance failover deployments.
As for the error "Forbidden File or Application", I do not see that error. My only guess is that the cisco.com site is not allowing you access to that documentation because your cisco.com userid is not associated with a support contract that would allow you access.
I know they limit this type of access for file downloads, but was not aware that they may also limit access to user guide documentation.
You might need to do a search on cisco.com for "spanning-tree" to see what spanning-tree documentation your userid does have access to.
Sorry for the delayed response. I have been on vacation for the last week.
Hardware ByPass is not available for the IDSM-2 regardless of whether you are using inline vlan pairs or inline interface pairs.
For Appliances it requires either special interface cards or a separate Hardware ByPass Switch, and neither of these are available on the IDSM-2.
You need to configure your network so that their is a second path around the IDSM-2 in case of failure of the IDSM-2.
This can be done with a regular network cable.
Assume you have your IDSM-2 configured for inline vlan pairing of vlans 10 and 20.
Configure a standard switchport as an access port on vlan 10.
Configure another standard switchport as an access port on vlan 20.
Now using a regular network cable connect these 2 switch ports together.
Shutdown your IDSM-2, and the traffic should now be passed through this network cable and your network connectivity should be maintained.
Bring your IDSM-2 backup, and now spanning-tree should run and will choose either the IDSM-2 or the network cable as the primary path and will place the other into a Block state.
Execute "show spanning-tree vlan 10" and "show spanning-tree vlan 20" to determine whether the cable ports or the IDSM-2 port is in a BLK state.
If the cable ports are in a BLK state, then you don't need to modify the spanning-tree parameters.
If the IDSM-2 port is in a BLK state, then you will need to modify the spanning-tree cost and/or priority for the IDSM-2 port using the following commands:
-[no] intrusion-detection port-channel channel_number spanning-tree cost port_cost
Sets the spanning tree port cost for the data port on the specified module. The no option restores the spanning tree port cost for the data port on the specified module to the default value.
-[no] intrusion-detection port-channel channel_number spanning-tree priority priority
Sets the spanning tree port priority for the data port on the specified module. The no option restores the spanning tree port priority for the data port on the specified module to the default value.
To learn more about spanning-tree and how these parameters interact with spanning-tree you can look through this section of the switch user guide, or search cisco.com for spanning-tree documentation:
NOTE: Your switch shoud be configured for Rapid PVST for the most rapid failover. Work with your switch administrator to determine what spanning-tree protocol is being used on your switch. The IDSM-2 does not work with MST so ensure that MST is not being used.