STP: Spanning Tree Protocol Part 3

Hello once again, and I'm now going to continue with my discussion with STP -mainly on PVST and other PVST variants. Been quite busy with lots of big things (maybe I'll blog about these 'things' one day).

PVST or Per VLAN Spanning-tree is a propreitary protocol by Cisco, and soon came the time wherein lots of manufacturers needed to support this protocol. When such propreitary protocol becomes so prevalent, IEEE comes to the rescue by creating some standard protocols to be used by all. The following IEEE STP variants are: RSTP (rapid spanning-tree protocol) and the MSTP (multiple spanning-tree protocol). Though IEEE made such standard protocols, it didn't stop Cisco from creating more of their own STP variants: PVST+, and rapid PVST+. Now, lets get into details of each variant of STP.

PVST is Cisco's propreitary protocol that uses Cisco's propreitary ISL trunking protocol to determine which trunks to be in FORWARDING state for some VLANs and BLOCKING for others. With PVST, each VLAN has its own STP instance. So the STP instance for VLAN 10 will be different for VLAN 20. Since each VLAN would have their own instance of STP, every VLAN could also have their own ROOT BRIDGE. So the ROOT BRIDGE for one VLAN doesn't necessarily mean that it is the same for the rest, unless all switches in the network are in its factory default settings. What happens now with ports participating in STP is that a port could be in a FORWARDING state for a particular VLAN and in a BLOCKING STATE for another. So don't be surprised if all pilot lights of ports participating in STP are indicated as GREEN and not AMBER, because may be there are different ROOT BRIDGES for different VLANS and all STP ports are in FORWARDING state, not just for all VLANS. The PVST+ is just the same as PVST, only that it was developed to support the 802.1q trunking protocol. PVST+ are running by default on Cisco Catalyst 2960.

Ok, some PVST BID (Bridge ID) discussion. Remember that a standard 802.1d BID is composed of 2bytes Bridge Priority and 6bytes MAC address. Let's focus a bit on the Bridge Priority part. The Bridge Priority is composed of 4bits as the PRIORITY number, and the 12bits as the EXTENDED SYSTEM ID. With the standard STP is used, only the 4bits is used (PRIORITY NUMBER). The 12bits EXTENDED SYSTEM ID is where the the VLAN ID is indicated.

Now for configuring PVST+ on your Catalyst switches, first we want to make sure that we know which switches are going to be the ROOT BRIDGE for each VLAN. Most likely ROOT bridges are placed in the distribution layer so that convergence would be faster since the BPDU would reach almost all switches in the network since it is in between the CORE and ACCESS layers -faster access.

First we choose which routers becomes the PRIMARY and the SECONDARY ROOT BRIDGES. We set the spanning-tree mode to PVST by the command:
S1(config)#spanning-tree mode pvst
Then we configure the the PRIMARY and SECODARY priority of each switch per VLAN by this command:
S1(config)#spanning-tree vlan root
or
S1(config)#spanning-tree vlan priority <0-61440,>
Then just check your spanning-tree configuration by the commands in the privelage mode:
S1#show spanning-tree active
and
S1# show running-config

RSTP or Rapid Spanning-tree Protocol is known as the IEEE 802.1w and is the evolution of the IEEE 802.1d. Ok, you may ask, what is the difference between the two (802.1d & 802.1w)? With the 802.1d, we have 5 port states: the learning, listening, blocking, forwarding, and disabled. With the 802.1w, we have 3 port states: the discarding, learning and forwarding. So, with RSTP, it redefines the ports states and type. Now wonder why it is called rapid? It's because it has only 3 port states, there would only be 3 transition states rather than 5. Moreover, it allows port states to change from DISCARDING to FORWARDING immediately without relying on timers. With the DISCARDING state, we see this state in both the active and sync topology state and is the one responsible for breaking the loops by not allowing frames to be forwarded. With the LEARNING state, we see this state also both in the active and syn topology state, and this state accepts frames to populate the MAC table. Lastly, with the FORWARDING state, we only see this state in the active topology state, and this state determines the entire network topology since this ports are the ones that forward frames. Now that we have defined the port states for RSTP, let check out the port roles. With RSTP we also have 4 port roles: ROOT, DESIGNATED, BACKUP and ALTERNATE ports. The ROOT port roles appears on non-ROOT bridges, and this are the ports that are connected or is selected as the path to the ROOT bridge. There could only be one ROOT port per non-ROOT bridge. The DESIGNATED port roles on the other hand are ports that receive frames going to the ROOT bridge. They appear on all switches and there are atleast one DESIGNATED ports in a given segment. The ALTERNATE port roles are the ports that offer an alternate route to the ROOT bridge. They assume the DISCARDING state and immediately transitions to the FORWARDING state and become the DESIGNATED port if the first DESIGNATED port fails. The BACKUP port roles are ports on a designated bridge that has a redundant or another link to a segment where it is designated. This port role assume the DISCARDING state, and turns to FORWARDING state when the DESIGNATED port fails.

One of the enhancements that RSTP gave is that the BPDU messages sent carries information about the port status of their neighboring ports only. Remember how the BPDU looks like? (If not refer to STP part1) The RSTP BPDU has the PROTOCOL VERSION ID set to 2, and the BPDU type set to 2. Also, it uses the FLAG field, which is only a byte long to determine if there is a topology change and carries the information of the port roles and states. So pretty much an RSTP enabled switch could still communicate with switches that has 802.1D enabled since there aren't changes in the BPDU format. RSTP uses the BPDU as a keep-alive mechanism, if the port doesn't receive BPDU three consecutive times (which is 6 seconds since HELLO timers are 2 seconds), it means that the connection to the root bridge or neighboring bridge is lost. With the fast aging time, this is what makes RSTP detect failures in the network faster.

I've also got to mention another factor why RSTP converges faster than STP (802.1D). It's because RSTP doesn't rely on its timers when a port has been chosen to be a DESIGNATED port, rather it relies on link-by-link basis. If RSTP had to rely on timers, then when the STA has chosen a DESIGNATED port, it should wait for twice FORWARD DELAY timer before transitioning to the FORWARDING state. With RSTP, bridges goes through a process of proposing and agreeing on which port is to be set to ALTERNATE, DESIGNATED, & ROOT. The proposal and agreement is based on the path cost going to the ROOT bridge, the higher the better. When a bridge receives this proposal and sees that it has a better path cost going to the ROOT bridge, it blocks all non-edge ports then transitions the port that received the BPDU as a ROOT port. All EDGE ports and point-to-point links transitions immediately to the FORWARDING state.

Oh yeah, I've got to mention the RSTP EDGE ports. These are ports that are not connected to any switches, rather to end devices. Edge ports is similar with Cisco PortFast technology, wherein the switch port immediately transitions to the forwarding state when enabled -cutting the time for the end device to get connected. What's nice with Edge ports is that when they receive BPDUs, they automatically become a port that participates in the spanning-tree. Unlike with PortFast though, you have to make sure that the port with PortFast will not have a switch connected or else loops will occur. To enable Edge port on Cisco switches using RSTP, just use type:
S1(config)#spanning-tree portfast

rapid PVST+ is another Cisco propreitary protocol which is based on the 802.1w standard and is known to be faster than the 802.1d standard. rapid PVST+ is Cisco's version of IEEE's RSTP. I'll not be explaining this much in detail since it works pretty much the same with RSTP. So I'll go ahead and show you how to configure RSTP and rapid PVST+ on your Catalyst Switch.
To enable RSTP or rapid PVST+, enter:
S1(config)#spanning-tree mode rapid-pvst
S1(config)#spanning-tree mode rstp
To configure a port/s as point-to-point, enter:
S1(config-if)#spanning-tree link-type point-to-point
After all configuration, erase all STP detected protocols by:
S1#clear spanning-tree detected-protocols

To verify your configuration, type: S1#show spanning-tree vlan , then you'll see there what STP protocol your bridge is running on, and the link-type of each port you have configured. You could also verify your configuration by entering: S1#show running-config.

Ok, enough of these technical stuff, and now I'll just go ahead and give you some design pointers for you not to mess up your network. First, don't let STP decide which is the ROOT bridge, go and configure the primary and secondary ROOT bridge. Why? It'll be hard to debug STP in your network if you don't know. And another reminder to knowing where your ROOT bridge is supposed to be, it is better to place the ROOT bridge wherein all devices can reach the ROOT bridge with equal and minimal hops -meaning at the center of your network. This is to reduce the hop counts and traversing time.

Second, when designing your network and you have redundancy kept in mind (which is supposed to be), have a network diagram ready to know which ports are in the blocking and forwarding state. So when a problem occurs such as a loop, you will know where it originated. And oh, always use VTP pruning to avoid unecessary use of bandwidth!

Third, if it is possible to use L3 switches for you CORE layer switches, go and do so. Because you will not need a router to connect all your VLANs and the forwarding speed is as fast as a L2 switch.

Fourth, don't disable STP even though your network doesn't need it yet. STP doesn't take much processing power and doesn't eat bandwidth.

Alright ladies and gentlemen, this concludes my discussion regarding STP. There might be added topics that I'll be writing soon that are related to STP: like BackboneFast, UplinkFast, Portfast, BPDU guards and ROOT guards. So until next time, I'll be writing about new stuff too.

For any CCNA or Cisco knowledgable peeps who are reading this, please do check if what I wrote is correct (including typos or wrong grammar haha). And if you guys have any questions regarding STP, please do ask, I'll be glad to help and find the answers.

STP: Spanning Tree Protocol Part 2

OK, just to recap on what we have discussed on the previous blog: We've covered basically what STP does in our network and how it helps us in our design for redundancy. We've covered in detail regarding the BPDUs and the BID that are found in the BPDUs. We've also discussed how STP uses the STA (spanning-tree algorithm) to select the shortest/best path to the root bridge without creating a loop.

Now, what we're gonna talk now is about a little bit of port roles and BPDU timers. After which we'll go ahead and start discussing PVST (per VLAN spanning-tree). We'll end with some important CLI commands to configure and verify STP on our switches.

If you had read Part 1 my STP blog, you are pretty much knowledgable about STP. I agree some things could be left out, but then again, more knowledge means you can make decisions better. Let's start with port roles.

Ok, I've written before that there are four roles that a port could be playing, but I'll just put in key points about each roles.
1. root port - the switch port that is the best path to the root bridge
- there could only be one root port per bridge
- could populate the MAC address table
2. designated port - the switchport that forward frames to the root bridge
- there could only be one per segment
- all ports of the root bridge are designated ports
- exists on both root and non-root bridge
- could populate the MAC address table
3. non-designated port - the switchport that blocks frames
- could not populate the MAC address table
4. disabled port - the interface has the 'shutdown' configuration, it's administratively down
Now you ask, how does the switch know what roles to assign to a port? The STA does that. It tells the switch what port is the closest to the root port, and the port closest to the root bridge is the root ports. The rest of the ports that participates in STP are either designated ports or non-designated ports. The best path is chosen by the number of hops going to the root bridge multiplied by the port cost (refer to part 1). The lowest path cost will be chosen.

Now let's discuss port states. You might ask, what's the difference? Well port roles is how we redundant ports should behave. While port states are what the ports are doing. Example, the port is a root port(port role) so it should be forwarding(port state). Another example would be, the port is a non-designated port(port role) so it should be blocking(port state). Get it? Ok. There are five port states: forwarding, learning, blocking, listening, and disabled. Ports transitions to these different states in order to have a loop free network.
- forwarding - port is able to forward frames
- learning - port is ready to participate in frame forwarding, populating MAC table
- listening - port has just been determined that it could participate in frame forwarding. prepares to go to learning state
- blocking - port is cannot forward frames, but can receive BPDU frames to know where the root bridge and the other port roles
- disabled - port is not active, adminstratively down

Now we're done with port roles and port states, we'll head over to a short discussion of the BPDU timers, and why are they significant.

There are three timers we need to focus on: the hello time, forward delay, and the maximum age. The hello time is the time interval before the port sends another BPDU frame. The default is 2 seconds and can be tuned from 1 to 10 seconds. The forward delay timers are generally the time a port spends in the listening and learning state. The default is 15 seconds, but can be tuned to 4 to 30 seconds. The use of the forward delay timer is to allow all switches to decide the correct port roles to have a loop free network. The maximum age timer is to tell the switch how long it should keep the BPDU information. The default is 20 seconds and can be tuned from 6 to 40 seconds.

Just a note: STP only functions on networks with the diameter size of seven. Diameter is the number of switches a frame has to travel to reach another node. With that note, it brings me telling you that though we could tune all of these timers, it is advised not to, since it is already optimized by default with the network diameter size of 7 so that you wouldn't mess up the convergence(state where in STP has already calculated the best path and all ports are in their proper roles).

To view or verify the spanning-tree status type in show spanning-tree on the privelage mode of the switch CLI (command line interface). There you will see the following:
- the root bridge ID (you will know if the switch your accessing is the root bridge because it will indicate there: "this bridge is the root".
- priority value
- MAC address
- BPDU timers
- the bridge ID
- priority value
- extended systed id
- MAC address
- BPDU timers
- the interfaces that participates in STP, you will be able to see:
- the roles they are currently on
- the path cost going to the root bridge
- the status that the port currently have

To configure STP on a switch, we must be in the global-configuration mode of the switch
1. change BID of the switch
- spanning-tree vlan priority <1>
2. change switch priority
- spanning-tree vlan root , if it is set to seconday, the priority value will be set to 28672. if primary, always 4096 interval lower than the lowest priority value found.
3. change cost of a port (you must be in the interface-configuration mode of that port)
- spanning-tree cost
4. setting the STP diameter
- spanning-tree vlan root primary diameter <0>
5. changing the port priority (you must be in the interface-configuration mode of that port)
- spanning-tree port-priority <0-240,>

OK boy and girls, I think my brain can't take anymore writing at the moment. Forgot that I have to do my labs and my thesis paper still. Yes, I'm not done discussing PVST and some scenarios to help your network design. Guess there would be a part 3 for STP. It'll take some time for me to finish on STP part 3, since I've got to read about stuff related to my thesis. Anyway, it's another review day for me.

For any CCNA or Cisco knowledgable peeps who are reading this, please do check if what I wrote is correct (including typos or wrong grammar haha). And if you guys have any questions regarding STP, please do ask, I'll be glad to help and find the answers.

STP: Spanning Tree Protocol Part 1

Alright, another day to review! Gosh this is a long topic!! Today I'm gonna write about STP, and it stands for Spanning Tree Protocol. Without STP, boi, you'll gonna have lots of headaches, you'll know why later. STP is used by switches, and before I go any further, first let me give you an introduction of where STP comes into play on your switched network --redundancy. It's resolves the availability issue in a computer network (crucial networks) by having redundant equipment and connection in case the main line or equipment goes down. For short, redundancy is like having an alternate route. Having multiple paths to a destination allows you to reach the destination even if a route goes down. Implementing redundancy, organizations (e.g. webhosting companies or telephone companies) that depends on computer networks can be assured of business continuity.

Just a side note: redundancy is achieved by having a heirarchical network design (having the access, distribution, and core layers). I'll not write about network design since its a broad topic to talk about. Heck its got its own certification for it: CCDP (Cisco Certified Design Professional). Maybe I'll write something about simple network design and Layer 2 & 3 redundancy next time.

Here's were the problem comes. With redundancy, Layer 2 loops can occur, wherein packets will not stop traversing different switches and will eat up lots of the switch's CPU resources. How does this happen, and what is a Layer 2 loop? Ok, let me try to explain without the use of a diagram. Say we have three switches namely S1, S2, and S3, all connected together using trunk ports. Say PC1 is connected to S1, and PC2 is connected to S3. Here is the thing, remember that switches forward broadcast packets to ALL ports except the port where the broadcast packet came from? If you could visualize the diagram above, you'll get the whole idea. Each switch in the example has 2 trunk ports, and each would be receiving the broadcast message on one trunk port.
Step 1: receive a broadcast packet on a trunk port 1.
Step 2: the switch forwards the packet to all ports except where the packet came from(trunk port 1). Thus each switch will forward it to the other trunk port (trunk port 2).
Step 3: the receiving switch receives the broadcast on the trunk port 2.
Step 4: the switch forwards the packet to all ports except where the packet came from(trunk port 2). Thus each switch will forward it to the other trunk port (trunk port 1).
Step 5: go back to Step 1.
This is what we call the Layer 2 loop or the switching loop, and this occurs in a switched network having redundancy links without STP. If you're thinking that the packet will eventually get dropped when the TTL (time-to-live) expires, you're wrong. Ethernet frames or Layer 2 messages has no TTL field! Switching loops will soon turn out to broadcast storms if more broadcast are sent by different computers to the network. Switching loop can only stop if the physical link (trunk port) goes down. As more and more broadcast are sent, soon you'll find your network useless since all bandwidth is consumed.

Now knowing what disaster Layer 2 loops can do, you'll appreciate why there's STP. You might be wondering too if all switches (different brands/vendors) have STP running. Honestly, I'm not sure. What I can say is that all managed switches has STP. Managed meaning you can configure.

The purpose of STP is to avoid switching loops in your switched network. STP does that by blocking redundant ports dynamically and intentionally to maintain only one logical path to all nodes. STP dynamically unblocks the redundant port if the main path goes down.

STP utilizes the ST (spanning-tree) algorithm. Wherein the algorithm selects the shortest path to all nodes based on path cost without creating a loop. Applying STA, first we need to have our starting point, the root. Every network with switches will need and has to have one for our reference as the starting point. The selection of the root switch happens during the startup of switches (yes, all switches in your network participates in this election). They would send each other messages notifying who would be root. Now, after the election, let's say our switch has multiple paths to a destination, what STA does is it will only select one path, then the switch uses the information from STA to set port roles to the rest of the redundant ports, either blocking, forwarding. This entire process is how STP functions.

Hmm, I've mentioned about port roles, I'll give you a brief explaination about this, then I'll go into detail in part 2. Port roles are basically how a port should perform based on STP. There are four roles: root ports, designated ports, and non-designated ports. The root port is the port closest to the switch. The designated port is the port that allows the forwarding of packets. The non-designated port is the port that blocks all packets, and the disabled port is the port that is administratively down (it has the 'shutdown' configuration).

To clarify and be more detailed on the election process, the election starts when switches the starts up. All switches initially are root bridges. They'll be sending messages which is BPDU (bridge protocol data unit) every 2 seconds. Inside BPDU will contain the BID (bridge ID), and the BID consists of a priority value, switch's MAC address, and an extended system ID. Each switch will compare their BID with the BID of the other switches, and the lowest BID will be elected as the root. All subsequent BPDUs of the switches that has its root ID change will send the updated root ID so that all other switch will know the lower root ID. We could manipulate te priority value in the BID to manipulate the election process. The default value of the priority value is 32768, and it could range from 1 - 65536. The lower the priority value, the higher the chance that the switch would become the root bridge. The extended system ID is used to support VLANs (I'll write another blog explaining how STP works in per VLAN basis), so it could be ignored if there are no VLANs in the network. Let's say all switches have the default bridge priority value of 32768, switches will use the MAC address as the basis of determining the root bridge. The switch with the lower MAC address will be the root bridge.

Now about the path selection, how what parameters are used to determine which is the best/shortest path to the root bridge? STP sums up all the port costs in a given path to determine the path cost. The path will the lowest path cost is the best/shortest path. The port costs are the following:
10Gbps = 2
1Gbps = 4
100Mbps = 19
10Mbps = 100
These values are the default values set by the IEEE. If your wondering if the port cost could be modified, why yes. They can to give you the flexibility of choosing your path to the root bridge. To configure the port cost you must enter into the interface-configuration mode by selecting the port you want to configure, then enter 'spanning-tree cost '. If you want to reset if back to the default, just type 'no spanning-tree cost' in the interface-configuration mode of that port and your good to go.

Ok, let me give a scenario: Let's say we have to ports with the same path cost going to the root bridge, how does the switch decide what port to block? The answer is simple, the port with the lower port ID will be used. Example, fa0/1 and fa0/24 have both the same path cost to the root bridge. The switch will select fa0/1 since it has the lower port ID. But still, we can override this by changing the port priority for STP. The default value of this is 128. We can configure this by going to the interface-configuration mode of the chosen interface, then type 'spanning-tree port-priority <0-240,>'. To verify the change, type 'show spanning-tree' in the privelage mode and see that the port priority of that port will change from 128 to the priority number you have entered.

The general process of how STP works are the following:
Step 1: a root bridge is elected (BPDU is sent by each switch and each switch compares their root ID with the root ID of others)
Step 2: each switch uses the STA to determine the shortest path to the root bridge
Step 3: each switch takes into account the port speed/bandwidth for which port to block and unblock | path cost is calculated using port speeds/bandwidth also, so if there are two paths to one destination, the path with the lowest cost is selected.
Step 4: port roles are assigned based on the STA calculated path to use.
Step 5: voila, converged!

Reminder: all switch ports are in blocking mode when all switches are calculating the root bridge and determining paths.

Alright, seems to me that we've got the gist of how STP works in switches and in our network, but I'm not done with my review yet since Cisco is also covering the BPDU in detail. If you want to know the details of BPDUs go and read, but if you just want to know how to configure STP on your switches, just skip the BPDU part.

BPDUs has three fields, each fields contains four important information for STP.
The first field:
protocol ID - determines what protocol is used.
version - determines what version of the protocol is used.
message type - determines the type of message sent.
flags - indicates whether there's a topology change and indicates the receipt of a topology change.
The second field:
root id - when a root bridge is already elected, the bridge id of the root bridge will be indicated here. At start up, all switches are root, thus the root id will be their own bridge id.
cost of path - the total path cost of the sender of the BPDU going to the root bridge.
bridge id - the bridge id of the sender of the BPDU.
port id - indicates from what port the BPDU was sent, this allows loop created by multiple connected bridges to be detected and corrected.
The third field:
message age - indicates how much time elapsed from the time the root bridge sent the message of the current configuration.
max age - indicates how long the BPDU should last. If the message age reached the max age, there would be a new election of a root bridge since it assumes the connection is lost from the root. 20 secs by default and can be tuned from 6 - 40 secs.
hello timer - indicates the interval where the root bridge will send another BPDU. 2 secs by default, can be tuned from 1 - 10 secs.
forward delay - indicate the time for bridges to wait before transitioning to a new state.

Alright, I guess I'll stop here for the moment, my head hurts quite a bit already. I'll write part 2 of STP later this evening which includes detail discussion of port roles, BPDU timers, per VLAN STP (PVST), some design tips on STP, and what are the important stuff to configure for STP.

Etherchannel and Cisco Portfast

Another day for more review, another day for more blogs. I'm getting the hang of this haha. Anyway, today I'll be discussing about Etherchannel and Cisco Portfast technology and how the work and benefit in out network.

First, people believed that if they had two connections to a switch, they would have more bandwidth, thus improving their downstream & upstream speed. To tell you honestly my friends, I too was mislead. What happens if you do this is just like having two separate doors in your house. Both could let people in and out, but it could only allow as much at the same time due to the size of the door. Why so? Because of STP, since every port is treated as a separate connection, STP will always make sure that there would be a loop free network connection, thus blocking one of the two connections to a switch. If we had two connection doesn't make the two doors combine to let more people pass at the same time, unless you reconstructed your house.

So to make the two connections combine and make it possible to increase your upstream downstream bandwidth, we configure etherchannels on your switch. By having etherchannels, you tell ports (from 2 to 8 ports only) to group as one logical port and STP will see these ports as one -no more blocking of the other ports.

To enable etherchannel on switches, you must configure them on both switches first. To configure you must go to the interface-configuration mode of the switch (the switch ports that you want to group). Here it goes:
S1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
S1(config)#interface fast 0/11
S1(config-if)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1
S1(config-if)#interface fast 0/12
S1(config-if)#channel-group 1 mode on

S2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
S2(config)#int fast 0/11
S2(config-if)#channel-group 1 mode on
S2(config-if)#int fast 0/12
S2(config-if)#channel-group 1 mode on

After this configuration, both ports fa0/11 and fa0/12 of both switches will group logically as one. For us to verify, we use the commands 'show interface trunk' and 'show spanning-tree' in the privelage-user mode. You'll notice that the name of the port changed. Instead of having individual entries for each port, only one port name appears for the grouped ports which is 'Po1'. Po1 stands for 'port-channel1' which is created when etherchannel is configured. For the ouput of the 'show spanning-tree', instead of seeing two individual ports (fa0/11 & fa0/12) with one in blocking state, we only see one port entered which is Po1.

Just a note: since etherchannel is a logical group of ports, even if one port goes down, as long as there are ports in that etherchannel that are still up, the etherchannel logical port will be up.

Now we know how to use etherchannels in our network, now we discuss about Cisco Portfast technology.

Cisco PortFast Technology applies to networks that has STP running, and it applies to ports that we consider to be directly connected to end-nodes (computers/printers). Cisco PortFast allows ports to transition from blocking state to forwarding state immediately. With normal operations, switchports transitions from blocking to listening to learning then to forwarding or blocking again (the listening & learning states are 15 secs long by default). This is to ensure that we have a loop-free network. Come to think, switchports that are connected to other switches only need all four transitions to ensure a loop-free network. Having them on access ports seems useless and it takes much time for a PC to get connected. So applying Cisco PortFast on access ports enables servers, workstations or any end-user devices to get hooked up immediately.

To enable Cisco PortFast on your switch, you must go to the interface-configuration mode of the switch (the switch ports that you want to enable PortFast on). Here it goes:
S1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
S1(config)#interface fast 0/11
S2(config-if)#spanning-tree portfast

Just a note: only enable PortFast on access ports, if you enable them on ports that connects to other switches your in for some switching loop trouble! Use it with care.

Alright friends, another topic reviewed, and if you guys have any questions regarding this topic just ask, I'll be more than happy to find the answer. Till next time.

VTP: VLAN Trunking Protocol

Today, before taking the test, guess a good way to review is to apply what I've said in my previous blog. Today I'll be writing about VTP. VTP stands for VLAN(virtual local area network) Trunking Protocol. VTP is a Cisco proprietary protocol. They run mostly on all Cisco Catalyst Switches available. So the switches that I'll be pertaining to are all Cisco Catalyst switches.

The purpose of the VTP is to simplify management of VLAN information and trunk settings on a group of switches. You see, as the network gets bigger (the number of switches that are to be deployed increases), you would have to configure the VLAN information and trunk settings on every switches --thats going to be very tedious. But thanks to VTP, we don't have to configure VLAN information and trunk settings on every switches.

VTP provides VLAN configuration consistency on all switches of the same domain when you add, delete, or rename VLANs. So we get a lot of benefits when we use VTP in our switched network:
1. we don't have to worry about adding/deleting/renaming of VLANs on each switch in the domain to have consistency because all switches in the same domain dynamically learn changes on a switch's VLAN configuration.
- to make it clearer, if we add/delete/rename a VLAN on a switch, all other switches in the same domain will have that VLAN added/deleted/renamed. sweet right?
2. the trunk ports are dynamically configured to allow the new VLANs to be forwarded. why is this important?
- a switch's trunk port will drop a packet from a particular VLAN if the switch doesn't have that particular VLAN in its VLAN database.

Ok, so what does VTP need in order for it to work? Better yet, what are VTP's components? Let's go explore it one by one!

First component is the VTP modes which a switch will have to play. There are three modes available: the server, client, and transparent mode. By default, all Cisco Catalyst switches are running on VTP server mode. On server mode, you will be able to add/delete/rename VLANs for a domain on just one switch. The VTP server also listens to VTP advertisements by other switches on the same domain and then advertise it to other switches on the same domain as well. With switches running on VTP client mode on the other hand, it's pretty much the same as the VTP server but we can't add/delete/rename VLANs on that switch. I know you'll be asking why not just have all switches run on VTP server mode. Ok, first, VTP server switches needs more memory to keep track of all VLAN information. Secondly, not all switches in your organization would be a distribution class switch (a higher performance switch). With switches running on VTP transparent mode, the switch could add/delete/rename VLANs locally and it would not affect the VLAN configuration of the domain it belongs to. VTP transparent mode also forwards VLAN advertisements of other switches to other switches of the same domain, but it doens't advertise and synchronize its own VLAN configuration with the domain. So basically, this is what Cisco says that VTP transparent mode doesn't participate in VTP. So if you have VLAN configurations that have local significance and don't want to share it to the rest of the network, you can configure your switch in VTP transparent mode.

Oh just a side note: remember that VTP only propagates VLANs that are in the VLAN ID range from 1 to 1005. The extended VLAN IDs are not propagated. Moreover, VLAN IDs from 1 to 1005 are stored in the NVRAM under the vlan.dat file (this only applies to switches running on VTP server mode), while the extended VLAN IDs are stored in the running-configuration. For switches running on VTP client mode, the VLAN IDs are all stored in the VLAN database (RAM) and not in the NVRAM since VTP clients cannot input VLAN configurations but it dynamically learn VLAN configurations from other switches(then based from what it has learned, it propagates that information). Yeah, when you power off the switch running on VTP client mode, it would lose all the VLAN configuration, but not to worry, it can learn it again.

Sorry really if I give to much emphasis about switches being on the same VTP domain. This is because the domain name plays a big big role on VTP --and this is the second component of VTP. Because if a switch has a different domain name, and you expect that switch to learn VLAN configurations of another domain, not in a million years you'll get that to work. But if your plan is to have a VTP server that is on domain B, but the switch is connected to switches on domain A, you don't have to worry about VTP advertisements, they won't screw either domain's VLAN configurations =) More of the design part later. VTP domains determines the logical group of switches that would participate in VTP and determines the limit of the VTP propagation (separate your network into smaller management domains). Another note: yes we could have more than one VTP domain for your network. It really depends on how you design your network for an organization's needs.

The third component of VTP is the VTP advertisements. Without this, how do you think switches learn about VLAN configurations? VTP uses different forms (or should I say a heirarchy) of advertisements to synchronize and maintain the consistency of VLAN configurations over the domain. So let's dig deeper regarding VTP advertisements. VTP is a Layer 2 (OSI model) protocol, thus its messages are sent by frames. VTP frames consist of the VTP header and VTP content/message, and both are located at the data/payload field of an ethernet frame. Then the whole ethernet frame is not encapsulated as a 802.1q or ISL frame. The destination address of the encapsulated frame would be a multicast address, so that all VTP enable switches would receive the advertisement message.

There are three different types of VTP advertisement messages: summary, subset, and request. VTP header contains the following: VTP domain name, domain name length, VTP version, and the configuration revision number. Other information are added based on the type of advertisement message. The VTP message on the other hand first contains this fixed-length global domain information; VTP domain name, identity of the switch (IP address) sending the message and the time it was sent, MD5 digest for VTP checksum and MTU size of each VLAN, and the frame format (either ISL or 802.1q). Then for each VLAN, the VTP message contains the: VLAN ID (for 802.1q), VLAN name, VLAN type, VLAN state, and additional VLAN configurations based on the VLAN type. To clear things about the three different VTP advertisement messages, I'll go ahead and discuss them too. The summary message contains the domain name, revision number, and the rest of the VLAN configuration. The summary messages are being sent every five minutes interval and sent when there is a VLAN configuration change. The subset message contains VLAN informations and is sent when triggered by one of the following events: VLAN addition, deletion, activation, suspension, renaming, and changing of the VLAN's MTU size. Lastly, the request message is a message sent to the VTP server to request for the VLAN configuration information. The VTP server responds with a summary and subset message to this request message. The request message are sent when triggered by one of the following events: the switch reloaded/power-cycled, the switch's VTP domain has been changed, or the switch receives a higher revision number of a summary message.

Just some final notes on VTP advertisements, one of the key factors about VTP advertisement message are the configuration revision number. Every time there is a change in the VLAN configuration (e.g. addition/deletion of VLANs), the configuration revision number increments. This is to notify other switches and the switch checking the VTP advertisement message that the VTP advertisement message is a new or old one. The configuration revision number is a 32-bit number. Thus it could increment up to 2^32 (go get a calculator).

The fourth component of VTP is the VTP pruning. VTP pruning prevents unecessary broadcast on all trunk ports. I'll give an example so that you could understand it better. Let's say we have three switches and the ports that connects them are trunk ports (802.1q). Let's name the switches S1, S2 and S3 with S2 as the switch that connects S1 to S3. Say S1 have access ports ranging from VLAN 1 to VLAN 10, and S3 have access ports ranging from VLAN 11 to VLAN 20. Assuming that all three switches are on the same VTP domain, they should have all the VLAN configuration synchronized. Ok, here comes the VTP pruning part. Let's say that a host on S1 with VLAN 10 sends a broadcast. Without VTP pruning, the broadcast would be sent to all VLAN 10 ports, plus all trunk ports. But with VTP pruning, S2 will not forward the broadcast to the trunk port where S3 is connected since S3 has no access port configured with VLAN 10. That's how VTP pruning save bandwidth on your VLAN switched network! Oh yeah, to enable VTP pruning (only on one VTP server), you have to go to the global configuration mode CLI of the switch, then type in vtp pruning.

To view VTP information/status on the switch, type in show vtp status on the privelage mode of the switch CLI (command line interface). There you will see the following:
- vtp version (the version number, usually 1 or 2)
- vtp domain (the domain name)
- vtp password (the password for the domain, and yes it is shown in plain text form)
- number of existing VLANs on the switch
- current revision number (reflects the number of changes done)
- vtp pruning (if it is turned on or not)
- vtp version 2 (indicates whether is using version 2 of VTP)
- maximum number of VLANs supported by the switch
- vtp trap generation (indicates whether the switch is sending VTP traps to a network managment system)
- MD5 digest (this is a checksum for the VTP configuration)
- configuration last modified (the date/time the configuration was last change)

To see if VTP advertisement took place, use show vtp counters.

To configure VTP settings, you must be on the global configuration mode of the switch.
1. configure VTP domain name:
- vtp domain
2. configure VTP password
- vtp password
3. configure VTP mode
- vtp mode
4. configure VTP pruning
- vtp pruning
5. configure VTP version
- vtp version <1,>

How to configure VTP on your network:
1. always make sure that all switches are in their factory default settings, if your adding a new switch to a configure VTP domain, make sure that switch is in its default settings or atleast reset the configuration revision number OR ELSE!
2. configure trunk ports for switch-to-switch connections (don't expect VTP to work on access ports! I wasted an hour of debugging because of that).
3. atleast have two VTP servers for redundancy purposes, if one fails, you could still manage your VLANs.
4. configure the VTP domain on the server so it would advertise its domain name to other swithces with default settings.
5. configure password (if you want to, and I suggest you do for security purposes | I won't discuss why anymore, we're gonna branch out to Information Security here. If you wanna know, just leave a comment asking me why and I'll answer).
6. configure VTP clients for the rest of the switches, and configure the password for the VTP domain on them.
7. check the VTP status to make sure everything is working fine on each switch, use show vtp status in the privelage mode of the switch's CLI.
8. when your done, you can start adding/deleting/renaming VLANs.

Ok, time for some real life design tips and scenarios about VTP. These are some of the few things I've tried with VTP, and it might be useful information someday. First, let's say you have an existing switched network and you wanted to add a new switch on the network. You must make sure that the switch is in its factory default settings, why? Because if the switch has VLAN configurations that you unconsiously don't want and it has the same domain name as your switched network's domain name, the unwanted VLAN configurations would then be propagated. Just make sure that when adding new switches it is in its factory default settings or it has a different domain name so that it won't propagate wrong/unwanted VLAN configurations.

Here is another scenario given that all switches are on the same domain. If there are two switches running on VTP server mode and is separated by a VTP transparent mode switch. Then all switches would have VLAN 10 in their VLAN database, would the VTP transparent mode switch be able to forward a packet to other switches that has VLAN 10? Yes, assuming that all trunk ports allow VLAN 10 to pass. And yes, VTP advertisements would reach the VTP client even though the VTP server and VTP client is separated by a VTP transparent switch because VTP transparent switches still forwards VTP adverstisements.

For other VTP or VLAN configuration/troubleshooting/weird experience scenarios that I'll be encountering, I'll make it a point to publish it.

For any CCNA or Cisco knowledgable peeps who are reading this, please do check if what I wrote is correct (including typos or wrong grammar haha). And if you guys have any questions regarding VTP or VLANs, please do ask, I'll be glad to help and find the answers.

Compiz on Ubuntu 7.10 using ATI Mobility Radeon x1400

Got this from the Ubuntu forums, and atlast! I could now experience Compiz with my ATI Mobility Radeon x1400!! I waited for a year for this!! Now all I need is to find the Compiz dock and the wavy wavy minimize effect and my Linux would look better than a Mac hahaha!

You've got to have the fglrx package on your Ubuntu.
Code:

sudo apt-get install xorg-driver-fglrx

Before we begin -- supported hardware list

Taken from fglrx driver description for Gutsy.

This version of the ATI driver officially supports:

* FireGL: V7350, V7300, V7200, V7100, V5200, V5100, V5000, V3400,
V3300, V3200, V3100, X3-256, X3, X2-256, Z1-128, T2-128,
X1-128, X1-256p
* FireMV: 2200 (Single card PCI-e configuration)
* Mobility FireGL: V5000, T2
* Mobility Radeon: X1800, X1600, X1400, X1300, X800, X700, X600, X300,
9800, 9600, 9550, 9500
* Radeon Xpress: 200M series, 1250 IGP, 200 series
* Radeon: X1900, X1800, X1600, X1300, X850, X800, X700, X600, X550,
X300, 9800, 9700, 9600, 9550, 9500

ATI All-in-Wonder variants of the above cards/chips are also supported,
but video capture is not.

If you are doing fresh install of Gutsy

1. Enable fgrlx driver.

Install linux-restricted-modules and restricted-manager provied in the restricted repositories:
Code:

sudo apt-get update
sudo apt-get install linux-restricted-modules-generic restricted-manager

Open the restricted drivers manager in "System -> Administration -> Restricted Drivers Manager" and select "ATI accelerated graphics driver".
2. Install xserver-xgl package
Code:

sudo apt-get install xserver-xgl

3. Install compiz
Code:

sudo apt-get install compizconfig-settings-manager compiz compiz-core compiz-fusion-plugins-main compiz-fusion-plugins-extra compiz-gnome compiz-plugins libcompizconfig-backend-gconf libcompizconfig0

4. Reboot
5. Log in. 3D effects should be enabled!
6. Customize Compiz Fusion.
Select System → Preferences → Advanced Desktop Effects Settings
In the new window, General Options → Desktop Size → Horizontal Virtual Size. Set it to 4.
The other two options have to be left at 1.