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]
