>http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sft_6_1/configgd
>/vlans.htm
>
>http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/c65sp_wp.htm
>
>Give a good idea of configuring and deploying PVLAN's
>
These pointers became my introduction to Private VLANs. My first
impression of the material was "huh? What problem is this solving?"
My second impression is that the marketing people have come up with
yet another proprietary name for a set of functions that all are
well-defined, although admittedly it may be original to package them
together.
The motivation for much of this seems to be generalizing "Ethernet"
to non-LAN applications, such as using optical Fast or Gigabit
Ethernet as an access technique. Inside Nortel, I recently was
accused of sending out the "sermon email" bewailing that the word
"Ethernet" is being extended so that it's approximately as precise as
"switch" or "hub," rather than a family of specific IEEE 802
specifications and some vendor extensions.
As I read the Private VLAN spec, although I haven't extensively
analyzed it, it appears to be a means of imposing a hub-and-spoke,
NBMA subnet onto a switched Ethernet subnet. In other words,
switched Ethernet is normally a classical IP subnet that follows the
local versus remote assumption: if you are on the same subnet as
another node, according to this assumption, you have layer 2
connectivity to it. WAN NBMA services such as frame and ATM partial
meshes violate this assumption.
Private VLANs appear to be such a topology restriction, which I
suppose may have applications when VLAN technology is simply being
used for transmission. It's rather ironic that VLANs, as first
defined in IEEE 802.10, were conceived as a security solution and
included encryption. The evolution to 802.1 took out the security
features, but Private VLANs are introducing a different security
mechanism.
If I went back to basics in the 802.10 model and applied it to
private VLANs, considering one direction of transmission only just
for simplicity, I might achieve a cryptographic equivalent that
suggests that the promiscuous node had a set of decryption keys for
traffic encrypted by isolated ports. Isolated ports would each have
a unique encryption key. Another way to look at it is that there is,
in IPsec terms, a set of security associations from the isolated
ports to a common promiscuous port. Many-to-one topology, in contrast
to the usual one-to-many we see in multicast.
On the other hand, the same topology could be achieved by having each
isolated node use a /31 subnet, or some flavor of unnumbered subnet,
and have the promiscuous node present some aggregated subnet to the
larger routing system.
So I'm not sure precisely what problem this solves. It seems to have
an assumption that it is worthwhile to reduce the number of VLANs in
the system, but I'm not completely sure why this is a problem.
Limiting IDB consumption by subinterfaces perhaps?
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
