IPv6 and Transition Strategies

I'm sure by now you've heard that the world is running out of addresses.  It seems like once every few months, on a slow news day the reporters dust off this old classic of impending doom that we'll be out of addresses within just a few short weeks, but luckily we have network administrators working to implement a new technology.

Well, it is true that we are running out of address space, and have been for a while, will we run out by the end of this year?  Possibly, but I doubt it.  People have been crying the end is near since 2002, and we've made it last this long, what's another year?  My guess is we'll have switched to IPv6 long before we would have run out completely, and as more people start to switch over, the demand for IPv4 addresses will not be so pressing.

With all that said, it IS time to start thinking about IPv6, so I'm going to give you the skinny on what it's made up of, and how we're transitioning to it.

The typical IPv4 address looks something like this: 141.219.10.55, comprised of 4 chunks of decimals ranging from 0-255, separated by periods.  Now when I started thinking about IPv6 I thought they'd just tack on another 2 chunks, so the address would look like 141.219.55.28.244.53, but no, it's not like that at all!  You see, the powers that be never wanted to have to make this transition ever again, so they made up a scheme that gives us more combinations than we could ever hope to use (at least not in the next few centuries).  An IPv6 address looks like this:
2001:0DB8:AC10:FE01:0000:0000:0000:0000

Whoa, are those letters!  Yup, an IPv6 address is made up of hexadecimal, so there's even more combinations.  If you don't understand hexadecimal, you might want to do a little research, I'll go over the combinations as review, but it might be a good idea to do some practice with it.
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = A (10 is A)
1011 = B
1100 = C
1101 = D
1110 = E
1111 = F
So each Hexadecimal character is comprised of 4 bits, which means a whole IPv6 addresses is made of 128 bits.

Must be a pain to set an interface with all those letters/numbers, huh?  Well yes, it is, but there are some shortcuts to make it a little easier.

First, you can drop any consecutive blocks of zeros by using a double colon.
2001:0DB8:0010:FE01:0000:0000:0000:0000 turns into
2001:0DB8:0010:FE01::
Just know that you cannot do this
2001:0DB8:0000:0000:FF31:054B:0000:0000:EE26
2001:0DB8::FF31:054B::EE26
That's because your router won't know where to put how many zeros to put back where.

Second, you can drop any leading zeros, so our initial address is reduced down into
2001:DB8:10:FE01::

There are also a bunch of types of IPv6 addresses you need to be aware of.  These are strictly memorization, so write them down on flash cards and look over them often!
Unicast - Packets addressed to a unicast address go out a single interface
Global Unicast - Publicly routable addresses
Link-Local Address - Private addresses, not to be routed
Unique-Local address - Routable within multiple local networks.
Multicast -  Packets are delivered out  all interfaces indicated by the multicast address.
Anycast - Really cool, this one identifies multiple interfaces, and the packet is delivered to the closest one.  Picture this, your company has web servers in 5 different countries.  You give them all the same anycast address and hosts will automatically be directed to the one that is closest to them!

Notice I didn't say anything about broadcasts.  They're gone!  Poof, no such thing in IPv6.

Addresses you should know:
0:0:0:0:0:0:0:0 or :: - Source address of a host (for stateful configuration)
::1 - The new 127.0.0.1
:0:0:0:0:0:0:192.168.1.1 - IPv4 address in a mixed IPv6/v4 network
FE80::/10 - Link-local unicast range
FD00::/8 - Unique local unicast range
2000:/3 - All publicly routed addresses start this way
FF00::/ - Multicast addresses

With IPv6 addresses being so long, DHCP and auto-address configuration are incredible useful tools.  The way auto-address configuration works is the device learns its prefix information from the router and appends it's own MAC addresses as the interface ID.  A MAC address is only 48-bits, and the interface ID has to be 64, so it shoves "FFFE" right into the middle of it.
So a MAC of 00-50-56-C0-00-08 becomes an interface ID of
0050:56FF:FEC0:0008 -> 50:56FF:FEC0:8
This is known as an EUI-64 identifier.

As for the converting process, there are several tools to help us ease our way over to IPv6, so we don't have to pick a date and say "if you're not using IPv6, you're not going to get on the internet."

Dual Stack Routers - This is definitely the most simple.  All it does is have a router run both IPv4 and IPv6, so it can support both networks.  To set it up (assuming you already have IPv4 set up), just turn on ipv6 routing, and apply IPv6 addresses to interfaces.
Router(config)#ipv6 unicast-routing
Router(config)#int fa1/1
Router(config-if)#ipv6 address 2001:db8:10:1:/64 eui-64 (this tag at the end fills in the interface ID for you!)

Tunneling - 6to4 carries Teredo, which places the IPv6 packets into UDP packets, which NAT doesn't nuke.

NAT-PT - My least favorite method, it doesn't encapsulate the data, it just rips it out of the packet and sticks it in the opposite type.  Imagine sending  an IPv4 packet, NAT will rip out the data and put it in an IPv6 packet.  Sounds kind of brutal if you ask me.  My texts and teachers say to try to avoid it, so I'll do just that.

Last thing you should know, most of the routing protocols had to change a little bit to support IPv6.  For the ICND2 you shouldn't need to know too many specifics, but I'll go over the basics.

RIP survived, it's now called RIPng (next generation).  Instead of using the network command to turn on RIP interfaces, just go under the interface and turn rip on.
Router(config-if)#ipv6 rip 1 enable
This'll start the rip process if you haven't created it already, and RIP will advertise this interface's subnet.

EIGRP is also very similar, it uses the multicast address FF02::A now, (IPv4 was 224.0.0.10).  OSPF did something similar to keep part of its identity.  Just like RIP, you don't use the network command anymore, just turn on the router process (you must do a no shutdown on the router process now!), and enable ipv6 on the interface
Router(config)#ipv6 router eigrp 42
Router(config-router)#no shut
Router(config-if)#ipv6 eigrp 42

OSPF is similar to it's predecessor, it even still uses 32-bit values for it's RID, area ID, and LS ID, but you must assign them manually since you don't have IPv4 addresses anymore.
Multicast addresses used for LSAs are FF02::5 and FF02::6.

Router(config)#router ospf 1
Router(config-router)#router-id 1.1.1.1
Router(config-if)#ipv6 ospf 1 area 0.0.0.0

Phew.  If I had to tell you 3 things to remember most from this post, it would be why we need IPv6, what an IPv6 address looks like (and how to shorten it), and the methods of transitioning from IPv4 to IPv6.

Thanks for reading!

Great News!

I took the ICND2 today and passed!  I'm limited in what I can say about the exam, but I can tell you that the things I posted about I tended to know much more about than the things I didn't.  The exam was pretty fair, and I didn't feel very confident when I finished the last question, but I ended up doing very well.

I woke up at about 5am this morning with the jitters (and spent the hour before getting up listening to my roommate play video games through the wall) and studied until about 7am, then drove 2.5 hrs to the testing center (I live in the middle of nowhere).  Little did I realize that the testing center was in a different time zone, so I was actually about an hour early.  I used this time to do some last minute review on WANs, EIGRP, OSPF, and IPv6, so it all turned out for the best.

Being CCNA certified is all well and good, but I want to keep going!  I'll try to finish out my posts on the ICND2 topics before I start moving on to study for my CCNP studies, so don't worry!

VLSM & Summarization

Man, I thought I'd never be done talking about switches.  Now it's on to our next topic on the ICND2's objectives: implementing IP addressing schemes to meet network requirements in an enterprise branch office network.  In order to understand this post, I recommend you know how to perform basic classful subnetting, as it was covered in the ICND1.

VLSM, or Variable Length Subnet Masking is a way to preserve address space by splitting up a block of addresses into multiple smaller chunks.  Consider it as the ability to change your subnet mask wherever.  It lets you use custom subnet masks for each part of the network.  The easiest way to learn VLSM is to see it, and the best way is to do it.  Take a look at the following image, and forgive my depiction of serial links.

So, the rule with VLSM is to start with the largest subnets first.  That means the left network.  We need to provide at least 62 hosts, and waste as few addresses as possible.  Here's the way I remember my network masks.
Start with the base /24, provides 256 address.
A single /25 provides half that, 128,
/26 = 64
/27 = 32  Remember two of those addresses are used as the network and broadcast address, so that leaves us 62 usable host addresses, perfect!

So the left side of the network uses 192.168.0.0/26, providing the host addressed 192.168.0.1-62, since .0 and .63 will be used for the network and broadcast address.

Next we deal with subnet C, which needs 14 hosts with room for expansion.  So lets continue talking halves.
/27 = 32
/28 = 16
A /28 would work for the current setup, but if we want to leave room for expansion, we should use the /27.  This subnet's address will start right where our last one left out, so it uses 192.168.0.64/27 providing usable addresses of 192.168.0.65-94 (.64 and .95 are reserved).

The top part of the network needs at least 7 hosts, so do you think we will use a /28 or a /29?  A /29 provides 8 addresses, but only 6 of them are usable; we need a /28 mask.
192.168.0.96/28 providing usable addresses 192.168.0.97-110.

All done? No.  It's tricky, but remember the interfaces for the serial links need IP addresses too!  In the name of efficiency, all point-to-point subnets should use a /30, which provides just 2 usable addresses.
The links will use the following addresses:
192.168.0.112/30 (.113 & .114 will be used)
192.168.0.116/30 (.117 & .118 will be used)
192.168.0.120/30 (.121 & .122 will be used)

To recap, here's what our network ends up looking like with VLSM addressing:

I just want to mention that this looks really good when you're designing it, and it should mimic what is on the exam, but in the real world you'll hopefully be working for a company that's growing, and you definitely don't want to run out of addresses because you were trying to be so efficient.  If the subnetwork on the left suddenly gained another user, you'd have to redesign this whole scheme, so always leave room for growth!

Now that you know how VLSM works, take caution that you know it can only be used with a classful routing protocol, such as EIGRP, OSPF, RIPv2, etc.  It will NOT work with RIP or IGRP.

While I'm on the topics of routing protocols and IP addresses, I want to introduce the next big topic, Summarization.  Summarization is the processes of combining multiple routes into one in order to speed up route processing.  You see, the way routers work is they get a destination IP and they look down their routing table for a match.  The larger the routing table, the longer it will take to find a match.  By combining individual routes into larger groups, you make the routing table smaller, and subsequently, the router faster.

Imagine you have a whole bunch of routers connected to each other.  Connected to one of these routers are the following networks:

192.168.0.0/24

192.168.1.0/24

192.168.2.0/24

192.168.3.0/24

In order for every other router, they will need to have entries for each network in order to reach them.  What summarization does is combine those four routes into a

192.168.0.0/22

This works because all the other routers need to go to this router in order to get to those networks anyway, so they don't really need to have a separate route for each one.  What if you add another network to this router: 192.168.4.0/24.  The summary route will no longer work, as it does not encompass the new network. You have two choices, either expand the summary route to a /21, which will also absorb .5.0/24, .6.0/24, and 7.0/24, or just leave it as is.  If you leave it as is, routers will have the summary route and the additional route, and you will not waste the other 3 networks.  If you end up adding another network or two, then you can push the summary route back to a /21, and not waste so many addresses. 

Now, that's the efficient way to summarize.  You should also know the incorrect way, the automatic way.  By default, most routing protocols have auto summarization turned on by default.  This means they summarize networks back to their classful boundaries.  So instead of getting our summary route, you'd end up with 192.168.0.0/16.  Woahsummarization, which you'll need to do if you plan on using VLSM/discontiguous network schemes.

You can do that with the command

Router(config-router)#no auto

I'll show you the commands to create summary routes when I talk about EIGRP and OSPF routing protocols, but for now, just stick to the basics.  Try practicing some summary routes on your own; with VLSM and summarization, practice really does make perfect (or at least gets you closer).

Thanks for reading!

Switch Security

I can see the light at the end of the tunnel.  This will be my last post on switches for the ICND2 test, and it's going to be a short one.  Let's start with the most complex topic of this post first and get it out of the way.

EtherChannel - A way to bundle multiple links into one logical link.  Imagine you have 4 links connect SwitchA to SwitchB.  Well STP is going to disable 3 of them, which leads to a lot of lost bandwidth.  Imagine grabbing all those links and squeezing really hard, until it becomes one big fast link.  That's the whole point for EtherChannel. It's important to recognize there are two versions of EtherChannel, the Cisco version and the IEEE version, but since I'm studying for a Cisco Cert, that's the way I'll be configuring.

PAgP is overkill for the CCNA, but I'll explain it anyway.
Port Aggregation Protocol (PAgP) - Adds more features to EtherChannel.  Used to learn capabilities of connected EtherChannel ports, and connect Fast EtherChannel automatically.  Has four options:
On
Off
Desirable - Actively tries to become a channel.
Auto - Does not try actively, but will become a channel if the other side wants to.

So the following combinations will work, on-on, on-auto, on-desirable, desirable-desirable, desirable-auto.
PAgP must have static VLANs assigned to the ports (not dynamic), have same speed/duplex settings on the ports, and must be in the same VLAN or be trunk ports.  Once the EtherChannel bundle is working, any changes made on a port will effect all ports in that bundle, which is pretty neat.

SwitchA#conf t
SwitchA(config)#int port-channel 1
SwitchA(config-if)#int range fa0/1-4
SwitchA(config-if-range)#switchport trunk encapsulation ISL
SwitchA(config-if-range)#switchport mode trunk
SwitchA(config-if-range)#switchport nonegotiate (this stops the switch from trying to autodetect link types and auto-setup trunking)
SwitchA(config-if-range)#channel-group 1 mode desirable

SwitchB#conf t

SwitchB(config)#int port-channel 1

SwitchB(config-if)#int range fa0/1-4

SwitchB(config-if-range)#switchport trunk encapsulation ISL

SwitchB(config-if-range)#switchport mode trunk

SwitchB(config-if-range)#switchport nonegotiate

SwitchB(config-if-range)#channel-group 1 mode desirable

Another important topic for the CCNA is switch security.  So much focus is placed on protecting a network from the outside via firewalls that it's easy to overlook the damage malicious users can do from the inside of your network if they manage to sneak into your building.  Luckily, the boom of wireless technologies have forced companies to re-examine their internal network security.

Switch security was touched on in the ICND1, so I'll skip past the basics of setting an enable secret password, securing VTY ports and setting up SSH (not that they aren't important!)  I mainly want to focus on the importance of assigning ports and port security.  It's easy to see why it isn't a good idea to have switchports available for anyone to plug into.  One of a hacker's most effective methods of breaking into a network is to piggyback into a building.  That is to say, they stand outside a backdoor smoking a cigarette until someone else comes out to smoke, and then just walk right in the building, pretending they work there.  From there they can just walk up to the wall, plug in their laptop, and wham, server access.  The way to protect against this is port-security.  Port-security statically limits the number of MAC addresses that can be assigned to a port, and can assign those MAC addresses, instead of learning them dynamically.  You can also set the penalty when a user violates the set policy.  You can shutdown the port completely until you re-enable it, or you can just stop it from working until the correct MAC address is heard again.

S1(config)#int range fa0/1-8

S1(config-if-range)#switchport port-security maximum 1

This sets a maximum number of MACs that can be assigned to that port (useful if you only want 1 computer using it, forbids a user from plugging in a hub and using a whole bunch of devices)

S1(config-if-range)#switchport port-security mac-address sticky

The sticky option will learn the MAC of what is connected to that port, and only allow that MAC (or multiple MACs if permitted).  This prevents a malicious user from unplugging a computer and plugging theirs in.

You can also assign the MAC address manually, but this could take forever.  If you use the Sticky command, just be sure the right devices are currently plugged in.

S1(config-if-range)#switchport port-security violation <restrict | shutdown | protect>

Chooses what will happen if the policy is broken.

Shutdown - Turns the port off, will not work until administrator re-enables it.

Restrict - Alerts administrator via SNMP that the policy has been broken

Protect - Just drops incoming frames from the non-match MAC address.

Finally, the last objective is to setup a switch so that it may be managed remotely.  To do this just set an ip address for the management VLAN, and set the switch's default gateway.

Switch(config)#ip default-gateway 192.168.1.1

Switch(config)#int vlan 1 (assuming you haven't changed the management VLAN number)

Switch(config-if)#ip add 192.168.1.2 255.255.255.0

Switch(config-if)#no shut

That's it folks.  Hopefully that's everything you (and I) need to know about switches for the ICND2 exam.  If you haven't already, please be sure to look over my previous Switching-topic posts, and if you have, thanks for reading!

STP Enhancements

I wasn't being completely honest when I was talking about STP in my last post.  There are several versions of STP, and the one I introduced in the previous post is known as Common Spanning Tree (CST).  Now, this was the original spanning tree, but is rarely used in a modern network due to its limitations.  In fact, by default, it isn't run on Cisco switches.  Cisco switches run what is known as Per VLAN Spanning Tree (PVST).  It is just what its name suggests, PVST runs an instance of STP on each VLAN.  PVST is Cisco-proprietary, as is PVST+.  PVST+ runs PVST, but is backwards compatible with CST.  So if there is a single switch that is running CST, all PVST+ switches will revert back to CST, so only use it if you are sure you need to be able to switch to running CST quickly, while preserving your PVST information.

So why is running an instance of STP in each VLAN a good thing?  Well' it isn't always.  If you have a very large amount of VLANs and only a few switches, your root bridges will be overloaded with overhead.  There's a fix for that too, and it's known as MST, Multiple Spanning Tree.  MST breaks STP into zones, so it can handle a collection of VLANs in one instance.

Let's go over the individual enhancements to STP to overcome the limitations I discussed in my last post.

PortFast - Turns off STP on an interface.  Why oh why would you ever want to use this?!  Well, say you build a new computer with one of those fancy SSDs that makes your server boot up in 10 seconds flat.  Well, you'll have to wait another 40 seconds to use the network, since STP will take 50 seconds to converge.  Portfast bypasses this by saying "I'm not a switch, I'll never cause a switching loop so I don't need to participate in STP". Now, this command can be VERY DANGEROUS.  If you turn PortFast on and someone plugs in a switch to that port, or connects two ports via crossover cable, you have potential for a switching loop.  Only use PortFast on access ports, and only if you are sure no one will cause a loop on it.
Switch(config-if)#spanning-tree portfast

BPDUGuard/BPDUFilter - Many switches support this addition to PortFast.  Basically, this prevents the scenario I just described by monitoring for BPDUs on a PortFast enabled port.  If it hears a BPDU (this will mean a switching loop), it shuts down that port into errdisable state.  BPDUFilter accomplishes the same goal, but by disabling PortFast when it hears a BPDU, forcing that port to participate in STP.  Be sure to use one or the other when you turn on PortFast.
Switch(config-if)#spanning-tree bpduguard enable
Switch(config-if)#spanning-tree bpdufilter enable


UplinkFast - Cisco-specific feature that improves STP convergence time when a link failure occurs.  Used when the switch has at least one backup root port currently in blocking state.  Basically, if a primary link fails, the backup link comes online quickly, instead of waiting 50s for STP to re-converge.  Typically used on Access layer switches, and only those that know alternative paths.
Switch(config)#spanning-tree uplinkfast

BackboneFast - Used for speeding up convergence when a link not directly connected to the switch fails.  This one is a little tricky, if the switch hears what's called an "inferior BPDU"

In the picture above, A is the root bridge, and the link between A and C goes down.  C has lost its path to root, and has no alternate path to it, since it was using that link to get to bridge B.  So it think that it's the new root.  It'll send out BPDUs on the link to bridge B.  Bridge B will see these BPDUs, and say, "Well, wait a second, my link to the root bridge(A) is fine, these BPDUs are inferior".  So it'll ignore BPDUs on the blocked port.  After 20 seconds, max_age for the blocked port will time out, and B will send out a BPDU to bridge C, which will be better than the BPDUs C is sending out.  Bridge C will stop sending BPDUs, and the blocked port will go through listening, learning, and finally forwarding states.  The whole process takes about 50 seconds.

BackboneFast overcomes this by timing out the max_age as soon as an inferior BPDU is heard.  This saves 20 seconds.  Like I said, it's a little very confusing, just know that Cisco recommends enabling BackboneFast on all Catalyst switches so they can dtetect indirect link failures.
Switch(config)#spanning-tree backbonefast

Last, we have my favorite part of STP, 802.1w - or Rapid Spanning Tree Protocol (RSTP).  RSTP can run on all brands of switches, and includes all of the features I just discussed.  Remember, the enhancements I just wrote about were created by Cisco to fix the problems of CST, and as such, they were Cisco-proprietary.  RSTP essentially combines the Listening, Blocking, and Disabled modes into the new mode Discarding.  This is because all of these modes are simply not forwarding packets, and are not learning MAC addresses.  In RSTP bridges also send out BPDUs every hello time, not just when they hear a BPDU from their root port.  These two changes cause convergence time to drop to mere seconds, rather that 50 seconds of other versions.  That's why if you can run RSTP, you should, just make sure all switches are running it, since it'll provide no benefit if it has to conform to 802.1D (RSTP will work with regular STP, but will none of the enhancements).

Turning RSTP on is very simple.
Switch#conf t
Switch(config)#spanning-tree mode rapid-pvst

I'm going to wrap up with verification commands that should be memorized.

The show spanning-tree command show important information to see who is the root bridge, what priorities are set to the VLANs, what role ports are in, their costs, and priorities.  If you are running PVST (as all Cisco switches are by default), you can specify which VLAN to see information for.  If you don't, it'll show all of them.
S1#show spanning-tree
S1#show spanning-tree vlan 10

The show mac address table command shows what VLAN ports are in, what MAC address(es) is/are assigned to that port, and whether those MACs are statically or dynamically assigned.
S1#show mac address-table

This command helps verify the IP address of the switch
S1#sh int vlan 1

Thanks for reading!

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!

The best way to learn

They say the best way to remember information is to teach it. I remember throughout high school teachers showing me an info-graphic that says a person remembers something like 10% of what they read, 20% of what they hear, 50% of what they do, and 90% of what they teach. Now I imagine this is a total crock, but experience has taught me that I do remember things better when I teach them to others. So there's my motivation behind this blog. I'm currently studying for my Cisco ICND2 exam that I'll be taking in just over 2 weeks, which, upon passing will give me my complete CCNA certification. In each post I'll explore an objective or two of the INCD2 test, putting the concept in its most easy to understand form. Hopefully someone will learn something, but at the very least it should help solidify the concepts in my own mind. I'll try to include some tips and tricks in each post, along with visualizations and practice labs. I myself have several study materials, including 2 texts, and software to help me simulate labs. Feel free to contact me by email if you have any questions, or if you noticed something I posted that was incorrect.

Hopefully, we can both learn something.