Packet Tracer Video Tutorial 2

Packet Tracer Video Tutorial 2

Packet Tracer Video Tutorial 1

Packet Tracer Video Tutorial 1

Troubleshooting Ipconfig

Troubleshooting Ipconfig

An error occurred while renewing interface
Can ping ip but not name
Can ping IP but not hostname after installed/upgraded software
Can receive IP packets but not send them
Can't obtain/renew IP addresses from the DHCP server
Can't ping my own IP address
Cannot use the 2nd NIC
IP address conflicts
No IP while the network cable is disconnected
No operation can be performed on the adapter
One-way ping only
Some Win9x obtain different subnet mask
The DHCP client has obtained an IP address that is already in use on the network
Unexpected network failure or insufficient access or access is denied
Why the ipconfig shows 0.0.0.0 ip even you have assigned a static ip
Why do I get 169.254.x.x IP?

An error occurred while renewing interface

Symptoms: When trying to release and renew the IP address using the Ipconfig command, you may receive the following error message: “An error occurred while renewing interface 'Internet': An operation was attempted on something that is not a socket.”

Cause: These issues may occur if the Winsock registry keys are damaged or corrupted.

Can ping ip but not name

I have a situation here where I could ping an IP of a computer but how come I couldn't ping with its computer name?

1. Incorrect WINS and DNS settings.
2. Incorrect TCP/IP settings
3. Check lmhosts and hosts files

Can ping IP but not hostname after installed/upgraded software

Cause: the may modify the networking configuration in registry.

Can receive IP packets but not send them

Symptoms: When using ipconfig command, you may have no IP address or no Automatic Private IP Addressing (APIPA) address. You may be receiving IP packets but not sending them.

Cause: These issues may occur if the Winsock registry keys are damaged or corrupted.

Can't ping my own IP address

Failure to ping a computer's own IP address is most likely caused by a firewall program or improperly configured.
Can't obtain/renew IP addresses from the DHCP server

Symptoms: 1) you have a DHCP client which may not be able to obtain/renew IP addresses from the DHCP server intermittently. 2) after setup a workstation to obtain an IP address from DHCP, the machine can't ping others and ipconfig /all shows Autoconfiguration IP Address. . . : 169.254.x.x.
Resolutions: 1) If this is XP, obtain the latest service pack for Windows XP.
2) Use the Network Diagnostics tool to identify any failed settings. To do this, go to Help and Support>Use Tools to view your computer information and diagnose problems>Network Diagnostics>Scan your system. When the process finishes, check for any items marked "FAILED" in red, expand those categories, and view the additional details about what the testing showed.
3) Assign a static ip on the client and ping the DHCP server. If you can't ping the DHCP server, check the connection and hardware.
4) If you can ping the DHCP after assigning static ip, check the DHCP settings.
5) Make sure no firewall is running on your LAN.
6) Run Repair this connection if it is XP. Or use netsh to reset TCP/IP configuration.
7) If it is win98/w2k, remove and reinstall TCP/IP.
8) Try to upgrade the new NIC driver.
9) Make sure you don't run out of IPs in the DHCP scope.
10) If you use a router as DHCP, you may want to upgrade the firmware.

Cannot use the 2nd NIC

Symptom: You have two computers and each one has two NICs. You are using the first NIC with 192.168.1.0/24 to connect the Internet and it works. You also want to use the 2nd NIC with crossover cable to connect to each other using the same IP range (one is 192.168.1.10 and another is 192.168.1.11). You can't ping each other (192.168.1.10 and 192.168.1.11).

Resolution: The 2nd NICs should use the different IP range.


IP address conflicts
SYMPTOMS: when trying to set the IP address on a NIC, you may receive the following error message: "The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box? "
RESOLUTION:
1. If you click Yes, you see the TCP/IP properties where you can change the IP address. Then assign the different IP.
2. If you click No, the IP address is assigned to the network adapter. To resolve this problem, uninstall the ghosted network adapter from the registry: At command prompt, type set devmgr_show_nonpresent_devices=1, and then press ENTER. Type Start DEVMGMT.MSC, and then press ENTER. Click View, and then click Show Hidden Devices. Expand the Network Adapters tree and right-click the dimmed network adapter, and then click Uninstall.

No IP while the network cable is disconnected

Symptoms: your computer has a static IP. However, the ipconfig shows no IP (Media State - Cable Disconnected) while the network cable is disconnected.

Cause: this is by design. If you have some software using TCP/IP whiteout connecting to a network, you may setup it manually.

No operation can be performed on the adapter

Symptoms: when attempting to use ipconfig /release or renew command, you get "No operation can be performed on the adapter as this connection has its media/cable disconnected.

Causes: 1. The network is up-plugged or no NIC. 2. You are using static IP.

One-way ping only

If you can ping other computers and other computers can't ping your computer, this is often caused by an improperly configured firewall
on you computer. For example, ICF should not be enabled on LAN NIC.

Some Win9x obtain different subnet mask

Symptoms: In your domain network, some computers (most are win9x) obtain mask 255.255.255.0 instead of 255.0.0.0 randomly and they can't logon to the Domain. IPCONFIG /renew doesn't fix the problem. If you assign static ip and correct mask, the computer will be able to logon without any problem. If you check the WINS, you may find many bad records.

Possible reasons: you may have another network device (possible a router) except main DHCP functions as a DHCP.

The DHCP client has obtained an IP address that is already in use on the network

Symptom: When trying to renew IP, you may get this error "An error occurred while renewing the interface Local Area Connection: The
DHCP client has obtained an IP address that is already in use on the network. The local interface will be disabled until the DHCP client can obtain a new address."

Resolution: 1. Release and the renew it.
2. Clean the internal DNS and WINS records.
Refer to case 083104LR

Unexpected network failure or insufficient access or access is denied

Symptoms: when trying to use ipconfig /release or renew, you may receive the following message "The following error occurred when releasing adapter Local Area Connection: Unexpected network failure or insufficient access or access is denied"

Cause: You don't have permission to release or renew the IP.

Why do I get 169.254.x.x IP?

Symptom: The Internet Assigned Numbers Authority (IANA) has reserved 169.254.0.0-169.254.255.255 for Automatic Private IP Addressing. If the computer can't get ip from DHCP, APIPA provides an address that is guaranteed not to conflict with routable addresses.

Resolutions: 1) Make sure you have good connection.
2) Check the hardware and settings.
3) Make sure the DHCP is working.
4) For the test, you can assign static ip. If static ip works, it is possible DHCP issue. If static ip doesn't work, check the hardware or connection.
5) WinSock2 stack may be corrupted and need to repair.

Why the ipconfig shows 0.0.0.0 ip even you have assigned a static ip

Question: I have assigned a static ip, subnet to the computer, but the ipconfig shows IP address is 0.0.0.0 and subnet mask 0.0.0.0.. Why?

Answer: An existing IP address on the network has the same IP address. You may use tracert ip, WINS and DNS records to find out another computer using the same IP.

If your laptop users frequently disconnect from one network segment and reconnect to another network segment, they may not be able to access the second network. Resolution will be run ipconfig /registerdns.

Mitigate problems using Cisco IOS debug

Ideally, all of your Cisco router configurations run like clockwork and you rarely need to troubleshoot them. That's the way it should be, since these devices usually work as the pillars of network connectivity within an organization. But if your Cisco routers do have problems, you need to be able to come to a resolution quickly and effectively. That's why we're going to look at how to use the Cisco IOS debug commands.

This article is intended for the intermediate level network administrator who has never encountered circumstances that would require debugging the Cisco IOS. But if you've used debug before, perhaps this article will give you some suggestions for ways to use debug that you haven't previously tried.

Key points
Before I introduce 10 ways to use Cisco IOS debug, here are a few tips and caveats:

• · The techniques I'm including are not the only ways to use debug. In fact, there are hundreds of ways to use debug. Listing A: shows all the possible subcommands that can be debugged in IOS 12.2 (the version I was running). You will see that there are more than you would ever want to use. In addition, each subcommand has its own subcommands. I'll be focusing on some of the debug commands I consider most common and useful.
• · Using Cisco IOS debug can be dangerous and should first be used on a test router and then used carefully on a production router. I don’t want anyone to get fired because he crashed the company’s production router after trying debug commands from this article.
• · By default, debug messages will go to the console and will not be sent to any log. To log debug output (or any system output) to the IOS system log, you must turn on logging buffered in global configuration mode. You can see if logging is on by issuing the show logging command on your router. The output looks like Listing B. As you can see, there are three kinds of logging: console, monitor, and buffer. There are also different levels of logging.
  
• · If you want to see debug output on a terminal (or Telnet session) that is not the console, use the terminal monitor command.
• · You can also set up “conditional debugging” to debug only when certain conditions apply. See Cisco's Troubleshooting and Fault Management to learn more about this.
• · If you turn on some debugging that is filling up your screen, the quickest way to turn it off is by running the un all command. The un is a built-in macro for undebug.

Now let’s move on and look at 10 ways to use Cisco IOS debug. We'll start with number 10 and work our way up to the most useful debug command.

10. Debug all
By far, the most dangerous debug command is debug all. This command will most likely crash a production router. The Cisco IOS is nice enough to ask, “Are you sure?” before doing it. Only use this command if you are desperate, you know you are on a test router, and/or you are having trouble isolating the proper subcommand to debug. To satisfy your curiosity of what it looks like to run it, Listing C shows the output from executing the command and then issuing show debug to see what it turned on.

9. Debug with ISDN and dialer
Debugging is helpful when troubleshooting Cisco router dialup configurations. In my experience, these technologies rarely seem to work the first time. The best way to configure IOS dialup technologies (or any networking technologies) is layer by layer, testing each layer after configuring it. I try to think of a multilayer cake, where the icing is the successful testing of each OSI layer after each configuration. When something doesn’t work, debug is usually a must. Useful debug commands for ISDN and dialup networking appear below:

• · debug isdn events debugs all ISDN events. Start with this one first before trying q921 or q931, as those are very verbose and events may tell you all you need to know.
• · debug isdn q921 is Layer 2.
• · debug isdn q931 is Layer 3.
• · debug dialer events will tell you about the calls (i.e., the reason the call was initiated and/or disconnected). Here is some sample output:

00:18:52: BRI0/0 DDR: Dialing cause ip (s=1.1.1.2, d=1.1.1.1)
00:18:52: BRI0/0 DDR: Attempting to dial 8358661
00:19:22: BRI0/0:2 DDR: disconnecting call

This can be especially helpful if you have a router that keeps calling when you don't want it to.

· debug dialer packet will tell you what packets are doing across your dialer interfaces, where they are going to and coming from, and whether they were permitted (as interesting traffic) or denied (as uninteresting traffic) by the dialer-list configured on that interface. Here's some sample output of permitted and denied packets:

00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:39:24: BRI0/0 DDR: ip (s=1.1.1.2, d=1.1.1.1), 100 bytes, outgoing interesting (ip PERMIT)
00:41:09: BRI0/0 DDR: cdp, 273 bytes, outgoing uninteresting (no list matched)

8. PPP authentication
If you configured PPP authentication on your dialup lines (which you should, for security reasons), you could end up with username/password mismatches on each side. Finding out that this is the reason that the line won’t come up can be impossible without using debug ppp authentication.

Here's some sample output of missing username/password information on one router:
00:32:30: BR0/0:1 CHAP: O CHALLENGE id 13 len 23 from "r2"
00:32:31: BR0/0:1 CHAP: I CHALLENGE id 2 len 23 from "r1"
00:32:31: BR0/0:1 CHAP: O RESPONSE id 2 len 23 from "r2"
00:32:31: BR0/0:1 CHAP: I FAILURE id 2 len 26 msg is "Authentication failure"

This is sample output of an incorrect password on one router:
00:47:05: BR0/0:1 CHAP: O CHALLENGE id 25 len 23 from "r2"
00:47:05: BR0/0:1 CHAP: I CHALLENGE id 19 len 23 from "r1"
00:47:05: BR0/0:1 CHAP: O RESPONSE id 19 len 23 from "r2"
00:47:05: BR0/0:1 CHAP: I FAILURE id 19 len 25 msg is "MD/DES compare failed"

7. Debug {topology} packet
As I mentioned above, it is best to troubleshoot networking technologies using a layered approach, working your way up the OSI model from Layer 1. (I give credit to Bruce Caslow and his book Cisco Certification: Bridges, Routers, and Switches for CCIEs for carefully documenting this approach.)

Using that model, for whatever network topology you are working with, you can use the debug command to see that your Layer 2 packets are being encapsulated properly. (Of course, I'm assuming that all the cables are connected at Layer 1.) For instance, let's say that you work with frame-relay and you're having trouble getting packets across a link. You've verified that the link is up, but there is still no data passing on it. You could try
debug frame-relay packet

Then, you could attempt to ping the interface on the remote router. If the ping passes, you will get the following:
01:03:22: Serial0/0:Encaps failed--no map entry link 7(IP)

This tells you that encapsulation failed for the IP packet into the frame-relay protocol. It even tells you that it failed because there is no frame-relay map statement. If you fix that and try it again, you might find that you get no frame-relay errors. But then the packet still may not pass. Thus, you'll need to go up to Layer 3 and try:
debug ip packet

You might get this output:
01:06:46: IP: s=1.1.1.2 (local), d=11.11.11.11, len 100, unroutable

This tells you that there is no IP route for your packet to traverse. Thus, you know you need to add a route.

You can insert whatever networking topology you are working with on the debug {topology} line. Some other possibilities are:

• · debug atm packet
• · debug serial packet
• · debug ppp packet
• · debug dialer packet
• · debug fastethernet packet

6. Debug crypto (IPSec and VPN features)
I won’t go into a lot of detail and examples here since IPSec and VPN are huge topics that can get very complex. But I do want to point out that you can troubleshoot IPSec connections with debugging commands. Because of the popularity of VPN and IPSec, it is important to know how to use debug commands for these technologies. Some of the possibilities are:

• · debug crypto isakmp
• · debug crypto ipsec
• · debug crypto engine
• · debug ip security
• · debug tunnel

In addition, debug ip packet, as mentioned below, is useful in troubleshooting IPsec connections.

If you want to learn more on this topic, I recommend going to Cisco’s IP Security Protocols Section, choosing the protocol you are interested in (IPSec, IKE, etc.), and looking at the different configurations along with their recommended troubleshooting methods.

5. Debug IP routing
Using debug with IP routing protocols can be useful as well. For example, to know if you have a route flapping (a route being added and removed frequently), you can use debug ip routing.

If you had a flapping route, you might see something like:
01:30:56: RT: add 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:31:13: RT: del 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:31:13: RT: delete subnet route to 111.111.111.111/32
01:31:13: RT: delete network route to 111.0.0.0
01:32:56: RT: add 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:33:13: RT: del 111.111.111.111/32 via 12.12.12.11, ospf metric [110/65]
01:33:13: RT: delete subnet route to 111.111.111.111/32
01:33:13: RT: delete network route to 111.0.0.0

This could indicate a routing loop in your network. On the other hand, it could indicate a link going up and down, perhaps a bouncing dialup interface or frame-relay interface.

4. Debug ip {routing protocol}
You can insert many options with debug ip. Issuing the debug ip ? command will display them. We've included the options in Listing D.

Most routing protocols (e.g., OSPF, EIGRP, IGRP, and BGP) are included in this list. Each has its own extensive options that can be debugged. (You can see all the options for a particular protocol by issuing the debug ip {routing protocol} ? command.) For instance, the only way to know that your two OSPF routers are not forming an adjacency due to mismatched authentication types is to issue debug ip ospf adjacency.

You might see the following output, telling you that the authentication types are mismatched:
01:39:46: OSPF: Rcv pkt from 12.12.12.11, Serial0/0 : Mismatch Authentication type. Input packet specified type 0, we use type 2

In this case, if it weren't for debug, you could be scratching your head for a while.

3. Debug list
An interesting debug command that isn’t widely known is debug list. This command doesn’t actually debug anything. Instead, it sets an interface and/or access list for the next debug you enter. So if you are going to issue some command that you know will produce a lot of output but that doesn’t have an option to limit that output with an access command, you can first issue the debug list XXX command (where XXX is an access list number you have already created) and then run the command you want to debug on. An example would be:
debug list 1
debug dhcp detail
DHCP client activity debugging is on for access list: 1 (detailed)

2. Log an access list to system or syslog
You can use the log option at the end of an access list to log packets that are permitted or denied. This could enable you to log packets that are denied on a router being used as a firewall or to control access at an important network point. Remember that a firewall doesn’t have to just protect you from the Internet; it can protect higher security departments (such as accounting), be placed between two business partners, or just keep some traffic (like P2P traffic) off your network. While this isn’t technically a debug command, it can certainly be used for debugging and troubleshooting. Let's look at a couple of examples.

First, suppose that you want to allow only BGP traffic in your network and keep track of all other traffic that attempts to enter a link. Here's a sample configuration:
Interface Serial 0/0
Access-group 100 in

access-list 100 remark Begin -- Allow BGP IN and OUT
access-list 100 permit tcp host 1.1.1.1 host 2.2.2.2 eq bgp
access-list 100 permit udp any host 2.2.2.2 gt 33000
access-list 100 remark End
access-list 100 deny ip any any log

All traffic will go to your Cisco router’s log if you have “logging buffered” turned on or to a syslog server if you configured one.

For the second example, let's say you are trying to nail down an access list to permit only the proper traffic to go over your dialup link. You use an access list and log the existing traffic to get an idea of what is being carried so that you can configure the correct access list. Here's a sample configuration:
Interface BRI 0/0
Access-group 100 in
Access-group 100 out

access-list 100 permit ip any any log

If you look at the output in the router’s log, you will see that an ICMP packet and a TCP packet went across your link:
02:03:43: %SEC-6-IPACCESSLOGDP: list 100 permitted icmp 1.1.1.2 -> 1.1.1.1 (0/0), 1 packet
02:06:25: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet

1. Debug IP packet detail XXX (access list number)
My number-one debug technique is using an access list to see all the traffic going to and from some destination, just like a basic sniffer/protocol analyzer. The limitation to this one is that you can’t see the packet payload and can see almost nothing of the headers.

Since you can do this with an access list, you can nail it down to a particular host, protocol, port, or network range, as well as using a uni- or bi-directional access list. I know it isn’t a real protocol analyzer, but it could still come in handy—and it's already built into the IOS. The sample configuration below shows the logging of all Telnet packets to your router. (These could just as well be a host on one of your router’s networks.)
access-list 101 permit tcp any any eq telnet
debug ip packet detail 101
IP packet debugging is on (detailed) for access list 101

Listing Eshows the sample output of what the debug output would look like.

You can see from the output that you get the IP source, destination, interfaces, source and destination port numbers, sequence numbers, acknowledgement numbers, window sizes, and TCP communication flags (SYN, ACK, FIN).

Troubleshoot Cisco routers and switches using the debug commands - Part 3

What are the three most common mistakes made when using Debug?

Using Debug can be a risky proposition, and even experienced admins have made mistakes when using it.

I’d say the number one common mistake is to forget that you have left Debug on in a production environment. Sometimes, we get so focused on resolving the issue that when we get it resolved, we are on to the next “opportunity” and forget to issue the no debug command to turn off debugging. I think that many a network admin can attest to horror stories of when they brought their router to its knees because they forgot this simple task of turning off Debug.

The second common mistake would be not realizing the effect on your router of issuing a lot of Debug commands at the same time. Remember that the router’s job is to forward packets, not to monitor processes and generate Debug messages. For example, you are having a problem with the packets on your router, so you issue the Debug statement debug ip packet. Then you decide that you want to view the events on the RIP protocol. Now, you have two separate Debug statements that are being processed and sent to the console. Debug statements are processed at a higher priority than other network traffic, so, needless to say, these Debug statements can jeopardize your router’s performance.

The third common mistake made with the Debug command is entering debug all or debug ip packet detail on a production router. Either one of these commands can crash a heavily loaded production router. Luckily, there is an “are you sure” prompt before these take effect; however, that hasn’t prevented every debug-related catastrophe. You should be as specific as possible when using Debug, and then turn it off as quickly as possible. Also, always test your Debug commands on a test router before using them in a production environment.

Troubleshoot Cisco routers and switches using the debug commands - Part 2

Let’s take a look at a simple example. We are going to view RIP (Routing Information Protocol) in Debug mode.

Router# debug ip RIP

RIP protocol debugging is on

To verify what debugging is enabled, use this command:

Router# show debug

  RIP protocol debugging is on

The output from whatever type of debug is enabled will be sent to wherever the Cisco IOS logging system tells that output to go. Either you will receive the output on your screen, it will go to the buffered log on the router, or it will go to a syslog server across the network (or all of these).

To see what level the various outputs are set to and where the output will go, type:

Router# show logging

Syslog logging: enabled (1 messages dropped, 3 messages rate-limited,

                0 flushes, 0 overruns, xml disabled, filtering disabled)

    Console logging: level debugging, 8 messages logged, xml disabled,

                     filtering disabled

    Monitor logging: level debugging, 0 messages logged, xml disabled,

                     filtering disabled

    Buffer logging: level warnings, 2 messages logged, xml disabled,

                    filtering disabled

    Logging Exception size (4096 bytes)

    Count and timestamp logging messages: disabled

    Trap logging: level informational, 12 message lines logged

Log Buffer (51200 bytes):

*Jun  9 20:56:49.195: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Jun  9 20:56:49.231: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

Router#

The console should display RIP updates that are sent and received through the RIP protocol. Here is an example of what you might see for RIP debugging:

*Jun  9 21:13:56.471: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)

*Jun  9 21:13:56.471: RIP: build update entries - suppressing null update

*Jun  9 21:14:22.519: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)

*Jun  9 21:14:22.519: RIP: build update entries - suppressing null update

Remember that you should use Debug only for a short time to get a snippet of information, and then turn Debug off as it can be a serious performance hit on your router.

There are several commands for turning off Debug.

Router# no debug

If you type debug ?, you will see that there are over 200+ Debug commands, and each of those has many options. Debugging RIP is just a very simple example.

Troubleshoot Cisco routers and switches using the debug commands - Part 1

Often, you cannot solve router and switch issues with “show” commands alone. At some point, you will have to use Debug commands to find out what is really going on behind the scenes. In this article, you will learn about Cisco IOS Debug commands and how they can help you.

What makes Cisco IOS Debug commands so useful?

Cisco IOS Show commands can tell you many things about what is going on with your router or switch, but they can’t tell you everything. For example, Show commands cannot tell you when routes drop in or out of the routing table, why an ISDN line failed to connect, whether a packet really went out the router, or what ICMP error code was received. On the other hand, Cisco IOS Debug commands can tell you all these things, and more.

Besides providing more detailed information than what Show commands can provide, Debug commands have the benefit of providing information in “real time” (or dynamically). This is contrary to Show commands that just take a snapshot in time and display the results on your console (somewhat static results). This real-time difference can be very helpful in diagnosing problems.