Any 1U - 2U Ethernet switches that can handle 4K VLANs?

This is correct, but then why spend the money on a L3 switch? Routing
isn't needed so save the money and purchase a L2 switch.

bye,
ken emery

L3 switchiong is just term for idiots - it is ROUTING in old terms. So,
VLAN's means _routing_.

The point of using VLAN's is that, in many cases, IP routing for VLANs is
provided by the switching fabric, very effectively. And that you have
universal patching - everything is very flexible. But .. managing 100 Cisco
3550 (or other venor, no matter) switches wiith 4,000 VLAN's... brr, it is
a very seriuos task. I'd think about central 6509 switch(es), with a few
local (in rack) dumb 3524 switches to decrease a patching... or about
private VLAN (single!) .

If they mean dynamic VLAN's so that they assign VLAN to the MAC, they expect
to assign 4,000 different VLAN's. Having 4,000 LVALs means that workstations
are just isolated. Ok, set up 1 (one) private VLAN, and workstations are
isolated (be very careful, because it will require careful ARP
configuration, careful proxy arp etc etc... but it is possible. Or just keep
1 VLAN and many ssecondary IP per interface... I think, that you can find
many options.).

May be (I can not exclude it), they have a very good idea, which pay off
when configured. As I was saying, I can not exlude it, and I am sure, that
it is possible to find non-cisco L3 switches, able to do such task much
better than Cisco. The only drawback is _time te test it all_ and _time to
select such vendor_.

:
:L3 switchiong is just term for idiots - it is ROUTING in old terms. So,
:VLAN's means _routing_.

Um, no, VLAN does not infer routing. 802.1q and even Cisco's ugly
proprietary ISL both operate at layer two.

As to "L3 switching" and the spin involved in such, it's an old,
predictable story, which we all wrote off as marketing drivel at least a
couple years ago...

1) Cisco ISL is much better than urgly 802.1q - first of all, it was
designed many years before 802.1q. I am not even talking abiout those
idiots, who designed 802.1q as a _spanning tree on the trunk level_, which
made many configurations (which we used with ISL ain 199x years) impossble,
and caused vendors to extend 802.1q.

2) Of course, VLAN does not infer routing. But VLAN routing can be provided
on the switch fabric, effectively bypassing many traditional drawbacks - see
Cisco 6509, for example.

1) Cisco ISL is much better than urgly 802.1q - first of all, it was
designed many years before 802.1q. I am not even talking abiout those
idiots, who designed 802.1q as a _spanning tree on the trunk level_, which
made many configurations (which we used with ISL ain 199x years) impossble,
and caused vendors to extend 802.1q.

Is it April 1st? ISL changes the size of packets, does it not? So know you have to deal with MTU issues. What happens when I want the biggest MTU possible? I know it is not much a difference in size, but for some people, size does matter.

I am quite happy with dot1q. My gripe is with poor spanning-tree implementations. I don't want a single spanning-tree for every vlan on a trunk... I like standards, but I am happy with Rapid-PVST. Just my feelings about the issue. I would never deploy ISL unless I had something like a 1900 that did not do dot1q

2) Of course, VLAN does not infer routing. But VLAN routing can be provided
on the switch fabric, effectively bypassing many traditional drawbacks - see
Cisco 6509, for example.

Are you talking about multilayer switching implementations? That is why C came out with dCEF. I costs, but if you want to do serious routing, damn if it ain't fast :wink:

ISL _DOES NOT CHANGE_ packet size.

Is it April 1st? ISL changes the size of packets, does it not? So know
you have to deal with MTU issues. What happens when I want the biggest
MTU possible? I know it is not much a difference in size, but for some
people, size does matter.

I am quite happy with dot1q. My gripe is with poor spanning-tree
> 2) Of course, VLAN does not infer routing. But VLAN routing can be
> provided
> on the switch fabric, effectively bypassing many traditional drawbacks
> - see
> Cisco 6509, for example.

Are you talking about multilayer switching implementations? That is why
C came out with dCEF. I costs, but if you want to do serious routing,
damn if it ain't fast :wink:

Agree in general.

> 1) Cisco ISL is much better than urgly 802.1q - first of all, it was
> designed many years before 802.1q. I am not even talking abiout those
> idiots, who designed 802.1q as a _spanning tree on the trunk level_,
> which
> made many configurations (which we used with ISL ain 199x years)
> impossble,
> and caused vendors to extend 802.1q.

Is it April 1st? ISL changes the size of packets, does it not? So know
you have to deal with MTU issues. What happens when I want the biggest
MTU possible? I know it is not much a difference in size, but for some
people, size does matter.

I am quite happy with dot1q. My gripe is with poor spanning-tree
implementations. I don't want a single spanning-tree for every vlan on
a trunk... I like standards, but I am happy with Rapid-PVST. Just my
feelings about the issue. I would never deploy ISL unless I had
something like a 1900 that did not do dot1q

Amen. At my previous employer, we got rid of ISL on almost all trunks.
I wouldn't dream of going back. The only thing I don't really like about
802.1q compared to ISL is the idea of "native" or "default" VLAN. I want
links to be either access (untagged) or trunk (*all* packets tagged).
Fortunately, reasonably new Cisco switches let me enforce that with
"vlan dot1q tag native".

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

ISL _DOES NOT CHANGE_ packet size.

An 802.1q tag adds 4 bytes to the Ethernet frame.

ISL encapsulation adds 30 bytes to the Ethernet frame.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Both the ISL _and_ the Dotq headers are stripped off at the trunk
interface so they _both_ change the packet size but neither alters the
payload.

                            Scott C. McGrath

Both the ISL _and_ the Dotq headers are stripped off at the trunk
interface so they _both_ change the packet size but neither alters the
payload.

Obviously. But the fact that ISL adds 26 bytes more than 802.1q means
that multiple levels of ISL encapsulation is somewhat less practical
than multiple levels of 802.1q tags.

Some of us *need* those multiple levels of 802.1q tags.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

So what? Is is a sugnificant drawback? I do not think so. Both ISL and
802.1q require special interface cards (with extended frame size), and I do
not see any reason, why 26 bytes vs 4 bytes makes big difference. /May be,
the only pro for 802.1q tagging is it's possible implementation on the old
interface cards, which did not allowed extra 30 bytes but allowed extra 4
bytes/.

I am no saying that ISL is better tha 802.1q, but 802.1q is not much better
than ISL, and (in some cases) is even worst.

Sorry; of course, I meant _change MTU_.

welcome to 2004. ISL is a thing of the past. let us move on.
  ./end_flamebait.sh

-J (who realized Cisco no longer supports ISL on 2950 and some other newer box)