VLAN basic question

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.

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.

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

Greetings,

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.

Cheers....................pk.

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?

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

Greetings,

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.

Cheers............pk.

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.

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.

switchport multi vlan 3,4 switchport mode multi

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

node1 10.0.0.1 VLAN 1 node2 10.0.0.2 VLAN 1 node3 10.0.0.3 VLAN 1,2 node4 10.0.0.4 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 10.0.0.1 VLAN 1 node2 10.0.0.2 VLAN 1 node3 10.0.0.3, 192.168.1.1 VLAN 1,2 node4 192.168.1.2 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 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.

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.

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