Re: [ISSForum] Inline Appliance and Switch Configuration

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.