VLAN basic question

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
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.

Re: VLAN basic question
Quoted text here. Click to load it

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.

Hope this helps.

Re: VLAN basic question
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)

Thank you for your help.

Re: VLAN basic question
Quoted text here. Click to load it

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, and has separate VLANs for,, and  There are no
trunks back to switch 1, it simply advertises these via a routing
protocol.  Switch 3 may own, and hopefully you get the

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 (, 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.......

Re: VLAN basic question

Quoted text here. Click to load it

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

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.


Peter from Auckland.

Re: VLAN basic question
Peter wrote:
Quoted text here. Click to load it

You mean this? (mono spaced font required to view diagram)

accountant Fred - PC ----+
accountant Mary - PC ----+ 1
                          |           +---- Accounts server
accountant Eric - PC ----+           |
                          |       3   |
                       Router --------+---- DBMS server
                          |           |
salesman Slim - PC ------+           |
                          | 2         +---- Sales server
salesman Sal - PC -------+

That is counter-intuitive to me, if the Accounts people use a different
server than the Sales people, wouldn't you put the Accounts server and
the Accounts people into the same VLAN?

I'd naively expect that most server traffic communicates with people's
PCs than with other servers.

Obviously this depends on server arrangements. A back-end DBMS server
might only communicate with middleware servers.

accountant Fred - PC ----+
                          | 1
accountant Mary - PC ----+
                          +---- Accounts server -----+
accountant Eric - PC ----+                          |
                                                     +---- DBMS server
                                                   3 |
salesman Slim - PC ------+                          |
                          +---- Sales server --------+
salesman Sal - PC -------+ 2

Three VLANs?

Re: VLAN basic question
Quoted text here. Click to load it

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.

Two 6500 cores with dual msfcs.  10 gig backbone, 2 gig backup.  Two,
4 gig etherchannels out to ALL sector (distribution) layer switches
from both cores.  Cores have VLANs for everything, logically separated
by function, and in some cases if a project has enough clout, by
project.  Example would be VLANS for network devices, routed vlans (2
networks), device management interfaces, wintel, sun, aix, linux,
external load balancer networks, internal load balanced networks,
users (by floor usually), mainframe (OSAs), internal/external DMZs,
and some specific networks for project specific stuff.

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....

Just an example of what you can do......

Re: VLAN basic question

Quoted text here. Click to load it

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).
Quoted text here. Click to load it

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.

Quoted text here. Click to load it


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.


Peter from Auckland.

Re: VLAN basic question
Quoted text here. Click to load it

Another way to do this:

Fred Mary and Eric are on VLAN-1
Slim and Sal are on VLAN-2

Accounts server is on VLAN 1 and 3
Sales server is on VLAN 2 and 3
DBMS server is on VLAN 3

This way, Fred can only access the accounts server. He cannot access the
sales or DBMS server directly.

And Slim can only access the sales server directly. He cannot access the
accounst or DBMS servers directly.

Accounts server can talk to DBMS and Sales servers. (since they all belong
to VLAN 3). But the accounts server cannot talk to Slim or Sal.

By giving a port multiple VLAN memberships, it can greatly simplify things.

And there is no need for a router.

Re: VLAN basic question
Quoted text here. Click to load it

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.

Re: VLAN basic question
Trendkill wrote:
Quoted text here. Click to load it

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
Quoted text here. Click to load it

switchport multi vlan 3,4
switchport mode multi

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

node1    VLAN 1
node2  VLAN 1
node3  VLAN 1,2
node4  VLAN 2

if node1 tries to ping node4, it will not get any response.
if node3 tries to ping node4, it will get normal responses.

Just because they are all in the same subnet doesn't absolutely require that
they all be reacheable from each other.

And if you do not like having a subnet where not all nodes can talk to each
other, then you simply do:

node1    VLAN 1
node2  VLAN 1
node3,  VLAN 1,2
node4  VLAN 2

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 IP , if it
tries to talk to node4, it will sign its packets with its 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.

Re: VLAN basic question
Quoted text here. Click to load it

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.

Re: VLAN basic question
Trendkill wrote:
Quoted text here. Click to load it

You don't want engineers/geeks to use promiscuous tools on their machines to
snoop on human resources systems to find out the president's salary.

By having the engineers on a separate VLAN, their ethernet simply doesn't carry
any of this traffic and they can't "physically" connect to the huram resources
servers to hack into it.

Re: VLAN basic question
Quoted text here. Click to load it

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 and 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.....

Site Timeline