http://www.everything2.com/index.pl?node_id=20165 HTH, TroyC -----Original Message----- From: Gareth Hinton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:50 PM To: [EMAIL PROTECTED] Subject: Re: Private Vlans - Is this a good idea FUD - Sounds gud! What is it? If the FU stands for what I think it does, what does the D stand for. Sorry for dragging the thread to one side, but I think I work somewhere that FUD cud become a major part of our vocabulary. I don't want to make up my own D if it's already in popular use :-) Cheers, Gaz ""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message news:p0500190eb6e697785d87@[63.216.127.100]... > Let me generalize my standard question of "what is the problem you > are trying to solve," with "what problem do you NOT WANT to solve." > What you are describing is a management, not a technical, problem. > > If your customers are part of the same organization as you are, > someone to whom both of you report needs to explain economic > realities to them. This explanation would be along the lines of: > > 1. The network organization has a budget. > 2. This budget is based on certain rational engineering assumptions > about what components can do, and what services can safely share > the same component. > 3. VLANs were invented as a security technique, with the goal of > isolating groups of users. > > 3a) The "multi-VLAN" approach that allows a port to be in more > than one VLAN, IMNSHO, is _evil_, has marginal applicability, > and designs that include it should be tied up and thrown into > a pond. If they float, burn them at the stake. If they don't > float, let them drown. > > 4. There is no reason for concern about sharing a properly configured > switch. Unless the customer can document WHY it is a problem, > their only justification is FUD, and the network organization should > not have its budget governed by FUD. > > 5. If there are real security requirements for physical switch separation, > as might be specified for government classified networks that > follow RED/BLACK isolation criteria, then the costs of additional > switchgear should be part of the budget of the organization with > the security requirement. > > If your customers are a true customer and you are in a profit-making > world, I would have the appropriate management (i.e., that is > concerned with cost of sales rather than gross revenue) consider > carefully if you can afford having them as a customer. Your > strategic business interest may be served by letting your competitor > inherit this customer's problems. > > In other words, the customer needs to ask, "what part of NO do you > fail to understand?" > > >Roberts, > > > >I don't think 5500 supports pvlan, it has to be 6500, but I heard from > >somewhere those lower end 2948/4000 also will be able to support pvlan very > >soon. > > > >pvlan, from my understanding, does not give you more security among vlans. > >It only controls ports within the same vlan by preventing them from talking > >to each other without your control. It is more of a way of saving vlans for > >service providers. > > Correct. > > >I believe the doc of 6500 explains it pretty well. > > > >If your customer is concerned about vlan leak, I am afraid you will probably > >have to give them a seperate switch or they can use some kind encryption > >before sending out any traffic. > > > >Just my 2 cents. > > > >HTH > >KY > > > >""Roberts, Timothy"" <[EMAIL PROTECTED]> wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > >> I have some customers that need to be connected to my network. They > >insist > >> on not having their servers connected to a switch that has other customers > >> on it. They will not pay for an additional switch. I was considering > >> recommending private vlans? That way things are more secure on the > >switch. > >> Is this a good idea? The current switches are catalyst 5500. Does this > >> hardware support private vlans? I have checked the documentation and I > >have > >> only found that the software needs to be 5.4(1) but they make no mention > >of > > > hardware requirements. > > _________________________________ > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > _________________________________ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _________________________________ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
