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

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

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!

A prime topic of your CCNA and CCNP CIT exams will be connecting Cisco routers directly via their Serial interfaces, and while the configuration is straightforward, there are some vital details and show commands you must know in order to pass the exams and configure this successfully in production and home lab networks. Let’s take a look at a sample configuration.

Connecting Cisco routers directly via their Serial interfaces works really well once you get it running – and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and it’s the DCE that must be configured with the clockrate command.

R3#show controller serial 1

HD unit 1, idb = 0×11B4DC, driver structure at 0×121868

buffer size 1524 HD unit 1, V.35 DCE cable

R3(config)#int serial1

R3(config-if)#ip address 172.12.13.3 255.255.255.0

R3(config-if)#clockrate 56000

R3(config-if)#no shut

Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Let’s remove the clockrate from R3 and see what happens.

R3(config)#int s1

R3(config-if)#no clockrate 56000

R3(config-if)#

18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

The line protocol doesn’t drop immediately, but it does drop. Let’s run show interface serial1 to compare the physical and logical interface states.

R3#show int serial1

Serial1 is up, line protocol is down

Physically, the interface is fine, so the physical interface is up. It’s only the logical part of the interface – the line protocol – that is down. It’s the same situation on R1.

R1#show inter serial1

Serial1 is up, line protocol is down

While a router misconfiguration is the most likely cause of a serial connection issue, that’s not the only reason for clocking issues. Cisco’s website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!