From: Benjamin Marandel (benjaminmarandel.com)
Date: Fri Jul 15 2005 - 15:11:50 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

James,

1°) Yes, the bypas unit in on the NIC for coper model. If you have a
fiber model you have to buy external ISS optical bypass unit.

2°) I am sure people read documentation, especialy if they speek
english... (I hope! :/ )

3°) Could do you tell me where you have seen in the documentation:
-That you have to plug your box power off ?
-That interface act as a 'PC' when you force the speed mode ?
-etc,....

Thanks.

-ben.

James Tingler wrote:
> Bypass included with the Prov-G? Is this internal because this didn't
> come with my package. It does however fail open to the best indications
> of my pre-tests. This is good information you are passing. Does anyone
> bother to read the documentation. What you say is all there.
>
> Thanks
>
> >>> Benjamin Marandel <benjaminmarandel.com> 7/12/2005 4:39 PM >>>
> Hi,
>
> I just want to re explain the way the Proventia G works, and how you
> should plug the box in production.
>
> First, you need to know that the box is pluged on the network OFF. Don't
> plug the power on your box, just plug the network and the network
> traffic should go.
>
> The only think you need to know is that the bypass unit (included for
> copper interface) works as a cross over unit when the appliance is power
> off.
>
> So if you want to plug the appliance in place of a straight cable, you
> have to use a straight cable and a cross over cable (included, green
> short cable).
>
> Then, you power on the appliance. By default each interface are in Auto
> Mode. This auto mode concern the classic speed and mode negociation, but
> it include also if the interface is crossed or not.
> To avoid this negociation (taking some time and not always efficiant)
> you should force the speed and mode of the interface. But in this case
> the interface works as a classic 'PC' interface (not crossed). So you
> should use more cross over cable.
>
> Take a look at these training excercices:
> Ex 1]
> Configuration:
> [Firewall]<--Straight Cable-->[Switch]
>
> Please place straight or cross over cable and the appliance.
> Answer:
> [Firewall]<--SC-->[Proventia G]<--COC-->[Switch]
> Power off: the traffic pass through, because the appliance is a
> crossover unit.
> Power on: the traffic pass through, in AUTO mode only.
> For forced mode you should use this configuration:
> [Firewall]<--COC-->[Proventia G]<--SC-->[Switch]
> So the place where you put the cross over cable is important.
>
> Ex2]
> Configuration:
> [Router]<--CrossOver Cable-->[Firewall]
> Answer:
> [Router]<--SC-->[Proventia G]<--SC-->[Firewall]
> Power off: the traffic pass through.
> Power on: the traffic pass through, in AUTO mode only.
> For forced mode you should use this configuration:
> [Router]<--COC-->[Proventia G]<--COC-->[Firewall]
>
>
> Hope this helps.
>
> -ben.
>
>
> McLean, Michael R wrote:
> > David:
> >
> > That would be wonderful if you had anything to help the pain.
> >
> > Thanks,
> > MRM
> >
> > -----Original Message-----
> > From: CAUSEY, David [mailto:davidclmi.org]
> > Sent: Friday, July 08, 2005 9:12 PM
> > To: McLean, Michael R; Matt Kaar; Chris Norris/AMIG
> > Cc: ISSForumiss.net
> > Subject: RE: [ISSForum] Inline Appliance and Switch Configuration
> >
> >
> >
> > Yes, I have been here too. When we set things up about 1 1/2 years
> ago I had the exact same questions and issues. We have a Pro G. and
> wanted it to sit between a Cisco PIX firewall and Cisco 65xx series
> switch. It worked fine when things were on but if it was powered down
> there were lots of problems getting the PIX and the Cisco 6500 to
> renegotiate.
> >
> >
> >
> > I called ISS and they pretty much read the book to me which was no
> help. I already knew what the book said... "the Pro g fails open, it
> does nothing to change the data flow, it just passes from NIC A to B,
> etc". But that isn't really true. It does do something. When it would
> either power off, have the services stopped or go through a warm boot we
> had differing results. So it must be doing something! It isn't truly a
> passive pass-through as ISS claims. If that were true then off or on the
> Cisco devices on both sides would not have a need to renegotiate.
> >
> >
> >
> > I opened a call with Cisco also and they concur with what people are
> saying in this forum. PortFast needs to be ON. I tried every combo and
> ran tons of simulations to see. The fastest I was able to obtain was
> about a 15-30 second outage while ports renegotiated during a Proventia
> power outage. When the Pro G came back up there was no delay at all. I
> think ISS says you lose 1 packet. With portfast off the reneg. time was
> more like several minutes I believe. (this was 1.5 years ago) I do
> remember you had to have a crossover cable on one side of the Pro G. (it
> did not matter which side).
> >
> >
> >
> > I will try to find the docs I created at the time and post those
> results. (btw... because of some other issues we put a smaller switch
> (Cisco 2924) on both sides of the Pro G and that solved a lot of those
> slow reneg. times. So our config now goes:
> >
> >
> >
> > Internet <> Cisco 2924 (outside firewall) <> Pro G port B / Pro G
> port A <> Cisco 2924 (inside firewall) <> Cisco 65xx <> internal network
> >
> >
> >
> > I'll look for those notes which I created BEFORE adding the 2924's.
> >
> >
> >
> >
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: issforum-bouncesiss.net [mailto:issforum-bouncesiss.net] On
> Behalf Of McLean, Michael R
> > Sent: Tuesday, June 28, 2005 11:59 AM
> > To: Matt Kaar; Chris Norris/AMIG
> > Cc: ISSForumiss.net
> > Subject: Re: [ISSForum] Inline Appliance and Switch Configuration
> >
> >
> >
> > We will be doing the same thing, so I am very interested in your
> experience.
> >
> > And I will provide our experience to all.
> >
> >
> >
> > MRM
> >
> >
> >
> > -----Original Message-----
> >
> > From: Matt Kaar [mailto:matt.kaargmail.com]
> >
> > Sent: Tuesday, June 28, 2005 8:54 AM
> >
> > To: Chris Norris/AMIG
> >
> > Cc: ISSForumiss.net
> >
> > Subject: Re: [ISSForum] Inline Appliance and Switch Configuration
> >
> >
> >
> >
> >
> > Chris,
> >
> >
> >
> > I wrestled with this question about a year ago while working with G
> >
> > appliances and here's my take on it. Though I have not played with
> >
> > uplinkfast or backbonefast, I recommended enabling portfast on those
> ports
> >
> > connected to the G. Here's my reasoning (and it's been a while since
> I've
> >
> > done this, so anyone feel free to correct me :)
> >
> >
> >
> > Spannning tree's main purpose is to avoid switching loops within your
> >
> > network. Now, if you take a fully functioning network with IPS
> working and
> >
> > you don't have switching loops, then you just need to worry about when
> >
> > link-state goes down on the G for that split second. If there are no
> loops
> >
> > created during that period of time, you can bring the G back up w/o
> waiting
> >
> > through the STP learning period and have no problems. Since the
> period of
> >
> > time that the link-state is actually down is fairly small (less than a
> >
> > second IIRC), you're betting that no one will create a switching loop on
> >
> > another part of your network during that time.
> >
> >
> >
> > Since connectivity after a G power loss was a paramount concern, I
> >
> > recommended using portfast to bring those switch ports up as fast as
> >
> > possible. Your environment may have different requirements, so as usual
> >
> > YMMV.
> >
> >
> >
> > -Matt
> >
> > --
> >
> > Matt Kaar, CISSP
> >
> > Carnegie Mellon University
> >
> > Information Networking Institute
> >
> > matt.kaargmail.com
> >
> >
> >
> > On 6/24/05, Chris Norris/AMIG <CNorrisamig.com> wrote:
> >
> >
> >
> >>Just curious to know how others are handling the physical install of
> >
> >
> >>Inline
> >
> >
> >>IDP devices. We are looking to move our Proventia G to inline mode as it
> >
> >
> >>wasn't installed this way originally.
> >
> >
> >
> >>I was told that in "acts just like a cable" and would not be a problem in
> >
> >
> >>passing traffic in the event of a power failure on the device. That's not
> >
> >
> >>exactly true. With no power it passes traffic "like a cable" but when
> >
> >
> >>power
> >
> >
> >>is present the IDP establishes link-state with the 2 switches it's
> >
> >
> >>connected to. When power is lost so is link-state with the switches which
> >
> >
> >>can invoke a spanning-tree change.
> >
> >
> >
> >>This is what happened during our test. It's too bad that the device
> is not
> >
> >
> >>truly "passive" from a link-state perspective so that it would allow the
> >
> >
> >>switches to "see" each other through the IDP, but it is what it is.
> >
> >
> >
> >>So my suggestion to our network team is to look at options such as
> >
> >
> >>"uplinkfast" or "backbonefast" since they are using Cisco switches. I
> >
> >
> >>suppose they could use "portfast" on the IDP ports but I have always
> >
> >
> >>frowned on "portfast" (which disables Spanning-Tree learning mode) on
> >
> >
> >>anything but end user ports.
> >
> >
> >
> >>What are other people doing?
> >
> >
> >
> >>Regards,
> >
> >
> >>Chris Norris CISSP
> >
> >
> >>American Modern Insurance Companies
> >
> >
> >>Sr. Security Engineer
> >
> >
> >>IS Risk and Security Management
> >
> >
> >
> >>_______________________________________________
> >
> >
> >>ISSForum mailing list
> >
> >
> >>ISSForumiss.net
> >
> >
> >
> >>TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
> >
> >
> >>https://atla-mm1.iss.net/mailman/listinfo/issforum
> >
> >
> >
> >>To contact the ISSForum Moderator, send email to mod-issforumiss.net
> >
> >
> >
> >>The ISSForum mailing list is hosted and managed by Internet Security
> >
> >
> >>Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
> >
> >
> >
> > _______________________________________________
> >
> > ISSForum mailing list
> >
> > ISSForumiss.net
> >
> >
> >
> > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
> https://atla-mm1.iss.net/mailman/listinfo/issforum
> >
> >
> >
> > To contact the ISSForum Moderator, send email to mod-issforumiss.net
> >
> >
> >
> > The ISSForum mailing list is hosted and managed by Internet Security
> Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > ISSForum mailing list
> >
> > ISSForumiss.net
> >
> >
> >
> > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
> https://atla-mm1.iss.net/mailman/listinfo/issforum
> >
> >
> >
> > To contact the ISSForum Moderator, send email to mod-issforumiss.net
> >
> >
> >
> > The ISSForum mailing list is hosted and managed by Internet Security
> Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
> >
> > _______________________________________________
> > ISSForum mailing list
> > ISSForumiss.net
> >
> > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
> https://atla-mm1.iss.net/mailman/listinfo/issforum
> >
> > To contact the ISSForum Moderator, send email to mod-issforumiss.net
> >
> > The ISSForum mailing list is hosted and managed by Internet Security
> Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
> >
> >
>
> _______________________________________________
> ISSForum mailing list
> ISSForumiss.net
>
> TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
> https://atla-mm1.iss.net/mailman/listinfo/issforum
>
> To contact the ISSForum Moderator, send email to mod-issforumiss.net
>
> The ISSForum mailing list is hosted and managed by Internet Security
> Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
>

_______________________________________________
ISSForum mailing list
ISSForumiss.net

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to mod-issforumiss.net

The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]