Re: How does Internal Bypass mode work on Juniper IDP range

The problem may have been related to the spanning tree protocol. Many
(most?) bypass units cause a momentary loss of link when relays switch
the security device in and out of the circuit. The link state change
likely causes the switches on either end of the link to enter a
recovery phase in which they begin to recalculate the "new" network
topology. With some switches and some complex (redundant network
paths) networks, this can take many minutes to complete during which
the network will generally not pass traffic. Combine that with the
typical bypass event triggering 4 link state changes (bypass engages
causes a link down followed by an immediate link up, and when the
bypass disengages it causes another link down and link up) and you
find that some switch topologies get "lost in the weeds" for _many_
minutes while all of the spanning tree activity resolves itself.

On Wed, Oct 27, 2010 at 4:13 AM, Maqbool Hashim <[email protected]> wrote=
:
> Hi Joel,
>
> Good point, I'm not sure that a duplex or mdix issue was the cause of the=
 downtime in our case however. =A0Reason I say this is that the issue seeme=
d to disappear after half an hour, without any intervention. =A0This wouldn=
't happen if it was a duplex/MDIX issue. =A0However its certainly the type =
of gotcha I was hoping to find out about when posted to the mailing list.
>
> Many Thanks
>
> -----Original Message-----
> From: Joel M Snyder [mailto:[email protected]]
> Sent: 26 October 2010 18:25
> To: Maqbool Hashim
> Cc: [email protected]
> Subject: Re: How does Internal Bypass mode work on Juniper IDP range
>
> =A0> In bypass mode, traffic enters the IDP ingress port and is forwarded=
 =A0> out of the egress interface without being passed to the IDP engine.
>
> I can't speak to the Juniper IDP box, but there are a number of issues th=
at I have seen with hardware bypass.
>
> First, depending on the equipment, you may have incorrectly made cables.
> =A0Different hardware works differently, but normally the hardware bypass=
 inserts a crossover between the two devices when it snaps into place.
> Thus, depending on what you have on either end of the IPS, you may need t=
o have one crossover cable on one side and a straight-through on the
> other side. =A0 For gig, not a problem, but if you have a device that
> doesn't do auto-MDIX, you've got an issue. =A0This is the number-one prob=
lem I've seen and is the result of a sloppy install.
>
> Second, you may have a negotiation problem. =A0These are myriad throughou=
t the networking world. =A0Your typical networking team member knows how to=
 set it up correctly, but if a security person without the right background=
 did the configuration, you may have (for example) one side doing auto-nego=
tiation and the other side not, a recipe for failure (depending on how your=
 device actually implements non-negotiated traffic)
>
> Those two seem to cover about 90% of the issues. =A0The other 10% are cau=
sed by bad relays--the IPS box doesn't actually "snap in" to bypass mode wh=
en the watchdog doesn't go off or the power disappears.
>
> You can probably isolate to these three, or some other, by performing a p=
ower cord attenuation on the IPS device during a sanctioned downtime.
>
> Unless the Juniper is badly flawed and in need of a forklift upgrade, the=
 MAC table issue is non-existent; the IPS should not be interfering with th=
e MAC on either side of it.
>
> jms
>
>
> On 10/26/10 6:29 PM, Maqbool Hashim wrote:
>> Hi,
>>
>> I recently saw an outage in a network that had a Juniper IPS device depl=
oyed. =A0The outage consisted of tcp sessions timing out for users, ping co=
nnectivity was not confirmed. =A0The IPS is deployed in transparent mode an=
d Internal Bypass is enabled on the ingress and egress interface pair that =
make up the virtual router. =A0 My understanding of the internal bypass fea=
ture is as follows as per the Juniper documentation:
>>
>> In bypass mode, traffic enters the IDP ingress port and is forwarded out=
 of the egress interface without being passed to the IDP engine. =A0The ing=
ress and egress interface join mechanically to form a circuit in order to c=
ontinue passing traffic through the IPS device. =A0Effectively the interfac=
es become a piece of wire. =A0Bypass mode is triggered by a timing mechanis=
m during system failure or shutdown. =A0This feature has been enabled to op=
timise availability and ensure that network outages do not occur because th=
e IDS crashes/fails/ or cannot process packets fast enough.
>>
>> I'm trying to determine the cause of the outage we suffered, which is wh=
y I wanted a deeper understanding of internal bypass and the effects it may=
 or may not have on the surrounding network architecture. =A0The outage I s=
aw occurred at around the same time the IPS box rebooted and consequently e=
ntered bypass mode. =A0Bypass mode was only activated for a minute from the=
 syslog entries, however the outage we saw lasted for approximately half an=
 hour.
>>
>> So my questions regarding bypass mode are:
>>
>> 1) During bypass mode the link status on the IPS interfaces will be down=
. =A0Will the switch interfaces connected to the IPS device remain up as th=
ey are now connected to each other through the IPS (piece of wire) rather t=
han to the IPS interfaces?
>>
>> 2) =A0If the switch interfaces are now connected to each other rather th=
an the IPS what about mac forwarding tables? =A0Is it possible that the for=
warding tables on the switches get confused?
>>
>> 3) Any specific session based issues that could be caused by the IPS dev=
ice engaging and disengaging internal bypass mode?
>>
>> My feeling is that the issues might be caused by how the network environ=
ment responds to the IPS engaging/disengaging internal bypass mode rather t=
han an issue with the IPS device. =A0I'm just looking for some guidance on =
any gotchas that I should be aware of with regards to the network environme=
nt when the IPS device triggers bypass mode.
>>
>> Thanks
>>
>> Maq
>>
>>
>>
>> ----------------------------------------------------------------------
>> This e-mail and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are=
 addressed. If you are not an intended recipient, please delete this e-mail=
 immediately and notify NTS(UK) Ltd on 0844 815 5925 This e-mail does not n=
ecessarily reflect the Company's opinion and should not be interpreted as s=
uch.
>> This message was scanned by Proofpoint Protection Server - please contac=
t NTS for further information.
>>
>> -----------------------------------------------------------------
>> Securing Your Online Data Transfer with SSL.
>> A guide to understanding SSL certificates, how they operate and their ap=
plication. By making use of an SSL certificate on your web server, you can =
securely collect sensitive information online, and increase business by giv=
ing your customers confidence that their transactions are safe.
>> http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e
>> 1a17f194
>>
>>
>
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One =A0 =A0 =A0 Phone: +1 520 324 0494
> [email protected] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.opus1.com/jms
>
> -----------------------------------------------------------------
> Securing Your Online Data Transfer with SSL.
> A guide to understanding SSL certificates, how they operate and their app=
lication. By making use of an SSL certificate on your web server, you can s=
ecurely collect sensitive information online, and increase business by givi=
ng your customers confidence that their transactions are safe.
> http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a1=
7f194
>
>
>

-----------------------------------------------------------------
Securing Your Online Data Transfer with SSL.
A guide to understanding SSL certificates, how they operate and their application. By making use of an SSL certificate on your web server, you can securely collect sensitive information online, and increase business by giving your customers confidence that their transactions are safe.
http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a17f194