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.
