To pass the CCNA exam and earn that coveted certification, you’ve got to know Cisco switches inside and out. Among the many important details you’ve got to know are the three methods that Cisco switches use to forward frames, and the differences between the three.

The first switching method is Store-and-Forward. The name is the recipe, because that’s just what the switch does – it stores the entire frame before beginning to forward it. This method allows for the greatest amount of error checking, since the Frame Check Sequence (FCS) can be run before the frame is forwarded. As always, there is a tradeoff, since this error checking process makes this the slowest of the three frame forwarding methods.

The quickest method is Cut-Through, where only the destination MAC address of the frame is examined before the forwarding process begins. This means that the part of the frame is actually being forwarded as it is still being received! The tradeoff here is that the FCS does not run, so there is absolutely no error checking with Cut-Through switching.
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

To be truly prepared for your CCNA and CCNP exams, you need real hands-on experience with real Cisco routers and switches. However, a production network is a really bad place to practice your configurations, but an excellent way to get fired and/or sued. The key to becoming a true CCNA and CCNP is assembling your own Cisco home lab.

You don’t have to spend a lot of money to do so; used Cisco equipment is cheaper than ever. It’s robust as well – I’ve bought literally hundreds of used routers and switches over the years and have had very few problems. I owe much of my skill to practicing configurations and troubleshooting in my own home lab.
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!