Spanning Tree Protocol - 802.1D

My college campus used to have a gigantic problem with switching loops. The reason is, they didn't run STP.  All anyone had to do to bring the network to a complete standstill was plug a crossover cable from one port in the wall to another port in the wall.  This would cause a networking loop, leading to a broadcast storm, and obliterating the network.  Why are network loops so bad?  Isn't redundancy good?  Yes, but if you have more than one active path, broadcasts will obliterate your network.  Each time a broadcast it is sent out every port, this broadcast will reach the switch that sent it through the loop, and be forwarded again, and again, and again until there's no bandwidth left for legitimate traffic.

This is why it's so important to prevent loops, and STP is the way you accomplish that.  STP, the Spanning Tree Protocol eliminates loops in the network by essentially shutting down redundant links (paths) in a network.  Here's how it works.  All switches running STP send BPDUs (Bridge Protocol Data Units) as multicast packets to track down loops.  If these BPDUs find their way back to the originating switch, a loop was detected.  BPDUs are also essential to electing the Root Bridge, the pillar of the network.  All switches will try to find the most optimal path to the root bridge, and block all the other paths.  Now, STP is designed to work right out of the box, but without tweaking it can really slow down your network.  The reason for this is the way in which the root bridge is chosen, or elected.  Each switch has a Bridge ID, made of a priority and a MAC address.

Bridge ID = Priority.MACADDR.

It may seem counterintuitive, but lower is better when it comes to the bridge ID.  Out of the box, all switches have a default priority of 32768, so when the networking is choosing the root bridge, the switch with the lowest MAC address will be chosen, which is generally the oldest (going by manufacture date).  To rectify this you have several options.  You can lower the priority (in increments of 4096, don't ask me why) to a lower number than the default, but if there is a tie, they will default to MAC addresses to break it.  You can also use the following command, which will lower the priority to 24576 (IEEE's recommended value for the root):

Switch(config)#spanning-tree vlan 1 root primary

Making sure your root bridge is placed in an optimal location on a powerful switch is very important, otherwise your network will be slowed down by an outdated switch.

Once your root bridge has been elected, switches will start sending out BPDUs to find the best path to that switch.  It judges the path based on link cost.  The following Link Costs are assigned to these link types.
10 Mb/s   -  100
16 Mb/s   -  62
100 Mb/s -  19
1 Gb/s      -  4
2 Gb/s      -  2
4 Gb/s      -  1

So if a switch has to go across 3 100Mb/s links to get to the root bridge, that path will have a cost of 57.  If that switch connected directly to the root bridge over a 10 Mb/s link, it will prefer the former.

This leads us to the three different kinds of ports for STP.

Root Port - The port traffic goes out to reach the root bridge
Designated Port - Port that forwards traffic, there will be one of these per link.  It's either a port that leads to a host, a port on the root bridge, or a port opposite of one that is being blocked.
Blocking/Nondesignated - Port that is blocked by STP.  On a link that is blocked, only one port will be put in blocking mode, the other will remain designated.  Can you guess which side will be blocked?  Yup, the side of the switch with the higher MAC address, because in STP, lower is better.

Pop quiz, what are all the ports on the root bridge set to?  Answer: Designated.  Root ports are used to reach the root bridge, so it obviously won't want to reach itself, and it won't put any ports in blocking mode since other switches need to get to that switch.

It's a really good idea to go online and find some examples and sample problems to practice predicting which links will be shut down.

Let's say you have three switches, connected in a triangle.  Link 1 and 2 are active, and link 3 is in blocking.  Say someone unplugs link 2.  Well STP is going to see this and switch link 3 to a forwarding state, but it's going to take a while (30~50 seconds).  The reason it takes so long is that the ports on link 3 have several states to go through before they become designated ports.

Listening - Port listens to BPDUs to make sure it doesn't hear any loops on the network before it forwards frames.
Learning - Port listens to BPDUs and learns all paths on the network and populates the MAC address table.  The time it takes to go from listening to learning is known as a Forward Delay, and is set on the switch.
Forwarding - Sends and receives frames.  If the port is still a root port or a designated port at the end of the learning state, it will be put in this mode.
Blocking - Port will not send frames, but will listen for BPDUs.  When a switch is powered up, all ports are in this mode.
Disabled - Administratively shut down, does not forward frames or participate in STP.

When all ports in a network have entered a forwarding or blocking state, the switched network has converged.  While STP is in the process of converging, no host data is transmitting.  It usually takes about 50 seconds for the network achieve convergence (though you can reduce timers to lower this, I wouldn't recommend it for basic STP).  So every time there is a network change, your entire switched network goes down for 50 seconds!  Doesn't seem like a lot?  Well it's a huge amount of time in the networking world.  Imagine you have VOIP set up, it only takes a few seconds of downtime to drop your calls.  Credit card transactions won't go through, a server backup fails, and your boss can't get on Facebook.
Yikes.  Luckily there have been some major improvements to STP to speed up the process and make STP more efficient.

Thanks for reading!

VLAN Routing

There's one issue I want to cover before I finish VLANs for the ICND2: Routing between VLANs.  Now there are two ways you are required to know for the ICND2, but there is also a third method which I'll gloss over the basics briefly.

I like to call the first method Port-Per-VLAN, and it looks like this.

The premise is simple, you need to have a port for each VLAN you want to route between assigned to that VLAN.  So traffic from the top computer enters the switch, is forwarded to the router on the VLAN10 port, the router sees it and says, "Oh, I know the route to get to that computer, sends it out the VLAN20 interface, and the switch forwards it to the bottom computer.  Seems like a waste, huh?  Well yes and no, remember the whole point of using VLANs is to reduce broadcast traffic (okay, that's definitely not the only reason), so the picture above may minimize the benefit that the VLANs are actually providing.  Luckily, there is another way to set this up that will spare a router port.

A router on a stick (I'm not kidding, that's what it's actually called) looks like the following.

Pay special attention to the interfaces on the router.  Those are known as subinterfaces.  It basically splits one port into multiple interfaces.  So the actual interface isn't given an IP address, only the subinterfaces are.

Here's an example.  Traffic originating from the VLAN10 PC is sent to its default gateway (10.0.10.1), so the switch forwards it to the router on FA0/0.10.  The router gets it, sends it back out on FA0/0.20, which is assigned to VLAN20, and forwards the packet to the VLAN20 PC.  If this example were reversed, the bottom PC would send a packet to it's default gateway (10.0.20.1), thus demonstrating how the router is able to distinguish which packet is coming from which VLAN.

The final method is known as Layer 3 Switching, which is a CCNP topic.  It works essentially the same as a router on a stick, but uses a more powerful switch with a software upgrade.  This switch has both layer 2 and layer 3 capabilities, and can perform the router on a stick task without actually needing to send traffic to a router.

Let's configure a router on a stick using the above picture as a diagram of our network.  We'll assume our PCs are assigned their correct default gateways, and the VLANs have been created on the switch.

Corndog(config)#int fa0/0.10
Corndog(config-subif)#encapsulation dot1Q 10 (YOU MUST DO THIS BEFORE YOU SET THE IP)
If you're following along on your router, you might notice a warning message pop up here about "baby giant frames".  It's a funny name, but basically what it's saying is many routers don't support frames that are greater than 1500 bytes.  Remember, when you add your VLAN "clan membership card", you're adding an extra four bytes.  So if your MTU (Maximum Transmission Unit) is set to 1500, it won't be able to send the packet, so you'd have to set the MTU on both sides to 1496, unless your router and switch supports 1504 byte frames.  If you have Cisco equipment on both sides, it will automagically set both side's MTU to 1496, saving you the trouble.

Corndog(config-subif)#ip add 10.0.10.1 255.255.255.0
Corndog(config-subif)#exit
Corndog(config)#int fa0/0.20
Corndog(config-subif)#encap dot1q 20
Corndog(config-subif)#ip add 10.0.20.1 255.255.255.0

Corndog(config-subif)#int fa0/0
Corndog(config-if)#no shut

%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
%LINK-5-CHANGED: Interface FastEthernet0/0.10, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0.10, changed state to up
%LINK-5-CHANGED: Interface FastEthernet0/0.20, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0.20, changed state to up

Notice that when you turn on the interface fa0/0, it turns on all the subinterfaces as well.

Let's verify that our configuration works by pinging the bottom pc from the top pc.

PC>ping 10.0.20.10

Pinging 10.0.20.10 with 32 bytes of data:

Request timed out. (First ping fails due to time out, should happen only the first time).
Reply from 10.0.20.10: bytes=32 time=15ms TTL=127
Reply from 10.0.20.10: bytes=32 time=15ms TTL=127
Reply from 10.0.20.10: bytes=32 time=19ms TTL=127

Ping statistics for 10.0.20.10:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 19ms, Average = 16ms

Let's check the router's routing table for verification.

Corndog#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR


Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.10.0 is directly connected, FastEthernet0/0.10

C       10.0.20.0 is directly connected, FastEthernet0/0.20

Great, both route were learned, and VLANs can talk to each other.

Phew, we did it.  That should be all the posts I'll be covering on VLANs for the CCNA.  Thanks for reading!

VTP

VTP, or the VLAN Trunking Protocol can be a huge time saver.  It can also destroy your network, if you're not careful.  VTP is actually a bit of a misnomer, since the language of trunking is 802.1q.  What VTP does is copy your VLANs to all the switches in your network.

In my last post I demonstrated how to create a VLAN on two switches.  Now it's no big deal to create VLAN10 on two switches, but what about 200 switches?  It's really an issue when you have your network all set up, but later decide to add another VLAN.  Now you have to telnet or SSH to the other 199 switches in your network and add the VLAN.

The way VTP works is through revision numbers.  Every time a VLAN is added to a VTP switch, it increments the revision number.  The other switches see a revision number that is higher then theirs and say, "Hey! There's been an update, let me copy the VLAN database".  Now this is great, but can destroy your network if you aren't careful.  There are many network administrators who have sworn off VTP after being stung by this.  Imagine you work at a company that has a production environment and a lab environment.  One of your production switches catches fire and is burned past all repair.  So you go online and buy a new switch, but in the meantime you decided to loan out one of your switches from your lab environment.  All the sudden, your whole network goes down, all your switchports start blinking orange, and the masses panic.  Can you guess the problem?  The switch you had from the lab environment was plugged into the network, and had a higher revision number than any other switch, so all the other switches overwrote their VLAN databases with the lab environment's database.  When ports have their VLAN disappear, they panic and can't talk to anyone, essentially shutting off.  In order to fix the problem you would have to go on a VTP server switch and manually add back in each proper VLAN, so be very careful when you add a VTP switch onto a preexisting network.

Luckily there are some safeguards to prevent this from happening.  You can set the VTP domain name and password to minimize the risk of someone bringing a switch from home and wiping out your network.

So how does VTP work?  VTP has three modes: Server, Client, and Transparent.  Well, by default, every switch is in VTP Server mode which is great for setup/making changes, but also very dangerous.  What Cisco recommends is having very few servers, and the rest set as clients.

Server mode gives the power to make changes to the VLAN database and propagate those changes to all other switches.  If you have more than one switch set to server mode, the switch with the lower revision number will copy the VLAN database from the switch with the higher revision database, thereby becoming equal.

Client mode is unable to make changes to the VLAN database, but it can both receive and send VTP updates.  You can't add VLANs to these switches.  Now, you can always just convert a client to a server, make a change, and change it back, but what's the point of good network design if you do things like that?

The last mode is known as Transparent mode.  Transparent mode has the power to change the VLAN database, but they won't send these changes to other switches.  They will, however, forward other switch VTP updates they hear to other switches.  It seems more confusing than it is.  Basically they are their own little VTP group.  If they receive a VTP update on a port they'll say, "Sorry, I'm not going to make any changes to my VLAN database, but I will send this update forward to the next guy for you."

Concepts = Completed, let's do some configuration.

In this configuration we have 3 switches
SwitchServer = Server mode
SwitchTransparent = Transparent mode
SwitchClient = Client mode

The switches are set up so that the transparent mode switch is in the middle as follows.
SwitchServer------------SwitchTransparent------------SwitchClient

All of our switches are in server mode by default, so no configuration is needed on SwitchServer just yet, so let's start on SwitchTransparent.


SwitchTransparent(config)#vtp domain EXAMPLE
Changing VTP domain name from NULL to EXAMPLE     (Output)
SwitchTransparent(config)#vtp password sprinkles
Setting device VLAN database password to sprinkles         (Output)
SwitchTransparent(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.                  (Output)

Now let's make some changes to the transparent switch to demonstrate that they are not propagated.

SwitchTransparent(config)#vlan 10
SwitchTransparen(config-vlan)#name TRANSPARENT

Okay, let's jump over to the client switch and change it's VTP mode, domain, and password


Switch(config)#vtp domain EXAMPLE
Changing VTP domain name from NULL to EXAMPLE    (Output)
SwitchClient(config)#vtp password sprinkles
Setting device VLAN database password to sprinkles        (Output)
SwitchClient(config)#vtp mode client
Setting device to VTP CLIENT mode.                               (Output)





SwitchClient(config)#vlan 20
VTP VLAN configuration not allowed when device is in CLIENT mode.

Excellent, this is where you have to exercise self control, leave the switch in client mode, and jump over on your VTP server switch to make changes.


SwitchClient#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa1/1, Fa2/1, Fa3/1
                                                Fa4/1, Fa5/1
1002 fddi-default                     active  

1004 fddinet-default                  active  
1005 trnet-default                    active  

Now you can see the VLAN database has no additional VLANs besides the defaults.

Let's get on our SwitchServer...

SwitchServer(config)#vtp domain EXAMPLE
Changing VTP domain name from NULL to EXAMPLE     (Output)
SwitchServer(config)#vtp password sprinkles
Setting device VLAN database password to sprinkles         (Output)
SwitchServer(config)#vlan 20
SwitchServer(config-vlan)#name SERVERVLAN
SwitchServer(config-vlan)#exit
SwitchServer(config)#vlan 30
SwitchServer(config-vlan)#name ICECREAM



SwitchServer#show vtp status
VTP Version                     : 2
Configuration Revision          : 4
Maximum VLANs supported locally : 64
Number of existing VLANs        : 7
VTP Operating Mode              : Server
VTP Domain Name                 : EXAMPLE
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x0F 0x5A 0xC0 0xA5 0x42 0xF4 0xEB 0x2B
Configuration last modified by 0.0.0.0 at 3-1-93 00:13:49
Local updater ID is 0.0.0.0 (no valid interface found)

Okay, so you can see from the show command above there have been a few changes, bumping the revision number to 4.  7 VLANS exist, the two we created and the five that are there by default.  The configuration was last modified by this switch.

Let's look at the transparent switch...

SwitchTransparent#show vtp status
VTP Version                     : 2
Configuration Revision          : 0
Maximum VLANs supported locally : 64
Number of existing VLANs        : 6
VTP Operating Mode              : Transparent
VTP Domain Name                 : EXAMPLE
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0xC7 0x96 0x4B 0x8F 0x9A 0x02 0x26 0x38
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00

You can see that the VLANs were not propagated to this switch, and the revision number has not been incremented, as expected of a switch in transparent mode.

To finish, we'll look at the client to see if the changes were updated.

SwitchClient#show vtp status

VTP Version                     : 2

Configuration Revision          : 4

Maximum VLANs supported locally : 64

Number of existing VLANs        : 7

VTP Operating Mode              : Client

VTP Domain Name                 : EXAMPLE

Great!  That's VTP in a nutshell.  Thanks for reading!

VLANs: How do they work!?

Trunking, also known as tagging outside the Cisco-world is how machines connected to two switches can share the same VLAN.  Since VLANs operate at the switch, think layer 2, so think Ethernet Frames.

Say you live in town and are a member of the VLAN10 clan.  There's going to be a clan meeting in the mountains.  You can't get into the clan meeting without your proof of membership.  So you pack all your things up in your Ethernet packet.

Destination Address = Mountains

Source Address = Town

Type/Length = Ethernet II, your total height/weight

Data = Your person

Frame Check = List of what you're supposed to bring to the meeting, just so you know you didn't lose anything along the way.

Now all that's needed is your proof of membership.  So what you do in town is you shove your VLAN clan information into the Ethernet frame, right between your Source Address and the Type/Length fields.  Congratulations, you've now created an 802.1q frame.

Once you arrive at the Mountain, the gatekeeper (switch) will strip off this VLAN tag, and forward the frame.  This way, other members of the VLAN will never see a frame that has a VLAN tag on it, if they did, they would discard it since machines can't speak dot1q.

Cisco also has a proprietary trunking language, known as ISL which has largely been phased out, and isn't required knowledge for the ICND2.

Going back to our picture, imagine the town is connected to another switch, which has some VLAN20 machines.  The machine on VLAN20 sends out a broadcast.  Do you think that broadcast will go the forest link, since there are no VLAN20 machines in the mountains?  The answer is yes, the broadcast will get to the mountain switch, which will look at their tag and say, I don't have any VLAN20 machines here, sorry, but you can't get in the clan meeting!  There's a neat trick to prevent this from happening, and it's called VLAN pruning.  Basically, it prevents the town from ever sending VLAN20 broadcasts from crossing the forest link, since there are no VLAN20 machines across it.

Enough with the concepts, let's get down to configuration.


Town(config)#vlan 10
Town(config-vlan)#exit
Town(config)#vlan 20
Town(config-vlan)#exit

Town(config-if)#switchport mode access
Town(config-if)#switchport access vlan 10
Town(config-if)#int fa1/1
Town(config-if)#switchport mode access
Town(config-if)#switchport access vlan 20
Town(config-if)#int fa2/1
Town(config-if)#switchport mode trunk
Town(config-if)#switchport trunk encapsulation dot1q




Mountain#conf t
Mountain(config)#vlan 10
Mountain(config-vlan)#exit
Mountain(config)#int fa0/1
Mountain(config-if)#switchport mode access
Mountain(config-if)#switchport access vlan 10
Mountain(config-if)#int fa 1/1
Mountain(config-if)#switchport mode access
Mountain(config-if)#switchport access vlan 10
Mountain(config-if)#int fa2/1
Mountain(config-if)#switchport mode trunk
Mountain(config-if)#switchport trunk encapsulation dot1q

Now our VLANs have been created, and ports have been assigned to them and configured as trunk/access.  Notice that the trunk link is a FastEthernet line; in order to create a trunk link, the speed must be 100Mb/s or greater.

Let's do some verification.  We'll try pinging the far right machine from the far left machine.

PC>ping 192.168.1.4

Pinging 192.168.1.4 with 32 bytes of data:

Reply from 192.168.1.4: bytes=32 time=24ms TTL=128
Reply from 192.168.1.4: bytes=32 time=12ms TTL=128
Reply from 192.168.1.4: bytes=32 time=11ms TTL=128
Reply from 192.168.1.4: bytes=32 time=11ms TTL=128

Ping statistics for 192.168.1.4:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 24ms, Average = 14ms

Success.  Now lets try pinging the 2nd PC (the one in VLAN 20).

PC>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


As expected, the ping fails since they are in different VLANs.  Let's set up pruning to prevent PC2's broadcasts from crossing the link to the mountain.

Mountain(config)#vtp pruning
Town(config)#vtp pruning

And that's all there is to it!.  In my next post I'm going to talk about VTP or the VLAN Trunking Protocol, so don't worry if you don't understand those previous two commands.

The last thing I want to talk about is a popular issue with VLANs called a native VLAN mismatch.  A native VLAN mismatch occurs when you change the native VLAN on one switch, but leave it as the default on another switch connected.  Basically, you've connected a port in VLAN 1 to a port in VLAN 2, or what ever VLAN you chose.  This essentially combines the two VLANs, and leads to broadcasts leaking or seeping into their opposing VLAN.  It's generally good practice to leave the native VLAN as VLAN1 (the default) to avoid this problem.  At the very least, if you change the native VLAN on one switch, be sure to change it on all the other switches it is connected to.

Introduction to VLANs

VLANs, or Virtual Local Area Networks used to confuse me to a great extent.  I understood the concept, but didn't quite get when they would actually be implemented.  Moreover, I needed to practice implementing it to remember the commands.  Looking back, VLANs are incredibly simple, powerful, and useful.

At its core, a VLAN is a way to divide up a network.  A simple way to remember is that
A VLAN = A subnet.  I mean this in a way that they're both ways to divide up a network.  Two VLANs cannot talk to each other without a router, just like 2 subnets cannot talk to each other without a router.  What's the point of doing this?  Well, remember all devices on a subnet share a broadcast domain.  While this isn't a big deal on a subnet of 6 computers, imagine hundreds of computers and servers sending broadcasts.  It can really slow down a network.  There's also a good security implementation.  Say you are an administrator at a high school where there are two labs, one lab houses all the student computers, and the other lab is for teachers.  Obviously you wouldn't want the students to have access to the teacher's computers, so you decide to place the labs on separate VLANs.  Now students cant access the teacher's computers, mission accomplished.

Lets consider a different scenario.  You're a Network Administrator at a company that has multiple departments.  You've noticed traffic is being dropped left and right because there's just too much broadcast traffic clogging up your switches.  So you decide to segment each department into their own VLANs.

There are the following departments in your building:
Sales - 20 users
Billing - 16 users
Customer Support - 2 users (Thus the typical 50 minute wait to get support)

Your Network looks like this, where each computer represents all the machines in that department.

So the way the network is currently setup, each time a machine sends a broadcast, every other machine connect to that switch hears it.  This is bad.  The network is congested, and you can't afford another switch. VLANs to the rescue!  By placing each department in a separate VLAN, you will segment the network, and the switch will only send broadcasts from billing to the other machines that are in the billing VLAN.  This way, a Sales broadcast will never be heard by a billing machine.  Wait, you say.  What if the sales computers need to talk to the billing computers?  Won't they be unable to now?  Correct, but there's a reason there's a router in this picture.  What you can do is configure inter-VLAN routing, but we'll get to that later.

Let's get down to configuring our VLANs on the switch.  We'll make
Billing = VLAN 10
Sales = VLAN 20
Tech Support = VLAN 30

Switch> en
Switch# conf t
Switch(config)# vlan 10
Switch(config-vlan)#name BILLING
Switch(config-vlan)#exit

Switch(config)# vlan 20

Switch(config-vlan)#name SALES

Switch(config-vlan)#exit

Switch(config)# vlan 30

Switch(config-vlan)#name TECHSUPPORT

Switch(config-vlan)#exit

Now all our VLANs have been created, to confirm, let's do a

Switch#show vlan brief

VLAN Name                                   Status     Ports
---- -------------------------------- --------- -------------------------------
1    default                                        active      Fa0/1, Fa1/1, Fa2/1, Fa3/1
10   BILLING                                  active  
20   SALES                                     active  
30   TECHSUPPORT                      active  
1002 fddi-default                             active  
1003 token-ring-default                   active  
1004 fddinet-default                        active  
1005 trnet-default                            active  

Great, you can see that our VLANs have been created.  VLAN1 is the default VLAN for all ports, and the last 4 are standard on Cisco routers, but rarely used anymore.  You can see all four ports are assigned to VLAN1, the management VLAN, so although we created our VLANs, there's nothing in them.  Let's change that.

Now, there are two kinds of ports in the VLAN world.  An access port and a trunk port (There's also dynamic, which dynamically negotiates trunk or access, but for various reasons we'll avoid it).  Access ports are designed for the hosts.  Trunk ports carry VLAN information over links in the event that there are multiple switches with machines on the same VLAN or you need to perform inter-VLAN routing.  For now, we'll assign our switch ports connecting to the hosts as access mode and put them in their respective VLAN.


Switch(config)#int fa 1/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 10
Switch(config)#int fa2/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 20
Switch(config-if)#int fa3/1
Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 30

Switch#show vlan brief

VLAN Name                                   Status     Ports

---- -------------------------------- --------- -------------------------------

1    default                                        active      Fa0/1

10   BILLING                                  active      Fa1/1

20   SALES                                     active      Fa2/1

30   TECHSUPPORT                      active      Fa3/1

1002 fddi-default                             active    

1003 token-ring-default                   active    

1004 fddinet-default                        active    

1005 trnet-default                            active    

Done.  Machines in different departments can't talk to each other, broadcasts greatly reduced.  Machines in the same department can talk to each other.  Life is good.

Don't believe me?  Try it yourself.  Set up a small lab, if you're studying for a certification exam like me, I highly recommend it.  If not, there's several simulators available online.  Try pinging machines in different VLANs, it won't work!

Thanks for reading!