You should contact
your 3Com network consultant (sales engineer) for
this kind of advice at any time. I'm sure your regular 3Com
contact would be happy to work through these kind of issues.
I hope the following info helps.
The short answer to your question is yes, you most certainly
do have to assign different subnets to the different VLANs.
This is nothing peculiar to 3Com's implementation but simply
the nature of what a VLAN is/means/does. By definition, a VLAN --
whether defined as a grouping of ports or a grouping of MAC
addresses -- is a set of resources BRIDGED together so that
if a broadcast is issued by any resource in the VLAN,
it's received by the other resources in that VLAN. In other
words, it defines the set of switched segments that make up
a "Broadcast Domain."
By default, a switch would be a single
broadcast domain, i.e. all ports switched (bridged) together,
with a unicast forwarded to a port only if the destination address
is located there, but broadcasts forwarded to all ports -- i.e. a
single LAN. The basic idea of VLANs is to carve up the switch into
multiple broadcast domains. Sometimes we do this for performance,
i.e. at some point, with a set of interconnected switches, we can get
to the point where we have too many ports switched (bridged)
together, and the aggregate broadcast traffic gets too big. The limit
varies with which protocols and applications you use.
Sometimes we do this for security, where you might want to carve
a switch up into multiple zones where users in one VLAN can't "see"
(i.e. receive broadcasts from) a server or other resources on a
different VLAN and/or not allow a user to unicast to another resource
physically connected to the same switch, but in a different VLAN.
So that's the background. But the point is a VLAN is a set of resources
bridged together. To get from one VLAN to another, you must route. If
we bridged/switched two VLANs together ... well ... by definition at
point, they'd now be one big VLAN. But if you're going to route between
two LANs -- physically separate cable plants or logically separate VLANs
either way, if you're routing between two spaces, again by definition
they need to be separate subnets. If they're the same subnet, a sender
would expect to be able to ARP for the receiver's MAC address and
formulate a layer-2 packet end-to-end. A router only jumps into the
data path in the first place when the end station's protocol stack sees
that the layer-3 address he's trying to send to is on a *different*
thus he can't ARP for the MAC address (because ultimately ARP is a
broadcast-based mechanism, meaning you can only ARP for other folks
on your LAN/VLAN), so he sends the packet to his default gateway (the
router), who in turn forwards it on to the destination network.
*Because* we've separated into VLANs, the end stations can only
communicate inter-VLAN through a router, and *if* we want the
router to make that connection, they have to be separate subnets,
otherwise, the router would just bridge the two groups, and then
we'd be back to square one -- one broadcast domain, which means
they wouldn't be separate VLANs.
I don't know if I've been clear, but again, this is nothing peculiar to
way 3Com or the SuperStack Switch 1000, in particular, implement
VLANs. This is just the way VLANs, routing, and the separation of
ISO Layer 2 and Layer 3 work. By definition, to use VLANs is to create
separate logical networks on the same switched space, thus requiring
the router to interconnect these now separate networks (subnets).
And a final aside, this is the reason many folks have ended up not using
VLANs. Despite the hype, they ain't all they seem to be -- again, I'm
talking VLANs in general. This whole issue above is the basic hidden
"gotcha" behind the technology. Powerful tool for creating flexible
logical domains within a physical network, but to implement them
often (if not usually) means some resubnetting work.
The exception to this -- the place where I am a big fan of VLANs -- is
in reducing the cost of adding or moving users. In this case, I'm not
talking about breaking up an *existing* LAN into VLANs, but rather
that when a user from one network physically moves to another
network, if we're using VLANs, we could keep that user with his
same old logical group (subnet) by bridging him in with that group
even though he's now physically located with other folks bridged
into a different group.
Hope this is useful.
From: InterSerF Support Team[SMTP:support @
Sent: Wednesday, August 27, 1997 5:52 PM
To: firewalls @
Subject: 3C Switch
-----BEGIN PGP SIGNED MESSAGE-----
I have seen some folks on this list a couple of weeks ago that
discussion switches and specifically the 3Com switches. So I
have some switch experts out there. I need some help as I can't
any from the documentation or maybe my brain is just too fried
understand it. Sometimes I can't see the forest for the trees
can make you feel dumb as a rock!
We have the 3Com Switch 1000 - 24 port. It is setup with several
VLAN's. All NIC's on all 5 VLAN's are using an ip from the same
C address and yet I don't seem to be able to communicated
VLAN's. Now I realize that the idea is to gain better control
security over your network and the separated VLAN's are only
to be able to talk to each other through the router. All 5
ports are setup correctly (including security off) and are
to a repeater (only a short distance away) which is connected to
network gateway router (Cisco 2501). Do I need to be "routing"
VLAN's on an individual basis? What I mean is, do I need to add
routes to the cisco? The IP on the switch ether is also one from
same class C. Does this ether need to be included in the cisco
router? The cisco is already routing the whole class C anyway.
Subnetting seems to be redundant and a waste of IP's since I
have a switch. I have been over this many times in the last
days and can't seem to get a handle on it. I would appreciate
help and/or suggestions. Thanx.................
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
-----END PGP SIGNATURE-----
System Administrator http://www.interserf.net
InterSerF Support Team - Internet Services of Fredbrg
11901 Main Street Fredericksburg, Virginia 22408
(540) 371-4195 Voice (540) 371-4197 FAX