Amen!
""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]
