From: McLean, Michael R (Michael.McLeanjpfinancial.com)
Date: Mon Jul 11 2005 - 08:33:13 CDT

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

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.

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