When an NSP IntruShield sensor fails and the Fail-Open Kits become active, precisely what latency and packet loss will occur at that moment
Customer need this information for both the active-mode as well as passive-mode Fail-Open Kits.
This is one that is difficult to answer directly.
The answers vary for type and the Network Devices that are connected.
It also includes the time between "heartbeats" on the sensors that determine that a change to bypass is required.
Passive FO Kits: The heartbeat FROM THE SENSOR through the Fail-Open kit is 4 seconds. If the heartbeat is missed during this interval the fail-open kit will move to bypass. That change - once initiated is in ms. But the loss of the heartbeat until the change can be up to 4 secs plus the ms.
Then, once it has changed to bypass mode the two network devices have to negotiate the connection. Depending on the make, model, type, version, and "os" of the network devices this can take from less that a half second to worse cases of up to several minutes - but that is a function of the network devices and not the fail-open kit.
Active FO Kits: The heartbeat FROM THE FO KIT across the sensor monitor ports is a default of 3 seconds but on the Active FOKs is programmable. The change, once initiated is so small it is negligible. The reason for this is that the Active FOK maintains 4 separate links itself. One to each of the network devices and one to each sensor monitor port. The change from inline to bypass or back into inline is nearly instantaneous. The FO Kit either routes the traffic through the sensor or it doesn't - the FO Kit is negotiating the connection to the devices so even in bypass mode the devices do not have to negotiate with each other so the link never drops.
While that is still a generic answer to your question it will hopefully help you understand the differences between the two.
Notes on Active FO Kits: Currently they are only supported by the 5.1 NSP for command and control - and only on the M-Series. In that software version there is an added port mode of "Inline Fail-Open Mode (Active)" that supports the Active FOKs. However, logically the kits can be used on any sensor and on any other NSP Software version and will operate as described above but for the following exceptions:
- No Controller cable so you will not be able see the state of the FO Kit (Bypass or Inline)
- The sensor does not "see" that there is a FOK in the configuration
- Thus you have to set the port mode to "Inline Fail-Closed" - the end functionality is the same as setting it to Inline Fail-Open due the FOK handling the traffic flow.
- But again.. you won't be able to see whether the Monitor port pair in being bypassed or is inline expect by looking to see if there is traffic via the port stats.
- Caveat: the SNMP version of the FOK can be directly queried by an SNMP client to check it's status (Inline or Bypass)
- The next release of the 6.0 NSP will support Active FOKs. (I keep saying NSP because it is a combination of the NSM and NSS (sensor) software to support this feature) I do not have any word on the expected date for that release.
So... Under 5.1 NSP you can use the Active FOKs. Under 4.1 or 6.0 NSP the Active FOKs will work but you will have to set the sensor monitor ports to "Fail-Closed". You will not be able to manage the FOKs from the NSM in these 4.1 and 6.0 environments. But you can set up an NMS system to perform periodic checks via SNMP of the Bypass State.
will support the Active FOKs and is due out fairly 'soon' - in quotes because I do not have any release date to provide.
That shoud be enough to digest I think...
I'm fairly certain they are made for McAfee by NetOptics.
As for which models cross reference? I guess it would be possible to dig through the site and find the matching feature models.
Still the guides in the KBs are fully descriptive of how to deploy and use them.