Your CCNA studies are going to include quite a bit of information about switches, and for good reason. if you don’t understand basic switching theory, you can’t configure and troubleshoot Cisco switches, either on the CCNA exam or in the real world. That goes double for trunking!

Trunking is simply enabling two or more switches to communicate and send frames to each other for transmission to remote hosts. There are two major trunking protocols that we need to know the details of for exam success and real-world success, but before we get to the protocols, let’s discuss the cables we need.

Connecting two Cisco switches requires a crossover cable. As you know, there are eight wires inside an ethernet cable. In a crossover cable, four of the cables “cross over” from one pin to another. For many newer Cisco switches, all you need to do to create a trunk is connect the switches with a crossover cable. For instance, 2950 switches dynamically trunk once you connect them with the right cable. If you use the wrong cable, you’ll be there a while!

There are two different trunking protocols in use on today’s Cisco switches, ISL and IEEE 802.1Q, generally referred to as “dot1q”. There are three main differences between the two. First, ISL is a Cisco-proprietary trunking protocol, where dot1q is the industry standard. (Those of you new to Cisco testing should get used to the phrases “Cisco-proprietary” and “industry standard”.) If you’re working in a multivendor environment, ISL may not be a good choice. And even though ISL is Cisco’s own trunking protocol, some Cisco switches run only dot1q.
Read the full story

When you’re studying to pass the CCNA exam and earn your certification, you’re introduced to a great many terms that are either totally new to you or seem familiar, but you’re not quite sure what they are. The term “broadcast domain” falls into the latter category for many CCNA candidates.

A broadcast domain is simply the group of end hosts that will receive a broadcast sent out by a given host. For example, if there are ten host devices connected to a switch and one of them sends a broadcast, the other nine devices will receive the broadcast. All of those devices are in the same broadcast domain.

Of course, we probably don’t want every device in a network receiving every single broadcast sent out by any other device in the network! This is why we need to know what devices can create multiple, smaller broadcast domains. Doing so allows us to limit the broadcasts traveling around our network – and you might be surprised how much traffic on some networks consists of unnecessary broadcasts.

Using the OSI model, we find devices such as hubs and repeaters at Layer One. This is the Physical layer, and devices at this layer have no effect on broadcast domains.
Read the full story

CCNA / CCNP candidates are going to be drilled by Cisco when it comes to troubleshooting questions. You’re going to have to be able to analyze configurations to see what the problem is (and if there is a problem in the first place), determine the meaning of different debug outputs, and show the ability not just to configure a router or switch, but troubleshoot one.

That’s just as it should be, because CCNAs and CCNPs will find themselves doing a lot of troubleshooting in their careers. Troubleshooting isn’t something that can just be learned from a book; you’ve got to have some experience working with routers and switches. The only real way to learn how to troubleshoot is to develop that ability while working on live equipment.
Read the full story

As your CCNA / CCNP home lab expands, an access server such as the Cisco 2509 or 2511 is one of the best investments you can make. In this article, we’ll look at the basic configuration for an access server and discuss how to connect to the other routers and switches in your pod through the AS.

Here’s part of a configuration from one of my access servers:

ip host FRS 2006 100.1.1.1

ip host SW2 2005 100.1.1.1

ip host SW1 2004 100.1.1.1

ip host R2 2002 100.1.1.1

ip host R1 2001 100.1.1.1

ip host R3 2003 100.1.1.1

interface Loopback0

ip address 100.1.1.1 255.255.255.255

no ip directed-broadcast

This is an IP Host table, and this is what makes the entire AS setup work. Your PC will connect to the access server, and the access server is in turn physically connected to your other routers and switches via an octal cable. One end of the octal cable splices off into eight separate cables, each terminated with an Rj-45 connector. That connector will be placed into the console port of one of your home lab devices. In this configuration, I have connector 1 connected to the console port of R1, connector 2 to R2, connector 3 to R3, connector 4 to Sw1, and so forth. (The connectors are physically numbered as well.)

The IP Host table entries here are linked to the loopback address shown. The loopback can be any address, but it must match the address in the IP Host table. This allows you to create reverse telnet sessions to the routers and switches.

To open the reverse telnet sessions upon opening a connection to the AS, type the entire name of the device and press the enter key twice. A connection to that device will now be visible, as shown here:

Access_Server#r1

Trying R1 (100.1.1.1, 2001)… Open

R1#

To get back to the access server, use the key combination followed by pressing the “x” key. Keep doing this until you’ve opened a connection to every router and switch in your pod.

Once you’ve opened the lines, you will not use the full device name to connect to the home lab devices. You should press only the number corresponding to the reverse telnet session you opened. For instance, in this configuration I opened telnet session 1 to R1, session 2 to R2, and session 3 to R3. Once I opened those sessions, I just use those numbers to reconnect to the devices, as shown here:

Access_server#1

[Resuming connection 1 to r1 ... ]

R1#

Access_server#2

[Resuming connection 2 to r2 ... ]

R2#

Access_server#3

[Resuming connection 3 to r3 ... ]

R3#

If you type the full hostname again after initially opening the connection, you will see this message:

Access_server#r1

Trying R1 (100.1.1.1, 2001)…

% Connection refused by remote host

The connection is refused because you already have an open connection to that router.

There’s one more important part of an access server config your CCNA / CCNP home lab will need:

line 1 8

no exec

transport input all

The line numbers may differ according to your access server, but “no exec” is very important here. This will stop rogue EXEC sessions from refusing connections that it shouldn’t be refusing. Without this command, you’ll commonly see “connection refused by remote host” when you shouldn’t be. That message is the most common error you’ll see on an access server, and it’s there because you already have an open connection or you left “no exec” out of your configuration. “No exec” isn’t mandatory, but it will help you keep your sanity!

Occasionally, during your CCNA and CCNP studies, you’ll run into a term that just doesn’t quite make sense to you. (Okay, more than occasionally!) One such term is “reverse telnet”. As a Cisco certification candidate, you know that telnet is simply a protocol that allows you to remotely connect to a networking device such as a router or switch. But what is “reverse telnet”, and why is it so important to a Cisco CCNA / CCNP home lab setup?

Where a telnet session is started by a remote user who wants to remotely control a router or switch, a reverse telnet session is started when the host device itself imitates the telnet session.

In a CCNA / CCNP home lab, reverse telnet is configured and used on the access server. The access server isn’t a white box server like most of us are used to; an access server is a Cisco router that allows you to connect to multiple routers and switches with one session without having to move a rollover cable from device to device.

Your access server will use an octal cable to connect to the other routers and switches in your home lab. The octal cable has one large serial connector that will connect to the access server, and eight rj-45 connectors that will connect to your other home lab devices. Your access server then needs an IP Host table in order to perform reverse telnet.

An IP Host table is easy to put together (and you better know how to write one to pass the CCNA!). The IP Host table is used for local name resolution, taking the place of a DNS server. A typical access server IP Host table looks like this:

ip host FRS 2007 100.1.1.1

ip host R3 2003 100.1.1.1

ip host R1 2001 100.1.1.1

ip host R2 2002 100.1.1.1

ip host R4 2004 100.1.1.1

ip host R5 2005 100.1.1.1

ip host SW1 2006 100.1.1.1

interface Loopback0

ip address 100.1.1.1 255.255.255.255

no ip directed-broadcast

This configuration will allow you to use your access server to connect to five routers, a frame relay switch, and a switch without ever moving a cable. When you type “R1″ at the console line, for example, you’ll be connected to R1 via reverse telnet. If you have a smaller lab, an access server is still a real timesaver and an excellent investment. And by getting a static IP address to put on your access server, you can even connect to your home lab from remote locations!

As a CCNA or CCNP, one thing you’ve got to get used to is that change is constant. Cisco regularly issues new IOS versions, not to mention the many different kinds of hardware they produce! While it’s always nice to have “the latest and the greatest” when it comes to routers, switches, firewalls, etc., we have to be prepared for the fact that not all our clients are going to have that latest and greatest!

For instance, there are still quite a few Catalyst 5000 switches out there humming away, and if you’re used to working on IOS-driven switches like the 2950, the same command can have dramatically different results.

Let’s say you’re going to examine the spanning tree protocol (STP) setup of a new client. You’re used to working with newer 2950 switches, and you’ve always run show span on those switches to display spanning-tree information. Then, you run show span on a Catalyst 5000 – and something like this shows:

switch (enable) show span

Destination : Port 6/1

Admin Source : Port 6/2

Oper Source : Port 6/2

Direction : transmit/receive

Incoming Packets: disabled

Learning : enabled

Multicast : enabled

Filter : -

Status : active

Total local span sessions: 1

What’s going on here?

The command show span on a 5000 will not show spanning tree stats – instead, what you’re going to see are statistics relating to Switched Port ANalyzer (SPAN). Surprise!

Consider an example where you’re used to running show span on 5000 switches to see SPAN information. When you run that on a 2950, you know now what you’re going to get – spanning tree information! On a 2950, you’ll need to run show monitor session, followed by the SPAN session number.

SW1#show monitor session 1

Session 1

———

Type : Local Session

Source Ports :

Both : Fa0/1

Destination Ports : Fa0/2

Encapsulation : Native

Ingress: Disabled

As a CCNA and CCNP, this is one of those things you just have to get used to. Commands are going to be different, sometimes radically so, between models. That’s why you need to be adept with both IOS Help and Cisco’s online documentation site. IOS Help is easy, but the online doc site take a little getting used to. Once you learn how to navigate that site, a world of Cisco knowledge is at your fingertips.

Besides, when you sit for the CCIE lab exam, that will be the only friend you have! And a valuable friend it can be – you’re just going to have to trust me on that one.