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.

As a CCNA and/or CCNP candidate, you’ve got to be able to spot situations where Cisco router features can save your client money and time. For example, if a spoke router is calling a hub router and the toll charges at the spoke site are higher than that of the hub router, having the hub router hang up initially and then call the spoke router back can save the client money (and make you look good!)

A popular method of doing this is using PPP callback, but as we all know, it’s a good idea to know more than one way to do things in Cisco World! A lesser-known but still effective method of callback is Caller ID Screening & Callback. Before we look at the callback feature, though, we need to know what Caller ID Screening is in the first place!

This feature is often referred to simply as “Caller ID”, which can be a little misleading if you’ve never seen this service in operation before. To most of us, Caller ID is a phone service that displays the source phone number of an incoming call. Caller ID Screening has a different meaning, though. Caller ID Screening on a Cisco router is really another kind of password – it defines the phone numbers that are allowed to call the router.

The list of acceptable source phone numbers is created with the isdn caller command. Luckily for us, this command allows the use of x to specify a wildcard number. The command isdn caller 555xxxx results in calls being accepted from any 7-digit phone number beginning with 555, and rejected in all other cases. We’ll configure R2 to do just that and then send a ping from R1 to R2. To see the results of the Caller ID Screening, debug dialer will be run on R1 before sending the ping. I’ve edited this output, since the output you see here will be repeated fire times – once for each ping packet.

R2(config-if)#isdn caller 555xxxx

R1#debug dialer

Dial on demand events debugging is on

R1#ping 172.12.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.12.12.2, timeout is 2 seconds:

03:30:25: BR0 DDR: Dialing cause ip (s=172.12.12.1, d=172.12.12.2)

03:30:25: BR0 DDR: Attempting to dial 8358662.

Success rate is 0 percent (0/5)

R1 doesn’t give us any hints as to what the problem is, but we can see that the pings definitely aren’t going through. On R2, show dialer displays the number of screened calls.

R2#show dialer

BRI0 – dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

8358661 1 0 00:03:16 successful

7 incoming call(s) have been screened.

0 incoming call(s) rejected for callback.

The callback option mentioned in the last line shown above enables the router to reject a phone call, and then call that router back seconds later.

R2 will now be configured to initially hang up on R1, and then call R1 back.

R2(config-if)#isdn caller 8358661 callback

R1 will now ping R2. The pings aren’t returned, but seconds later R2 calls R1 back.

R1#ping 172.12.12.2

Success rate is 0 percent (0/5)

R1#

03:48:12: BRI0: wait for isdn carrier timeout, call id=0×8023

R1#

03:48:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

R1#

03:48:18: BR0:1 DDR: dialer protocol up

R1#

03:48:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

R1#

03:48:24: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2

show dialer on R2 shows the reason for the call to R1 is a callback return call.

R2#show dialer

BRI0 – dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

8358661 3 0 00:00:48 successful

7 incoming call(s) have been screened.

10 incoming call(s) rejected for callback.

BRI0:1 – dialer type = ISDN

Idle timer (120 secs), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is data link layer up

Dial reason: Callback return call

Time until disconnect 71 secs

Connected to 8358661 (R1)

The drawback to Caller ID Callback is that not all telco switches support it, so if you have the choice between this and PPP Callback, you’re probably better off with PPP Callback. However, it’s always a good idea to know more than one way to get things done with Cisco!