Hi, guys,
Would you please answer my question related to a basic concept of
virtual LAN? I learn that one of the big advantages of VLANs is that
VLANs provide an easy, flexible way to modify logical groups in
changing environments. But what determines a computer belongs to a
certain VLAN instead of other VLANs? Does it depend on the computer's
network configuration (default gateway), the MAC address, or what
plugs in the interface where the certain VLAN has been configured on
the switch?
Please help me clarify the basic question.
Thanks,

Very briefly, it all depends which port a node is plugged into at the
switch level. The network admin/engineer assigns VLANs based on
whatever network design they have decided to implement, and assigns
these VLANs to ports on the switch. When your PC plugs into that
port, it will automatically be joined to that subnet. However,
communications do not proceed until the node has a proper IP address,
which will either be assigned by DHCP automatically, or statically via
your network configuration. If you assign an IP that does not match
the network assigned to the VLAN, you do not 'automatically'
switch.....your node simply will not work.

The above being said, there are technologies (802.1X) that will allow
a switch to dynamically assign a VLAN to a port based on information
exchange with the node itself. This is usually for ports that may
have multiple different users plugging in, such as a port in a cubicle
that has both full-time associates and contractors. Certain
credentials will prompt the switch to place you into a wide-open VLAN
for associates, or a limited VLAN for vendors/contractors. All
depends on that authentication and information exhange.

Thank you for your answer, Trendkill.
In a real situation, several end nodes (workstations, printers,
laptops, etc.) connect to hubs and switches, and these hubs and
switched eventually connect to a core switch, where the VLANs will be
configured. Then i have two questions:
1. Hubs do not have the capability to provide VLANs to individual
ports. How can VLANs be extended beyond the edge device ports even if
a core switch capable of supporting VLANs is attached?
2. On these switches that directly attach the edge devices, do i still
have to configure VLANs on their ports? (These switches are usually
cheap lay2 switches. some of them don't support VLAN technology)

You have two options when it comes to VLANing. First, which is the
newer model and pushed by Cisco for datacenters, is layer 3
distributed. Meaning all switches are layer 3 switches that
effectively 'own' their own VLANs. The switches have
interconnections, and exchange routing. As an example, Switch 1 may
be your core backbone, but only has layer 3 links to other switches.
Switch 2 may own 192.168.0.0/22, and has separate VLANs for
192.68.0.0, 192.168.1.0, 192.168.2.0 and 192.168.3.0. There are no
trunks back to switch 1, it simply advertises these via a routing
protocol. Switch 3 may own 192.168.4.0/22, and hopefully you get the
idea.

The other option, which seems to be where you are due to your hardware
limitation, is when a central core switch (with layer 3 MSFC or
something similar), owns all vlans. The vlans are trunked out to
other switches where nodes are connected. Before I go any further,
whenever a HUB is involved, whatever VLAN is on the port that the hub
is connected to on the switch (hope that makes sense), is the VLAN for
ANY connection on that hub. As an example, if the hub connects to a
switchport that is in VLAN 10 (192.168.10.0), every port that is in
that hub will need to be in that vlan, as a hub is simply a repeater
and cannot separate broadcast domains.

Back to the discussion, the most common approach is to create how many
VLANs you need, most being /22 to /25s networks, and trunk them out to
switches as needed. Most people either choose to do this via
geography (VLANs for parts of your building, or buildings), via
business function (by department), or by device function (unix
servers, windows servers, users, etc). Large enterprises usually do a
mesh of device function and geography. As an example. vlans for unix
servers, windows servers, dmzs, mainframe, users on floor A, users on
floor B, users on floor C, etc).

Whatever you choose, just be aware of your contraints. If you have an
entire room that is served by a hub, even if they have different
business functions, you will need to put them all in the same VLAN as
hubs dont support multiple networks. Basically, you have to design a
network as good as you can, given the constraints that you have. I'd
be happy to discuss further.......

A big problem with Raw Ethernet is that as you connect more devices to
the SAME SEGMENT, then the Broadcast Domain also increases, and that
can increase the chance of a small issue on 1 or 2 machines, affecting
the entire network. Using VLANS to logically break up the larger
PHYSICAL segment provides a method of reducing the potential for
impact in such situations. VLANS also allows other security and
management requirements to be applied, but with much smaller areas of
impact.

With VLANS, it is important to remember that a VLAN is a ISO Layer 3
boundary that can be applied to a Layer 2 Network. So if you use VLANS
on an Ethernet Segment, then you need a ROUTER to move traffic between
the VLANS.

So the reality is to think about what you are trying to do with VLANS
and what "issues" you are trying to prevent/solve. Overall, the prime
reason is to reduce the size of the Broadcast Domain, and the most
obvious way of doing that is to contain all like functionality into
the same VLAN (EG: all Severs into VLAN 21, all Accounts people into
VLAN 22, all Sales people into VLAN 23, etc.).

So there are in fact MANY ways of using VLANS, but all of them revolve
around segmentation of the larger environment into much smaller,
easier to handle sizes.

While I will not sit here and say that broadcast domains are
completely a thing of the past, the concern for broadcast domains was
primarily in days when 10 meg ethernet was the standard, and 100 meg
was not around yet. There is absolutely no problem running /22 or /21
networks with thousand hosts, especially if you are running gig
interfaces. I work for a very very large company, and we run /21s
and /22s in our DMZs for thousands if not hundreds of thousands of
users to access.

That being said, and presuming we have eliminated the layer 3
distribution model from this discussion, I believe in separating users
and servers. In the old days, we did this so the servers weren't in
the same network with all the broadcast traffic from user end nodes,
although with today's technology that really isn't an issue anymore.
I guess if I had to justify it today, its for segmentation. Just in
case I need to toss up a ACL or VACL for a worm, I can do it very
easily and protect the data and applications that are critical. If
you have gigs between your switches or more, there is absolutely no
reason why you can't segment off servers even though their primary
users are in a different vlan. On the counterpoint, there is also no
reason why you can't just lob them all in together, but network design
is a tricky thing when you move from a small to medium sized company
or you get taken over or acquire somebody. While there may be no
reason to think about these things within a small business at the
moment, its always good to keep things in a good logical design for
the future.

While I have tons of layer 3 distribution layer stuff in my production
environment, here is a very brief example of what I still have left on
the layer 2 model.

Core1 owns all layer 2 and layer 3 for odd numbered vlans, Core2 owns
all layer 2/3 for even numbered vlans. What I mean by that is HSRP
and spanning tree priority. Secondary core would have next highest
spantree priority for odd vlans, and distribution layer has highest
priority so it never becomes root....

Well thats just one way of segmenting things up, however remember that
if you will need a Router to communicate between the Layer 2 sections,
and THAT is where you need to place ACL's to "manage" the traffic.
Now you could also do this with a Firewall, but then that would depend
on EXACTLY what you wanted to achieve. EG, you coud put ALL Servers
into one VLAN, but then you still need the ACL's to control access to
the servers (if you want to separate who can get at each Server).

Thats not always the case, I am aware of Database Servers that do
nothing but talk to Web Servers, the end user of the Web Servers don't
go anywhere near the DB Servers (so you get strong Server <> Server
flows). In this case security was important (Internet facing Web
servers), so there was a Firewall between the Web and DB servers.

There are a vast number of possible variations on a theme, however its
the overall concept of your reasons for segmenting things, and to do
that you have to fully understand all traffic flows involved, as you
can eaasily impact on performance while trying to add security.

Exactly.

Iit really all comes down being absolutely sure you know what you are
wanting to do and how you can make VLANS work for you.

I'm not sure I follow here. First you still need a router to 'own'
the VLANs. Second, you cannot have a interfaces on the same router in
the same network. So I'm not sure how you assign multiple vlans to a
port, when you still have to IP that server in one or the other. At
first I thought you were saying to dual-nic the servers, but your
statements further down tend to state otherwise. Lastly, the primary
VLAN is the only vlan that an addressed port will work in, unless the
device supports secondary VLANs such as IP phones.

The bottom line is you can VLAN the networks however you want....so
its best to come up with a design and stick with it. Whatever your
justification for segmentation (if segmenting at all), just make it a
standard and think through the possibilities of new departments,
divisions, doubling or tripling users, etc. Provided you architect
something that will meet your organizations needs for the next 5-10
years (given reasonable growth or changes), you have done your job.

VLANS are not "router" entities, they ethernet switching entities. So a switch
will be able to segragate your lans into multiple VLANS. You can then use a
router if you wish to connect these logically separate lans together.

> So I'm not sure how you assign multiple vlans to a

switchport multi vlan 3,4
switchport mode multi

In terms of IP level stuff, there is nothing preventing you from having:

So Node3 has two IP interfaces on the same ethernet interface. If it tries to
talk to node1 or 2, it will "sign" its packets with its 10.0.0.3 IP , if it
tries to talk to node4, it will sign its packets with its 192.168.1.1 IP.

In any event, node1 and 2 cannot see nor talk to node 4

If, on the other hand, the goal is not to isolate groups but rather segment
broadcast domains for performance reasons, then you will want to have a router
and have a different IP subnet in each VLAN. This way, any node can talk to any
node, but broadcasts will remain within the same subnet/VLAN only.

I suppose this makes sense, just have never encountered any such
requirements in very large, enterprise networks. Sounds to me like an
architecture pushed by limited budget for servers, NICs, or proper
network infrastructure. Regardless, I appreciate your time explaining
it and extend you a thank you.... Why you would want to have servers
in multiple non-routed vlans is definitely a unique requirement from
my perspective, can you give an example of such requirements from a
business perspective? I completely understand the usage of private
vlans for service providers, but I think this guy is talking about the
core of small network where most of this discussion is not
applicable...aka simple routed segmentation.

The above sounds like a generic requirement to simply VLAN off the two
different user groups and use an ACL. Seems to me this is micro-
managing IPs and switch ports when there are other ways to accomplish
this that don't involve segmenting a subnet into multiple vlans. I
couldn't even imagine troubleshooting local area network issues when
random rules are placed on layer 2. I don't see how having
192.168.0.0/25 and 192.168.0.128/25 and putting up an ACL doesn't
accomplish the same thing and make it much more logical from a network
and troubleshooting perspective. (Or make the subnets smaller if you
don't have that many machines).

Lastly, and back to the question on this thread, the guy should move
forward with segmenting his network as it makes logical sense. He can
always go back and throw in VACLs or ACLs, or a firewall if unique
requirements like this come up. I don't see the above scenario as
being scalable.....