Passing Cisco’s CCNA and CCNP Exams: Traceroute

In preparation for your CCNA and CCNP exam success, you've got to learn to troubleshoot Cisco routers. And while ping is a great basic IP connectivity tool, it doesn't give you all the information you need to diagnose network connectivity issues.

Let's say you have six routers between CityA and CityB. You send a ping from A to B, and get this return:

R1#ping 172.1.1.1

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

The five periods indicate that there is no IP connectivity to CityB. Problem is, that's about all ping tells you. You can have 5 or 50 routers between the two points, so how can you tell which downstream router has the problem?

That's where traceroute comes in. Traceroute sends three datagrams with a Time To Live (TTL) of 1. Those datagrams will timeout once they hit the first router in the path, and that router will respond with an ICMP Time Exceeded message.

In response, the sending router sends three more datagrams, but these have a TTL of 2. This means that the next router in line will send back ICMP Time Exceeded messages. This process continues until the final destination (CItyB) is reached the output of the command shows us the path the data took:

Router1#traceroute 271.1.1.1


Type escape sequence to abort.

Tracing the route to 271.1.1.1


1 20.1.1.1 4 msec 4 msec 4 msec

2 30.1.1.1 20 msec 16 msec 16 msec

3 271.1.1.1 16 msec * 16 msec

How does this help troubleshoot a problem? Let's say that the second router in this path, 30.1.1.1, doesn't know how to get to 271.1.1.1. The output would look like this:

Router1#traceroute 271.1.1.1


Type escape sequence to abort.

Tracing the route to 271.1.1.1


1 20.1.1.1 4 msec 4 msec 4 msec

2 30.1.1.1 20 msec 16 msec 16 msec

3 * * *

This indicates that the router at 30.1.1.1 doesn't know how to get to the final destination. Now you have a better idea of which router has an issue!
Now here's the bad part: you're going to get 30 lines of three asterisks, and until you abort this traceroute, you're going to just watch those asterisks go across the screen. There's an abort sequence that the router mentions in the first line of the console output, but the router doesn't tell you what it is! So I will - this top-secret sequence is TWICE, one right after the other.

That keystroke takes a little getting used to, but a CCNA or CCNP can do it! Add this command to your Cisco skill set, and it will serve you well both on the CCNA and CCNP exams and your real-world networks. And you'll impress your friends by knowing how to stop a traceroute!

Passing Cisco CCNA And CCNP Exams: Ping And Extended Ping

I often tell CCNA and CCNP candidates that you do your best learning when you screw something up. I often get a funny look right after I say that, but the only way to develop your Cisco troubleshooting skills - the skills you'll need to pass your Intro, ICND, and CCNP exams - is by actually fixing configurations. Since your employer will take a dim view of you practicing these skills on his or her network, you better do so on your home lab!
Three essential tools for networking and CCNA/CCNP exam success are ping, extended ping, and traceroute. Today we're going to take a look at the ping that we're used to using for LAN issues, and the extended ping.

We're all familiar with "basic" ping, where you use the ping command followed by the IP address you want to confirm IP connectivity with. When you've got connectivity, you will see five exclamation points, as seen here:

R1#ping 172.12.123.2

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/72 ms

The default source IP address for ping is the IP address closest to the destination IP address. Other defaults - five ICMP packets will be sent (that's why you see five exclamation points), and they're sent two seconds apart.

That's fine for many basic situations, but as you progress through your networking career and most advanced scenarios in your CCNA / CCNP studies, you will want to change some of these defaults. What could you do if you wanted to send 10,000 pings? What if you needed your router's loopback address to be the source IP address for the pings? What if you wanted to send them five seconds apart, instead of two?

That's where extended ping comes in. To use extended ping, just type "ping" and hit enter. (Note that you cannot use extended ping in user exec mode - you must be in enable mode to do so.)

R1>ping

% Incomplete command.

"incomplete command" indicates that the router is waiting for an IP address; you can't use extended ping in user exec mode.

R1>enable

R1#ping

Protocol [ip]:

Target IP address: 172.16.123.1

Repeat count [5]: 1000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: loopback0

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

.......................................

In this example, I sent 1000 ICMP packets to an address that doesn't exist, so I am getting periods instead of exclamation points. This illustration shows you the many options you have with extended ping.

Now that I've sent those 1000 pings, let's say that I want to stop that process. At the beginning of the basic ping output, you see this phrase:
Type escape sequence to abort.

This escape sequence works for ping, extended ping, and traceroute. Funny thing, though - Cisco doesn't tell you what the escape sequence is! One day, this will really come in handy. The escape sequence is , TWICE in rapid succession.

After I used it in this example, the pings stopped and I got this message:

Success rate is 0 percent (0/192)

The ping stopped after 192 ICMP packets were sent.

This keystroke takes a little practice, so practice it in your home lab. Knowing how to use extended ping will really come in handy on your CCNA and CCNP exams as well as your real-life networking job, and knowing how to stop an extended ping will as well!

Cisco Routing: "ip default-network" vs. Default Static Routes

One point of confusion for some CCNA and CCNP candidates is the difference between configuring a static default route and using the Cisco routing command ip default-network.


At first glance, they appear to do the same thing. Both configure a destination to which packets should be routed if there is no more specific route in the routing table.


The major difference between these two options is that configuring a static default route only defines a default route for the router you're configuring it on, while ip default-network will propagate the route via its routing protocol.


Let's examine the routing tables of a hub-and-spoke network using the ip default-network command. R1 is the hub and R2 and R3 are the spokes. They are directly connected via the network 172.12.123.0 /24, and each has a loopback with a 32-bit mask that are numbered according to the router number (1.1.1.1, etc.) RIP is running on all three routers and the loopbacks are advertised.


R1 has another serial interface with the IP address 10.1.1.1 /24, and this network has been flagged as a default network with the command ip default-network 10.0.0.0 . It is not being advertised by RIP.


The routing protocol will then advertise this route. With RIP, the default network is advertised as 0.0.0.0 . (With IGRP, it appears as the network number, but is marked as an IGRP External route. ) This route has been designated a candidate default route on R1, as we see with the asterisk next to the 10.0.0.0 /24 network (code table removed for brevity):


R1#show ip route


Gateway of last resort is not set


1.0.0.0/32 is subnetted, 1 subnets

C 1.1.1.1 is directly connected, Loopback0

R 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:11, Serial0

R 3.0.0.0/8 [120/1] via 172.12.123.3, 00:00:11, Serial0

172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks

C 172.12.21.0/30 is directly connected, BRI0

C 172.12.123.0/24 is directly connected, Serial0

* 10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, Serial1


On R2 and R3, a default RIP route is now seen (code tables again deleted):


R2#show ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0


R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:00, Serial0.213

2.0.0.0/32 is subnetted, 1 subnets

C 2.2.2.2 is directly connected, Loopback0

R 3.0.0.0/8 [120/2] via 172.12.123.1, 00:00:00, Serial0.213

172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks

C 172.12.21.0/30 is directly connected, BRI0

C 172.12.123.0/24 is directly connected, Serial0.213

R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:00, Serial0.213


R3#show ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0


R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:27, Serial0.31

R 2.0.0.0/8 [120/2] via 172.12.123.1, 00:00:28, Serial0.31

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Loopback0

172.12.0.0/24 is subnetted, 1 subnets

C 172.12.123.0 is directly connected, Serial0.31

R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:28, Serial0.31


And the default route works, since we can ping 10.1.1.1 from both R2 and R3. Since they have no other match in their routing tables, they use the default route.


R2#ping 10.1.1.1


Type escape sequence to abort.

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

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms


R3#ping 10.1.1.1


Type escape sequence to abort.

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

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms


When deciding whether to use a default static route or a default network, keep in mind that if you want the routing protocol to propagate the default route, the ip default-network command will do that for you. But if you want only the local router to have the default route, a static IP route is the way to go.

Cisco CCNA Exam Tutorial And Case Study: VLANs and IP Connectivity

In this CCNA case study, we'll take some basic switching and trunking theory and put it into action. We have two routers (R2 and R3) along with two switches (SW1 and SW2). R2 is connected to SW1 at fast 0/2, and R3 is connected to SW2 at fast 0/3. Both routers have IP addresses on the 172.12.23.0 /24 network.

For these routers to be able to ping each other, the switches must be able to communicate. These are two 2950 switches, and they're connected via two crossover cables. Before we worry about the router connectivity, let's make sure the trunk link is up between the switches with the "show interface trunk" command.

SW2#show interface trunk

Port Mode Encapsulation Status Native vlan

Fa0/11 desirable 802.1q trunking 1

Fa0/12 desirable 802.1q trunking 1

< output truncated for clarity >

The default mode of these switches is for the ports to run in dynamic desirable trunking mode, so we didn't even need to write a configuration to have the trunk form - it's already there!

Show vlan brief reinforces the theory that by default, all switch ports are placed into VLAN 1 (except the trunk ports).

R2 and R3’s Ethernet addresses have already been configured, the trunk line is operational, and both ports are in VLAN 1. We'll ping R2’s Ethernet interface from R3, and then R3’s Ethernet interface from R2 to verify IP connectivity.

R2#ping 172.23.23.3

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

R3#ping 172.23.23.2

Type escape sequence to abort.

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

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

With pings, exclamation points indicate IP connectivity, and periods indicate no connectivity.

So we've got connectivity! Now let's see if we still have that connectivity when the ports are placed into different VLANs. Cisco CCNA theory states that devices in different VLANs can't communicate without the intervention of a Layer 3 device, but let's see if that's true by placing R2 into VLAN 23. (VTP is already running on these switches.)

SW1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#int fast 0/2

SW1(config-if)#switchport mode access

SW1(config-if)#switchport access vlan 23

SW1(config-if)#^Z

Now that R2 and R3 are in separate VLANs, can they still send pings back and forth?

R2#ping 172.23.23.3

Type escape sequence to abort.

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

Success rate is 0 percent (0/5)

R3#ping 172.23.23.2

Type escape sequence to abort.

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

No, they can’t. The difference is that they’re now in separate VLANs, and devices in different VLANs can’t communicate unless routing is taking place somewhere. Here, no routing is taking place, so the pings don’t go through.

Put R3’s switch port into VLAN 23, and try the ping again.

SW2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW2(config)#interface fast0/3

SW2(config-if)#switchport mode access

SW2(config-if)#switchport access vlan 23

R3#ping 172.23.23.2

Type escape sequence to abort.

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

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

R2#ping 172.23.23.3

Type escape sequence to abort.

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

Now that R2 and R3 are in the same VLAN, pings can go through. This just proves the theory - that inter-VLAN communicate requires a Layer 3 device. Layer 3 switches are becoming more and more popular, but router-on-a-stick is still around - and we'll see how to configure that in our next tutorial!

Cisco CCNA Exam Tutorial: Loopback Interfaces

As a CCNA candidate, you most likely have some background in PC hardware and workstation support. If so, you're already familiar with loopback interfaces, particularly 127.0.0.1, the loopback address assigned to a PC.

When you're learning all about the different physical interfaces for your CCNA exam - serial, ethernet, and BRI, among others - there's one logical interface you need to know about, and that is - you guessed it! - the loopback interface.

What isn't as immediately apparent is why we use loopback interfaces on routers and switches to begin with. Many of the Cisco router features that can use loopbacks are intermediate and advanced features that you'll learn about in your CCNP and CCIE studies, but these features all come back to one basic concept: If the loopback interface on a router is down, that means the router is unavailable as a whole.

In contrast, a physical interface being down does not mean the router itself is out of commission. A router's ethernet port can go down, but the other physical interfaces on that router are still operational. Since a loopback interface is logical, there's nothing physical that can go wrong with it.

As I mentioned, you'll learn different Cisco router and switch features that utilize loopback interfaces as you climb the Cisco certification ladder. There's one misconception about Cisco loopback interfaces that you want to get clear on now, though. You’re probably familiar with loopback interfaces on a PC, and may even know that the address range 127.0.0.0 is reserved for loopback addressing.

Note that this reserved address range does not apply to loopbacks on Cisco devices, however. If you attempt to assign an address from this range to a Cisco loopback interface, you get this result:

R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#interface loopback0

R1(config-if)#ip address 127.0.0.2 255.255.255.0

Not a valid host address - 127.0.0.2

R1(config-if)#ip address 127.1.1.1 255.255.255.0

Not a valid host address - 127.1.1.1

The range 127.0.0.0 is reserved for host loopbacks (such as PCs), not routers or switches. The most commonly used address from this range is 127.0.0.1 – if you can’t ping that on a workstation, that means you can’t ping yourself, which means there’s a problem with the TCP/IP install itself.

Keep these details in mind on the exam and in the workplace, and you’re on your way to CCNA exam success!

Cisco CCNA Certification: Five Key Combinations You Should Know

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.

R2#traceroute 10.1.1.1

Type escape sequence to abort.

Tracing the route to 10.1.1.1

1 * * *

2 * * *

3

R2#
The traceroute was successfully terminated. This combination works for pings as well, both extended and regular. Of all the keystrokes you can learn, this one is the most valuable!

Cisco CCNA / CCNP Exam Tutorial: Testing ISDN Links Without Pings

To earn your Cisco CCNA and CCNP certifications, you've got to master ISDN - and despite what some people say, there's still a lot of ISDN out there that needs to be supported. And when it comes to troubleshooting ISDN, there's a lot to look at. Is the correct ISDN switchtype configured? Are the dialer map statements correct? What about the dialer-group and dialer-list commands? And that's just the start.

I always say that all troubleshooting starts at Layer 1, the Physical layer of the OSI model. The usual method of troubleshooting ISDN is sending pings across the link, but the connection can be tested without using pings or even before assigning IP addresses to the BRI interfaces!

It's a good idea to place these test calls before configuring the interfaces - that way, you know you've got a valid connection before beginning the configuration (and there's a lot of config to go along with ISDN!)

To place a test call without using pings, use the isdn call interface command.

R1#isdn call interface bri0 8358662

R1#

03:54:43: BR0 DDR: Attempting to dial 8358662

03:54:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

03:54:44: BR0:1 DDR: dialer protocol up

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

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

To tear the test call down correctly, use isdn disconnect interface. IOS Help displays the options with this command.

R1#isdn disconnect interface bri 0 ?

all Disconnect the data call(s) on all b channels

b1 Disconnect the data call on b1 channel

b2 Disconnect the data call on b2 channel

R1#isdn disconnect interface bri 0 all

03:58:36: BR0:1 DDR: disconnecting call

03:58:36: BR0:2 DDR: disconnecting call

03:58:36: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 8358662
R2, call lasted 20 seconds

03:58:36: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

03:58:36: BR0:1 DDR: disconnecting call

03:58:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down

I say "correctly" because the one thing you don't want to do to end an ISDN call, test or otherwise, is just shut the interface. Telcos don't like it, and ISDN lab devices like it even less. Always let the d-channel do its work and tear the call down in an orderly fashion - don't just cut it off by shutting the interface down.