For CCNA and CCNP candidates, it's hard not to laugh the first time you hear the phrase "router on a stick". Let's face it, that's a pretty silly term. But as those who have passed the CCNA and CCNP exams know, this is a vital exam topic that you must know how to configure and troubleshoot.
Basic Cisco theory states that for hosts in different VLANs to communicate, a Layer 3 device must be involved to handle the routing between the VLANs. That device is a router, and there are special considerations that must be taken into account for both the physical router itself and the configuration you'll be writing.
The router will be connected to a switch via a FastEthernet port (or higher). The router port cannot be a regular Ethernet port, since the router port will need the ability to send and receive data at the same time.
The configuration of the interface is where things get interesting. Let's say we have two VLANs that will be using router-on-a-stick to communicate.
Here is the VLAN information:
VLAN 20: 20.20.20.0 /24
VLAN 40: 40.40.40.0 /24
The port on the switch that will be connected to the router's FastEthernet port must be in trunking mode, and you must know the trunking protocol in use. We'll go with the Cisco-proprietary ISL here.
The physical FE port on the router will not have an IP address. The use of router-on-a-stick mandates the use of logical subinterfaces. While we don't have to use the VLAN numbers for the subinterface numbers, I've found this helps you keep the interfaces straight. One subinterface must be given an IP address in VLAN 20, and the other will have an IP address in VLAN 40.
After creating subinterfaces fast 0.20 and fast 0.40, the config looks like this:
interface fastethernet0
no ip address
interface FastEthernet 0.20
ip address 20.20.20.1 255.255.255.0
interface FastEthernet 0.40
ip address 40.40.40.1 255.255.255.0
Believe it or not, you're almost done! Now we need the encapsulation statement under each subinterface. The subinterface statement must reflect both the VLAN number and the encapsulation type being used. When we're finished, the config would look like this:
interface fastethernet0
no ip address
interface FastEthernet 0.20
ip address 20.20.20.1 255.255.255.0
encapsulation isl 20
interface FastEthernet 0.40
ip address 40.40.40.1 255.255.255.0
encapsulation isl 40
And that's it! Your hosts in VLAN 20 should now be able to communicate with hosts in VLAN 40, and vice versa.
A couple of final troubleshooting points - the most common error with router-on-a-stick is to put the wrong vlan number in the encapsulation statement. Also, make sure you have configured the router's IP address in VLAN 20 as the default gateway for hosts in VLAN 20, and do the same for VLAN 40.
I hope you've enjoyed this look at router-on-a-stick. While the name may get a chuckle out of you, it's still used in quite a few networks out there, and knowing how to configure and troubleshoot it will get you that much closer to earning your CCNA and CCNP.
Showing posts with label vlan. Show all posts
Showing posts with label vlan. Show all posts
Saturday, December 27, 2008
Thursday, December 25, 2008
Cisco CCNP / BCMSN Exam Tutorial: Static VLANs
BCMSN exam success and earning your CCNP certification requires you to add to your knowledge of VLAN configuration. When you studied for your CCNA exam, you learned how to place ports into a VLAN and what the purpose of VLANs was, but you may not be aware that there are two types of VLAN membership. To pass the BCMSN exam, you must know the details of both types.
In this tutorial, we'll take a look at the VLAN type you are most familiar with, the "static VLAN". As you know, VLANs are a great way to create smaller broadcast domains in your network. Host devices connected to a port belonging to one VLAN will receive broadcasts and multicasts only if they were originated by another host in that same VLAN. The drawback is that without the help of a Layer 3 switch or a router, inter-VLAN communication cannot occur.
The actual configuration of a static VLAN is simple enough. In this example, by placing switch ports 0/1 and 0/2 into VLAN 12, the only broadcasts and multicasts hosts connected to those ports will receive are the ones transmitted by ports in VLAN 12.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
% Access VLAN does not exist. Creating vlan 12
SW1(config-if)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if you have forgotten to do something, the Cisco device is generally going to remind you or in this case actually do it for you. I placed port 0/1 into a VLAN that did not yet exist, so the switch created it for me!
There are two commands needed to place a port into a VLAN. By default, these ports are running in dynamic desirable trunking mode, meaning that the port is actively attempting to form a trunk with a remote switch in order to send traffic between the two switches. The problem is that a trunk port belongs to all VLANs by default, and we want to put this port into a single VLAN only. To do so, we run the switchport mode access command to make the port an access port, and access ports belong to one and only one VLAN. After doing that, we placed the port into VLAN 12 with the switchport access vlan 12 command. Running the switchport mode access command effectively turns trunking off on that port.
The hosts are unaware of VLANs; they simply assume the VLAN membership of the port they're connected to. But that's not quite the case with dynamic VLANs, which we'll examine in the next part of this BCMSN tutorial.
In this tutorial, we'll take a look at the VLAN type you are most familiar with, the "static VLAN". As you know, VLANs are a great way to create smaller broadcast domains in your network. Host devices connected to a port belonging to one VLAN will receive broadcasts and multicasts only if they were originated by another host in that same VLAN. The drawback is that without the help of a Layer 3 switch or a router, inter-VLAN communication cannot occur.
The actual configuration of a static VLAN is simple enough. In this example, by placing switch ports 0/1 and 0/2 into VLAN 12, the only broadcasts and multicasts hosts connected to those ports will receive are the ones transmitted by ports in VLAN 12.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
% Access VLAN does not exist. Creating vlan 12
SW1(config-if)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if you have forgotten to do something, the Cisco device is generally going to remind you or in this case actually do it for you. I placed port 0/1 into a VLAN that did not yet exist, so the switch created it for me!
There are two commands needed to place a port into a VLAN. By default, these ports are running in dynamic desirable trunking mode, meaning that the port is actively attempting to form a trunk with a remote switch in order to send traffic between the two switches. The problem is that a trunk port belongs to all VLANs by default, and we want to put this port into a single VLAN only. To do so, we run the switchport mode access command to make the port an access port, and access ports belong to one and only one VLAN. After doing that, we placed the port into VLAN 12 with the switchport access vlan 12 command. Running the switchport mode access command effectively turns trunking off on that port.
The hosts are unaware of VLANs; they simply assume the VLAN membership of the port they're connected to. But that's not quite the case with dynamic VLANs, which we'll examine in the next part of this BCMSN tutorial.
Cisco CCNP / BCMSN Exam Tutorial: Changing Root Bridge Election Results
Your BCMSN and CCNP studies will include mastering the details of Spanning Tree Protocol (STP). While you learned some of these details in your CCNA studies, quite a bit of it may be new to you. Before going on to the intermediate and advanced STP features, let's review the root bridge election process and learn how to change these results.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Cisco CCNP / BCMSN Exam Tutorial: Dynamic VLANs and VMPS
Knowledge of Dynamic VLANs and VMPS is important in your efforts to pass the BCMSN exam and earn your CCNP, and it's also a great skill to have for your networking career.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
Cisco CCNA Exam Tutorial And Case Study: VLANs and IP Connectivity
In this CCNA case study, we'll take some basic switching and trunking theory and put it into action. We have two routers (R2 and R3) along with two switches (SW1 and SW2). R2 is connected to SW1 at fast 0/2, and R3 is connected to SW2 at fast 0/3. Both routers have IP addresses on the 172.12.23.0 /24 network.
For these routers to be able to ping each other, the switches must be able to communicate. These are two 2950 switches, and they're connected via two crossover cables. Before we worry about the router connectivity, let's make sure the trunk link is up between the switches with the "show interface trunk" command.
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
< output truncated for clarity >
The default mode of these switches is for the ports to run in dynamic desirable trunking mode, so we didn't even need to write a configuration to have the trunk form - it's already there!
Show vlan brief reinforces the theory that by default, all switch ports are placed into VLAN 1 (except the trunk ports).
R2 and R3’s Ethernet addresses have already been configured, the trunk line is operational, and both ports are in VLAN 1. We'll ping R2’s Ethernet interface from R3, and then R3’s Ethernet interface from R2 to verify IP connectivity.
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
With pings, exclamation points indicate IP connectivity, and periods indicate no connectivity.
So we've got connectivity! Now let's see if we still have that connectivity when the ports are placed into different VLANs. Cisco CCNA theory states that devices in different VLANs can't communicate without the intervention of a Layer 3 device, but let's see if that's true by placing R2 into VLAN 23. (VTP is already running on these switches.)
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 23
SW1(config-if)#^Z
Now that R2 and R3 are in separate VLANs, can they still send pings back and forth?
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
.....
No, they can’t. The difference is that they’re now in separate VLANs, and devices in different VLANs can’t communicate unless routing is taking place somewhere. Here, no routing is taking place, so the pings don’t go through.
Put R3’s switch port into VLAN 23, and try the ping again.
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#interface fast0/3
SW2(config-if)#switchport mode access
SW2(config-if)#switchport access vlan 23
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Now that R2 and R3 are in the same VLAN, pings can go through. This just proves the theory - that inter-VLAN communicate requires a Layer 3 device. Layer 3 switches are becoming more and more popular, but router-on-a-stick is still around - and we'll see how to configure that in our next tutorial!
For these routers to be able to ping each other, the switches must be able to communicate. These are two 2950 switches, and they're connected via two crossover cables. Before we worry about the router connectivity, let's make sure the trunk link is up between the switches with the "show interface trunk" command.
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
< output truncated for clarity >
The default mode of these switches is for the ports to run in dynamic desirable trunking mode, so we didn't even need to write a configuration to have the trunk form - it's already there!
Show vlan brief reinforces the theory that by default, all switch ports are placed into VLAN 1 (except the trunk ports).
R2 and R3’s Ethernet addresses have already been configured, the trunk line is operational, and both ports are in VLAN 1. We'll ping R2’s Ethernet interface from R3, and then R3’s Ethernet interface from R2 to verify IP connectivity.
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
With pings, exclamation points indicate IP connectivity, and periods indicate no connectivity.
So we've got connectivity! Now let's see if we still have that connectivity when the ports are placed into different VLANs. Cisco CCNA theory states that devices in different VLANs can't communicate without the intervention of a Layer 3 device, but let's see if that's true by placing R2 into VLAN 23. (VTP is already running on these switches.)
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 23
SW1(config-if)#^Z
Now that R2 and R3 are in separate VLANs, can they still send pings back and forth?
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
.....
No, they can’t. The difference is that they’re now in separate VLANs, and devices in different VLANs can’t communicate unless routing is taking place somewhere. Here, no routing is taking place, so the pings don’t go through.
Put R3’s switch port into VLAN 23, and try the ping again.
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#interface fast0/3
SW2(config-if)#switchport mode access
SW2(config-if)#switchport access vlan 23
R3#ping 172.23.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R2#ping 172.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:
!!!!!
Now that R2 and R3 are in the same VLAN, pings can go through. This just proves the theory - that inter-VLAN communicate requires a Layer 3 device. Layer 3 switches are becoming more and more popular, but router-on-a-stick is still around - and we'll see how to configure that in our next tutorial!
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: Configuring And Troubleshooting VTP
Not only is your CCNA exam going to have questions on VLAN trunking protocol, almost any network that has more than one VLAN is going to have VTP running. Whether you're planning on passing the CCNA exam or just brushing up on your networking skills, this VTP tutorial will help you learn the basics of this important protocol.
VTP allows switches to advertise VLAN information between other members of the same VTP domain. VTP allows a consistent view of the switched network across all switches. When a VLAN is created on one switch in a VTP server, all other VTP devices in the domain are notified of that VLAN’s existence. VTP servers will know about every VLAN, even VLANs that have no members on that switch.
Switches run VTP in one of three modes. In server mode, VLANs can be created, modified, and deleted on a VTP server. When these actions are taken, the changes are advertised to all switches in the VTP domain. VTP Servers keep VLAN configuration information upon reboot.
In client mode, the switch cannot modify, create, or delete VLANs. VTP clients cannot retain VLAN configuration information upon reboot; they have to obtain this information from a VTP server.
In real-world networks, this is generally done to centralize the creation and deletion of VLANs. An interesting side effect of the server/client methodology is that if a VLAN is only to have ports on the VTP client switch, the VLAN must still first be created on the VTP server. The VTP client will learn about the VLAN from the VTP server, and ports can then be placed into that VLAN.
The third VTP mode is transparent mode. VTP switches in this mode ignore VTP messages. They do forward the VTP advertisements received from other switches. VLANs can be created, deleted, and modified on a transparent server, but those changes are not advertised to the other switches in the VTP domain.
For switches running VTP to successfully exchange VLAN information, three things have to happen. I've listed them for you in the order that you'll see them in the real world.
The VTP domain name must match. This is case-sensitive. "CISCO" and "cisco" are two different domains.
To distribute information about a newly-created VLAN, the switch upon which that VLAN is created must be in Server mode.
Learning VTP isn't just a good idea for passing your CCNA exams, it's a skill you must have to be effective in configuring and troubleshooting VLANs. I wish you the best in both of these pursuits!
VTP allows switches to advertise VLAN information between other members of the same VTP domain. VTP allows a consistent view of the switched network across all switches. When a VLAN is created on one switch in a VTP server, all other VTP devices in the domain are notified of that VLAN’s existence. VTP servers will know about every VLAN, even VLANs that have no members on that switch.
Switches run VTP in one of three modes. In server mode, VLANs can be created, modified, and deleted on a VTP server. When these actions are taken, the changes are advertised to all switches in the VTP domain. VTP Servers keep VLAN configuration information upon reboot.
In client mode, the switch cannot modify, create, or delete VLANs. VTP clients cannot retain VLAN configuration information upon reboot; they have to obtain this information from a VTP server.
In real-world networks, this is generally done to centralize the creation and deletion of VLANs. An interesting side effect of the server/client methodology is that if a VLAN is only to have ports on the VTP client switch, the VLAN must still first be created on the VTP server. The VTP client will learn about the VLAN from the VTP server, and ports can then be placed into that VLAN.
The third VTP mode is transparent mode. VTP switches in this mode ignore VTP messages. They do forward the VTP advertisements received from other switches. VLANs can be created, deleted, and modified on a transparent server, but those changes are not advertised to the other switches in the VTP domain.
For switches running VTP to successfully exchange VLAN information, three things have to happen. I've listed them for you in the order that you'll see them in the real world.
The VTP domain name must match. This is case-sensitive. "CISCO" and "cisco" are two different domains.
To distribute information about a newly-created VLAN, the switch upon which that VLAN is created must be in Server mode.
Learning VTP isn't just a good idea for passing your CCNA exams, it's a skill you must have to be effective in configuring and troubleshooting VLANs. I wish you the best in both of these pursuits!
Monday, December 22, 2008
Cisco CCNA / CCNP / BCMSN Exam Review: Trunking And Trunking Protocols
To earn your CCNA or CCNP certification, you've got to understand the basics of trunking. This isn't just a CCNA topic - you must have an advanced understanding of trunking and etherchannels to pass the BCMSN exam and earn your CCNP as well. Before we address those advanced topics, though, you need to master the fundamentals!
A trunk allows inter-VLAN traffic to flow between directly connected switches. By default, a trunk port is a member of all VLANs, so traffic for any and all VLANs can travel across this trunk. That includes broadcast traffic!
The default mode of a switch port does differ between models, so always check your documentation. On Cisco 2950 switches, every single port is in dynamic desirable mode by default, meaning that every port is actively attempting to trunk. On these switches, the only action needed from us is to physically connect them with a crossover cable. In just a few seconds, the port light turns green and the trunk is up and running. The command show interface trunk will verify trunking.
How does the receiving switch know what VLAN the frame belongs to? The frames are tagged by the transmitting switch with a VLAN ID, reflecting the number of the VLAN whose member ports should receive this frame. When the frame arrives at the remote switch, that switch will examine this ID and then forward the frame appropriately.
There are two major trunking protocols you must understand and compare successfully, those being ISL and IEEE 802.1Q. Let's take a look at the details of ISL first.
ISL is a Cisco-proprietary trunking protocol, making it unsuitable for a multivendor environment. That's one drawback, but there are others. ISL will place both a header and trailer onto the frame, encapsulating it. This increases the overhead on the trunk line.
You know that the default VLAN is also known as the "native VLAN", and another drawback to ISL is that ISL does not use the concept of the native VLAN. This means that every single frame transmitted across the trunk will be encapsulated.
The 26-byte header that is added to the frame by ISL contains the VLAN ID; the 4-byte trailer contains a Cyclical Redundancy Check (CRC) value. The CRC is a frame validity scheme that checks the frame's integrity.
In turn, this encapsulation leads to another potential issue. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes.)
IEEE 802.1q differs substantially from ISL. In contrast to ISL, dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL. If the frame is destined for hosts residing in the native VLAN, that header isn't added. Since the header is only 4 bytes in size, and isn't even placed on every frame, using dot1q lessens the chance of oversized frames. When the remote port receives an untagged frame, the switch knows that these untagged frames are destined for the native VLAN.
Knowing the details is the difference between passing and failing your CCNA and CCNP exams. Keep studying, get some hands-on practice, and you’re on your way to Cisco certification success!
A trunk allows inter-VLAN traffic to flow between directly connected switches. By default, a trunk port is a member of all VLANs, so traffic for any and all VLANs can travel across this trunk. That includes broadcast traffic!
The default mode of a switch port does differ between models, so always check your documentation. On Cisco 2950 switches, every single port is in dynamic desirable mode by default, meaning that every port is actively attempting to trunk. On these switches, the only action needed from us is to physically connect them with a crossover cable. In just a few seconds, the port light turns green and the trunk is up and running. The command show interface trunk will verify trunking.
How does the receiving switch know what VLAN the frame belongs to? The frames are tagged by the transmitting switch with a VLAN ID, reflecting the number of the VLAN whose member ports should receive this frame. When the frame arrives at the remote switch, that switch will examine this ID and then forward the frame appropriately.
There are two major trunking protocols you must understand and compare successfully, those being ISL and IEEE 802.1Q. Let's take a look at the details of ISL first.
ISL is a Cisco-proprietary trunking protocol, making it unsuitable for a multivendor environment. That's one drawback, but there are others. ISL will place both a header and trailer onto the frame, encapsulating it. This increases the overhead on the trunk line.
You know that the default VLAN is also known as the "native VLAN", and another drawback to ISL is that ISL does not use the concept of the native VLAN. This means that every single frame transmitted across the trunk will be encapsulated.
The 26-byte header that is added to the frame by ISL contains the VLAN ID; the 4-byte trailer contains a Cyclical Redundancy Check (CRC) value. The CRC is a frame validity scheme that checks the frame's integrity.
In turn, this encapsulation leads to another potential issue. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes.)
IEEE 802.1q differs substantially from ISL. In contrast to ISL, dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL. If the frame is destined for hosts residing in the native VLAN, that header isn't added. Since the header is only 4 bytes in size, and isn't even placed on every frame, using dot1q lessens the chance of oversized frames. When the remote port receives an untagged frame, the switch knows that these untagged frames are destined for the native VLAN.
Knowing the details is the difference between passing and failing your CCNA and CCNP exams. Keep studying, get some hands-on practice, and you’re on your way to Cisco certification success!
CCNP / BCMSN Exam Tutorial: VLAN Trunking Protocol (VTP)
Passing the BCMSN exam and getting one step closer to the CCNP certification means learning and noticing details that you were not presented with in your CCNA studies. (Yes, I know – you had more than enough details then, right?) One protocol you’ve got to learn more details about is VTP, which seemed simple enough in your CCNA studies! Part of learning the details is mastering the fundamentals, so in this tutorial we’ll review the basics of VTP.
In show vtp status readouts, the "VTP Operating Mode" is set to "Server" by default. The more familiar term for VTP Operating Mode is simply VTP Mode, and Server is the default. It's through the usage of VTP modes that we can place limits on which switches can delete and create VLANs.
In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one switch in Server mode, or VLAN creation will not be possible. Again, this is the default setting for Cisco switches.
Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes.
VTP Transparent mode actually means that the switch isn't participating in the VTP domain as Servers and Clients do. (Bear with me here.) Transparent VTP switches don't synchronize their VTP databases with other VTP speakers. They don't even advertise their own VLAN information! Therefore, any VLANs created on a Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. (I know you remember that phrase from your CCNA studies!)
Devices running VTP Transparent mode do have a little something to do with the other switches in the VTP domain, though. When a switch running in Transparent mode receives a VTP advertisement, that switch will forward that advertisement to other switches in that VTP domain.
Configuring switches as VTP Clients is a great way to “tie down” VLAN creation capabilities to switches that are under your physical control. However, this occasionally leads to a situation where only the VTP clients will have ports that belong to a given VLAN, but the VLAN still has to be created on the VTP server. (VLANs can be created and deleted in transparent mode, but those changes aren't advertised to other switches in the VTP domain.)
In the next BCMSN tutorial, we’ll take a look at the details of VTP.
In show vtp status readouts, the "VTP Operating Mode" is set to "Server" by default. The more familiar term for VTP Operating Mode is simply VTP Mode, and Server is the default. It's through the usage of VTP modes that we can place limits on which switches can delete and create VLANs.
In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one switch in Server mode, or VLAN creation will not be possible. Again, this is the default setting for Cisco switches.
Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes.
VTP Transparent mode actually means that the switch isn't participating in the VTP domain as Servers and Clients do. (Bear with me here.) Transparent VTP switches don't synchronize their VTP databases with other VTP speakers. They don't even advertise their own VLAN information! Therefore, any VLANs created on a Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. (I know you remember that phrase from your CCNA studies!)
Devices running VTP Transparent mode do have a little something to do with the other switches in the VTP domain, though. When a switch running in Transparent mode receives a VTP advertisement, that switch will forward that advertisement to other switches in that VTP domain.
Configuring switches as VTP Clients is a great way to “tie down” VLAN creation capabilities to switches that are under your physical control. However, this occasionally leads to a situation where only the VTP clients will have ports that belong to a given VLAN, but the VLAN still has to be created on the VTP server. (VLANs can be created and deleted in transparent mode, but those changes aren't advertised to other switches in the VTP domain.)
In the next BCMSN tutorial, we’ll take a look at the details of VTP.
CCNA / CCNP Home Lab Tutorial: The VLAN.DAT File
CCNA and CCNP candidates who have their own Cisco home labs often email me about an odd situation that occurs when they erase a switch's configuration. Their startup configuration is gone, as they expect, but the VLAN and VTP information is still there!
Sounds strange, doesn't it? Let's look at an example. On SW1, we run show vlan brief and see in this abbreviated output that there are three additional vlans in use:
SW1#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
We want to totally erase the router's startup configuration, so we use the write erase command, confirm it, and reload without saving the running config:
SW1#write erase
Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]
[OK]
Erase of nvram: complete
00:06:00: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvram
SW1#reload
System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
The router reloads, and after exiting setup mode, we run show vlan brief again. And even though the startup configuration was erased, the vlans are still there!
Switch#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
The reason is that this vlan and VTP information is actually kept in the VLAN.DAT file in Flash memory, and the contents of Flash are kept on a reload. The file has to be deleted manually.
There's a little trick to deleting this file. The switch will prompt you twice to ask if you really want to get rid of this file. Don't type "y" or "yes"; just accept the defaults by hitting the return key. If you type "y", the router attempts to delete a file named "y", as shown here:
Switch#delete vlan.dat
Delete filename [vlan.dat]? y
Delete flash:y? [confirm]
%Error deleting flash:y (No such file or directory)
Switch#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
Switch#
The best way to prepare for CCNA and CCNP exam success is by working on real Cisco equipment, and by performing lab tasks over and over. Repetition is the mother of skill, and by truly erasing your VLAN and VTP information by deleting the vlan.dat file from Flash, you'll be building your Cisco skills to the point where your CCNA and CCNP exam success is a certainty.
Sounds strange, doesn't it? Let's look at an example. On SW1, we run show vlan brief and see in this abbreviated output that there are three additional vlans in use:
SW1#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
We want to totally erase the router's startup configuration, so we use the write erase command, confirm it, and reload without saving the running config:
SW1#write erase
Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]
[OK]
Erase of nvram: complete
00:06:00: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvram
SW1#reload
System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
The router reloads, and after exiting setup mode, we run show vlan brief again. And even though the startup configuration was erased, the vlans are still there!
Switch#show vlan br
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
The reason is that this vlan and VTP information is actually kept in the VLAN.DAT file in Flash memory, and the contents of Flash are kept on a reload. The file has to be deleted manually.
There's a little trick to deleting this file. The switch will prompt you twice to ask if you really want to get rid of this file. Don't type "y" or "yes"; just accept the defaults by hitting the return key. If you type "y", the router attempts to delete a file named "y", as shown here:
Switch#delete vlan.dat
Delete filename [vlan.dat]? y
Delete flash:y? [confirm]
%Error deleting flash:y (No such file or directory)
Switch#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
Switch#
The best way to prepare for CCNA and CCNP exam success is by working on real Cisco equipment, and by performing lab tasks over and over. Repetition is the mother of skill, and by truly erasing your VLAN and VTP information by deleting the vlan.dat file from Flash, you'll be building your Cisco skills to the point where your CCNA and CCNP exam success is a certainty.
Subscribe to:
Posts (Atom)
