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!

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.