Troubleshooting basic networks

www.professordkinney.com
08/26/13
Instructional Design-Computer Networking -
Bridges Educational Group

Troubleshooting Basic Connectivity
08/26/13

Lessons Summary:
Troubleshooting IPv4 Network
Troubleshooting IPv6 Network
08/26/13

Troubleshooting IPv4 Network
Tools for Troubleshooting IP Problems
 The tools ping and traceroute, both in the TCP/IP protocol suite, will greatly assist in
troubleshooting IP connectivity. Most operating systems and IP implementations come with these
tools installed by default. On some UNIX platforms, however, you may need to download and install
a traceroute package.
 Cisco routers provide a basic method of viewing IP traffic switched through the router called packet
debugging. Packet debugging enables a user to determine whether traffic is travelling along an
expected path in the network or whether there are errors in a particular TCP stream. Although in
some cases packet debugging can eliminate the need for a packet analyzer, it should not be
considered a replacement for this important tool.
 Packet debugging can be very intrusive—in some cases, it can cause a router to become inoperable
until physically reset. In other instances, packets that are present on the network and switched
through the router may not be reported by packet debugging. Thus, a firm conclusion cannot be
drawn that a packet was not sent solely from the output of packet debugging; a network analyzer
must be used to accurately make this assessment. Packet debugging should be used with extreme
caution by only advanced operators because it can cause the router to lock up and stop routing traffic,
if not used carefully. The risks of using packet debugging may be compounded by the necessity of
disabling fast switching for packet debugging to be effective. As a general rule, packet debugging
should not be used on a production router unless you have physical access to the router and are
willing to risk it going down.
08/26/13

ping
The ping tool uses the IP ICMP echo request and echo reply messages to test reachability to a remote
system. In its simplest form, ping simply confirms that an IP packet is capable of getting to and
getting back from a destination IP address (Figure below). This tool generally returns two pieces of
information: whether the source can reach the destination (and, by inference, vice versa), and the
round-trip time (RTT, typically in milliseconds). The RTT returned by ping should be used only as a
comparative reference because it can depend greatly on the software implementation and hardware
of the system on which ping is run. If ping fails or returns an unusual RTT, traceroute can be used to
help narrow down the problem. It is also possible to vary the size of the ICMP echo payload to test
problems related to maximum transmission unit (MTU).
08/26/13

Example below shows ping returning three values separated with the slash "/," the minimum, average,
and maximum RTT. Large differences in these values could indicate network congestion or a network
problem. In most cases, the average value accurately portrays the network latency to the destination.
By default, ping uses small packets for connectivity testing; the packet size will influence the RTT
values. The packet size may be changed in some implementations, including that of Cisco Systems's
IOS.
ping Returning Three Values Separated with the Slash "/," the Minimum, Average, and
Maximum RTT
CiscoRtr1>ping 10.3.1.6
……….
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoes to 10.3.1.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Firewalls and routers can be configured to not allow devices to be pinged but to still permit other types
of IP traffic. For this reason, a ping failure between two devices should not be misconstrued as a lack
of IP connectivity between those devices.
08/26/13

Table below shows a list of some of the codes returned by the Cisco ping utility, along with their
meanings and possible cause.
08/26/13

traceroute
The traceroute utility sends out either ICMP echo request (Windows) or UDP (most implementations)
messages with gradually increasing IP TTL values to probe the path by which a packet traverses the
network (Example below). The first packet with the TTL set to 1 will be discarded by the first hop,
and the first hop will send back an ICMP TTL exceeded message sourced from its IP address facing
the source of the packet. When the machine running the traceroute receives the ICMP TTL exceeded
message, it can determine the hop via the source IP address. This continues until the destination is
reached. The destination will return either an ICMP echo reply (Windows) or a ICMP port
unreachable, indicating that the destination had been reached. Cisco's implementation of traceroute
sends out three packets at each TTL value, allowing traceroute to report routers that have multiple
equal-cost paths to the destination.
Traceroute can return useful information about TCP/IP connectivity across your network. Table below
shows some of the codes that can be returned by the Cisco traceroute utility, along with their
possible cause.
08/26/13

Cisco Tracerourte:
CiscoRtr1>traceroute 10.3.1.6
Tracing the route to 10.3.1.6
1 CiscoRtr2 (10.1.1.2) 0 msec
CiscoRtr3 (10.1.1.3) 0 msec
2 CiscoRtr5 (10.2.1.6) 4 msec 4 msec 0 msec
If there had been a problem between CiscoRtr5 and CiscoRtr6, you would have seen the following on a
Cisco router:
CiscoRtr1>traceroute 10.3.1.6
Tracing the route to 10.3.1.6
1 CiscoRtr2 (10.1.1.2) 0 msec
3 * * *
4 * * *
08/26/13

To use the debug ip packet command, you must do the following:
1. Enter enable mode.
CiscoRtr> enable
CiscoRtr#
2. Disable console logging. (This command can be run with console logging, but this increases the
likelihood of locking up the router.)
CiscoRtr# configure terminal
CiscoRtr(config)# no logging console
CiscoRtr(config)# end
CiscoRtr#
3. Enable buffer logging.
CiscoRtr(config)# logging buffered
CiscoRtr#
4. Turn on logging timestamps with millisecond output.
CiscoRtr(config)# service timestamps log datetime msec
CiscoRtr#
08/26/13

5.Ensure that the router's CPU is not overloaded. This depends greatly on the amount of traffic to
capture and the type of router. As a general rule, a CPU percentage (highlighted here) less than 30
percent should be safe. Note: This may still cause your router to lock up!
CiscoRtr#show processes cpu
CPU utilization for five seconds: 2%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 2075 308386 6 0.00% 0.00% 0.00% 0 Load Meter
2 273 55 4963 1.55% 0.18% 0.06% 0 Exec
[snip]
CiscoRtr#
6.Disable fast-switching on the inbound and outbound interfaces from which you would like to capture
traffic.
CiscoRtr#configure terminal
CiscoRtr(config)# interface ethernet 0
CiscoRtr(config-if)# no ip route-cache
CiscoRtr(config-if)# interface ethernet 1
CiscoRtr(config-if)# no ip route-cache
CiscoRtr(config-if)# end
CiscoRtr#
08/26/13

7.Create an access list that matches only the traffic that you want to capture. In this example, we are
using access list 101 to match all DHCP traffic. The number 101 should be replaced with an available
IP access list on your router.
CiscoRtr#configure terminal
CiscoRtr(config)# access-list 101 permit udp any any eq bootpc
CiscoRtr(config)# access-list 101 permit udp any any eq bootps
CiscoRtr(config)# access-list 101 permit udp any eq bootpc any
CiscoRtr(config)# access-list 101 permit udp any eq bootps any
CiscoRtr#
8.Double-check that the access list exists and is correct. (A nonexistent or incorrect access list can lock
up your router.)
CiscoRtr# show ip access-lists
Extended IP access list 101
permit udp any any eq bootpc
permit udp any any eq bootps
permit udp any eq bootpc any
permit udp any eq bootps any
08/26/13

9.Start packet debugging with the access list. (Omitting the access list can lock up your router.)
CiscoRtr# debug ip packet 101 detail
10.Stop debugging.
CiscoRtr# undebug all
11. View results in the log.
CiscoRtr# show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 16 messages logged
Trap logging: level informational, 0 message lines logged
Log Buffer (4096 bytes):
*Mar 16 18:00:10.485: IP: s=0.0.0.0 (Ethernet0), d=255.255.255.255, len 328, rcvd 2
*Mar 16 18:00:10.485: UDP src=68, dst=67
*Mar 16 18:00:10.485: IP: s=10.1.1.1 (local), d=10.1.2.2 (Ethernet1), len 328, sending
*Mar 16 18:00:10.485: UDP src=67, dst=67
*Mar 16 18:00:10.492: IP: s=10.1.2.2 (Ethernet1), d=10.1.1.1, len 328, rcvd 4
 *Mar 16 18:00:10.492: UDP src=67, dst=67
 *Mar 16 18:00:10.492: IP: s=10.1.1.1 (local), d=10.1.1.10 (Ethernet0), len 328, sending
 *Mar 16 18:00:10.492: UDP src=67, dst=68
08/26/13

General IP Troubleshooting Suggestions
the process of troubleshooting TCP/IP connectivity issues with the assumption that you will have access
to the client (or source) and may not have access to the server (or destination). If the problem is
determined to be a server issue, you contact the server administrator. If you are the server
administrator, you can apply the troubleshooting process in reverse (server to client) to further
troubleshoot connectivity issues. This chapter will not address the specifics of troubleshooting
server-side IP services; for this, consult the manual or web page for the software or service running
on the server.
Because TCP/IP does not store path information in its packets, it is possible for a packet to have a
working path from the source to the destination (or vice versa), but not to have a working path in the
opposite direction. For this reason, it may be necessary to perform all troubleshooting steps in both
directions along an IP path to determine the cause of a connectivity problem.
Narrowing Down the Problem Domain
To efficiently troubleshoot a TCP/IP connectivity problem, it is necessary to identify a single pair of
source and destination devices that are exhibiting the connectivity problem. When you've selected
the two devices, test to make sure that the problem is actually occurring between these two devices.
Possible problems include these:
•Physical layer issue somewhere along the path
•First-hop Layer 3 connectivity issue, local LAN segment
•Layer 3 IP connectivity issue somewhere along the packet's path
•Name resolution issue
08/26/13

Where to start:
1. Try to ping from the source to destination device by IP address. If the ping fails, verify that you are
using the correct address, and try the ping again. If the ping still fails, go to the next section,
"Troubleshooting Local Connectivity Problems." Otherwise, proceed to Step 2.
2. Try to ping from the source to the destination device by name. If the ping fails, verify that the name is
correctly spelled and that it refers to the destination device, and then try the ping again. If the ping
still fails, go to the section "Troubleshooting Domain Name Server Problems," later in this chapter.
Otherwise, proceed to Step 3.
3. If you can ping the destination by both name and address, it appears that the problem is an upper-
layer problem
Troubleshooting Local Connectivity Problems
Going through the methodology in this chapter with help determine and resolve problems moving
packets on the local LAN segment or to the next-hop router.
•Configuration problem
•DHCP or BOOTP issue
•Physical layer issue
•Duplicate IP address
08/26/13

Check for Configuration Problems
To begin troubleshooting, display and examine the IP configuration of the source device. The method to
determine this information varies greatly from platform to platform. If you are unsure of how to
display this information, consult the manual for the device or operating system. Refer to the
following examples:
On a Cisco router, use show ip interface and show running-config.
Check for Local Connectivity
If the destination is on the same subnet as the source, try pinging the destination by IP address. If the
destination is on a different subnet, then try pinging the default gateway or appropriate next hop
obtained from the routing table. If the ping fails, double-check the configuration of the next-hop
router to see if the subnet and mask match the source's configuration.
If the configuration is correct, check that the source or next-hop router is capable of pinging any other
device on the local LAN segment. If you cannot ping the next-hop address, and if the next-hop
address is an HSRP virtual address, try pinging one of the next-hop router's actual IP addresses. If the
actual address works but the virtual address does not, you may be experiencing an HSRP issue.
Failure to communicate with some or all devices on the LAN segment could indicate a physical
connectivity problem, a switch or bridge misconfiguration, or a duplicate IP address.
08/26/13

Ruling Out Duplicate IP Addresses
To rule out a duplicate IP address, you can disconnect the suspect device from the LAN or shut down the
suspect interface and then try pinging the device from another device on that same LAN segment. If
the ping is successful, then there is another device on that LAN segment using the IP address. You
will be able to determine the MAC address of the conflicting device by looking at the ARP table on
the device that issued the ping.
If at this point you still do not have local connectivity for either the source or the next-hop router,
proceed to the next section.
Troubleshooting Physical Connectivity Problems
Even though it may seem logical to first troubleshoot at the physical layer, problems can generally be
found more quickly by first troubleshooting at Layer 3 and then working backward when a physical
problem is found or suspected.
•Configuration is incorrect.
•Cable is faulty or improperly connected.
•Wiring closet cross-connect is faulty or improperly connected.
•Hardware (interface or port) is faulty.
•Interface has too much traffic.
08/26/13

Rule Out a Configuration Problem
Check to make sure that all cables are connected to the appropriate ports. Make sure that all cross-
connects are properly patched to the correct location using the appropriate cable and method. Verify
that all switch or hub ports are set in the correct VLAN or collision domain and have appropriate
options set for spanning tree and other considerations.
Check Cable Connections
Verify that the proper cable is being used. If this is a direct connection between two end systems (for
example, a PC and a router) or between two switches, a special crossover cable may be required.
Verify that the cable from the source interface is properly connected and is in good condition. If you
doubt that the connection is good, reseat the cable and ensure that the connection is secure. Try
replacing the cable with a known working cable. If this cable connects to a wall jack, use a cable
tester to ensure that the jack is properly wired. Also check any transceiver in use to ensure that it is
the correct type, is properly connected, and is properly configured. If replacing the cable does not
resolve the problem, try replacing the transceiver if one is being used.
Check the Configuration
Verify that the interface on the device is configured properly and is not shut down. If the device is
connected to a hub or switch, verify that the port on the hub or switch is configured properly and is
not shut down. Check both speed and duplex.
08/26/13

Check the Network Interface
Most interfaces or NICs will have indicator lights that show whether there is a valid connection; often
this light is called the link light. The interface may also have lights to indicate whether traffic is being
sent (TX) or received (RX). If the interface has indicator lights that do not show a valid connection,
power off the device and reseat the interface card.
Troubleshooting IP Connectivity and Routing Problems
When troubleshooting IP connectivity problems across large networks, it always helps to have a network
diagram handy so that you can understand the path that the traffic should take and compare it to the
path that it is actually taking.
When IP packets are routed across a network, there is the potential for problems at every hop between
the source and the destination, so test connectivity at each hop to determine where it is broken is the
logical troubleshooting methodology.
The following could be wrong:
•A router may not have a route to the source or destination.
•The network might have a routing loop or other routing protocol-related problem.
•A physical connectivity problem might have occurred.
•A resource problem on one router might be prohibiting proper router operation. This could possibly be
caused by lack of memory, lack of buffers, or lack of CPU.
•A configuration problem might have occurred on a router.
•A software problem might have occurred on a router.
•A packet filter or firewall might be preventing traffic from passing for an IP address or protocol.
•An MTU mismatch problem might have occurred
08/26/13

Isolating IP Routing Problems Related to hosts
The troubleshooting process outlined in this chapter separates the troubleshooting steps—one part for
the hosts, and one part for the routers. Essentially, for any problem in which two hosts cannot
communicate, the first parissues that might impact each host’s ability to send packets to and from its
respective default gateway. The second part isolates problems related to how routers forward
packets.
The following list outlines the troubleshooting steps focused on testing the host’s
connectivity to the first router:
Step 1 Check the host’s ability to send packets inside its own subnet. Either ping the
host’s default gateway IP address from the host, or ping the host’s IP address from
the default gateway. If the ping fails, do the following:
a. Ensure that the router’s interface used at the default gateway is in an “up and up” state.
b. Check the source host’s IP address and mask setting as compared to the router’s interface used as the
default gateway. Ensure that both agree as to the subnet number and mask, and therefore agree to
the range of valid addresses in the subnet.
c. If the router uses VLAN trunking, solve any trunk configuration issues, ensuring that the router is
configured to support the same VLAN in which the host resides.
d. If the other steps do not lead to a solution, investigate Layer 1/2 problems with the LAN.
08/26/13

Step 2 Verify the default gateway setting on the host by pinging one of the default router’s other
interface IP addresses. Or, from the default router, use an extended ping of the host’s IP address with
a source address from another of the router’s interfaces.
Isolating IP Routing Problems Related to Routers
When the host problem isolation process is complete, and the pings all work, on both the sending and
receiving hosts, any remaining IP routing issues should be between the ﬁrst and last router in both
the forward and reverse route between the two hosts. The following list picks up the troubleshooting
process with the source host’s default gateway/router, relying on the traceroute command on the
router. (Note that the host’s equivalent command, such as tracert on Microsoft operating systems,
can also be used.)
Step 3 Test connectivity to the destination host by using the extended traceroute command on the host’s
default gateway, using the router’s interface attached to the source host for the source IP address of
the packets. If the command successfully completes:
a. No routing problems exist in the forward route or reverse route
directions.
b. If the end-user trafﬁc still does not work (even though the traceroute
worked), troubleshoot any ACLs on each interface on each router in
the route, in both directions.
08/26/13

Step 4 If the traceroute command in Step 3 does not complete, test the forward
route as follows:
a. telnetto the last traced router (the last router listed in the traceroute
command).
b. Find that router’s route that matches the destination IP address that was used in the original
traceroute command (show ip route, show ip route ip-address).
c. If no matching route is found, investigate why the expected route is missing. Typically it’s either a
routing protocol issue or a static route misconfiguration. It could also be related to a missing
connected route.
d. If a matching route is found, and the route is a default route, confirm that it will be used based on the
setting for the ip classless/no ip classless commands.
e. If a matching route is found, ping the next-hop IP address listed in the route. Or, if the route is a
connected route, ping the true destination IP address.• If the ping fails, investigate Layer 2 problems
between this router and the IP address that was pinged, and investigate possible ACL problems.
• If the ping works, investigate ACL issues.
f. If a matching route is found, and no other problems are found, confirm that the route is not errantly
pointing in the wrong direction.
Step 5 If Step 4 does not identify a problem in the forward route, test the reverse route:
a. If the forward route on the last traced router refers to another router as the next-hop router, repeat
the substeps of Step 3 from that nexthop router. Analyze the reverse route—the route to reach the
source
IP address used by the failed traceroute command.
b. If the forward route on the last traced router refers to a connected subnet, check the destination host’s
IP settings. In particular, confirm the settings for the IP address, mask, and default gateway.
08/26/13

08/26/13
Common Host Problem Symptoms and Typical Reasons
When troubleshooting networking problems in real life, it’s helpful to get used to thinking about the symptoms, because that’s
where the problem isolation process typically begins.
However, for the exams, most host communication problems are caused by just a handful
of issues:
Step 1 Check all hosts and routers that should be in the same subnet to ensure that they all use the same mask and that their
addresses are indeed all in the same subnet.
Step 2 Compare each host’s default gateway setting with the router’s conﬁguration to ensure that it is the right IP address.
Step 3 If the ﬁrst two items are correct, next look at Layer 1/2 issues

LAN Switch IP Support
Ethernet switches do not need to know anything about Layer 3 to perform their basic Layer 2 function of
forwarding Ethernet frames. However, to support several important features, such as the ability to
telnet and SSH to the switch to troubleshoot problems, LAN switches need an IP address.Switches
act like hosts when it comes to IP configuration. As compared to a PC, a Cisco switch does not use a
NIC. Instead, it uses an internal virtual interface associated with VLAN 1 that essentially gives the
switch itself an interface in VLAN 1. Then, the same kinds of items that can be configured on a host
for IP can be configured on this VLAN interface: IP address, mask, and default gateway. DNS server
IP addresses can also be configured.
08/26/13
Switch Static IP Address Configuration

Figure below shows the output of the show ip route command. The ﬁgure numbers various parts of the
command output for easier reference, with Table After that describing the output noted by each
number.
08/26/13

VLSM Troubleshooting Summary
The following list summarizes the key troubleshooting points to consider when you’re troubleshooting
potential VLSM problems on the exams:
■ Pay close attention to whether the design really uses VLSM. If it does, note whether a
classless routing protocol is used.
■ Be aware that overlapping subnets can indeed be conﬁgured.
■ The outward problem symptoms may be that some hosts in a subnet work well, but others cannot
send packets outside the local subnet.
■ Use the traceroute command to look for routes that direct packets to the wrong part of the network.
This could be a result of the overlapped subnets.
■ On the exams, you might see a question you think is related to VLSM and IP addresses. In that case,
the best plan of attack may well be to analyze the math for each subnet and ensure that no overlaps
exist, rather than troubleshooting using ping and traceroute
08/26/13

Access List Troubleshooting Tips
Troubleshooting problems that are impacted by ACLs may well be one of the most difficult tasks for real
networking jobs. One of the major difficulties is that the traditional troubleshooting tools such as
ping and traceroute do not send packets that look like the packets matched by the variety of fields in
extended ACLs. So, although a pingmay work, the end-user host may not be able to get to the right
application, or vice versa.This section summarizes some tips for attacking ACL-related problems in
real life and on the exams:
Step 1 Determine on which interfaces ACLs are enabled, and in which direction (show
running-config, show ip interfaces).
Step 2 Determine which ACL statements are matched by test packets (show access-lists, show ip access-
lists).
Step 3 Analyze the ACLs to predict which packets should match the ACL, focusing on the following
points:
a. Remember that the ACL uses first-match logic.
b. Consider using the (possibly) faster math which converts ACL address/wildcard mask pairs into
address/subnet mask pairs that allow the use of the same math as subnetting.
c. Note the direction of the packet in relation to the server (going to the server, coming from the server).
Make sure that the packets have particular values as either the source IP address and port, or as the
destination IP address and port, when processed by the ACL enabled for a particular direction (in or
out).
d. Remember that the tcp and udp keywords must be used if the command needs to check the port
numbers.
e. Note that ICMP packets do not use UDP or TCP. ICMP is considered to be another protocol matchable
with the icmp keyword (instead of ip, tcp, and udp).
f. Instead of using the implicit deny any at the end of each ACL, use an explicit configuration command
to deny all traffic at the end of the ACL so that the showcommand counters increment when that
08/26/13

Troubleshooting IPv6 Network
It is difficult to identify all the possible issues in a full protocol stack such as IPv6. Administrators of IPv6
networks usually have some familiarity with the issues discussed here, especially in specific areas such as
stateless auto configuration or routing protocols such as OSPF. Examining IPv6 issues reveals that there
are many common configuration mistakes. An example for this is a misconfigured auto configuration
router that is not advertising network information to hosts. Until a problem like this is recognized
and corrected, IPv6 hosts cannot establish full connectivity as they lack global unicast addresses.
Other typical problem areas are related to IPv6 routing protocols. There are many similarities between
IPv6 routing problems and their IPv4 counterparts. Examples of IPv6 routing problems include
suboptimal routing due to improper summarization and parameter mismatches on protocols such as
OSPF that negotiate parameters.
For tunnel scenarios, because of the great variety of methods, you might find several instances in which
other components such as routing protocols need to change when the specific migration or tunneling
method changes. For example, when using 6to4 tunnels, not all interior gateway protocols (IGPs) will
function properly, because when multicast addresses are used to establish adjacencies, those
addresses are not properly mapped to a tunnel destination.
08/26/13

Identifying the IPv6 issues and failure conditions is not always an easy task, given the complexity of the
protocol and especially considering the lack of experienced network practitioners who have used it. The
good news is that several Cisco IOS tools and commands can help, including the following:
• debug ipv6 routing: Use this command to display debugging messages for IPv6 routing table
updates and route cache updates. This command displays messages whenever the routing table changes.
• debug ipv6 nd: Use this command to display debugging messages for IPv6 Internet Control
Message Protocol (ICMP) ND transactions. During troubleshooting, this command can help determine
whether the router is sending or receiving IPv6 ICMP ND messages.
• debug ipv6 packet: Use this command to display debugging messages for IPv6 packets. The
debugging information includes packets received, generated, and forwarded. Note that fast-switched
packets do not generate messages.
• show ipv6 interface: Use this command to display the usability status of interfaces configured for
IPv6 or to validate the IPv6 status of an interface and its configured addresses. If the interface’s
hardware is usable, the interface is marked as up. If the interface can provide two-way
communication for IPv6, the line protocol is marked as up.
• show ipv6 routers: This is an IPv6-specific command (does not have an IPv4 counterpart) you can use
to display IPv6 router advertisement (RA) information received from onlink routers.
• show ipv6 route: This command displays the contents of the IPv6 routing table.
show ipv6 protocols: This command displays the parameters and current state of the active IPv6
routing protocol processes. The information displayed by this command proves useful in
troubleshooting routing operations
08/26/13

In addition to the commands, an effective troubleshooting method provides a comprehensive end-to-
end
approach to identifying symptoms and isolating problems. For example, consider the output of the
debug ipv6 nd command, and how helpful it can be in identifying neighbor discovery, duplicate
addresses, autoconfiguration, and other conditions. The output of this command is critical not only
in understanding the ND process and the role of ICMPv6, but also for identifying and isolating IPv6
failure conditions
CCNA Questions On IPV6:
Well in CCNA exam they don't want you to know in and out about IPV6.
All they want to know is about how its works, its addressing and so on.
So to give you an idea as what's the questions like that come in CCNA exam on IPV6 i am putting some
questions as well as the answer for you. Hope it ease out you all a bit!!!
Question A- 1. Which of the following is the most likely organization from which an
enterprise could obtain an administrative assignment of a block of IPv6 global unicast IP addresses?
a. An ISP
b. ICANN
c. An RIR
d. Global unicast addresses are not administratively assigned by an outside organisation.
Answer: A. One method for IPv6 global unicast address assignment is that ICANN (Internet
Corporation for Assigned Network Numbers) allocates large address blocks to RIRs (Regional Internet
Registry), RIRs assign smaller address blocks to ISPs (Internet Service Provider), and ISPs assign even
smaller address blocks to their customers.
08/26/13

Question A- 2. Which of the following is the shortest valid abbreviation for
FE80:0000:0000:0100:0000:0000:0000:0123?
a. FE80::100::123
b. FE8::1::123
c. FE80::100:0:0:0:123:4567
d. FE80:0:0:100::123
Answer D. Inside a quartet, any leading 0s can be omitted, and one sequence of 1 or more quartets of
all 0s can be replaced with double colons (::). The correct answer replaces the longer 3-quartet
sequence of 0s with ::.
Question A- 3 . Which of the following answers lists a multicast IPv6 address?
a. 2000::1:1234:5678:9ABC
b. FD80::1:1234:5678:9ABC
c. FE80::1:1234:5678:9ABC
d. FF80::1:1234:5678:9ABC
Answer D.
Global unicast addresses begin with 2000::/3, meaning that the first 3 bits match the value in hex
2000.
Similarly, unique local addresses match FD00::/8, and link local addresses match FE80::/10 (values
that begin with FE8, FE9, FEA, and FED hex).
Multicast IPv6 addresses begin with FF00::/8, meaning that the first 2 hex digits are F.
08/26/13

Question A- 4. Which of the following answers list either a protocol or function that can be used by
a host to dynamically learn its own IPv6 address?
a. Stateful DHCP
b. Stateless DHCP
c. Stateless autoconfiguration
d. Neighbor Discovery Protocol
Answer: A and C. IPv6 supports stateful DHCP, which works similarly to IPv4’s DHCP protocol to
dynamically assign the entire IP address. Stateless autoconfiguration also allows the assignment by
finding the prefix from some nearby router and calculating the interface ID using the EUI-64 format.
Question A- 5. Which of the following help allow an IPv6 host to learn the IP address of a default
gateway on its subnet?
a. Stateful DHCP
b. Stateless RS
c. Stateless autoconfiguration
d. Neighbor Discovery Protocol
Answer A and D. Stateless autoconfiguration only helps a host learn and form its own IP address,
but it does not help the host learn a default gateway. Stateless RS is not a valid term or feature.
Neighbor Discovery Protocol (NDP) is used for several purposes, including the same purpose as ARP
in IPv4, and for learning configuration parameters like a default gateway IP address
08/26/13

Question A- 6. Which of the following are routing protocols that support IPv6?
a. RIPng
b. RIP-2
c. OSPFv2
d. OSPFv3
e. OSPFv4
Answer A and D. OSPFv3, RIPng, EIGRP for IPv6, and MP-BGP4 all support IPv6. (Memory Hint:
RIPng could also be regarded as RIP version 3!)
Question A- 7. In the following configuration, this router’s Fa0/0 interface has a MAC address of
4444.4444.4444. Which of the following IPv6 addresses will the interface use?
ipv6 unicast-routing
ipv6 router rip tag1
interface FastEthernet0/0
ipv6 address 3456::1/64
a. 3456::C444:44FF:FE44:4444
b. 3456::4444:44FF:FE44:4444
c. 3456::1
d. FE80::1
e. FE80::6444:44FF:FE44:4444
f. FE80::4444:4444:4444
Answer C and E. The configuration explicitly assigns the 3456::1 IP address. The interface also forms
the EUI-64 interface ID (6444:44FF:FE44:4444), adding it to FE80::/64, to form the link local IP
address.
08/26/13

Lessons Learned:
*Ipv4 troubleshooting tools and commands.
*Ipv6 troubleshooting tips.
*Some sample questions on IPV6
08/26/13

Troubleshooting basic networks

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Troubleshooting basic networks (20)

More from Arnold Derrick Kinney (10)

Recently uploaded (20)

Troubleshooting basic networks