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 <benjamin@marandel.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:davidc@lmi.org]
> Sent: Friday, July 08, 2005 9:12 PM
> To: McLean, Michael R; Matt Kaar; Chris Norris/AMIG
> Cc: ISSForum@iss.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-bounces@iss.net [mailto:issforum-bounces@iss.net] On
Behalf Of McLean, Michael R
> Sent: Tuesday, June 28, 2005 11:59 AM
> To: Matt Kaar; Chris Norris/AMIG
> Cc: ISSForum@iss.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.kaar@gmail.com]
>
> Sent: Tuesday, June 28, 2005 8:54 AM
>
> To: Chris Norris/AMIG
>
> Cc: ISSForum@iss.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.kaar@gmail.com
>
>
>
> On 6/24/05, Chris Norris/AMIG <CNorris@amig.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
>
>
>>ISSForum@iss.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-issforum@iss.net
>
>
>
>>The ISSForum mailing list is hosted and managed by Internet Security
>
>
>>Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
>
>
>
> _______________________________________________
>
> ISSForum mailing list
>
> ISSForum@iss.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-issforum@iss.net
>
>
>
> The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
>
>
>
>
>
> _______________________________________________
>
> ISSForum mailing list
>
> ISSForum@iss.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-issforum@iss.net
>
>
>
> The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
>
> _______________________________________________
> ISSForum mailing list
> ISSForum@iss.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-issforum@iss.net
>
> The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
>
>
_______________________________________________
ISSForum mailing list
ISSForum@iss.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-issforum@iss.net
The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
_______________________________________________
ISSForum mailing list
ISSForum@iss.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-issforum@iss.net
The ISSForum mailing list is hosted and managed by Internet Security Systems,
6303 Barfield Road, Atlanta, Georgia, USA 30328.
