Will traffic flow ?

[dondongamo]

Hi

In IPS4255 it was mentioned once you set Auto-Bypass mode traffic will continuously flow in case of software failure, will it forward the traffic in case of HW failure ?

[marcabal]

No,

The IPS-4255 has a Software ByPass feature where the NIC driver can pass the packets when the AnalysisEngine is Not Running. But it is the NIC driver that does the bypass so the base operating system and the NIC driver have to be running at minimum.

The IPS-4255 does NOT have a Hardware ByPass option which would opperate even if power is lost on the sensor.

For Hardware ByPass you would need to purchase a 3rd party Hardware ByPass switch.

[dondongamo]

Since most of the company prefer having uninterrupted network does Cisco has any plan of adding this feature in the future releases of IPS ? and can you disclose any brand of HW ByPass Switch which Cisco recommends ?

Thanks

[marcabal]

Can't comment on future plans, but I can say the request and urgency have been passed on to our marketing team.

As for recommend brand for an external HW ByPass Switch. We have tested ShorMicro Systems SM-2400 Programmable ByPass Switch for 10/100 and Gig Copper connections.

We will also be testing NetOptics ByPass switches in the next couple of weeks.

Alternatives:

Also keep in mind that there are alternatives to using HW ByPass if you are deploying in a switched environment.

If you are connecting the sensor between 2 switches or between 2 vlans on the same switch, then you can connect a second sensor between the same 2 switches (or 2 vlans).

Spanning-tree will recognize that there are 2 paths and will place one of the paths (one of the sensors) in a Blocking state and only Forward traffic through the other path (sensor).

So the sensor in a Forwarding state is doin the analyzing, and the second sensor only gets traffic if the first sensor fails.

This can get a little expensive for some customers so there is another alternative. Instead of a second sensor use a simple copper wire. You will need to setup spanning-tree so that the sensor is the primary path and is in Forwarding state, and the wire is the secondary path and would normally be Blocking.

This way if the sensor fails, then the switch starts using the plain copper wire to pass the packets.

You in effect have created your own ByPass switch at the expense of a wire, 2 switch ports, and a little time configuring spanning-tree.

[jeff-krauss]

Marco,

How does this apply to failover for IDSM's? i.e. what is the recommended method of providing high availability for an IDSM deployment (inline IPS)

1) Where you have two IDSM's in a single Catalyst 6500?

2) Where you have on IDSM in one of the core 6500's and a second IDSM in the redundant core switch?

Thanks

[marcabal · Accepted solution]

With 2 IDSM-2s in a single chassis then spanning-tree can be used for the failover.

One IDSM-2 will be in a Forwarding state, and the second IDSM-2 will be Blocking.

If the IDSM-2 in Forwarding state fails, then spanning-tree will change the other IDSM-2 from Blocking to Forwarding and start sending the traffif through that one.

BE AWARE THOUGH, that this type of failover is what we term Stateless. The second IDSM-2 will not have been tracking the active TCP sessions. So when the first one fails and the second one starts seeing traffic the second IDSM-2 will see TCP packets for existing sessions as being out of state order (no 3 way handshake seen). It will deny those connections and new TCP connections will have to be started.

When looking at redundant switches you add an additional level of complexity.

You have to first ensure that all traffic flows through just one of the IDSM-2s. If you have assynchronous routing then you could have client packets going through one switch and it's IDSM-2, and server reponses going through the second switch and it's IDSM-2. Each IDSM-2 would only see half the connection and would deny the packets because they could not track both sides of the connection.

If you get the assynchronous routing problem prevented, then the next issue is to ensure that if the IDSM-2 in the first 6500 fails, then the traffic will be sent to the second 6500. Depending on your Code switch configuraton spanning-tree may work for this, or you may need to use a routing protocol like HSRP to do this.

Be aware that this may depend on the switches ability to use the IDSM-2 port state to determine whether or not to bring down the switch/MSFC interface using the autostate feature. The autostate feature was set to intentionally ignore the IDSM-2 ports when they were promiscuous.

Native IOS code is being modified to turn the autostate feature On when the IDSM-2 is inline but I don't think it has been delivered. I am not sure what the state of the issue is in Cat OS (Hybrid).

Also be aware that once again this would be a stateless failover so existing TCP sessions would be denied and new TCP connections would have to be established.