Troubleshooting basic networks

www.professordkinney.com

04/13/23Instructional Design-Computer Networking - Bridges Educational Group

Troubleshooting Basic Connectivity


Troubleshooting Basic ConnectivityLessons Summary:

Troubleshooting IPv4 Network Troubleshooting IPv6 Network


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.



pingThe 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).



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.



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



tracerouteThe 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.



Cisco Tracerourte:CiscoRtr1>traceroute 10.3.1.6

Type escape sequence to abort. Tracing the route to 10.3.1.6

1 CiscoRtr2 (10.1.1.2) 0 msec CiscoRtr3 (10.1.1.3) 0 msec CiscoRtr4 (10.1.1.4) 4 msec 2 CiscoRtr5 (10.2.1.6) 4 msec 4 msec 0 msec 3 CiscoRtr6 (10.3.1.6) 4 msec 4 msec 4 msecIf 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

Type escape sequence to abort. Tracing the route to 10.3.1.6 1 CiscoRtr2 (10.1.1.2) 0 msec CiscoRtr3 (10.1.1.3) 0 msec CiscoRtr4 (10.1.1.4) 4 msec 2 CiscoRtr5 (10.2.1.6) 4 msec 4 msec 0 msec 3 * * * 4 * * *



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# configure terminal CiscoRtr(config)# logging buffered CiscoRtr(config)# end CiscoRtr# 4. Turn on logging timestamps with millisecond output.CiscoRtr# configure terminal CiscoRtr(config)# service timestamps log datetime msec CiscoRtr(config)# end CiscoRtr#



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#



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(config)# end 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



9.Start packet debugging with the access list. (Omitting the access list can lock up your router.)

CiscoRtr# debug ip packet 101 detail10.Stop debugging.CiscoRtr# undebug all11. 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



General IP Troubleshooting Suggestionsthe 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 DomainTo 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



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 ProblemsGoing 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.Possible problems include these:•Configuration problem•DHCP or BOOTP issue•Physical layer issue•Duplicate IP address



Check for Configuration ProblemsTo 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 ConnectivityIf 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.



Ruling Out Duplicate IP AddressesTo 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 ProblemsEven 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.

Possible problems include these:•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.



Rule Out a Configuration ProblemCheck 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 ConnectionsVerify 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 ConfigurationVerify 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.



Check the Network InterfaceMost 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 ProblemsWhen 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



Isolating IP Routing Problems Related to hostsThe 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.



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 RoutersWhen 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 first 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 traffic still does not work (even though the tracerouteworked), troubleshoot any ACLs on each interface on each router in the route, in both directions.



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 traceroutecommand).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.

04/13/23

Instructional Design-Computer Networking - Bridges Educational Group



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 configuration to ensure that it is the right IP address.

Step 3 If the first two items are correct, next look at Layer 1/2 issues


LAN Switch IP SupportEthernet 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.


Switch Static IP Address Configuration


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



VLSM Troubleshooting SummaryThe 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 configured.■ 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



Access List Troubleshooting TipsTroubleshooting 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 action is taken.



Troubleshooting IPv6 NetworkIt is difficult to identify all the possible issues in a full protocol stack such as IPv6.

Administrators of IPv6networks usually have some familiarity with the issues discussed here, especially in

specific areas such asstateless 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.



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 tableupdates 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 ControlMessage Protocol (ICMP) ND transactions. During troubleshooting, this command can help

determinewhether 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



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 ISPb. ICANNc. 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.



Question A- 2. Which of the following is the shortest valid abbreviation for FE80:0000:0000:0100:0000:0000:0000:0123?a. FE80::100::123b. FE8::1::123c. FE80::100:0:0:0:123:4567d. 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:9ABCb. FD80::1:1234:5678:9ABCc. FE80::1:1234:5678:9ABCd. 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.



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 DHCPb. Stateless DHCPc. Stateless autoconfigurationd. 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 DHCPb. Stateless RSc. Stateless autoconfigurationd. 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



Question A- 6. Which of the following are routing protocols that support IPv6?a. RIPngb. RIP-2c. OSPFv2d. OSPFv3e. OSPFv4Answer 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-routingipv6 router rip tag1interface FastEthernet0/0ipv6 address 3456::1/64

a. 3456::C444:44FF:FE44:4444b. 3456::4444:44FF:FE44:4444c. 3456::1d. FE80::1e. FE80::6444:44FF:FE44:4444f. FE80::4444:4444:4444Answer 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.

04/13/23

Instructional Design-Computer Networking - Bridges Educational Group


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



Troubleshooting basic networks

Technology

Transcript of Troubleshooting basic networks