Archive for vtp

Invisible Networks (No Kidding), the World of Virtual LANs (VLANS), Part III

Posted in Cisco Certification with tags , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , on June 7, 2011 by jjrinehart

Oops...I Forgot to Turn Off VTP

The history of technology and innovation is full of attempts to create greater efficiencies and automate tasks, a good example is DHCP; this protocol hands out IP address information with little intervention needed.  Any engineer/technician that has had to renumber a network can certainly appreciate this particular task being simplified.  On the other hand, if someone brings in a home router and plugs it in, it can wreak havoc for every other user.

The focus of this post centers on a switching technology that also had good intentions but can create outages that turn an engineer’s hair gray or loose, namely, Virtual Trunking Protocol, or VTP.  The intention of VTP was to simplify the configuration of VLANs across multiple switches.  In a network of less than a dozen devices, manually configuring VLANs is not that big of a deal, but in a large campus environment of a hundred or more switches this becomes ridiculously difficult.  Why not just configure this once and let it propagate automatically?  Seems like a win-win right?  Hold that thought while we go through some specifics.

There are three operational modes of VTP on a Cisco switch (yes, this is a Cisco proprietary protocol), as follows:

  1. Server: This switch serves in a master operational mode, where all the changes are made and then passed out to switches.  To ensure that the latest data is propagated accurately, each time the database changes, the revision number is incremented.
  2. Client: This switch does not store any VLAN information locally, nor can any changes be made to the information it contains.  Think of it as a “read only” mode of operation.
  3. Transparent: A switch in transparent mode operates independently, just as it would if VTP didn’t even exist.  It ignores all updates, though it does pass those updates to all other switches it has trunk links too.  Since VTP cannot be shut off, this is about the closest you can get to off.  If all switches are in a network are configured in this mode it effectively negates any effect it could have on the environment.

Now that you have an idea of how VTP operates, you can appreciate the “gotchas” that come with using it.  If only one switch operates as the server and the rest are all clients, then life is good.  But what happens when you add a new switch in server mode?  Hopefully nothing, unless the configuration revision number just so happens to be higher than the one that all the other switches have.  At that point, “poof” (see picture above), the database on every single switch is immediately erased.  The technical term for this is RGE–Resume Generating Event.  Best practices recommend just operating in transparent mode.

Talk to you later…

– Joe


Invisible Networks (No Kidding), the World of Virtual LANs (VLANS), Part II

Posted in Cisco Certification with tags , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , on June 2, 2011 by jjrinehart


Words are funny things, and if you start using the word trunk at a cocktail party, people will probably look at you strangely, as it evokes images of luggage, large animals, or the back of an automobile (pictured above).  As I mentioned previously, this term comes from the telephony world, and it is worthy of a bit of explanation.  The analog line between a residential home is typically referred to as a local loop or subscriber loop and is designed to carry a single phone conversation.  These lines all terminate at the central office, and if the call is destined for someone else served by that office, a connection is made locally.  If the call is destined to another location, it is bundled together with other calls and sent over a single connection to another central office–multiple calls on a single line…this is essential the definition of a trunk.  In the LAN switching world the principle is the same–if the destination is local, the switch passes the traffic out the correct port, otherwise, it is sent across a single connection to another switch or switches, and a trunk link carries multiple VLANs across a single line.

As you would see in looking at a compact car next to an SUV, all trunks are not created equal, and there are actually two types in the Cisco networking world. These two types are Cisco’s InterSwitch Link (ISL) and the IEEE’s 802.1Q (dot1q), and each have their own distinctive characteristics.  Understanding the differences is a critical factor to both passing the CCNA exam and surviving in the real world of networking.

  1. ISL

To begin with, ISL is a Cisco-proprietary trunking protocol, meaning it will only work on Cisco switches.  If you operate a mixed environment, then ISL will not be your friend.  ISL (like some tunneling protocols) operates by taking the existing frame and wrapping it in a completely new frame and header.  This makes things simple when the header is stripped off at the destination switch/VLAN because the original frame is left intact (no FCS recalculations).  The VLAN id is carried in the ISL header, and there is no concept of a native VLAN.  Pretty straightforward, right?

        2. 802.1Q

802.1Q (referred to as dot1q in command-line syntax) is an industry-standard trunking protocol, so all switches are able to use it.  Unlike ISL, 802.1Q inserts a VLAN tag into the existing frame, which requires that the FCS be recalculated when altering the frame.  The only exception to this is the native VLAN, which in plain English just means that the frame is left untouched, or more properly, untagged.

Next, we will talk about a protocol that seems like a good idea on the surface, but can have disastrous consequences.  Just remember it’s not a bug, it’s a feature!

– Joe

I’d Rather Fight Than Switch

Posted in Cisco Certification with tags , , , , , , , , , , , , , , , , , , , , , , , , , , , , , on April 26, 2011 by jjrinehart

My maternal grandfather smoked Tareyton cigarettes, which carried the famous ad line of “I’d rather fight than switch” that I thought was a perfect lead-in for discussing LAN switching (clever, right?)  To the uninitiated, the term switch conjures up a whole set of images, usually relating to electrical components and/or lights.  In terms of networking, switching was a quantum leap forward, especially in terms of network congestion and bandwidth.  Think of a hub just like a parking lot after a sporting event–there is only one exit, and everybody is crowding to get out of that one opening, and coming from all directions as well.  Not a pretty picture, especially if you have waited seemingly hours to get out…

Wouldn’t it be amazing if there were a whole block of separate exit points from that parking lot?  Imagine how much faster things would go and how much more smoothly would the lot empty.  That’s the essential idea behind switches…instead of all stations sharing a single network entry point, separate data channels are created for all of the attached devices.  Sounds almost magical, but there is a rather simple logic that makes it all work, and it all based at Layer 2…the data-link layer of the OSI model.  Hubs just took electrical signals and retransmitted it out all ports because it had no way of distinguishing traffic.  Switches are different because they are examining the MAC (hardware) addresses of the frames passing through their ports.  If the frame is one it has never seen before, or a broadcast (ffff.ffff.ffff), it sends it out all ports except the one it arrived on (termed flooding).  The switch then records the source address contained in the frame, as well as the interface it came in on, and when a frame destined for that address arrives again, it send it out the port contained in the table entry (termed forwarding).  If it arrives on the same port in the table, it simply drops the frame (termed filtering).  The reason for the term switch is simple, because it takes a frame from one port,and then switches it to another port and sends it on its way.

In the next blog, I will drill into the specific types of switches in the Cisco product line and how they are best used in real-world settings.

– Joe