Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [ISSForum] Inline Appliance and Switch Configuration |
|---|---|
| Date: | Tue, 28 Jun 2005 08:54:04 -0400 |
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.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [ISSForum] Auto Mail Alert 2.2 - Available, Marandel, Benjamin \(ISS Paris\) |
|---|---|
| Next by Date: | Re: [ISSForum] Inline Appliance and Switch Configuration, McLean, Michael R |
| Previous by Thread: | [ISSForum] Inline Appliance and Switch Configuration, Chris Norris/AMIG |
| Next by Thread: | Re: [ISSForum] Inline Appliance and Switch Configuration, McLean, Michael R |
| Indexes: | [Date] [Thread] [Top] [All Lists] |