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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Friday, July 08, 2005 9:12 PM > > To: McLean, Michael R; Matt Kaar; Chris Norris/AMIG > > Cc: [email protected] > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of McLean, Michael R > > Sent: Tuesday, June 28, 2005 11:59 AM > > To: Matt Kaar; Chris Norris/AMIG > > Cc: [email protected] > > 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:[EMAIL PROTECTED] > > > > Sent: Tuesday, June 28, 2005 8:54 AM > > > > To: Chris Norris/AMIG > > > > Cc: [email protected] > > > > 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 > > > > [EMAIL PROTECTED] > > > > > > > > On 6/24/05, Chris Norris/AMIG <[EMAIL PROTECTED]> 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 > > > > > >>[email protected] > > > > > > > >>TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to > > > > > >>https://atla-mm1.iss.net/mailman/listinfo/issforum > > > > > > > >>To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] > > > > > > > >>The ISSForum mailing list is hosted and managed by Internet Security > > > > > >>Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328. > > > > > > > > _______________________________________________ > > > > ISSForum mailing list > > > > [email protected] > > > > > > > > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to > https://atla-mm1.iss.net/mailman/listinfo/issforum > > > > > > > > To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] > > > > > > > > The ISSForum mailing list is hosted and managed by Internet Security > Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328. > > > > > > > > > > > > _______________________________________________ > > > > ISSForum mailing list > > > > [email protected] > > > > > > > > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to > https://atla-mm1.iss.net/mailman/listinfo/issforum > > > > > > > > To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] > > > > > > > > The ISSForum mailing list is hosted and managed by Internet Security > Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328. > > > > _______________________________________________ > > ISSForum mailing list > > [email protected] > > > > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to > https://atla-mm1.iss.net/mailman/listinfo/issforum > > > > To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] > > > > The ISSForum mailing list is hosted and managed by Internet Security > Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328. > > > > > > _______________________________________________ > ISSForum mailing list > [email protected] > > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to > https://atla-mm1.iss.net/mailman/listinfo/issforum > > To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] > > The ISSForum mailing list is hosted and managed by Internet Security > Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328. > _______________________________________________ ISSForum mailing list [email protected] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
