cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2509
Views
15
Helpful
9
Replies

Cisco IDSM and IPS hardware bypass

ankurs2008
Level 1
Level 1

Hi All

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

Regards

Ankur

2 Accepted Solutions

Accepted Solutions

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:

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/spantree.html

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.

View solution in original post

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.

View solution in original post

9 Replies 9

marcabal
Cisco Employee
Cisco Employee

Let me explain that there are 3 types of ByPass: Software ByPass, Hardware ByPass, and Parent Chassis ByPass.

Software ByPass:

Is available on sensors (both modules and appliances).

So long as the Operating System and Driver are still functioning the underlying IPS applications can fail, and the driver itself can "ByPass" the traffic. The driver will read in the packet and turn it right back around. Either sending it out the other interface of the interface pair, or out the same interface on the other VLAN of the vlan pair. Or in the case of modules, read in the packet and send it right back to the parent chassis.

The analysis engine is "bypassed" so the packets are not analyzed.

This can be triggered to happen in 3 ways:

1) When the analysis engine IPS application crashes

2) When the analysis engine is processing new configuration and/or an upgrade

3) The customer specifically turns on the ByPass feature

Hardware ByPass:

The IPS-4260 and IPS-4270 have a Copper ByPass Gigabit Ethernet card. There are 4 ports on the card that can be made into 2 interface pairs. If the box is powered off, then the 2 port of the interface pair will mechanically connect together to have that pair now act as a wire. The 2 other devices that were connected to the interface pair are now connected together.

Software ByPass takes care of the ByPass functionality most of the time, and HW ByPass kicks in when the OS and driver go down (generally because of power loss).

The fiber gigabit ethernet, and fiber 10 gigabit ethernet cards in the 4260 and 4270 do not support HW ByPass.

For these cards, as well as interfaces from all Other IPS Appliances you can use an external HW ByPass Switch. Try checking NetOptics if you are interested in a HW ByPass Switch.

NOTE: HW ByPass only works for inline interface pairing. It does not work with inline vlan pairing.

Software ByPass works with both inline interface pairing and inline vlan pairing.

Parent Chassis ByPass:

This differs depending on the module type.

All modules support Software ByPass, so the parent chassis only needs to do something in cases where Software ByPass doesn't work (reboots, major OS crash)

The SSC-5, SSM-10, SSM-20, and SSM-40 are all modules for ASA firewalls.

If the ASA is configured in failover mode, then the failure of an SSM will cause the ASA to failover to the other ASA.

If only one ASA is being used, then the configuration line in the ASA config for sending traffic to the SSM can be configured for "fail-open" or "fail-close". In "fail-open" the ASA bypasses the SSM and sends the packets through without analysis if the SSM fails (this would be the euivalent of HW ByPass).

In "fail-close" the ASA will drop traffic when the SSM fails. This is generally only used in high security environments where traffic MUST be analyzed before being allowed in the network.

The AIM-IPS, and NME-IPS are router moduls. And the router has similar fail-open and fail-close configuration to allow or drop packets on AIM-IPS or NME-IPS failure.

The IDSM-2 is a switch module. The switch, however, does not have any type of built-in bypass method. Instead you would need to design a second network path that could be used if the IDSM-2 failed. The common method is using a wire for the second path (the wire connects the same 2 vlans being paired by the IDSM-2). Spanning tree is then configured to prefer the IDSM-2, and only fall back to the wire if the IDSM-2 fails.

NOTE: The same wire and spanning-tree method can be used for the Appliances as well.

Hope this information helps.

Hi marcabal

Thanks for accurate and excellent explanation.However i have few queries , if you can help me through that it will be really great

1)HW ByPass only works for inline interface pairing. It does not work with inline vlan pairing.

Query : Please let us know if there are workarounds to make that work .We have 2 Cisco IDSM2 (6509 Switch in failover) in 2 different Switch chasis (one

IDSM2 in each chasis). We have configured them in Inline VLAN Pair however we want to see the possibilities of the Hardware bypass in case IDSM2 Module fails .If there is no alternative , do you suggest to change the inline VLAN pairing to the inline interface pairing ?

2)IDSM2 does not have any type of built-in bypass method. Instead you would need to design a second network path that could be used if the IDSM-2 failed. The common method is using a wire for the second path (the wire connects the same 2 vlans being paired by the IDSM-2). Spanning tree is then configured to prefer the IDSM-2, and only fall back to the wire if the IDSM-2 fails.

Query : Please let me know how to configure the same (wire method) as well as spanning tree config

Regards

Ankur

Hi marcabal

Please guide me for my above queries

Regards

Ankur

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:

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/spantree.html

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.

Hi marcabal

Again , i appreciate your in-depth explanation on this topic.

1) In "fail-open" the ASA bypasses the SSM and sends the packets through without analysis if the SSM fails (this would be the equivalent of HW ByPass).

Query :If the software (analysis engine) fails then the packet will be bypassed through (say inline fail-open is configured) however if the hardware of SSM gets faulty [consider that there is only 1 ASA (no failover)] will there be still a bypass .OR is it like that the software and hardware bypass are same in this case . Please correct me if i have understood incorrectly or if i am wrong.

Also ,can we configure wire and spanning-tree method in this case ?

While browsing the URL for spanning-tree documentation: , i am getting the error "Forbidden File or Application"

Regards

Ankur

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.

Sheer excellence !

thanks again for detailed explanation ,request you to please throw some light on the Switch and IDSM Module packet intra-process also (just the way you have explained above for the ASA and SSM Modules in terms of "driver" and "control & data plane" i.e actual internal process)for below example

Eg: A 6500 series Switch has FWSM and IDSM Modules .A Router is connected to Fa0/2 of this Switch assigned to VLAN2.The data port is configured as 1 and VLANS allowed are 2 & 3 for intrusion detection (IDSM is module 6)

Sources behind Router forwards packet to a 6500 Switch fasthethernet0/2 (VLAN2 ) to be sent across to VLAN 3 devices sitting behind FWSM .The packet after successful inspection from IDSM (in Inline VLAN pair for VLAN 2 & 3) will forward traffic to destination in VLAN 3 with FWSM ACL(via its VLAN 3 IP configured in FWSM)

Inbound packet :Switch->IDSM->Switch->FWSM

Return packet : FWSM->Switch->IDSM->Switch

Hi Marcabal

Request you to please let me know regarding the query in my last post [Jul 12, 2009] .

Also ,In one of the above thread you have explained regarding the second path (wire method) in case of failure of the IDSM-2.

1)Your statement : 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.

Query : If i have a switch A port 4 connect to the 6500 Switch (of IDSM) port 4 and the 6500 Switch (of IDSM) port 5 connect to the Switch B port 5 .Assuming that Switch port 4 is in VLAN 10 and Switch port 5 in VLAN 20 .

If the IDSM fails , then how the traffic will pass through from one VLAN to another .Please look at the traffic flow scenarios below

Switch A -> 6500 Switch -> IDSM (In Inline Failed) ->FWSM -> Switch B

or

Router -> 6500 Switch -> IDSM (In Inline and failed) -> FWSM -> Switch B

Hi marcabal

Please guide me on below queries

regards

Ankur

Review Cisco Networking for a $25 gift card