<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>When a IPS/IDS device (any in-path device to be honest) with fail-to-wire capabilities is in production, you will have two Ethernet links: One on the "inside" link, one on the "outside" link.</div><div><br></div><div>When the NIC fails to wire, these Ethernet links will have to be setup again, this time between the device on the "inside" link and the device on the "outside" link.</div><div>It is the time it takes to setup the Ethernet link again which will cause the packet loss.</div><div><br></div><div>So far I have seen:</div><div>- All back within seconds (no spanning tree enabled on the connected devices, interface were set to a fixed speed/duplex (yes this is before gigabit networks))</div><div>- All back within seconds (no spanning tree enabled on the connected devices, interface were set to autonegotiation).</div><div>- All back in 10-30 seconds (spanning tree enabled on the connected devices)</div><div>- Came back with a lot of errors (different speed/duplex settings on the connected devices)</div><div>- Never came back (wrong cables, incompatible speed/duplex settings on the connected devices)</div><div><br></div><div>Packets will be lost with an in-path device, it is up to the higher layer protocols to recover from it. TCP is very good at it on its own, the rest needs help from the application.</div><div><br></div><div>Hook up the device when it is off to make sure the network is working.</div><div>Turn on the device and make sure the network is working. If not, fix it and make sure it still works when the device is off after the change.</div><div><br></div><div><br></div><div>Interfaces set to Fail to block are a different story, you will have no network connectivity through it unless you have redundancy around it.</div><div><br></div><div>Edwin</div><div><br></div><div><div>On 01/12/2011, at 00:18 , Eric Appelboom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi, Depends on the vendor, McAfee Intrusheilds (I-Series) for example are usually installed with external fail-open kits.<div>The originals (white leds) were supplied by netoptics (they do taps as well) they would kick in without a network interruption when upgrading appliance firmware or removing the sensor. The newer kits (blue leds) do drop stateless protocols (icmp/udp and the like) however TCP pauses as packets are retransmitted. Typically no longer than 1-2 seconds.</div>
<div><br></div><div>Have not deployed any M-Series appliances to date. Checkpoint IPS-1, Radware DefensePro have internal failopen switches which makes RMA'ing and an appliance challenging. </div><div>Eric</div><div>
<br><br><div class="gmail_quote">On Wed, Nov 30, 2011 at 2:46 PM, <span dir="ltr"><<a href="mailto:mants@tpg.com.au">mants@tpg.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
Just wondering if anyone want's to share their experience regarding IDS /IPS<br>
solution related to traffic handling during hardware power cycle. Did you see<br>
any packet/s drops during and after? and why?<br>
<br>
Cheers,<br>
Amante<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Eric Appelboom MInfoSysSecurity CISA CISM CRISC CISSP-ISSAP CSSLP CGEIT C|EH CCSA CCSE CCNA(SECURITY) SEC+ MCSA(SECURITY) MCSE MCTS MCITP ITIL TOGAF</div>
<br>
</div>
_______________________________________________<br>AusNOG mailing list<br><a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>http://lists.ausnog.net/mailman/listinfo/ausnog<br></blockquote></div><br></body></html>