-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 2000-06-20-23:01:45 Roeland Meyer (E-mail):

...

Bob Biver: Tuesday, June 20, 2000 7:28 PM the docs say max 250, is this informational or a limit of spanning tree?

If I recall correctly, that's also real close to the maximum number of physical connections to the chasis, with all modules installed. Personally, I've never run anywhere near that number. I don't think it is useful to have less than 2 members in a vlan. You would also be surpassing the bandwidth limitations of that chasis, even if all the connections were 100baseTX.

For many uses, I think you certainly have a clear and reasonable point. But while I don't know what the original poster had in mind, I can fantasize a use for thousands of vlans, even on a switch that doesn't have thousands of distinct ports. And without necessarily exceeding available bandwidth. Lessee, suppose I were designing something like an internet-access-for-hotel-rooms, or thereabouts. Or suppose otherwise I had thousands of users who didn't trust each other, at all, who I didn't want to have sniffing each other's traffic, who were just wanting to share access to an internet connection, itself less than 100BaseT, maybe even much less. One way I could fantasize doing it would be to assign a separate VLAN to each port of as many different switches, interconnected with 802.1Q or ISL, as it took to provide ports to every room. Run one 802.1Q line into the one router in this picture, say a Linux box using iproute2 for traffic shaping. Ok, so maybe 6509s would be way overkill for this application, no way you need that kind of backplane bandwidth. But as circumstances emerge where you want to have a fully-routed network (next step up the protocol ladder from a fully-switched network --- each host gets its own dedicated router port) I can anticipate settings where VLANs might get abused in a most remarkable way. - -Bennett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5UDpTL6KAps40sTYRAkSXAJ9zRIAdsIp1xjdS2Vl56WjTeNdmdgCghySl Z+zy1YE6u1OW3RopArzAkDg= =gFAm -----END PGP SIGNATURE-----

2000-06-20-23:56:07 Bora Akyol:

If you put all of the users on seperate switch ports, then would they be able to snoop each other's traffic? At least the switches that I have seen prevent this behavior unless you put a particular switch port in "monitor" mode.

Sorry, I did a dumb thing here, I basically carried over a whole debate context from other lists and assumed it here. I should have least referenced the other discussions. It's been discussed at great length on firewall-wizards@nfr.com and firewalls@lists.gnac.net. The short version is, the core switch behavior you're talking about was never designed as a security barrier, or an IP level traffic visibility control tool; it was just designed to shrink the scope of traffic visibility for performance reasons. Any number of hacks, like CAM table flooding, can coerce a normal switch to leak somethign fierce. Furthermore, and badly mangling the intent of my example, VLANs weren't originally designed as security barriers, they were just intended to help provide control over the scope of broadcast domains, to help people better provision the use of the excruciatingly expensive switch ports, when switches were young, their ports were dear, and they came in just a few sizes. But where the focus of core switch behavior is purely at the MAC level, VLANs at least are defined in terms of specific physical ports, leaving room to hope that barring security bugs in the OSes on the host processors of the switches, VLANs may be a bit more effective as security barriers.

As long as all rooms in this hotel are on seperate switch ports, you would basically be OK even without using VLANs.

Depends on the level of protection and control you want to offer. Barring bugs in the switch OS, VLANs _should_ allow you to very positively associate traffic with specific ports, if you give each one a separate VLAN; this you cannot reasonably do with simple switches given a dynamic user community. Simple switches leave you far weaker guarantees about inter-user protections as well, but what I was trying to hint at with the thought about doing traffic shaping with the upstream router was the idea of keeping accountability right from the individual switch port all the way to the router. Probably too flawed an example to be any good, sorry for the digression here. -Bennett

Sez "Roeland Meyer (E-mail)" <rmeyer@mhsc.com>

...

Bob Biver: Tuesday, June 20, 2000 7:28 PM the docs say max 250, is this informational or a limit of spanning tree?

The docs say 1000, actually. http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_ gd/vlans.htm#xtocid225297 I'd worry if you plan on having more than 100 STP instances on a switch; if you're doing single-port VLANs, do yourself a favor and disable STP for those VLANs.

...

also, is anyone running more than 250 ?

There's probably someone doing it somewhere.

If I recall correctly, that's also real close to the maximum number of physical connections to the chasis, with all modules installed. Personally, I've never run anywhere near that number.

It's possible to have 384 FE connections in a single Cat6509 today. I do it frequently, but not with each in a different VLAN.

I don't think it is useful to have less than 2 members in a vlan.

You forget that the routing module (aka MSFC) might be the other member, not counting as a physical port.

You would also be surpassing the bandwidth limitations of that chasis, even if all the connections were 100baseTX.

Oversubscribed by 20%. In reality, a Cat6509 doing end-user aggregation, loaded to the hilt with 10/100 ports, will rarely see 10% utilization. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, HCOE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com