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.
