Lesson 23 - Introduction to Rapid STP (802.1w)

Lesson 23 - Introduction to Rapid STP (802.1w)

Good news is that if you have learned 802.1d protocol (STP standard), only few things change in terms of the terminology and operation in the Rapid Spanning-Tree Protocol. RSTP is clearly an evolution of the regular STP but definitely NOT the revolution. The three phases of operation mentioned in lesson 20 still apply. 

This post is going to be the last in the series on Spanning-Tree Protocol fundamentals.

Let's focus on the major changes introduced in RSTP by comparing it to the standard STP.

• STP Port States: "disabled", "blocking", "listening" are renamed to DISCARDING inRSTP. As far as the "forwarding" state, the name remains unchanged.
• STP Port Roles: designated and root roles are still the same. But the non-designated role has been split in two new ones: ALTERNATE and BACKUP roles in RSTP.

Below picture will give you an indication as to what they describe.

Pic. 1 - Rapid STP Alternate Port.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

An alternate port is a port that is in a blocking state and receives superior (better) BPDU frames from another switch. The port F0/2 of SW2 is the example of alternate port.

Pic. 2 - Rapid STP Backup Port.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

A backup port is a port in the blocking state that receives superior BPDU frames from the same switch like shown in Pic. 2. The port F0/3 of SW3 is the example of backup port.

Cisco STP Enhancement such as: spanning-tree uplinkfast and spanning-tree backbonefast are no longer used (except for spanning-tree portfast which Cisco still maintain in the IOS as an edge port). They have been replaced with negotiations of the port state that is based on the previously unused flags in the BPDU frame and a different mechanism of sending BPDU frames. The flags are shown below (pic. 3).

Pic. 3 - BPDU Flags.

Understanding the nuts and bolts of the RSTP operation is beyond the scope of this tutorial. All you need to know at this stage is the terminology and benefits of using it over a legacy STP. The major advantage of RSTP is that switches use BPDU frames differently than before. Ports, upon first connection or when topology changes, exchange BPDUs with proposal/agreement flags set helping achieve fast transition to the appropriate state. They negotiate whether the port should be the designated, non-designated or root port role. If the port becomes the root port, all other ports begin negotiation by exchanging proposal/agreement BPDUs since the path towards the root bridge is different. It is extremely fast mechanism that speeds up the convergence upon a topology change.

A few other changes implemented in RSTP you must be aware of are as follows.

• All switches exchange BPDUs instead of relaying them after they have received them from the root bridge. BPDUs have become a true keepalive mechanism. The switches do not have to wait for the root bridge to notify them about topology change that occurred somewhere in the network. A switch that detects change notifies its neighbors about it. And those in turn, notify their neighbors immediately. It is a mechanism similar to OSPF updates in that respect.
• RSTP is backward compatible with STP (802.1d) speaking switches. Upon receiving BPDU version 1 (802.1d), the port transitions to the legacy STP protocol. All timers (max_age, forward_delay) are used according to the STP specifications (802.1d).

There are also two new concepts introduced in RSTP that are worth mentioning:

1. Edge Port - which is something you are already familiar with. It is the port that is the candidate for a quick transition to forwarding state as it connects device that cannot create the loop (no BPDUs received on that port). Cisco enables Edge Port capability by using spanning-tree portfast feature described in the previous lesson. The ports must be a point-to-point link type (full duplex).
2. Link Type - the type of the link is derived from the duplex of the port:

• Full Duplex = Point-to-Point link
• Half Duplex = Shared link

All these changes serve one purpose: they help in fast convergence on a detection of the new connection or/and a topology change. The speed of convergence is similar to the one when Cisco STP Enhancements are used in STP. The difference is that now fast convergence is accomplished as an industry standard mechanism, not a proprietary solution.

The configuration of RSTP is pretty straightforward.

SW(config)#spanning-tree mode rapid-pvst

That is it!

Deterministic election of the root bridge and all the jazz related to it explained in the previous lesson are identical.

If you want to learn more on RSTP operation google it by using this query:
understanding rstp. You'll find a plethora of documents out there.

Lesson 21 - Spanning-Tree Protocol in Practice

Lesson 21 - Spanning-Tree Protocol in Practice

Previous post was designed to present in a nutshell the STP operation. However, without some practice it's just academic knowledge. I think it is a good idea to look at the same concepts using real equipment. Here goes...

The below topology (pic. 1) uses redundant links which create the loops.

Pic. 1 - Network Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

If there's one thing the administrator should do with such design, that would be configuring the root bridge. Typically, the most powerful switch in the center of the network plays that role. You do not want some access switch to be transmitting the frames between other switches. Access switches are designed to connect your computers to the network, and not to handle the majority of the traffic between the switches which root bridge must deal with.

If you do not configure root bridge yourself, the switch with the lowest MAC address becomes the root since the priority is identical on all of them by default. We do not want to leave it to a chance, do we? For simplicity reasons I have chosen to make SW1 my root bridge. There are at least two ways to configure this.

Method 1

I can manually decrement the priority on SW1 and leave the default value on the other switches. I want to make SW1 my root bridge for all the VLANs I use in my network (remember Cisco uses PVST+). The lowest priority value allowed is zero and if higher needs to be used, it must be an increment of 4096. If you type in the value that is not allowed, the system will present you with the list of values you can use.

Step 1
Check the VLANs configured.

Step 2
Make SW1 the root bridge for all the VLANs configured in the network by decrementing the default value. Here, I will use the value of '0'.

A quick verification if the command took effect is below:

 The above output confirms that SW1 has been elected as the root bridge:

 This bridge is the root

Familiarize yourself with the output of this command. All active ports of the switch are in designated role (forwarding state) as it is the root.

Also, notice that both Bridge ID and Root ID are the same values. I assigned priority of 0, but the system extended ID (PVST) adds VLAN number to the priority assigned. Thus, the priority 0 + (VLAN id) 500 = 500.

Priority: 500
MAC: 000b.5ff7.a080

Like mentioned before, if the priority value configured is not configured according to the allowed values, the system shows the numbers you can use:

Method 2

I can use the spanning-tree vlan root primary macro command which decrements the priority value using Cisco best practices.


Step 1
Check the VLANs configured like before.


Step 2
Make SW1 the root bridge for all the VLANs configured in the network by using the macro command.

And now comes the interesting bit. Having elected the root bridge SW1, I can predict all the rest of the process. Lesson 20 provides us with all the knowledge we need to posses to tell which ports will become root ports on SW2 and SW3 as well as which ports will be designated and which will be non-designated in our topology.

Can you do that on your own? 

The base MAC addresses on SW2 and SW3 are as follows (priority is default):

SW2 MAC: 000E:83DA:7580

SW3 MAC: 000D:28BF:FD40

If you want to check what is the base mac address on your switch type in:

SW#show version | include Base

At least give it a shot before you click at the pic. 2 below to check your answers. If you cannot do it yet, do not worry. I will guide you through the process using some powerful 'show' commands.

Pic. 2 - Spanning-Tree Topology Computed

Icons designed by: Andrzej Szoblik - http://www.newo.pl

There are two loops in my network. One between SW1 and SW2 using ports F0/13 and F0/14. The other loop is formed between SW3 connections to SW1 and SW2 (ports F0/15 and F0/16).

Let's look at SW2 first and see how the knowledge from lesson 20 applies here.

SW2 receives BPDU frames from SW1 on F0/13 and F0/14 ports and from SW3 on its F0/16 port. A closer look at the following output can be very informative.

The above output shows clearly which machine is the root bridge (000B:5FF7:A080). SW2 chose F0/13 as it Root Port. As you recall the first thing to check to determine which is the best path towards the root bridge (root port) is the accumulative cost towards the root. SW2 has three outgoing ports towards the root bridge as shown in the next output:

The accumulative cost is calculated by adding two values:

Port path cost + designated path cost.

• Port path cost - arbitrarily set values by IEEE (the speed-to-cost table is shown in the previous lesson).
• Designated path Cost - the cost towards the root bridge advertised by the neighboring switch.

Port F0/16 can be ruled out immediately since 'port path cost' (19) +  'designated path cost' (19) amounts to: 38.

As for the two remaining candidates to become a root port (F0/13 and F0/14), the total path cost is19 in both cases (19+0). We need to resort to the second test in our algorithm to break the tie: the lowest bridge id of the BPDU sender. Unfortunately, both ports receive BPDU frames from the same switch: SW1 (look at the previous output).

Designated Bridge has priority 500, address 000B:5FF7:A080

Next step to solve the issue is checking the port priority of the sender. But both ports F0/13 and F0/14 receive the same port priority (port id):

Designated port id is 128

The number of the port is not factored in, only the id value like shown above.

There is only one more thing that can help us determine which of these two ports should be the root port: the lowest port id of the receiver (SW2). F0/13 is lower in value than F0/14, so the former becomes the root port.

In the same way SW3 chooses its root port F0/15 as the root port since the accumulative cost using it is 19 as opposed to port F0/16 which total cost out towards the root bridge is 38.

Port F0/14 on SW2 becomes non-designated port (NDP) due to the fact, that the root bridge (SW1) has to have all the ports in designated mode which means they cannot be blocked.

The last thing to compute the STP active paths is to select the designated port between SW2(F0/16) and SW3 (F0/16). Again, the same formula solves the issue. As both SW2 and SW3advertise the same cost: 19, the tie breaker is going to be the lowest bridge id of the sender. In this contest, SW2 has higher bridge id (less preferred) which is: priority 33268, address 000E:83DA:758

SW3 priority being lower wins. SW3 bridge id for the same VLAN 500 looks like shown below:

priority 33268, address 000D:28BF:FD40

STP selects the layer 2 paths between the switches. In the pic. 2 I showed you also that all the ports connected to PC1, PC2 and R1 are in a designated role. This is because those ports do NOT receive BPDUs. They automatically become designated (forwarding state).

As the last thing in this lesson, I'd like to ask you two questions.

Assuming that SW1 is the root bridge:

Question1
What would you need to reconfigure in our topology (pic. 1), for SW2 to choose F0/14 as the root port for VLAN 500?

Question 2
What would you need to reconfigure in our topology (pic. 1) for SW3 to choose F0/16 as the root port for VLAN 500?

---

NOTICE!
The method of choosing root port/designated port in the previous lesson holds the answers to these questions. Remember about the order of operation.

---

The answer to question 1
Since the cost is the same towards SW1 (root), we could modify it on SW2 with the following command:

SW2(config)#interface f0/13

SW2(config-if)#spanning-tree vlan 500 cost 20

This way I have increased the cost on this port to 20, and F0/14 cost now is lower (19).

Another method could be to change the port priority on the SW1 preferring port F0/14. This is how you could do it:

SW1(config)#interface f0/14

SW1(config-if)#spanning-tree vlan 500 port-priority 64

Since, the path cost towards the root are identical on both ports, bridge id of the sender is the same switch SW1, the third thing to influence which one to use is the port priority assigned by the BPDU sender (here SW1). This is shown in the following picture taken from SW2 (show spanning-tree vlan 500 detail):

Now, the priority imposed by SW1 on SW2's F0/14 is lower: 64 compared to port F0/13 which is128. Port F0/14 becomes the root port.

Answer to question 2
In order to change the root port on SW3 the only way to do that is to increase the cost to reach the root bridge on F0/15. For instance you could configure the following:

SW3(config)#interface f0/15

SW3(config-if)#spanning-tree vlan 500 cost 39

Since the total cost towards SW1 (root) using port F0/15 is 39 now, and using port F0/16 the cost used equals 38, this configuration will do the job.

Did you have fun? I sure did ;)

Lesson 19 - Spanning-Tree Protocol Overview

Lesson 19 - Spanning-Tree Protocol Overview

Vlans described in the previous posts are very important elements of building modern networks. Equally important piece of technology is IEEE 802.1D, commonly known as Spanning-Tree Protocol. In the following few posts, I will focus on its application and basic operation.

If your network consists of layer 2 switches that allow computers connect and exchange data, you will need to consider the design that can withstand some types of failure.


Redundant Connections 

Consider the following layer 2 design. Imagine that the SW1, SW2 and SW3 switches connect many devices and there is only a single connection between the switches like depicted in the Pic1.

Pic. 1 - Switch Topology Without Redundancy

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Should either of the links between the switches break, the communication between many devices fail. Such design creates a single point of failure. We could easily tweak this simple design to make it more resilient by adding an extra path between SW2 and SW3. The below picture shows this modified design.

Pic. 2 - Redundant Paths

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Unfortunately, creating the extra path here comes at a cost. The redundant connection (Pic. 2) between SW2 and SW3 creates a loop. The loop in turn, will create three serious problems. The last one in the list will eventually render our system unavailable. Let's see what these problems are.

Duplicate Frame Delivery

Pic. 3 - Problem 1 - Duplicate Frame Delivery

Icons designed by: Andrzej Szoblik - http://www.newo.pl 

Look at the pic. 3 and imagine SW2 and SW3 do not have the MAC address of PC3(0000.3333.3333) in their databases (CAM). This can happen if the PC3 doesn't speak for more than five minutes. This is the default time MAC address is kept in the database without refreshing it. Then, we have PC1 sending frame towards PC3. As you recall, SW2 will flood the frame out of its active ports if it does not know where PC3 is located (unknown destination MAC address). The frame travels out SW2's port F0/13 towards SW1 and out the port F0/12 towards SW3. SW2 will deliver the frame to PC3. Since SW3 floods the frame out as well, it will be sent towards SW1 out of its port F0/14. Then, SW1 obediently delivers the same copy of the frame to PC3 again.


MAC Address Table Instability
Another issue caused by the loop we have created will make switches change the MAC addresses depending on where they hear the sender. Consider pic. 4 below.

Pic. 4 - Problem 2 - MAC address table instability

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Again, let us assume that none of the switches in the picture knows where PC3 is connected. This means they have not learned its MAC address yet. In our scenario, PC1 sends the frame to PC3(destination MAC: 0000.3333.3333). SW2 floods the frame out F0/12 and F0/13 ports.

Now, SW3 receives this frame sourced with 0000.1111.1111 MAC address (PC1). It learns the source MAC address and maps it to its F0/12 port where it arrived. Since SW1 does not know where PC3 is connected (at least right now) it will flood this frame out all active ports. This way, the frame is sent out SW1's port F0/14 towards SW3. SW3, upon receiving the frame on its F0/14 port, reads the source MAC address (0000.1111.1111) and maps it to port F0/14 this time. This causes a little confusion as SW3 learned it earlier on and it was port F0/12 before. Previous mapping is removed and F0/14 becomes the outbound port for 0000.1111.1111 now.

Broadcast Storm
The last problem is really severe. It can bring our traffic to a halt. Take a look at pic. 5 below.

Pic. 5 - Problem 3 - Broadcast Storm

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In this scenario, PC1 sends a broadcast frame. SW2 upon receiving it, floods it out all its active ports. SW1 receives it on port F0/13 and floods it out of other ports. SW3 receives the broadcast frame on its F0/12 port and floods it. Then, a tad later it receives this same broadcast frame from SW1 and again it floods it out all active ports except the port it arrived on. You can write the rest of the story on your own. This broadcast is running in the loop in both directions endlessly. Well, not exactly endlessly. It is true that there is not mechanism to stop it, but all three switches in the topology will be so busy sending out this broadcast, that eventually all its resources are consumed and they stop sending anything at all. If you look at switches that experience a broadcast storm, you will notice that all their LEDs are flashing amber like a Christmas tree. In a few seconds the switches become unresponsive. An attempt to access them remotely using SSH/telnet will fail. Even console connection may refuse to accept your commands. The only way to bring the switches back to the operation is to break the loop by pulling one of those cables.

So, what can we not have redundancy in our layer 2 topology? Of course, we can.

We will run Spanning-Tree Protocol (turned on by default), which will dynamically block redundant connections creating a loop free topology. Should the primary link fail, the one that is in the blocking state will start forwarding the traffic in about 30 seconds by default. Of course, we will need something much faster than 30 seconds, but I will show you that as soon as we know how STP works.

Here I am going to give you just an overview of its operation. But the devil is in the details which we will scrutinize in my next post.

Spanning-Tree Protocol Overview
STP is a layer 2 loop prevention mechanism. Switches running this protocol use special frames called Bridge Protocol Data Unit (BPDU). These frames contain enough information to allow the switches to create a loop free topology. This magic is accomplished using three distinct phases:

1. Elect a single switch to be the root bridge machine which is the central device in the layer 2 network. This machine will have all its ports in the forwarding state (designated port role).
2. All other switches (non-root switches), will select a single path towards the root bridge. That port is called the 'root port' and will be forwarding traffic that is destined out of the switch through the root bridge. This path is the least cost (best) path towards the root.
3. All other switches will select a single path per segment in order to block stop the loop. The port that is forwarding traffic is called designated port. The port that is blocking traffic to stop the loop is called non-designated port.

I will explain all the terms and the above process in details in my next post. Meanwhile, check the pic. 6 first.

Pic. 6 - Spanning-Tree Protocol

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In the above picture, SW1 has been elected as the root bridge. SW2 uses port F0/13 as its root port (the best, or the least cost path towards the root). SW3 uses it port F0/14 as the root port. SW3blocks the port F0/12 to stop the loop. SW2 keeps sending BPDU frames originated by the root bridge (SW1) out its F0/12 port towards SW3.

Now, what is really fascinating that the loop free structure like the above is done automatically (although you want and will affect how it works), and the fact that if the communication betweenSW2 and SW1, or SW3 and SW1 is broken, the SW3 port F0/12 will be put in the forwarding state.

If you are interested in the details how STP works please read my next post (lesson 20).

Lesson 17 - Inter VLAN Traffic Flow Analysis

Lesson 17 - Inter VLAN Traffic Flow Analysis

In Lesson 16, you had a chance to see how to implement simple VLAN scenario. It is relatively easy to configure VLANs, but what is far more important, is to understand the traffic flow between them. This post is going to show you step-by-step, how traffic flows between VLAN 10 and VLAN 20 used in the previous lesson.

Fancy a little, virtual journey between VLANs?

Our topology looks like this:

Pic. 1 - Topology Diagram

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In our scenario, PC1 (source) is going to send the packet to PC2 (destination). Let's jump on the packet and see what happens, shall we?

---

NOTICE!
MAC addresses use hexadecimal notation and are case insensitive (i.e. lower or upper case are interpreted as the same address).

---

PC1 (hostname=ancient) Addresses:
IP: 192.168.10.1/24
MAC: 0050.BF9C.456A
Gateway: 192.168.10.254

PC2 (hostname=red) Addresses:

IP: 192.168.20.1/24
MAC: 0010.5AD3.E4E0
Gateway: 192.168.20.254

---

NOTICE!
R1's interface FastEthernet0/0 has been configured as two sub-interfaces, but the MAC address used by both of them is the same (real MAC address of Fas0/0)

---

R1 Addresses: 

Gateway for VLAN 10 clients (sub-interface)
F0/0.10
IP: 192.168.10.254/24

Gateway for VLAN 20 clients
F0/0.20

IP: 192.168.20.254/24


F0/0 (both sub-interfaces use the real MAC below)
MAC:  000F.F752.EFE0

Having learned all these addresses we can finally hit the road!

Step 1
PC1 (ancient) wants to send a packet to PC2 (red). Since the IP address of the PC2 (destination) is NOT in the same layer 3 network as PC1 (source), it must be delivered to the default gateway.PC1 checks the destination IP by comparing its own 24 bits of the IP address (it uses 24 bit subnet mask=255.255.255.0) with 24 bits of the destination IP address.
192.168.10.0 (first 24 bits of PC1 in decimal notation)
192.168.20.0 (first 24 bits of PC2 in decimal notation)

The first sixteen bits (two bytes) are identical, but the third byte is NOT!

The packet must be sent to PC1's default gateway (192.168.10.254).

Step 2
Packet is encapsulated in a layer 2 Ethernet header. Source MAC address is PC1(ancient=0050.BF9C.456A) and the destination MAC address must be the default gateway's MAC address. PC1 (ancient) tries to find the mapping of the default gateway IP to its MAC address like shown below. If one is not found, the ARP request is sent asking for it. In my case the PC1 has it.

Pic. 2 - PC1 (ancient) ARP cache has mapping of R1's IP to its MAC address.

IP packet is encapsulated in the Ethernet header:
Src IP=192.168.10.1
Dst IP=192.168.20.1
Src MAC=0050.BF9C.456A
Dst MAC=000F.F752.EFE0

Those address are NOT going to change, until delivered to R1 router (look at step 7).

The frame leaves PC1 (ancient) and is sent towards SW1, interface F0/1.

Step 3
SW1 receives the frame on port F0/1. It learns or refreshes its MAC address table entry (PC1's source MAC address on F0/1). Remember, that F0/1 is now an 'access' port assigned to VLAN 10!This means, that all traffic coming to that port is considered as sourced by VLAN 10.

Pic. 3 - SW1 CAM entry for PC1.

SW1 must now find the outbound port for our destination MAC address (R1=000F.F752.EFE0).

Step 4
SW1 looks into its Content Addressable Memory (CAM) aka MAC address table, and finds the outbound port showing where the destination MAC has been previously learned.

Pic. 4 - SW1 outbound interface.

SW1 performs an additional check. It must make sure that the inbound interface (F0/1) and the outbound one (F0/15) belong to the SAME VLAN. As the F0/15 (outbound) interface is in a trunking mode, and allows ALL VLANs by default, the frame can be sent out that port. The frame is moved to the outbound interface (F0/15) and the TAG is going to be injected with the source VLAN identifier (VLAN 10).

Step 5
The SW3 (port F0/15) is receiving the frame with the TAG containing source VLAN 10. It refreshes the entry regarding the sender's MAC address (0050.BF9C.456A) on port F0/15. As this interface is also configured as a trunk, it accepts the frame with the 802.1q TAG inserted into the frame. It processes the frame trying to find the outbound interface by looking at the destination MAC address (000F.F752.EFE0). The entry is found in the CAM as shown below (pic. 5).

Pic. 5 - Default Gateway MAC address Entry on SW3.

The SW3 realizes that the outbound port is also a trunk interface. The frame is moved to F0/1 interface and the TAG (with source VLAN 10) is going to be preserved while sending this frame towards R1's F0/0 interface.

Step 6
Here's a tricky part. Normally, the R1 would expect to see just a regular Ethernet header (no TAG in it), but R1 has been configured to accept frames with the TAG containing VLAN 10 in it! Look at the picture below.

Pic. 6 - R1 accepts Ethernet header with the TAG containing VLAN 10 identifier.

Can you see this line: encapsulation dot1Q 10?

The TAG with VLAN 10 is allowed on this sub-interface. Now, since the layer 2 header is useless (remember that a router is a layer 3 device), it is stripped off and ditched. What is now being processed is the IP header. The R1, reads the destination IP address (192.168.20.1), and tries to find the outbound interface in the routing table by comparing source and destination IP addresses.

Step 7
Destination IP address (192.168.20.1) is compared with the entries in the routing table. The longest number that matches our destination points to F0/0.20 sub-interface (pic. 7). According to the routing table, the destination IP address (192.168.20.1) is directly connected to R1 (sub-interface F0/0.20).

Pic. 7 - R1 routing table.

The packet is moved from F0/0.10 sub-interface (inbound), to the F0/0.20 sub-interface (outbound).

Step 8
Since the interface is also configured with encapsulation dot1Q, the packet is going to be encapsulated with new source and destination MAC addresses and the TAG with the new source VLAN identifier (VLAN 20). Take a look at the picture below (pic. 8).

Pic. 8 - R1's outbound sub-interface configuration.

Step 9 
R1 encapsulates IP packet the Ethernet header as follows:
Src IP=192.168.10.1
Dst IP=192.168.20.1
Src MAC=000F.F752.EFE0
Dst MAC=0010.5AD3.E4E0 (PC2)
VLAN ID=20

Since the destination for the packet is directly connected to R1, the destination MAC address (that of PC2) is found in the ARP cache on R1. If one is not found, R1 sends ARP request asking for it as the destination is directly connected network.

Pic. 9 - ARP Cache on R1 shows MAC address for 192.168.20.1 (the last entry).

Step 10
The frame leaves sub-interface F0/0.20 with the TAG containing source VLAN 20 identifier as perR1's configuration (pic. 8).

Step 11
SW3 receives the frame on its F0/1 interface, but this time the MAC addresses look like below:
Src MAC: 000F.F752.EFE0 (R1's f0/0)
Dst MAC: 0010.5AD3.E4E0 (PC2)

SW3 refreshes the source MAC on its F0/1 interface. It is configured as trunk port, the TAG containing source VLAN 20 is allowed to be there.

Step 12
SW3 processes the frame and reads the destination MAC address (0010.5AD3.E4E0) trying to find the outbound interface for that destination.The entry is found pointing to F0/15 as the outbound interface (pic. 10)

Pic. 10 - SW3 entry for PC2 MAC address.

Step 13
The frame is delivered back to F0/15 of SW1. SW1 refreshes the source MAC address (000F.F752.EFE0) on its interface F0/15 and does the looks up in its CAM table trying to find the outbound interface for our destination MAC address (PC2). One is found as shown below.

Pic. 11 - SW1 finds the outbound interface for destination MAC (PC2)

Since both ports: inbound and outbound are trunks, the frame is sent out that port carrying VLAN 20. You can now guess what happens when the frame is delivered to SW2 port F0/13. Source MAC address is going to be refreshed on that port in the MAC address table (source here is the R1's MAC address). The inbound interface F0/13 on SW2 is configured as trunk port so it allows the TAG to be part of the Ethernet header. The SW2's outbound interface is going to be F0/1. Since this port is configured as an 'access' interface and is member of VLAN 20, both source and destination VLANs are the same. The frame is moved to the port F0/1, then the TAG is removed, as the outbound port is in 'access mode' and the frame is finally sent to PC2.

You may now be wondering why the path between the two VLANs looks like this. Why does SW3not send the frame directly to SW2 but it sends it back through SW1?

In order to answer that question, I must explain the details of Spanning-Tree Protocol. But this is the topic I will focus on in the upcoming lessons (starting with lesson 19).

Before we leave VLANs for good, I would like to dedicate one more lesson to it. In this lesson (lesson 18) I will try to help you check if you truly understand the implications of using VLANs, access and trunking interfaces. I'll also show you Cisco proprietary protocol called Vlan Trunking Protocol (VTP). This protocol is used to disseminate the VLANs among switches automatically.

Lesson 18 - VTP and VLAN Quiz

Lesson 18 - VTP and VLAN Quiz

The last lesson presented the gory details behind inter-VLAN routing. Now, I would like you to play a little game with me. A simple quiz will check your understanding of both access and trunk ports. Have fun!

Study the first topology carefully (Pic. 1) and answer the question 1.

Question1: When PC1 is sending broadcast frames (destination MAC address: FFFF.FFFF.FFFF), which computers are going to receive them?

---

NOTICE!
All switch-to-switch connections in Pic.1 are ACCESS ports. 

---

Pic. 1 - Switches are connected using ACCESS mode (NOT a trunk mode).

Icons designed by: Andrzej Szoblik - http://www.newo.pl

The answer to question 1 can be found at the bottom of this post. But try not to cheat. Check the answer after you have provided yours;).

Study the second topology carefully (Pic. 2) and answer the question 2.

Pic. 2 - Switches are connected using TRUNKING mode.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Question2: When PC1 is sending broadcast frames (destination MAC address: FFFF.FFFF.FFFF), which computers are going to receive them?

The answer to question 1 can be found at the bottom of this post. But try not to cheat. Check the answer after you have provided yours;).

Now, I can start our last lesson related to VLANs. It's about Cisco Vlan Trunking Protocol.

Vlan Trunking Protocol (VTP)
Cisco have created this protocol to facilitate automatic VLAN distribution between switches that use trunking connection. There is similar protocol called GVRP that is industry standard solution. At first glance, it looks like it works like VTP but it has some significant differences. For more details use google to learn it.

What Does VTP Do?
VTP is turned on by default but there are some things that need to be configured for this to work. The idea is very simple: instead of typing in all the VLANs end-to-end, (on all switches individually), you can configure VLANs on one switch only, and the same configuration will be propagated to all switches in the network (VTP domain to be more accurate). By 'the same configuration', I mean that VLAN database is synchronized (exchanged) between all the switches. In other words, VLAN numbers and their names are exchanged. The port-to-VLAN assignments are NOT exchanged. Consider this example:

SW1(config)#vlan 4

SW1(config-vlan)#name IT_Dept

SW1(config-vlan)#end

SW1#

The above configuration creates 'VLAN 4' and assings the name of 'IT_Dept' to it. In a split of a second, the same VLAN 4 named IT_Dept is populated into the database of all switches in the network (VTP domain).

How Does VTP Work?
As you recall from the lesson 16, VLAN configuration typically involves three steps:

1. Configuring VLAN numbers in the 'global config' mode. Optionally, you can also give those VLAN unique names.
2. Assigning interfaces to VLANs (access mode). Optionally, you can map MAC addresses to VLANs (access dynamic mode). But in order to use this method VMPS server is required.
3. Configuring trunking connections between the switches (if the same VLANs are applied on all switches - aka end-to-end VLANs).

Even though VTP is turned on by default, a few things must be configured for VLANs to be distributed among switches.

1. Switches must belong to the same VTP domain (the same domain name must be configured on the switches to synchronize their VLAN databases).
2. If, optionally, switches use domain password, this password must be identical on all switches in the VTP domain.
3. The connections between switches must be in the 'trunking mode' (it is Vlan TRUNKING Protocol after all).
4. VTP version must be the same on all switches (there are VTP 1,2 or 3 version).

VTP Modes
A Cisco switch can be configured in one of the three VTP modes:

• VTP Server (default mode) - this mode allow you to add, remove, delete, modify VLANs to a database. All is saved in NVRAM (Non-Volatile RAM memory - the one that does not lose its content on power-down). 
• VTP Client - in this mode you CANNOT create VLANs in the local database. The only way for the VTP client to learn VLANs is to send a request advertisement. Server respond to this, by sending information about VLANs and their names used in the domain (subset advertisement).
• VTP Transparent - is a similar to a server mode of operation. The major difference is that, the transparent mode does NOT participate in the VTP domain. This means that the transparent mode does NOT synchronize its database with any other switch (a local database of VLANs), and it does NOT learn VLANs propagated by a VTP server. Transparent mode WILL forward VTP messages between other switches over trunk ports.

VTP server sends a special VTP frame every 5 minutes out of all trunking ports. This message is the summary advertisement. In this message, among other pieces of information, it inlcudes: 

• VTP domain name
• MD5 digest (if password is used in VTP domain)
• Revision number

If there is a topology change (VLAN added, removed, name modified etc.), VTP server sends newsummary advertisement IMMEDIATELY with the revision number incremented. All other switches, upon receiving this message, will compare their own VTP domain name, protocol version, MD5 digest (if used), and the revision number. If the 'revision number' in the incoming message is HIGHER than the last seen, they send an advertisement request message towards the server. The VTP server responds with one or more subset advertisement describing all the VLANs found in its database. This new information is going to replace the old one on all other VTP client or server switches.

VTP Pruning
Vlan Trunking Protocol offers one more interesting feature called: PRUNING. It allows the switches to communicate over trunks which VLAN traffic should not be sent down from the upstream switch. Consider the Pic. 3 below:

Pic. 3 - VTP VLAN Pruning Example.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

If SW1 is sending broadcast from VLAN 10, the frames will be flooded out of all active ports in VLAN 10 as well as the trunking ports. Recall, that the ports in the trunking mode are multi VLAN ports allowing ALL of them by default (VLANs 1-4094). SW2 receives the broadcast from VLAN 10, on its interface F0/13, but then realizes, that currently there are NO members of VLAN 10 connected to any of its ports.

When VTP Pruning is enabled, SW2 will inform SW1 (pic. 3), that it does not want to receive traffic from VLAN 10. Should you connect at least one host to VLAN 10 to SW2 though, it will send another request, that VLAN 10 be on longer pruned on SW1 trunk port F0/13. It happens automatically without any further configuration.

Of course, if you do not want to use VTP, you do not have to. You can configure VLANs manually on all switches of yours. Also, you can prune the traffic on trunk ports manually. The command is shown below:

SW1#conf t

SW1(config)#interface f0/13

SW1(config-if)#switchport encapsulation dot1q

SW1(config-if)#switchport mode trunk

SW1(config-if)#switchport trunk allowed vlan 10,15,22

SW1(config-if)#

The above configuration will allow only VLANs 10,15 and 22 to cross the trunk f0/13 (command in blue).

VTP Configuration
In order to illustrate configuration steps, I am going to use the same topology as in a few previous posts.

Pic. 4 - Topology Diagram

Icons designed by: Andrzej Szoblik - http://www.newo.pl

The default configuration looks like the output below: 'show vtp status'.

Pic. 5 - Default VTP settings.

Well, in my output, the only setting that is not the default is the 'Number of existing VLANs'. I have one VLAN configured (VLAN 500), which is my management VLAN allowing me access the switch remotely.

As you can notice, the VTP mode is server, and the domain name is empty (no domain name configured). So, the switch allows you to configure VLANs but the database is not going to be propagate to other switches. Below are the steps of introducing VTP protocol for the first time.

---

NOTICE!

The command: vtp mode transparent in the 'global config' mode will clear the revision number back to '0'.

---

In my topology I am going to use the secure way of introducing VTP protocol FOR THE FIRST TIME!!!

Step 1
Clear the revision number on all the switches by typing the following in the 'global config' mode:

switch(config)#vtp mode transparent

switch(config)#

Step 2
Initially, I am going to use SW1 as the VTP server, SW2 and SW3 as the VTP clients.

SW1(config)#vtp mode server

SW1(config)#

SW2(config)#vtp mode client

SW2(config)#

SW3(config)#vtp mode client

SW3(config)#

Step 3
Configure VTP domain on SW1 (here domain name = CCNA).

SW1(config)#vtp domain CCNA

---

NOTICE!
SW1 is going to propagate the domain name (CCNA) to all other switches. They will learn it on their trunk ports. Trunk ports were configured in my previous lab.

---

Step 4
Apply the same password (MD5 algorithm is used), on all switches, so if somebody plugs in a new switch, that new switch without this password is not going to change the VLANs configured so far. Here the password used is: Secret123

SW1(config)#vtp password Secret123

SW1(config)#

SW2(config)#vtp password Secret123

SW2(config)#

SW3(config)#vtp password Secret123

SW3(config)#

Step 5 (Optional)
Enable VTP pruning to save bandwidth by not transmitting the broadcast traffic towards switches that have no members of VLANs defined in their databases. If you configure this on SW1 (server), this will enable pruning on all switches in our VTP domain.

SW1(config)#vtp pruning

If you want to make other switches servers, you can change their mode of operation now.

This way we have introduced VTP domain and now you can add, remove, delete, modify VLANs on one switch (VTP server), and all these changes will be propagated to all of switches (VTP servers or clients) in your domain CCNA.

I will have two videos recorded soon. The first one will provide you with explanation to the answers of my quiz presented above. The second one will show you how VTP can cause serious problems in your network if you do not take the right precautions.

And now, let me give you the answers to the quiz questions.

The answer for question 1 (pic. 1):
The broadcast frames sent by PC1 will be sent to PC2 and PC5.

The answer for question 2 (pic. 2):
The broadcast frames sent by PC1 will be sent to PC3 and PC6.

In my next post I will talk about Spanning-Tree Protocol.