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 start studying for your CCNA and CCNP exams, many books will present you with a huge list of keystroke shortcuts for use on Cisco routers. While the 640-801, 811, and 821 exams may ask you about one or two of these, you really have to get hands-on experience with these commands to master them. Even better, there are some key combinations that Cisco routers mention, but then don’t tell you what they are! Let’s take a look at a few of the more helpful key combinations, and conclude with the “secret” way to stop a ping or traceroute.

The up arrow on your keyboard is great for repeating the last command you typed. Let’s say you mis-enter an access-list. Instead of typing it from the beginning, just hit your up arrow to repeat it, then fix the problem.

CTRL-A takes the cursor to the beginning of a typed line. If you’ve written an extended ACL, you know that can be a very long command, and one you probably don’t want to retype. If you get a carat indicating there is a problem with the line, use your up arrow to repeat the command. If you see the error is near the beginning, use CTRL-A to move the cursor immediately to the beginning of the line. CTRL-E takes the cursor to the end of a typed line.

To move the cursor through a typed line without erasing characters, you’ve got a couple of options. I personally like to use the left and right arrows, but you can also use CTRL-B to move back and CTRL-F to move forward.

Finally, there’s the combination that Cisco mentions to you when you run ping or traceroute, but they don’t tell you what it is! If you send an extended ping or a traceroute, you could be looking at asterisks for a long time if you don’t know this one. In the following example, a traceroute is obviously failing:

R2#traceroute 10.1.1.1

Type escape sequence to abort.

Tracing the route to 10.1.1.1

1 * * *

2 *

The problem is that you’re going to get 30 rows of those asterisks, which is frustrating and time-consuming at the same time. Note the router console message “Type escape sequence to abort”. That’s helpful – but what is it?

Here it is: Just type CTRL-SHIFT-6 twice, once right after the other. You won’t see anything on the router console, but the traceroute will terminate.
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

When you begin your CCNA studies, you get hit with a lot of different networking terms right away that you might not be familiar with. What makes it a little more confusing is that a lot of these terms sound a lot alike. Here, we’re going to discuss the differences between broadcasts, multicasts, and unicasts at both the Data Link (Layer 2) and Network (Layer 3) layers of the OSI model.

A broadcast is simply a unit of information that every other device on the segment will receive. A broadcast is indicated by having every bit of the address set to its highest possible value. Since a hexadecimal bit’s highest value is “f”, a hexadecimal broadcast is ff-ff-ff-ff-ff-ff (or FF-FF-FF-FF-FF-FF, as the upper case does not affect hex value). The CCNA exam will demand you be very familiar with hex conversions, so if you’re not comfortable with these conversions, get comfortable with them before taking the exam!

At layer 3, a broadcast is indicated by setting every bit in the 32-bit binary string to “1″, making the dotted decimal value 255.255.255.255. Every host on a segment will receive such a broadcast. (Keep in mind that switches will forward a broadcast, but routers do not.) In contrast to a broadcast, a unicast is a packet or frame with only one destination.
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!